Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gothicserpent opened this issue Mar 24, 2020 · 63 comments

Comments

@gothicserpent
Copy link

@gothicserpent gothicserpent commented Mar 24, 2020

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 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.

image

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.

image

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

image

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.

image

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)

4 2 1

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)

4 2 2

@gothicserpent gothicserpent changed the title 4.2.2 download/upload not working 4.2.2 download/upload stalled & not functional Mar 24, 2020
@gothicserpent gothicserpent changed the title 4.2.2 download/upload stalled & not functional 4.2.2 download/upload stalled for all torrents Mar 24, 2020
@AlienIdeology

This comment has been minimized.

Copy link

@AlienIdeology AlienIdeology commented Mar 24, 2020

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

This comment has been minimized.

Copy link
Author

@gothicserpent gothicserpent commented Mar 24, 2020

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

This comment has been minimized.

Copy link
Author

@gothicserpent gothicserpent commented Mar 24, 2020

Wanted to provide an update.

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

image

the upload and download connection is working again:

image

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?

@gothicserpent gothicserpent changed the title 4.2.2 download/upload stalled for all torrents 4.2.2 download/upload stalled for all torrents using TCP (TCP and µTP works) Mar 24, 2020
@AlienIdeology

This comment has been minimized.

Copy link

@AlienIdeology AlienIdeology commented Mar 24, 2020

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

@AlienIdeology

This comment has been minimized.

Copy link

@AlienIdeology AlienIdeology commented Mar 24, 2020

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

@gothicserpent

This comment has been minimized.

Copy link
Author

@gothicserpent gothicserpent commented Mar 24, 2020

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:

image

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

If anyone else has this issue I hope they report!

@gothicserpent gothicserpent changed the title 4.2.2 download/upload stalled for all torrents using TCP (TCP and µTP works) 4.2.2 download/upload stalled for all torrents using only TCP (TCP and µTP works) Mar 25, 2020
@gothicserpent gothicserpent changed the title 4.2.2 download/upload stalled for all torrents using only TCP (TCP and µTP works) 4.2.2 download/upload stalled for all torrents using only TCP with VPN (TCP and µTP works) Mar 25, 2020
@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Mar 25, 2020

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

@arvidn

This comment has been minimized.

Copy link

@arvidn arvidn commented Mar 25, 2020

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"?

@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Mar 25, 2020

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

@gothicserpent

This comment has been minimized.

Copy link
Author

@gothicserpent gothicserpent commented Mar 25, 2020

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):

image

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

This comment has been minimized.

Copy link

@Rootax Rootax commented Mar 25, 2020

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.

@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Mar 25, 2020

@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

This comment has been minimized.

Copy link

@rwasef1830 rwasef1830 commented Mar 25, 2020

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

This comment has been minimized.

Copy link

@RedLion76 RedLion76 commented Mar 25, 2020

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

This comment has been minimized.

Copy link
Author

@gothicserpent gothicserpent commented Mar 25, 2020

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

@RedLion76

This comment has been minimized.

Copy link

@RedLion76 RedLion76 commented Mar 25, 2020

Yes. Sorry, typo.

@gothicserpent gothicserpent changed the title 4.2.2 download/upload stalled for all torrents using only TCP with VPN (TCP and µTP works) 4.2.2 download/upload stalled for all torrents using only TCP with VPN (µTP works) Mar 25, 2020
@arvidn

This comment has been minimized.

Copy link

@arvidn arvidn commented Mar 26, 2020

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

This comment has been minimized.

Copy link

@Aerozolic Aerozolic commented Mar 26, 2020

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

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 26, 2020

@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

This comment has been minimized.

Copy link
Author

@gothicserpent gothicserpent commented Mar 26, 2020

Just wanted to add this in:
image
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:
image

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

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 26, 2020

Just wanted to add this in:
image
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

This comment has been minimized.

Copy link
Author

@gothicserpent gothicserpent commented Mar 26, 2020

image

image

image

@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.

image

image

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

@FranciscoPombal

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 27, 2020

@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

This comment has been minimized.

Copy link
Contributor

@sledgehammer999 sledgehammer999 commented Mar 27, 2020

(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

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 27, 2020

In addition:

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

This comment has been minimized.

Copy link
Author

@gothicserpent gothicserpent commented Mar 28, 2020

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

@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Mar 28, 2020

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

This comment has been minimized.

Copy link

@Aerozolic Aerozolic commented Mar 28, 2020

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

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 28, 2020

@Aerozolic

And on Mac? Same as Linux?

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

@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Mar 28, 2020

Posting my log here

3/28/2020 8:52 PM - UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: no router found
3/28/2020 8:52 PM - UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: no router found
3/28/2020 8:50 PM - Successfully listening on IP: 172.20.155.204, port: UDP/20350
3/28/2020 8:50 PM - Successfully listening on IP: 172.20.155.204, port: TCP/20350
3/28/2020 8:49 PM - Trying to listen on: {96339EFC-4892-417C-A8E7-E44F59644089}:20350

route print:

===========================================================================
Interface List
 32...........................IPVanish
 28...00 ff 48 55 e1 18 ......TAP-NordVPN Windows Adapter V9
  6...00 ff 25 a5 24 56 ......TAP-Windows Adapter V9
 13...2c 4d 54 52 08 8d ......Intel(R) Ethernet Connection (2) I219-V
  1...........................Software Loopback Interface 1
 10...00 00 00 00 00 00 00 e0 Microsoft Teredo Tunneling Adapter
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.2.1    192.168.2.100   4260
          0.0.0.0          0.0.0.0         On-link    172.20.155.204      2
   103.13.242.211  255.255.255.255      192.168.2.1    192.168.2.100   4261
        127.0.0.0        255.0.0.0         On-link         127.0.0.1   4556
        127.0.0.1  255.255.255.255         On-link         127.0.0.1   4556
  127.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
   172.20.155.204  255.255.255.255         On-link    172.20.155.204    257
      192.168.2.0    255.255.255.0         On-link     192.168.2.100   4516
    192.168.2.100  255.255.255.255         On-link     192.168.2.100   4516
    192.168.2.255  255.255.255.255         On-link     192.168.2.100   4516
        224.0.0.0        240.0.0.0         On-link         127.0.0.1   4556
        224.0.0.0        240.0.0.0         On-link     192.168.2.100   4516
        224.0.0.0        240.0.0.0         On-link    172.20.155.204      2
  255.255.255.255  255.255.255.255         On-link         127.0.0.1   4556
  255.255.255.255  255.255.255.255         On-link     192.168.2.100   4516
  255.255.255.255  255.255.255.255         On-link    172.20.155.204    257
===========================================================================
Persistent Routes:
  None

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
 10    331 ::/0                     On-link
  1    331 ::1/128                  On-link
 10    331 2001::/32                On-link
 10    331 2001:0:2851:fcb0:28d3:2170:98f2:d28/128
                                    On-link
 13    291 fe80::/64                On-link
 10    331 fe80::/64                On-link
 10    331 fe80::28d3:2170:98f2:d28/128
                                    On-link
 13    291 fe80::c8f2:b99f:c974:325c/128
                                    On-link
  1    331 ff00::/8                 On-link
 13    291 ff00::/8                 On-link
 10    331 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

PS. Was using IPVanish.

@FranciscoPombal

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 28, 2020

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:

void Session::handleListenSucceededAlert(const lt::listen_succeeded_alert *p)

@Aerozolic

This comment has been minimized.

Copy link

@Aerozolic Aerozolic commented Mar 28, 2020

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.

@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Mar 29, 2020

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

This comment has been minimized.

Copy link

@CeruleanSky CeruleanSky commented Mar 29, 2020

@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:

image

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

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 29, 2020

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

This comment has been minimized.

Copy link

@CeruleanSky CeruleanSky commented Mar 29, 2020

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

This comment has been minimized.

Copy link

@arvidn arvidn commented Mar 29, 2020

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

This comment has been minimized.

Copy link

@arvidn arvidn commented Mar 29, 2020

@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

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 29, 2020

@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.

@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Mar 29, 2020

@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

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 29, 2020

@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.

@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Mar 29, 2020

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

@arvidn

This comment has been minimized.

Copy link

@arvidn arvidn commented Mar 29, 2020

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

@FranciscoPombal

This comment has been minimized.

Copy link
Member

@FranciscoPombal FranciscoPombal commented Mar 29, 2020

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

@an0n666

This comment has been minimized.

Copy link
Contributor

@an0n666 an0n666 commented Mar 29, 2020

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

This comment has been minimized.

Copy link

@c0re100 c0re100 commented Mar 29, 2020

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

This comment has been minimized.

Copy link

@c0re100 c0re100 commented Mar 29, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.