After internet connectivity is broken, qbt binded network interface stopped, qbt fails to resume connectivity

[slrslr]

qBittorrent & operating system versions

4.6.5 AppImage
Qt: 6.6.3
Libtorrent: 2.0.11.0
Boost: 1.85.0
OpenSSL: 1.1.1w
zlib: 1.2.11
OS: Debian 11 (oldstable) with KDE

What is the problem?

Qbt is unable to resume connectivity after its defined network interface where it is listening, is shutdown and then back up.

Steps to reproduce

No response

Additional context

Computer is connected to a Wireguard VPN server. Qbt is set (in Advanced configuration) to listen on Wireguard network interface wg0 and use all addresses).

Wireguard server starts refusing connection of a client. Client stops wireguard service so the wg0 interface cease to exist is no longer accessible by the qbt for around 15 minutes.

Wireguard VPN server starts accepting connections. Client restarts wireguard service: wg-quick down wg0;wg-quick up wg0;

I find qbt listing less than 10 DHT nodes in its status bar and zero connection speeds.

After I go to qbt settings, Advanced tab, switch interface from wg0 to other. Click OK. Switch back to wg0, click OK. Connectivity starts going.

Can you please check how qbt is handling interface "disappearing" for longer time and automatic retries?

Log(s) & preferences file(s)

No response

[luzpaz]

@slrslr can you please confirm on 4.6.6 ?

[stalkerok]

Confirmed, there is an issue.

After the screenshot, I disconnected WireGuard.

After reconnected WireGuard, the client could not find the external address.

Second test. I reconnected after 2 minutes, the client sees the external address, I disconnect, wait for more, after 30 minutes it does not see.

[Biceeeeepss]

Happened for me too on 4.6.6.

[PaulCoddington]

Possible related problem on Windows 11?:

• qBittorrent loses ability to listen on designated port when PC wakes from sleep (observed with v4.5.5–4.5.7).

• qBittorrent loses ability to listen on designated port up to several times per hour (observed with v4.5.6, v4.6.7).

In both cases, qBittorrent must be closed and re-launched to resolve the problem (Windows 11). Everything seems to work well until the connectivity icon unexpectedly turns red and everything stalls.

In the second case, someone must now be seated at the desk watching the connectivity icon at all times. It is no longer possible to run qBittorrent unattended.

[Rand-Random]

Faced the same issue, noticed that this issue is reported a couple of times already (most likely didn't find all related/identical issues)

• Add windows command line option to gracefully shutdown qbittorrent. #9466
• qbittorrent-nox add multiple interfaces incase 1 goes down #11290
• qBittorrent not using the interface ip the routing decides to use. #13094
• qBittorrent doesn't retry to bind to interface #13154
• Ipv6 auto bind to temporary address #16815
• Kill switch if IP address changes #16947
• qBittorrent doesn't seem to use the specified network interface for all traffic. This causes it to get stuck in "offline" status if a firewall rule force it through a VPN interface #18025
• If IP address changes I'm forced to restart qBT #18488
• Rebind IPv6 when it changes (has workaround) #18785
• Automatic renew connection when connect with VPN #18930
• permanent connection loss after network reconnection #19580
• qb status is offline on startup with protonvpn #20490
• qbittorrent will not feedback the proxy IP to the tracker when the proxy is enabled #20767
• qbittorrent will not reannounce proxy IP to the tracker when the proxy is turned on #20777
• Failed to report the latest IPv6 address to Trackers after ip changes. #21277
• After internet connectivity is broken, qbt binded network interface stopped, qbt fails to resume connectivity #21288 (we are here)

[101Dude]

I am having similar issues on macOS. (And a bit jealous at what options are available to the OP! You can choose "wireguard"?)

I am adding it here for now instead of creating another issue.

If I use the initial VPN Gateway address 10.190.18.2 at some point when that expires (still don't know why the gateway address expires) and becomes 10.190.18.3 qbittorrent stays on 10.190.18.2. That is as expected.... except when I select the new Gateway address qbittorrent won't accept it. The world icon stays red. I have to exit qbittorrent and restart.

So I move to the next best option using IPv4 thinking that will be more reliable:

The IPv4 option doesn't work as expected when my VPN Gateway address changes either. It is supposed to work with any IPv4 address but I get a red world icon and have to restart qbittorrent.

So now I keep it on All addresses. Which is not ideal because I have noticed.

When tracking all qbittorrent connections using nettop I see a bunch of port :443 connections to DNS providers over my en0 interface even though I have selected the utun interface in qbittorrent created by my VPN client. They are Google and Cloudflare IP addresses and it happens when I first start up qbittorrent.

[Cloweeee]

This seems to be a fairly common issue, and it's still present in 5.0.2.
It'd be great if this could get more attention from anyone with more technical knowledge.

[Cloweeee]

This seems to be the main issue thread on the libtorrent repo. arvidn/libtorrent#4412

[Sam14m]

I'm experiencing this
qBit 5.0.3
Qt: 6.7.3
Libtorrent: 1.2.19.0
Boost: 1.86.0
OpenSSL: 3.4.0
zlib: 1.3.1
win11
if the wireguard VPN that is bound to qBit disconnects at any time, or doesn't exist when qBit starts, qBit goes offline and wont reconnect. if there's any further info I can provide to help get this resolved please let me know and I'll do my best to provide it