Qbittorrent: 4.2.2 download/upload stalled for all torrents using only TCP with VPN (µTP works)

[gothicserpent]

qBittorrent version and Operating System

4.2.2 / Windows 10 Enterprise 10.0.18362 Build 18362

What is the problem

4.2.1 download/upload working for me, i tried to update to 4.2.2. after i updated, the download/upload stopped working (stalled).
For my network settings (using a VPN), I clicked on Connection -> Enabled Protocol: "TCP" which does not work.
Tried to change the port in settings of 4.2.2, still didn't work.
Connection -> Enabled Protocol: "µTP" or "TCP and µTP" _DOES work_ (implying µTP works but not TCP because when "TCP and µTP" is selected it chooses µTP).
After I downversioned back to 4.2.1 the dl/ul immediately started working again with TCP only.

What is the expected behavior

Expected download/upload to function

Steps to reproduce

download / install qbittorrent 4.2.2 version
download mullvad vpn from mullvad.net, sign up for trial (~$5.80) (_you might be able to use another VPN such as NordVPN, ExpressVPN or ProtonVPN as well; the steps below are mullvad specific_)

Open the Windows Control Panel.
Click on Network and Sharing Center.
Click on Change adapter settings.
On the adapter that contains "TAP-Windows Adapter V9" in its name, right click on it, select Rename, and enter Mullvad.
Proceed with the steps below

Open qBittorrent.
Click on Tools.
Click on Options.
Click on Advanced.
Change Network Interface to Mullvad if you use OpenVPN or wg-mullvad if you use WireGuard. (_If you use another VPN, select that interface here._)

Click on OK and restart qBittorrent.
Continue with the steps in the next section.

Click on Tools.
Click on Options.
Click on BitTorrent.
Check Enable anonymous mode.
Uncheck (disable) Enable DHT.
Uncheck (disable) Enable PeX.
Uncheck (disable) Enable Local peer discovery.

Click on Connection.
For Enabled Protocol, use the drop-down menu to select TCP.

Make sure internet connection is enabled and sending and receiving packets. Enable Mullvad VPN in the taskbar. Attempt to test download any .torrent or magnet torrent link with data, which would otherwise work on another client or in QBittorrent version 4.2.1. There is no upload or download activity on the network at this point.

At this point, you're at the configuration I had working with 4.2.1 and that does not work with 4.2.2.

Extra info(if any)

If anyone else has this issue or you can reproduce it I hope you can fix it. Love your program. Thanks!

IMAGE OF DL/UL WORKING IN 4.2.1 using a VPN with TCP network setting (tracker details and file details hidden to prevent leaking)

IMAGE OF DL/UL NOT WORKING IN 4.2.2 using a VPN with TCP network setting (tracker details and file details hidden to prevent leaking)

[AlienIdeology]

I'm having the same issue with v4.2.2 right now. None of my trackers are working (sometimes their status are "Updating", sometimes "Not contacted", and other times "Not working")
I've tried several torrent files and tracker links. All the same

[gothicserpent]

I'm having the same issue with v4.2.2 right now. None of my trackers are working (sometimes their status are "Updating", sometimes "Not contacted", and other times "Not working")
I've tried several torrent files and tracker links. All the same

@AlienIdeology glad to see i'm not the only one. you're using a VPN right? did you enable anonymous mode in bittorrent options?

[gothicserpent]

Wanted to provide an update.

When I set Options -> Connection -> Enabled Protocol: TCP and µTP instead of TCP like I had before:

the upload and download connection is working again:

Perhaps there's an issue with the way TCP is handled in 4.2.2 that is different from how TCP is handled in 4.2.1 for users with a VPN?

@AlienIdeology you might try setting Enabled Protocol: TCP and µTP to see if it works?

[AlienIdeology]

@gothicserpent yeah I'm using VPN.
I already have the protocol set to TCP and uTP. None of the trackers are working, sadly

[AlienIdeology]

oh i take it back, it is now working, but very slowly. (I didn't change anything, it fixed itself)

[gothicserpent]

oh i take it back, it is now working, but very slowly. (I didn't change anything, it fixed itself)

Cool - may have been an issue with the trackers you have. i was going to say that these are the only other settings I made:

and setting the network interface to my VPN in the advanced settings.

If anyone else has this issue I hope they report!

[ghost]

This is a libtorrent issue. Maybe @arvidn can better understand it.

[arvidn]

what version of libtorrent?
I'm a bit confused by the title. If TCP-only doesn't work, how can both TCP and uTP be working? Does it mean to say "TCP over VPN does not work, uTP over VPN works"?

[ghost]

1.2.5
I think he meant TCP only mode doesn’t work. Which implies that only uTP is working for VPN.
This might be related with https://github.com/arvidn/libtorrent/issues/4329

[gothicserpent]

Hi, yes I was able to get TCP working in 4.2.1 with my mullvad vpn, but when I tried 4.2.2 with VPN over TCP only, it did not have a connection (selected item highlighted in red does not work with a vpn):

It connected when i used the option "TCP and µTP". I believe the µTP connection was being utilized and TCP wasn't, so it was able to work over µTP only, in 4.2.2.

I am (assuming) maybe a change in the codebase was made that changed how TCP works with the VPN, such that it is no longer functional moving from 4.2.1 to 4.2.2. This is my speculation.

[Rootax]

1.2.5
I think he meant TCP only mode doesn’t work. Which implies that only uTP is working for VPN.
This might be related with arvidn/libtorrent#4329

If this is related, it's not a vpn issue, but a problem with selecting a specific interface.

[ghost]

@arvidn I just reproduced this issue with a VPN.

Selecting VPN interface breaks TCP connection. You get uTP connections instantly as soon as you switch to uTP only.

*Binding to any interface(default option) while using a VPN doesn't cause this issue.

Trackers & DHT are working fine.

Selecting specific interface without a VPN does NOT cause this issue.

Could this be a problem in the network selection code of qBT?

[rwasef1830]

I just saw this issue with qBittorrent 4.2.2 on Ubuntu 16.04 amd64 compiled with libtorrent 1.2.5. client_test is working. enum_if is still not seeing the gateway IPs. I will email you the results of those tools. @arvidn

I have TCP and uTP enabled, DHT, PEX, Local Peer discovery unchecked. Anonymous mode unchecked.

All torrents sit stalled and no trackers are contacted (all of them "Not Working").

EDIT: Recompiling qBittorrent with libtorrent-1_2_3 tag = zero issues.

[RedLion76]

Same here. I am running Ubuntu 19.10. with qBit 4.2.2.

There was an update of libtorrent rasterbar yesterday, from v1.2.3 to v.1.2.5.
SInce then, TCP works no more. TCP and µTP however works, but rather slow.

I can confirm rwasef1830s' post: Selecting "Any interface" from the dropdown menu seems to solve the issue.

I think libtorrent - rasterbar needs to be fixed.

Regards

RedLion

[gothicserpent]

SInce then, TCP works now more. TCP and µTP however works, but rather slow.
@RedLion76 you mean TCP works no more?

[RedLion76]

Yes. Sorry, typo.

[arvidn]

I cannot reproduce this. I need someone's help to understand whether there is some other configuration option that affects this. I'm testing current RC_1_2, which is pretty similar to libtorrent-1.2.5. At least I can't think of any changes that could have affected this.

This is what I've tried:

./client_test --enable_outgoing_utp=0 --enable_incoming_utp=0 -s .
./client_test --enable_outgoing_utp=0 --enable_incoming_utp=0 -s . --listen_interfaces=nordlynx:4325
./client_test --enable_outgoing_utp=0 --enable_incoming_utp=0 -s . --listen_interfaces=utun0:4325

That's testing without a VPN, with Private Internet Access (OpenVPN) and NordVPN's wireguard. In all cases I connect to peers over TCP and start downloading. Is there some other setting that could affect this?

[Aerozolic]

I have issues after updating to 4.2.2 as well.
One issue is that if I have a specific interface (tun) selected then I get red connection status icon. And even if I select "Any interface" then I still can't get qbittorrent back to being connectable (showing yellow icon). Canyouseeme.org shows "connection refused" but if I try Transmission with the same port then it shows that the port is open. Firewall exception for qbittorrent is added and I did codesign as well like I do after every qbittorrent update.
VPN connection was fine and is fine right now but there's definitely something wrong with qbittorrent.
Using macOS Catalina 10.15.4

[FranciscoPombal]

@arvidn

I cannot reproduce this. I need someone's help to understand whether there is some other configuration option that affects this. I'm testing current RC_1_2, which is pretty similar to libtorrent-1.2.5. At least I can't think of any changes that could have affected this.

This is what I've tried:

./client_test --enable_outgoing_utp=0 --enable_incoming_utp=0 -s .
./client_test --enable_outgoing_utp=0 --enable_incoming_utp=0 -s . --listen_interfaces=nordlynx:4325
./client_test --enable_outgoing_utp=0 --enable_incoming_utp=0 -s . --listen_interfaces=utun0:4325

That's testing without a VPN, with Private Internet Access (OpenVPN) and NordVPN's wireguard. In all cases I connect to peers over TCP and start downloading. Is there some other setting that could affect this?

It is possible the issue is on qBIttorrent's side - specifically, most likely something is broken with the way it binds to interfaces. Can you think of the way this could be done wrong such that it would result in this problem?

[gothicserpent]

Just wanted to add this in:

To get the issue on my end I'm setting the interface to my VPN (which is configured with OpenVPN. not wireguard) / ip address to bind to: ipv4.

@arvidn You might try using your NordVPN config with OpenVPN and not wireguard and see if that makes a difference in testing TCP fails. I found some guides here on the OpenVPN setup for NordVPN at the bottom of this web site : https://support.nordvpn.com/General-info/1047408082/What-is-OpenVPN.htm

Edit: Saw online that Private Internet Access is it's own VPN. if you set that up with OpenVPN it should match my setup (assuming you configured utun0 to use your PIA VPN which you did I would assume -- i saw that this was a generic adapter reference rather than a vpn reference but if you bound it properly it should work). I would maybe try with NordVPN / OpenVPN.

the only settings I can think of from https://www.libtorrent.org/reference-Settings.html is --mixed_mode_algorithm=prefer_tcp since it's peer_proportional by default, although i suppose your boolean settings --enable_outgoing_utp=0 --enable_incoming_utp=0 you made will always prevent utp regardless.

the only other changes in my config as I have it is in the Bittorrent -> Privacy settings for DHT / etc. (which i disabled) and anonymous mode which i turned on:

namely --max_pex_peers=0 --anonymous_mode=1 (I read that setting anonymous_mode to true will disable DHT and local peer discovery)

another thing i looked at was outgoing_interfaces, maybe look at if the default is correct.

[FranciscoPombal]

Just wanted to add this in:

To get the issue on my end I'm setting the interface to my VPN (which is configured with OpenVPN. not wiregaurd) / ip address to bind to: ipv4.

@arvidn You might try using your NordVPN config with OpenVPN and not wireguard and see if that makes a difference in testing TPC fails. I found some guides here on OpenVPN at the bottom of the page : https://support.nordvpn.com/General-info/1047408082/What-is-OpenVPN.htm . I hope this helps, I can't be of much more assistance because I have a win64 system and am using the QBittorrent windows 64 binary version.

What if you use All IPv6 addresses or All addresses as the address to bind to? Do you still get the issue?

[gothicserpent]

@FranciscoPombal I tried All addresses and TCP protocol and yes I still get this (no connection upload or download) - and the trackers have some errors here. The reason i switched to IPv4 earlier was to lower the rate of tracker error.

Edit: Also tried All IPv6 addresses, same result so far.

[ghost]

The issue occurs when you select the VPN interface to bind to. The IP address to bind to feature doesn't seem have any effect on this. It works fine when you select the VPN IP address to bind to but keep the network interface to all.

So basically when you're selecting the VPN interface qBt is failing to open up listen sockets for TCP. I don't believe this a problem on qBt end. Otherwise it would fail to open TCP sockets without a VPN as well. It probably has something to do with the changes that made through in libtorrent 1.2.4. Specially regarding VPNs/SOCK5 proxy/Multihoming improvements.

[arvidn]

@FranciscoPombal how do those settings translate to the libtorrent listen_interfaces setting?

The fact that they are presented as separate independent options look a bit suspicious to me. in libtorrent you can specify 1 or more (IP,port)-pairs and (interface,port)-pairs to listen on. i.e. if you specify an IP, the interface is implied (whichever interface the IP is configured of) or if you specify an interface, all IPs configured for that interface are used.

[arvidn]

(also, from libtorrent's point of view, there's no need to restart when changing the listen interface/IP)

[Aerozolic]

For me if I leave it to Any interface and just set the IP address to VPN IP then it still doesn't work. Shows Connection Status: Offline

[arvidn]

are there any configurations that do work with the VPN?

[ghost]

are there any configurations that _do_ work with the VPN?

All interface option works. Meaning listening on 0.0.0.0 probably.

[Aerozolic]

are there any configurations that _do_ work with the VPN?

All interface option works. Meaning listening on 0.0.0.0 probably.

For me selecting Any interface works as much as it's not showing offline but there's something wrong with ports because I get the "yellow icon" and DHT: Nodes continue to be 0 plus canyouseeme.org says that the specified port is refusing connections while the port is forwarded and is said to be open if I use some other bittorrent client.

[ghost]

are there any configurations that _do_ work with the VPN?

All interface option works. Meaning listening on 0.0.0.0 probably.

For me selecting Any interface works as much as it's not showing offline but there's something wrong with ports because I get the "yellow icon" and DHT: Nodes continue to be 0 plus canyouseeme.org says that the specified port is refusing connections while the port is forwarded and is said to be open if I use some other bittorrent client.

I know another guy who had same issue. His ports were forwarded but he wasn’t getting any sort of incoming connections and his canyouseeme was returing error as well. It got fixed after he downgraded to 4.2.1 (libtorrent 1.2.3). Probably the listen sockets are not being opened correctly.

[arvidn]

@Aerozolic does your VPN provider assign you a public IP address?
My impression is that it's common for VPN providers to not map ports to pass through incoming connections.

Can you make sure that the indications that you are connectable, while using the VPN, aren't trying to connect to you from your local internet connection? (i.e. not through the VPN). I'm suggesting that you not being connectable may be a sign of the VPN working as it should (and that you being connectible be a sign of the VPN being circumvented).

[Aerozolic]

@Aerozolic does your VPN provider assign you a public IP address?
My impression is that it's common for VPN providers to _not_ map ports to pass through incoming connections.

Can you make sure that the indications that you _are_ connectable, while using the VPN, aren't trying to connect to you from your local internet connection? (i.e. not through the VPN). I'm suggesting that you not being connectable may be a sign of the VPN working as it should (and that you being connectible be a sign of the VPN being circumvented).

Before the latest qbittorrent update everything was working fine so this can't be a configuration issue. I had tun interface selected in qbittorrent and the connection icon was green. Nothing has changed aside from the app update.
If it was a configuration issue then other apps would report that the port is closed as well. And I have selected "Send all traffic over VPN connection" in my OpenVPN client.
If I disable VPN then the connection icon turns green and DHT nodes start to increase.

Edit: Qbittorrent also shows the same thing for all trackers: "Not Working"

[arvidn]

Before the latest qbittorrent update everything was working fine so this can't be a configuration issue.

And you're confident it didn't just look fine but was circumventing the VPN, right?
I'm suggesting (not claiming, because I don't know) that the fact that it was "working" before may have been because of a bug, that has now been fixed.

@FranciscoPombal (or any other qbt developer), it would be helpful to know what the libtorrent listen_interfaces setting is set to.

[arvidn]

trackers not working when using a VPN sounds in line with the title of this ticket. I just wish I could reproduce it. Does anyone experience this on PrivateInternetAccess or NordVPN? (those are the ones I've been testing with), on linux.

[ghost]

@sledgehammer999

[Aerozolic]

Before the latest qbittorrent update everything was working fine so this can't be a configuration issue.

And you're confident it didn't just look fine but was circumventing the VPN, right?

I'm suggesting (not claiming, because I don't know) that the fact that it was "working" before may have been because of a bug, that has now been fixed.

@FranciscoPombal (or any other qbt developer), it would be helpful to know what the libtorrent listen_interfaces setting is set to.

Just tested it on my other computer that has the same VPN provider (Torguard) and forwarded ports, same torrent, same qbittorent configration but version 4.2.1. Connection icon is green, DHT nodes show more than 100 and trackers are working (not all ofcourse since it’s a torrent from public site).

[gothicserpent]

Just wanted to add: I have confirmed my mullvad VPN does issue a public IP which is different from my default IP. I tested this by downloading a magnet link from my mullvad vpn's web site which tests to see if my original IP is being leaked, and the site confirms it is not being leaked in either 4.2.1 or 4.2.2. here's the site i used for that from my vpn provider: https://am.i.mullvad.net/torrent (this is similar to using sites from the google result of torrent leak which lists sites that test if your torrent client is leaking your original ip)

the settings: --mixed_mode_algorithm=prefer_tcp , --max_pex_peers=0 --anonymous_mode=1, and outgoing_interfaces are all things that may have a role to play here. If it's possible to use NordVPN with OpenVPN as a test, this might help as a testing benchmark.

Finally, another series of users reported something similar at issue #12297 where they cannot use their VPN with 4.2.2

[Aerozolic]

I got some improvements. If I switched the OpenVPN protocol from UDP to TCP then DHT nodes started to increase and trackers changed from not working to working. But there's still an issue with connectivity. Canyouseeme now gives "Connection timed out" instead of connection refused.
Maybe this info helps, maybe not.

[FranciscoPombal]

@arvidn

@FranciscoPombal how do those settings translate to the libtorrent listen_interfaces setting?

The fact that they are presented as separate independent options look a bit suspicious to me. in libtorrent you can specify 1 or more (IP,port)-pairs and (interface,port)-pairs to listen on. i.e. if you specify an IP, the interface is implied (whichever interface the IP is configured of) or if you specify an interface, all IPs configured for that interface are used.

are there any configurations that _do_ work with the VPN?

@FranciscoPombal (or any other qbt developer), it would be helpful to know what the libtorrent listen_interfaces setting is set to.

I must say I am not too familiar with that code, there could be something wrong with it. @sledgehammer999 might be able to help you more with that right now, as he has worked on that code most recently.

[sledgehammer999]

(or any other qbt developer), it would be helpful to know what the libtorrent listen_interfaces setting is set to.

@arvidn The exact string is printed in the log.

@ everyone who has the problem. Report the log string for @arvidn to see. In english it is logged this way:

Trying to listen on: %1

where %1 is the string passed to listen_interfaces

[FranciscoPombal]

In addition:

• If on Windows, open CMD, run route print and post the output
• If on Linux post the output of ip route

[gothicserpent]

here is my output - https://pastebin.com/Fujhqbqd

[ghost]

trackers not working when using a VPN sounds in line with the title of this ticket. I just wish I could reproduce it. Does anyone experience this on PrivateInternetAccess or NordVPN? (those are the ones I've been testing with), on linux.

Trackers are working fine here. Just that we're not being able to connect with BT peers. uTP works. The title is appropriate.

I just tested with NordVPN as well and was able to reproduce the exact same issue. This is not a specific provider issue. All major VPNs are affected more or less. @arvidn

[Aerozolic]

In addition:

• If on Windows, open CMD, run route print and post the output

• If on Linux post the output of ip route

And on Mac? Same as Linux?

[FranciscoPombal]

@Aerozolic

And on Mac? Same as Linux?

I googled a bit and found on mac you should use netstat -nr instead.

[FranciscoPombal]

Note for @arvidn:
In qBittorrent's logs, the lines that read ... Successfully listening on IP: ... are basically the contents of a listen_succeeded_alert (endpoing.address(), sock_type and endpoint.port()).

Full detail here:
https://github.com/qbittorrent/qBittorrent/blob/82c23e67a47c79983a128338d338f055c9a054dc/src/base/bittorrent/session.cpp#L4698

[Aerozolic]

I feel super dumb right now because I was able to fix all my issues with one simple step - restarting my computer.
The error that I previously got was:
Failed to listen on IP: xx.xx.xx.xx, port: UDP/xxxxx. Reason: Address already in use.
So I contacted my VPN provider and they said that it’s not an issue with the VPN server and that the client’s IP address is in use by some other service.
Since I didn’t have any other ideas I just restarted my computer and qbittorrent started to work again. Connection status green while VPN interface set.

[ghost]

Just to add, it looks like the network interface selection is completely broken at the time.

If you bind to VPN interface and for some reason your VPN disconnects/crashes and has no killswitch then your IP will get leaked anyway because the interface somehow switches back to a working one even when the VPN interface is selected. qBt's interface selection option makes it look like it's not gonna use any other interface when there's no internet. But in reality it's not honouring that.

I think this thing requires a rework as such IP leaking can be potentially fatal unless user is using a killswitch.
@FranciscoPombal

[CeruleanSky]

@an0n666 I noticed that also and commented in a different issue. Where just like you, if the vpn drops or disconnects, even if you select a specific interface, the program shifts to listening to every interface. Since VPNs often give different intranet ip address per connection, the bind to ip address option isn't as useful and has to be set to "any ip address", so it can't really solve this.

Here is an image showing this where I disconnect the vpn to simulate a dropped connection/crash/disconnect with qbittorrent 4.2.2 built with qt 4.13.2:

IP leaking can be potentially fatal unless user is using a killswitch.

Killswitches for many vpn software run scripts using the "net" and related commands which will likely be slower than qbittorrent, leaving a window open as qbittorrent shifts adapters.

[FranciscoPombal]

Just to add, it looks like the network interface selection is completely broken at the time.

If you bind to VPN interface and for some reason your VPN disconnects/crashes and has no killswitch then your IP will get leaked anyway because the interface somehow switches back to a working one even when the VPN interface is selected. qBt's interface selection option makes it look like it's not gonna use any other interface when there's no internet. But in reality it's not honouring that.

I think this thing requires a rework as such IP leaking can be potentially fatal unless user is using a killswitch.
@FranciscoPombal

@an0n666
I generally agree, but just to be clear, I think the correct behavior is:
If a specific interface is selected and it stops being available at some point, qBittorrent should stop working until a working one is manually selected.

If this is not the case (i.e. "Any interface" is selected), qBIttorrent should use whatever interface it wants, but should strive to only use one interface at a time for everything.

@arvidn does libtorrent provide any way to detect whether an interface, while available, might not actually allow any connections? For example some kind of dht not working alert that allows deducing that the interface leads nowhere.

[CeruleanSky]

qBittorrent should stop working until a working one is manually selected.

Would it be too difficult to just let it keep that same interface, such as "Ethernet 2" which is a common one for VPNs on Windows, and just resume when it became available again, automatically?

[arvidn]

I can reproduce this issue if I also specify outgoing_interfaces=<VPN-interface>. (thanks @gothicserpent for pointing this out).

I see these errors in the log:

disconnecting (TCP) [sock_bind] [system]: Invalid argument

[arvidn]

@arvidn does libtorrent provide any way to detect whether an interface, while available, might not actually allow any connections? For example some kind of dht not working alert that allows deducing that the interface leads nowhere.

Not really. Would you like to indicate in the UI whether an interface is viable?

[FranciscoPombal]

@arvidn

Not really. Would you like to indicate in the UI whether an interface is viable?

If such a thing is possible, qBittorrent could use that information to auto-switch between interfaces when using "Any interface", right? I don't think there is the need to specifically indicate in the GUI though, it would just be something done transparently.

[ghost]

@FranciscoPombal currently qBt is not honouring listening on an unavailable/disconnected VPN interface. It auto switched to working interface but GUI is still indicating that VPN interface is being used/selected.

[FranciscoPombal]

@an0n666

@FranciscoPombal currently qBt is not honouring listening on an unavailable/disconnected VPN interface. It auto switched to working interface but GUI is still indicating that VPN interface is being used/selected.

Yes, I agree that should not happen when the VPN is specifically chosen as the listen interface.

[ghost]

I’m suspecting that the problem is in libtorrent. Probably when you pass an invalid interface it switches to a working one.

[arvidn]

could someone give this a try? https://github.com/arvidn/libtorrent/pull/4480

[FranciscoPombal]

could someone give this a try? arvidn/libtorrent#4480

No access to a setup where I can test this right now, but maybe @Kolcha @an0n666 @xavier2k6

[ghost]

could someone give this a try? arvidn/libtorrent#4480

No access to a setup where I can test this right now, but maybe @Kolcha @an0n666 @xavier2k6

Don’t have the build tools available to me ATM. If someone can provide a windows build I’d be happy to test.

[c0re100]

could someone give this a try? arvidn/libtorrent#4480

No access to a setup where I can test this right now, but maybe @Kolcha @an0n666 @xavier2k6

Don’t have the build tools available to me ATM. If someone can provide a windows build I’d be happy to test.

https://drive.google.com/open?id=1-7EGIlXhxX5EDsC78RO01E3lR87RqVfq
qbt master+arvidn/libtorrent#4480 here

[c0re100]

could someone give this a try? arvidn/libtorrent#4480

No access to a setup where I can test this right now, but maybe @Kolcha @an0n666 @xavier2k6

Don’t have the build tools available to me ATM. If someone can provide a windows build I’d be happy to test.

https://drive.google.com/open?id=1-7EGIlXhxX5EDsC78RO01E3lR87RqVfq
qbt master+arvidn/libtorrent#4480 here

Work fine if select any interface
If specify VPN interface: µTP work, no TCP connection
using NordVPN+Surfshark

[ghost]

could someone give this a try? arvidn/libtorrent#4480

Still not working. Same issue.

And here's what I found regarding invalid/disconnected interface.
If you have an invalid interface selected while starting qBt, it tries to listen on 127.0.0.1:port
Trackers/DHT doesn't work which is the expected behaviour.
But you still get peer connection if you had a downloading/seeding torrrent before (Probably peer list remains cached or something) even though it says binding to loopback address in logs.
And all the peer connections are outgoing connections. Meaning the outgoing interface is bound to 0.0.0.0

But if you had VPN connected already and suddenly disconnect it, then instead of binding to 127.0.0.1 it binds to 0.0.0.0 and leaks the IP(meaning tracker, DHT, peers everything goes through the main adapter) @arvidn

[HnyBear]

Same issues as before. All downloads stalled until I restart qbit. I'm using socks5 and PIA.

[ghost]

@FranciscoPombal
I understand now why the listen interface binds to 127.0.0.1 but outgoing binds to 0.0.0.0 when you choose an invalid interface.

According to libtorrent interface bind documentation if you pass an empty string for the outgoing interface (because the interface is invalid and we can't get the GUID of it from Windows) it binds to 0.0.0.0

To fix this issue you have to bind to the pseudo loopback interface if the selected interface is invalid. Maybe someone can make a PR and fix this.

[FranciscoPombal]

@an0n666

(Probably peer list remains cached or something)

I learned recently libtorrent stores it (at least partially, if not in full) at stop time in the .fastresume file.
I assume qBittorrent also does that, unless it is going out of its way to prevent that, which I doubt, although I did not look at that code.

I understand now why the listen interface binds to 127.0.0.1 but outgoing binds to 0.0.0.0 when you choose an invalid interface.

According to libtorrent interface bind documentation if you pass an empty string for the outgoing interface (because the interface is invalid and we can't get the GUID of it from Windows) it binds to 0.0.0.0

To fix this issue you have to bind to the pseudo loopback interface if the selected interface is invalid. Maybe someone can make a PR and fix this.

I'm thinking a client-side fix would be most appropriate. Something like if invalid_interface then lt_listen_interface = loopback_interface. But let's hear from @arvidn if he would prefer to change the behavior in libtorrent instead (empty string not falling back to anything).

[arvidn]

when setting outgoing_interfaces, libtorrent tries to bind outgoing sockets to that interface. It could be specified as an IP address or an interface/adapter name. If it's an interface name, libtorrent attempts bind_to_device (which has different names on different platforms, SO_BINDTODEVICE, IP_BOUND_IF and IP_FORCE_OUT_IFP).

If bind to device fails (or isn't supported, which I believe is the case on windows) libtorrent falls back to enumerating IP addresses configured for the specified device, and bind() the socket to the first address (with the correct address family) we find.

If enumerating IP addresses fail, which I would expect it to do if the interface/adapter doesn't exist, the socket is not bound but an error is returned and the socket is disconnected. This will post an peer_disconnected_alert specifying bind as the failing operation with an error code describing what failed. If this happens to every peer, that would explain the behavior described in this ticket.

[arvidn]

@FranciscoPombal I think it's important that an empty outgoing_interfaces simply disables binding outgoing sockets. This is also the default. If you want to force a failure, set it to an adapter name that doesn't exist (and let me know if that doesn't cause a failure).

[ghost]

When qBt is started with an invalid interface selected, it binds to loopback for incoming. But outgoing is still bound to 0.0.0.0 and peers download/upload continues if you had peers saved from previous announce(before exiting and starting qBt with an invalid interface). So empty string doesn’t disable binding to outgoing interface. Or maybe qBt is indeed passing 0.0.0.0 as outgoing interface in that case.

[FranciscoPombal]

@an0n666 @gothicserpent @arvidn @c0re100
FYI: over at https://github.com/qbittorrent/qBittorrent/issues/12297 users are reporting connection failures even when setting to "Any Interface + Any address".

[arvidn]

I could reproduce an issue with similar symptoms as described in this ticket. The problem I encountered was that bind() was called twice on a socket (when setting outgoing interfaces). This caused the second call to fail with EINVAL which led to the socket being closed. I fixed this in https://github.com/arvidn/libtorrent/pull/4480

Now I can no longer reproduce this issue. I'm trying with Private Internet Access on Ubuntu and Mac OS. I could use some help understanding what other settings may affect this behavior. I'm just setting listen_interfaces and outgoing_interfaces to the tun0 (linux) and utun0 (MacOS) and the sockets are bound to the expected IP, associated with the VPN interface.

I've also tried setting the device names to gibberish to confirm that nothing connects.

These are the command lines of client_test I'm using:

./client_test -f client-test.log -s . --alert_mask=error,connect --outgoing_interfaces=tun0 --listen_interfaces=tun0:12345 ubuntu-19.10-desktop-amd64.iso.torrent
./client_test -f client-test.log -s . --alert_mask=error,connect --outgoing_interfaces=tun0 ubuntu-19.10-desktop-amd64.iso.torrent
./client_test -f client-test.log -s . --alert_mask=error,connect --listen_interfaces=tun0:12345 ubuntu-19.10-desktop-amd64.iso.torrent

Even when I don't set outgoing interfaces, the peer connections are bound to the VPN interface, as one would expect. (in fact, I think the outgoing_interfaces setting may be subject to some simplications and changes down the line, maybe turned into a bool, and use the interfaces/IPs specified in listen_interfaces)

[ghost]

@arvidn
This problem doesn’t exits up until this commit
https://github.com/arvidn/libtorrent/pull/4249

[arvidn]

I would be interested in seeing error messages too

[ghost]

qBt isn’t generating any error so I’ll try reproducing it using deluge and maybe can get some error msgs from logs as well.

[arvidn]

@an0n666 I just realized you're on windows. I should test on windows as well.

[ghost]

I couldn't reproduce it on deluge. Maybe qBt is using some settings which is causing this issue.

[ghost]

@arvidn
If qBt passes the VPN IP to interface then it works fine.
But if it passes the GUID of the interface then TCP sockets do not open. Maybe you can reproduce it on Windows by passing interface GUID to listen interface/outgoing interface.

[arvidn]

@an0n666 thanks for investigating this! It makes sense, my impression is that adapter names on windows isn't as simple as on unix systems. And specifying an adapter that doesn't match exactly the name of one would have exactly this symptom.

[arvidn]

now the question is; Everybody who has this problem, are you on windows? Does it work if you specify the IP address of the VPN adapter rather than the name / GUID?

[ghost]

If anyone on windows wants to confirm the GUID issue then :
Select —>Any interface (this probably passes an empty string instead of any GUID)
—>VPN interface IP from optional IP bind option when using a VPN

[gothicserpent]

I am on Windows 10, qbt 4.2.2. Just tested this. It downloads/uploads and connects with:

• Connection->Enabled Protocol->TCP
• Advanced->Network Interface->Any interface
• Advanced->Optional ip address to bind to: Link-local ipv6 address of my VPN

Side notes:

1. When i try the ipv4 or ipv6 address of my VPN as the Optional ip address to bind to with Any interface as the Network Interface, i only get download and no upload.
2. When I select my VPN as the Network Interface, I get no download or upload connections regardless of what IP address I choose.
3. Keep in mind i'm using Anonymous mode without DHT/PEX/local peer discovery while testing.

I verified the link-local ipv6 of my vpn by looking it up in ipconfig /all

Edit: Here is my log with these settings, along with my VPN's local information from ipconfig at the bottom of the log https://pastebin.com/tP9wBwbV

[sledgehammer999]

About issue where the interface becomes unavailable and qbittorrent starts up
I looked at the qbt code. When it detects an invalid network interface it sets listen_interfaces to 127.0.0.1 and doesn't touch outgoing_interfaces at all (aka uses libtorrent's default value). @arvidn in this case should qbt input a specific value to outgoing_interfaces to make it stop traffic?

Relevant functions of qbt Session::configureNetworkInterfaces() and Session::getListeningIPs().

[ghost]

You have to set 127.0.0.1 to both since libtorrent treats empty strings as 0.0.0.0
The more intriguing issue is when VPN connection drops, it switches over to 0.0.0.0 automatically and leaks the IP.

[sledgehammer999]

You have to set 127.0.0.1 to both since libtorrent treats empty strings as 0.0.0.0

As far as I understand outgoing_interfaces takes only interfaces not IPs.

[ghost]

Then you have to set it to an invalid interface or a pseudo loopback interface I guess.

[sledgehammer999]

The more intriguing issue is when VPN connection drops, it switches over to 0.0.0.0 automatically and leaks the IP

While running qbt doesn't re-configure the listen_interfaces/outgoing_interfaces. (unless of course the user explicitly changes network settings). So the above behavior is coming from libtorrent.

[arvidn]

As far as I understand outgoing_interfaces takes only interfaces not IPs.

both outgoing_interfaces and listen_interfaces take both network interface names (adapter names) or IP addresses. docs here and here.

@arvidn in this case should qbt input a specific value to outgoing_interfaces to make it stop traffic?

I would imagine it to be more intuitive behavior for qbt, when detecting an invalid network interface to not do anything. If the user has set a network interface that doesn't exist (perhaps temporarily), chances are the user does not want it to work.

So, unless I'm misunderstanding something, I think the "specific" invalid value, should just be the name of the adapter that might come back into existence soon. At which point things will just start working again, without any further actions from qbt.

Also, to clarify, outgoing_interfaces only apply to TCP connections, that's (most likely) why the symptoms are that everything else works. The reason for it only applying to TCP is that all uTP sockets share a single underlying UDP socket (or rather, one UDP socket per listen_interface, and which one is used by any given uTP connection may be affected by outgoing_interfaces, but it's a looser connection).

[arvidn]

The more intriguing issue is when VPN connection drops, it switches over to 0.0.0.0 automatically and leaks the IP

While running qbt doesn't re-configure the listen_interfaces/outgoing_interfaces. (unless of course the user explicitly changes network settings). So the above behavior is coming from libtorrent.

@an0n666 what is switching to 0.0.0.0 exactly? the local IP address TCP sockets are bound to? listen sockets? What tool are you using to discover this? the log?

[ghost]

It switches to 0.0.0.0 only when specifying a interface name(in this case the VPN interface name). It doesn’t do that when you specify an IP to bind to.
And yes I’m guessing it from log since as soon as I disconnect I get listen success in log for all interfaces.

Also the download upload continues over the main interface.

[Rootax]

And what happens when binding to ipv4+ipv6 ?

Le mer. 1 avr. 2020 à 14:08, An0n [e-mail] a écrit :

It switches to 0.0.0.0 only when specifying a interface name. It doesn’t
do that when you specify an IP to bind to.
And yes I’m guessing it from log since as soon as I disconnect I get
listen success in log for all interfaces.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/12253#issuecomment-607210654,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFLELOQP5JLM6NYRRV5R6U3RKMVD7ANCNFSM4LS6S67Q
.

[xavier2k6]

(May or may not be of any benefit/have any effect on this issue - It's just an FYI)

Microsoft releases Windows 10 builds with VPN fix

Here's the highlight:

Updates an issue that might display the wrong internet connection status for certain VPN users or might prevent some applications from connecting to the internet.

And here's the fix:

Addresses an issue that might display a limited or no internet connection status in the notification area on devices that use a manual or auto-configured proxy, especially with a virtual private network (VPN). Additionally, this issue might prevent some devices from connecting to the internet using applications that use WinHTTP or WinINet.

Windows 10 Versions 1909 and 1903 get KB4554364 Info KB4554364 Download
Windows 10 Version 1809 will get KB4554354 Info KB4554354 Download
Windows 10 Version 1803 will get KB4554349 Info KB4554349 Download
Windows 10 Version 1709 will get KB4554342 Info KB4554342 Download

[sledgehammer999]

both outgoing_interfaces and listen_interfaces take both network interface names (adapter names) or IP addresses. docs here and here.

Well the docs about listen_interfaces are a lot more clearer that they take IPs and device names as input.

In any case, I take the rest of your comment as a useful tip, and I'll see how to integrate it into the qbt logic. And since outgoing_interfaces take IPs too, it will simplify the logic a bit.

[arvidn]

@sledgehammer999

you're right, the documentation is not very clear for outgoing_interfaces. I'll improve that.

It switches to 0.0.0.0 only when specifying a interface name(in this case the VPN interface name). It doesn’t do that when you specify an IP to bind to.

@an0n666 can you be more specific what "it" refers to in that sentence? Do you see 0.0.0.0 as the local IP address of TCP connections in lsof? Or is it the local IP reported in qBT's peer list?

Also the download upload continues over the main interface.

You see this in wireshark or something like that, or it must be the main interface since VPN is for sure down?

[ghost]

Idk why I should check with wireshark. It’s quite obvious that when you turn off a VPN connection and your client is still downloading/uploading and saying in the logs that it’s successfully listening on your main interface as well as loopback interfaces, it’s safe to assume that the listen sockets were re-established over all interfaces instead of the one that it was using before the VPN was disconnected.

[sledgehammer999]

Hold your horses a bit. I am going to present a patch based on what @arvidn has said and maybe that will sidestep some of the issues. In the meantime @arvidn probably looks at libtorrent's code too, to figure out if this is even possible.

[hbh7]

Gosh I think this must by why nothing has been up/downloading for few weeks now. I'm on Ubuntu Server with qBittorrent-nox. I noticed my connections was set to TCP only and it didn't work at all. I could see tracker connections worked and there was peers listed but no connections to any. Setting it to TCP/UTP and it fired right up. Seems that if I set interface to any works too on TCP only, but not on a specified interface (which is a valid interface). Very interesting

[FranciscoPombal]

@hbh7

Gosh I think this must by why nothing has been up/downloading for few weeks now. I'm on Ubuntu Server with qBittorrent-nox. I noticed my connections was set to TCP only and it didn't work at all. I could see tracker connections worked and there was peers listed but no connections to any. Setting it to TCP/UTP and it fired right up. Seems that if I set interface to any works too on TCP only, but not on a specified interface (which is a valid interface). Very interesting

You could have other problems as well, 4.2.2 has only been out for barely a week.

[hbh7]

You may totally be right. But I thought I saw another issue or something saying it happened in 4.2.1 too, and the way to replicate/fix matches here so ¯\_(ツ)_/¯

[arvidn]

@hbh7 are you on windows and do have you picked your VPN adapter to bind to?

[hbh7]

I'm on Ubuntu server, and there's only 1 interface (router VPN, entire VM is routed out it). Selecting an interface makes it not work, selecting "any" interface makes it work.

[arvidn]

@hbh7 are you sure the interface you're selecting is spelled correctly? does it match the name in ifconfig for example?

[hbh7]

Of course. It's literally a dropdown menu, no typing involved. Regardless, it does match, and was set months ago and only became an issue recently.

[sledgehammer999]

@hbh7 are you using our PPA? If yes, FYI currently it has the latest commit from libtorrent RC_1_2. I also released v4.2.3 but it hasn't been built yet.
However, latest libtorrent available from the repo includes a recent fix made @arvidn. Care to update the libtorrent package and give it a try?
Also the qbittorrent log outputs the exact string used for the network interface name. The UI might not show the string actually passed to libtorrent. So please verify from the log that the correct string is used.

[hbh7]

Yes, I'm using the PPA. I did try compiling the 4.2.0 version earlier today and that seems to be working much better with many downloads running now that weren't before. I'll try uninstalling that and returning to the PPA version and check the log to make sure. It sounds like whatever is on the PPA now is newer than what we were testing before and possibly includes a fix if I'm understanding correctly, so I'll see how that works out. It's not impossible that if the PPA has libtorrent in it, that I'm now already running it with 4.2.0. Not 100% on how that all works together. I'll just get everything up to date and see what happens.

[ghost]

@sledgehammer999
The issue is apparently fixed now in qBt 4.2.3.
I mean now it’s working when VPN interface is selected with TCP only mode.

[sledgehammer999]

@an0n666 which OS did you test? AFAIK v4.2.3 doesn't contain something new in itself for networking. The big factor is the newer libtorrent used.

[ghost]

Tested on Windows 10. Maybe the newer libtorrent or maybe some windows update fixed it idk. I’ll downgrade later to confirm when I get time.

[ghost]

Does the QT version have anything to do with networking stuff? Seems like it got a downgrade in 4.2.3 windows x64.

[hbh7]

It does appear that 4.2.3 fixes the issue discussed here. However, I noticed a few odd things:

1. Version number in help->about still says 4.2.2, but the install log suggests 4.2.3:
   Setting up qbittorrent-nox (1:4.2.3.99~202004020718-6939-3c17ad5~ubuntu19.10.1)
2. The web ui takes approximately 5 minutes after starting before it is accessible. Before it was within a few seconds. Perhaps new bug?

[Rootax]

Yes. 5.14.1 was buggy with some network stuff. Was fixed in 5.14.2. And
5.13.x was ok too.

Le jeu. 2 avr. 2020 à 19:34, An0n [e-mail] a écrit :

Does the QT version have anything to do with networking stuff? Seems like
it got a downgrade in 4.2.3 windows x64.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/12253#issuecomment-607988689,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFLELORY6VYSWCU2RNZQL3LRKTECZANCNFSM4LS6S67Q
.

[sledgehammer999]

Version number in help->about still says 4.2.2, but the install log suggests 4.2.3:

As I said, it has been build yet in the PPA. It is still building: https://launchpad.net/~qbittorrent-team/+archive/ubuntu/qbittorrent-stable

@an0n666 see News in main site and https://github.com/qbittorrent/qBittorrent/issues/12270

[hbh7]

Okay, I'm not sure I understand why I'm seeing changes and that message in the install log then if it's still building. Bit confused here

[gothicserpent]

This now works for me in qBT 4.2.3 win10. Upload and Downloads functioning.

Settings: Connection->Enabled Protocol->TCP , Advanced->Network Interface->My VPN Interface , Advanced->Optional ip address to bind to: All addresses

Log: https://pastebin.com/Z9UW0UMH

[sledgehammer999]

Okay, I'm not sure I understand why I'm seeing changes and that message in the install log then if it's still building. Bit confused here

Probably because you're using the newest libtorrent package which includes fixes from @arvidn

[hbh7]

That's likely it then, I think you're right. Cool
libtorrent-rasterbar-dev/eoan,now 1.2.5+git20200401.dcf3c83d29-1ppa1~19.10 amd64 [installed] libtorrent-rasterbar10/eoan,now 1.2.5+git20200401.dcf3c83d29-1ppa1~19.10 amd64 [installed,automatic]
Thanks!

[FranciscoPombal]

Can a few more people confirm this is fixed in 4.2.3 before this can be closed, please?
@AlienIdeology @Aerozolic @CeruleanSky @c0re100

[bimmerdriver]

Just checked and it works fine for me. Windows 10, version 1909, mullvad, latest version. 4.2.1 worked, 4.2.2 didn't work, 4.2.3 works.

[HnyBear]

Still no luck with Socks5 on 4.2.3 it's still not downloading until I restart qbit.

[ghost]

Still no luck with Socks5 on 4.2.3 it's still not downloading until I restart qbit.

You posted in wrong ticket I guess. This ticket only concerns VPNs. For socks5 issues create a new ticket with the logs. Socks5 error should get logged in 4.2.3.

[ghost]

@FranciscoPombal
You can close this I guess.

But there are still two concerns left regarding VPNs that were discussed in recent comments. Binding to loopback has to be removed and the continuation of download over main interface upon disconnect needs to be investigated further.

[ghost]

@arvidn

This is what I get in logs after VPN disconnects.

4/3/2020 9:43 AM - Successfully listening on IP: 192.168.2.100, port: UDP/61838
4/3/2020 9:43 AM - Successfully listening on IP: 127.0.0.1, port: UDP/61839
4/3/2020 9:43 AM - Successfully listening on IP: fe80::c8f2:b99f:c974:325c%14, port: UDP/61840
4/3/2020 9:43 AM - Successfully listening on IP: ::1, port: UDP/61841
4/3/2020 9:43 AM - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: UDP/61838

Things to note here. Different ports are seen in these messages for each IP ranging from 61838-61840. Seem like chosen randomly each time. And they're trying to listen on UDP ports only.

[FranciscoPombal]

@an0n666 thanks, please open new ticket(s) to track those.
@HnyBear please post in issue reports related to proxy issues or open a new one if no existing one is appropriate.

[arvidn]

@an0n666 libtorrent will try to detect if the IP address changes (by reading from a NETLINK_ROUTE socket). If a possible IP change is detected, the listen sockets will be re-opened. However, the listen_interfaces or outgoing_interfaces settings will not change/

If listen_interfaces contain an invalid interface name, incoming connections will not be accepted. However, outgoing connections may still be made. If outgoing_interfaces is set to an invalid interface name, then outgoing TCP connections are also blocked.

It's unclear if uTP connections are blocked in such case actually, it seems like it.

the DHT and tracker announces don't seem to be disabled though. It seems like it would be a good idea to not open any listen sockets at all in such case. Or rather, open one with the invalid interface name and have everything fail.

[arvidn]

@an0n666 I filed this: https://github.com/arvidn/libtorrent/issues/4500 please feel free to comment there!