Should this be pinned?

xavier2k6 on 23 Dec 2019

This is the test build mentioned above based on https://github.com/arvidn/libtorrent/pull/4202 and on 4.2.1 with below patch applied.
Please report the errors you get in the log. Don't forget to enclose them in "code" tags. For this click the relevant button from the toolbar present above the comment input box which has a tooltip "Insert code". The loglines will be posted suitable for easy reading.

Link: http://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735.7z
(run from any folder or overwrite official files)

diff:

diff --git a/src/base/bittorrent/session.cpp b/src/base/bittorrent/session.cpp
index a4cf15107..b86e83219 100644
--- a/src/base/bittorrent/session.cpp
+++ b/src/base/bittorrent/session.cpp
@@ -4211,6 +4211,9 @@ void Session::handleAlert(const lt::alert *a)
         case lt::external_ip_alert::alert_type:
             handleExternalIPAlert(static_cast<const lt::external_ip_alert*>(a));
             break;
+        case lt::socks5_alert::alert_type:
+            handleSocks5Alert(static_cast<const lt::socks5_alert*>(a));
+            break;
 #if (LIBTORRENT_VERSION_NUM >= 10200)
         case lt::alerts_dropped_alert::alert_type:
             handleAlertsDroppedAlert(static_cast<const lt::alerts_dropped_alert *>(a));
@@ -4623,6 +4626,11 @@ void Session::handleListenFailedAlert(const lt::listen_failed_alert *p)
 #endif
 }

+void Session::handleSocks5Alert(const lt::socks5_alert *p)
+{
+    LogMsg(tr("Socks5 error: %1").arg(QString::fromLocal8Bit(p->message().c_str())), Log::CRITICAL);
+}
+
 void Session::handleExternalIPAlert(const lt::external_ip_alert *p)
 {
     lt::error_code ec;
diff --git a/src/base/bittorrent/session.h b/src/base/bittorrent/session.h
index 4591f4477..859b9abad 100644
--- a/src/base/bittorrent/session.h
+++ b/src/base/bittorrent/session.h
@@ -576,6 +576,7 @@ namespace BitTorrent
         void handleListenFailedAlert(const lt::listen_failed_alert *p);
         void handleExternalIPAlert(const lt::external_ip_alert *p);
         void handleSessionStatsAlert(const lt::session_stats_alert *p);
+        void handleSocks5Alert(const lt::socks5_alert *p);
 #if (LIBTORRENT_VERSION_NUM >= 10200)
         void handleAlertsDroppedAlert(const lt::alerts_dropped_alert *p) const;
 #endif

sledgehammer999 on 23 Dec 2019

Should this be pinned?

No.

sledgehammer999 on 23 Dec 2019

Can i post this here?

When I used QBittorrent Version 3.3.16 + Socks5 proxy + Nordvpn = Show on EXECUTION LOG TAB:
External IP: x.x.x.x
where "x.x.x.x" is the vpn proxy, of course,
and all connections IS MADE

When I used QBittorrent Version 4.2.0 + Socks5 proxy + Nordvpn = Show on EXECUTION LOG TAB:
External IP: 0.0.0.0
and NO connections is made.
NO DOWNLOAD, NOTHING.

The same settings was made for both version 3.3.16 and 4.2.0.

calvilasboasjr on 23 Dec 2019

@calvilasboasjr did you even read my 2 previous comments?

sledgehammer999 on 23 Dec 2019

Please report the errors you get in the log.
Link: http://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735.7z

Log (no error "Socks5 error: %1", wait 30min):

qBittorrent v4.2.1 started
Using config directory: ...
Trying to listen on: 192.168.0.2:8999
Peer ID: -qB4210-
HTTP User-Agent is 'qBittorrent/4.2.1'
DHT support [ON]
Local Peer Discovery support [ON]
PeX support [ON]
Anonymous mode [ON]
Encryption support [ON]
GeoIP database loaded. Type: GeoLite2-Country. Build time: ... .
Options were saved successfully.
Successfully listening on IP: 192.168.0.2, port: UDP/8999
...
'...' restored.
Successfully moved torrent: ... New path: ...
...
UPnP / NAT-PMP support [OFF]

Test:

Windows 7 Ultimate 64-bit SP1
Use proxy only for torrents (Socks5 Tor proxy, doesn't support UDP connections)
Any interface and all addresses OR set interface and address
Disable/Enable anonymous mode
Disable/Enable UPnP / NAT-PMP support (use port forwarding in my router)
Disable disable connections not supported by proxies

Result:

No DHT, no magnet working
No in log: Successfully listening on IP: 0.0.0.0, port: TCP/port
When set Any interface and all addresses get in log Detected external IP: x.x.x.x
When set Any interface and my address get in log Detected external IP: x.x.x.x
When set My interface and all addresses no in log Detected external IP: x.x.x.x
When set My interface and my address no in log Detected external IP: x.x.x.x
Gone back to 4.1.9 again and working fine

In my case, I want to connect to trackers through a proxy and make all other connections directly.

ExceptionGit on 23 Dec 2019

@ExceptionGit There is a slight possibility that the posted build didn't have the patch applied. I reuploaded it. Can you download the same file again and test?

sledgehammer999 on 23 Dec 2019

@sledgehammer999 Yes, file hashes have been updated.

SHA3_512
fb0b262bf1f7b68457863e3abea9a661cf39bb656f4f309d2533dbf3e575c00622b66718d6e1b98f14e82babb0e659cf29c49b48371f0e7d2626b47a93742727 *qbittorrent.exe
b11b4c40379e6009813f8c3bb291e3f303966ecc721387c589396ba3eae8292d090db327d303750747cee532ce05e2f775dd74c238dd52f1dc6e49c1ce46d4f6 *qbittorrent.pdb

Config:

Enable anonymous mode
Set My interface and my addres

Log (no error "Socks5 error: %1", wait ~8min):

qBittorrent v4.2.1 started
Using config directory: ...
Trying to listen on: 192.168.0.2:8999
Peer ID: -qB4210-
HTTP User-Agent is 'qBittorrent/4.2.1'
DHT support [ON]
Local Peer Discovery support [ON]
PeX support [ON]
Anonymous mode [ON]
Encryption support [ON]
GeoIP database loaded. Type: GeoLite2-Country. Build time: ... .
Options were saved successfully.
Successfully listening on IP: 192.168.0.2, port: UDP/8999
UPnP / NAT-PMP support [OFF]

Config:

Disable anonymous mode
Set Any interface and all addresses

Log (no error "Socks5 error: %1", wait ~10min):

qBittorrent v4.2.1 started
Using config directory: ...
Trying to listen on: 0.0.0.0:8999,[::]:8999
Peer ID: -qB4210-
HTTP User-Agent is 'qBittorrent/4.2.1'
DHT support [ON]
Local Peer Discovery support [ON]
PeX support [ON]
Anonymous mode [OFF]
Encryption support [ON]
GeoIP database loaded. Type: GeoLite2-Country. Build time: ... .
Options were saved successfully.
Successfully listening on IP: 0.0.0.0, port: UDP/8999
Detected external IP: ...
UPnP / NAT-PMP support [OFF]

I think my old proxy server version does not return error for libtorrent.

ExceptionGit on 23 Dec 2019

@sledgehammer999 you can test the build and logging by just setting a random hostname and port as a socks5 proxy, and ensure you get the socks5_alert(s) indicating you failed to connect.

After having thought a bit more about this, I think one issue, that may not have existed in libtorrent-1.1.x, is that the socks5 proxy logic sits on the individual socket object layer. That means that if you have multiple interfaces (which one is likely to have), each interface will trigger a socks5 connection and tunnel. This is not ideal, and I can understand if socks proxies frown upon that behavior and only let the first one (or the last one) in.

For example, when just testing this now, I get these listen interface by default:

[Dec 24 01:00:11] successfully listening on [UDP] 0.0.0.0:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::1%lo0]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::1%lo0]:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::1808:b4b2:e86b:e3ee%en0]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::1808:b4b2:e86b:e3ee%en0]:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::44e7:e2ff:feeb:6bb3%awdl0]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::44e7:e2ff:feeb:6bb3%awdl0]:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::44e7:e2ff:feeb:6bb3%llw0]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::44e7:e2ff:feeb:6bb3%llw0]:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::302c:6ee8:8e44:c2f2%utun0]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::302c:6ee8:8e44:c2f2%utun0]:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::429c:ce7f:c10b:49df%utun1]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::429c:ce7f:c10b:49df%utun1]:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::8956:242a:2e6d:aac5%utun2]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::8956:242a:2e6d:aac5%utun2]:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::6693:a331:ed65:6426%utun3]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::6693:a331:ed65:6426%utun3]:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::35fa:7336:d62c:1b24%utun4]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::35fa:7336:d62c:1b24%utun4]:6881
[Dec 24 01:00:11] successfully listening on [TCP] [fe80::ce3f:b640:c788:9377%utun5]:6881
[Dec 24 01:00:11] successfully listening on [UDP] [fe80::ce3f:b640:c788:9377%utun5]:6881

As a quick hack to avoid this, I think setting listen_interfaces to 0.0.0.0:6881 (or whatever port) whenever a socks5 proxy is configured, might work. I think it would make sense for libtorrent to work a bit differently too. I can see two approaches:

whenever a proxy is configured, we're not accepting connections directly via sockets anyway, just via the proxy (which is only one connection/socket). So, the proxy setting could override the logic of opening one socket per interface. Instead it would open one that matches whatever protocol the proxy uses (either IPv4 or IPv6). Problem with this is that if you really have multiple interfaces connected to the internet, you wand to use them all, and all of them should establish a tunnel via the proxy.
When establishing a proxy connection, only do that with a matching address family as the listen socket. If the proxy hostname doesn't resolve to a compatible address family, disable that listen socket. i.e. if the socks5 proxy only resolves to an IPv4 address, don't open the IPv6 listen sockets, and vice versa.

I'm leaning towards (2), but maybe there's should be a more generic rule around filtering listen interfaces as well. For instance, all those %utun0 etc, interfaces are most likely stale.

Does anyone have any opinions?

arvidn on 24 Dec 2019

you can test the build and logging by just setting a random hostname and port as a socks5 proxy, and ensure you get the socks5_alert(s) indicating you failed to connect.

Yes it does print errors if I point to eg 127.0.0.1

As a quick hack to avoid this, I think setting listen_interfaces to 0.0.0.0:6881 (or whatever port) whenever a socks5 proxy is configured

Guys, if you want to test the above, go to Advanced settings and choose Any interface + All IPv4 addresses (and then restart)

sledgehammer999 on 24 Dec 2019

Please report the errors you get in the log. Don't forget to enclose them in "code" tags. For this click the relevant button from the toolbar present above the comment input box which has a tooltip "Insert code". The loglines will be posted suitable for easy reading.

Link: http://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735.7z
(run from any folder or overwrite official files)

Sorry - I did not understand "to enclose them in "code" tags" as I could not find "click the relevant button from the toolbar present above the comment input box which has a tooltip "Insert code". The loglines will be posted suitable for easy reading."

Link: http://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735.7z extracted to folder and ran from that folder.

qBittorrent v4.2.1 Set Tools, Options, Connections Proxy Server Socks5, Authentication, OK

Preloaded torrents with URL http trackers: some are Working, some are Not Working,
Had to individually Pause / Force Resume or Force reannounce each torrent where URL http Not Working for all URL http to be Working.

Loaded torrent with URL udp trackers: all trackers Not Working, have 0-Seeds, have 0-Peers, and torrent is not downloading.

Looking at qBittorrent v4.2.1 Execution Log I see no errors and these are the lines copied one-by-one ...
24/12/2019 11:08 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: UDP/45484
24/12/2019 11:08 - Successfully listening on IP: fe80::9f9:72a4:f6eb:d270%11, port: UDP/55535
24/12/2019 11:08 - Successfully listening on IP: fe80::9f9:72a4:f6eb:d270%11, port: TCP/55535
24/12/2019 11:08 - Options were saved successfully.
24/12/2019 11:08 - GeoIP database loaded. Type: GeoLite2-Country. Build time: Tue Dec 17 19:59:54 2019.
24/12/2019 11:08 - UPnP / NAT-PMP support [ON]
24/12/2019 11:08 - Encryption support [ON]
24/12/2019 11:08 - Anonymous mode [ON]
24/12/2019 11:08 - PeX support [OFF]
24/12/2019 11:08 - Local Peer Discovery support [OFF]
24/12/2019 11:08 - DHT support [OFF]
24/12/2019 11:08 - HTTP User-Agent is 'qBittorrent/4.2.1'
24/12/2019 11:08 - Peer ID: -qB4210-
24/12/2019 11:08 - Trying to listen on: 0.0.0.0:55535,[::]:55535

qBittorrent v4.2.1 Set Tools, Options, Connections Proxy Server (None) OK. Closed client. Deleted App Data Local Temp Files. Restarted client.

URL udp trackers Working, have Seeds, have Peers, and torrent is downloading.

Looking at qBittorrent v4.2.1 Execution Log I see no errors and these are the lines copied one-by-one ...
24/12/2019 11:47 - Successfully listening on IP: fe80::9f9:72a4:f6eb:d270%11, port: UDP/55535
24/12/2019 11:47 - Successfully listening on IP: fe80::9f9:72a4:f6eb:d270%11, port: TCP/55535
24/12/2019 11:47 - Successfully listening on IP: 0.0.0.0, port: UDP/55535
24/12/2019 11:47 - Successfully listening on IP: 0.0.0.0, port: TCP/55535
24/12/2019 11:47 - Options were saved successfully.
24/12/2019 11:47 - GeoIP database loaded. Type: GeoLite2-Country. Build time: Tue Dec 17 19:59:54 2019.
24/12/2019 11:47 - UPnP / NAT-PMP support [ON]
24/12/2019 11:47 - Encryption support [ON]
24/12/2019 11:47 - Anonymous mode [ON]
24/12/2019 11:47 - PeX support [OFF]
24/12/2019 11:47 - Local Peer Discovery support [OFF]
24/12/2019 11:47 - DHT support [OFF]
24/12/2019 11:47 - HTTP User-Agent is 'qBittorrent/4.2.1'
24/12/2019 11:47 - Peer ID: -qB4210-
24/12/2019 11:47 - Trying to listen on: 0.0.0.0:55535,[::]:55535

condoghost on 24 Dec 2019

it does print errors if I point to eg 127.0.0.1

This is my case (if I set a non-existent network address), but no error "Socks5 error: %1" if i set proxy address, Any interface + All IPv4 addresses and restart: no dht, no error.

@condoghost

button Insert code in editor window
or https://help.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks and https://guides.github.com/features/mastering-markdown/
or copy&edit:

```text

your_logs

```

ExceptionGit on 24 Dec 2019

I'm looking at one which has these characteristics

As you can see it has 2 seeds and 32 peers, yet nothing is happening, it's stuck at "downloading metadata".
Here are some active trackers:

Usually when data actually flows it is from one of these sources:

Is the code base which uses trackers separate from the code base which handles DHT/PeX/LSD?

Sorry in advance, I just noticed these trackers aren't UDP, but I figure this might be useful toward figuring out what is going on.

RandomInhabitant on 25 Dec 2019

@RandomInhabitant http trackers do not go through the same path as udp trackers, when using a socks5 proxy.
The issue people seem to experience is related to the socks5 UDP proxying.

arvidn on 26 Dec 2019

Guys, I don't know if you noticed that:

Versions 3.3.16 and 4.2.0 and using VPN on SOCKET5:

I noticed that in both versions, when I add a new torrent, the torrent DOES NOT AUTOMATICALLY START!

So when I click the PAUSE and START buttons a few times:
PAUSE, I wait 4 seconds ...
START, I wait 4 seconds ...
PAUSE, I wait 4 seconds ...
START

Result:
After doing this sequence, the VPN IP FINNALY APPEARS in the EXECUTION LOG TAB, and the torrent starts loading SEEDS and the download starts.

Please make this test and comment.

Thanks.

calvilasboasjr on 27 Dec 2019

there's also no application layer timeout on the connection attempts to the socks5 proxy. If the other machine does not respond with port-unreachable and the network doesn't respond with host-unreachable, the connection attempt may take several minutes before failing. The test build only print socks5 errors to the logs, not attempts to connect (for instance). So make sure you give any test runs plenty of time to fail.

arvidn on 27 Dec 2019

Understand.

What I mean is, when I do this kind of action, PAUSE-START, the torrent starts faster.
Whenever I start a new torrent, it takes a long time for the SOCKET5 VPN IP to appear in the LOG TAB and the torrent only starts after this IP appears in the LOG.

calvilasboasjr on 27 Dec 2019

I'm using a private SOCKS5 proxy and i face the same issues. What I did was to pause all my torrents, close the client and copy the patched executable. I added a new torrent and (by pure luck?) the client logged that detected an external ip. At this mere moment, just one of the trackers worked and the torrent started downloading, although the logs contain many errors.

(N) 2019-12-29T01:30:03 - qBittorrent v4.2.1 started
(N) 2019-12-29T01:30:03 - Using config directory: ...
(I) 2019-12-29T01:30:03 - Trying to listen on: 0.0.0.0:30728,[::]:30728
(N) 2019-12-29T01:30:03 - Peer ID: -qB4210-
(N) 2019-12-29T01:30:03 - HTTP User-Agent is 'qBittorrent/4.2.1'
(I) 2019-12-29T01:30:03 - DHT support [OFF]
(I) 2019-12-29T01:30:03 - Local Peer Discovery support [OFF]
(I) 2019-12-29T01:30:03 - PeX support [OFF]
(I) 2019-12-29T01:30:03 - Anonymous mode [ON]
(I) 2019-12-29T01:30:03 - Encryption support [ON]
(I) 2019-12-29T01:30:03 - GeoIP database loaded. Type: GeoLite2-Country. Build time: Tue Dec 3 19:09:39 2019.
(N) 2019-12-29T01:30:04 - Options were saved successfully.
(I) 2019-12-29T01:30:04 - Successfully listening on IP: 0.0.0.0, port: UDP/30728
(I) 2019-12-29T01:30:04 - Successfully listening on IP: fe80::615c:27c4:1775:7892%14, port: TCP/30728
(I) 2019-12-29T01:30:04 - Successfully listening on IP: fe80::615c:27c4:1775:7892%14, port: UDP/30728
(N) 2019-12-29T01:30:04 - ... restored.
(N) 2019-12-29T01:30:04 - Download first and last piece first: Off, torrent: ...
(N) 2019-12-29T01:30:04 - ... added to download list.
(C) 2019-12-29T01:30:15 - Socks5 error: SOCKS5 error. op: sock_read ec: End of file ep: 134.19.189.19:1080
(C) 2019-12-29T01:30:15 - Socks5 error: SOCKS5 error. op: sock_read ec: End of file ep: 134.19.189.19:1080
(C) 2019-12-29T01:30:15 - Socks5 error: SOCKS5 error. op: sock_read ec: End of file ep: 134.19.189.19:1080
(C) 2019-12-29T01:30:15 - Socks5 error: SOCKS5 error. op: sock_read ec: End of file ep: 134.19.189.19:1080
(C) 2019-12-29T01:30:15 - Socks5 error: SOCKS5 error. op: sock_read ec: End of file ep: 134.19.189.19:1080
(I) 2019-12-29T01:30:18 - Detected external IP: 134.19.189.20
(C) 2019-12-29T01:30:20 - Socks5 error: SOCKS5 error. op: connect ec: A connect request was made on an already connected socket ep: 134.19.189.19:1080
(C) 2019-12-29T01:30:20 - Socks5 error: SOCKS5 error. op: connect ec: A connect request was made on an already connected socket ep: 134.19.189.19:1080
(C) 2019-12-29T01:30:20 - Socks5 error: SOCKS5 error. op: connect ec: A connect request was made on an already connected socket ep: 134.19.189.19:1080
(C) 2019-12-29T01:30:20 - Socks5 error: SOCKS5 error. op: connect ec: A connect request was made on an already connected socket ep: 134.19.189.19:1080
(C) 2019-12-29T01:30:20 - Socks5 error: SOCKS5 error. op: connect ec: A connect request was made on an already connected socket ep: 134.19.189.19:1080
(I) 2019-12-29T01:31:10 - UPnP / NAT-PMP support [OFF]

After that, no matter how many torrents I added, removed, paused and times restarted the client, the trackers never worked. The same errors were reported and the line detecting my external ip was missing. The proxy is checked and works fine for HTTP/HTTPS trackers.

doxavk on 29 Dec 2019

@sledgehammer999 I don't expect this to make a significant difference, but it cuts down on the number of SOCKS5 UDP tunnels that are opened. It's still not ideal (which would be a single tunnel), but under normal circumstances it should only open 2. https://github.com/arvidn/libtorrent/pull/4209

I've tested this with the SOCKS5 proxy provided by privateinternetaccess, and it works. I disabled all TCP to make sure I could make uTP connections and made sure I got a DHT routing table as well.

arvidn on 29 Dec 2019

👀2

Can we get a build with that patch to see if it works for us?

USBhost on 3 Jan 2020

I have it ready locally. I am just waiting on the guy who admins the ftp. Apparently he switched configurations and messed up the login credentials. I hope that later today I'll be able to upload the build.

sledgehammer999 on 3 Jan 2020

👀2 👍2

I am sorry for the long wait. Here is a build based on v4.2.1 using @arvidn's latest code and PR.
Link: https://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735_v2.7z

sledgehammer999 on 6 Jan 2020

Use proxy only for torrents (my Socks5 proxy doesn't support UDP connections)
Any interface + All IPv4 addresse
Anonymous mode [ON]

Result:

Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [::]:0
No DHT, no magnet working
No in log: Successfully listening on IP: 0.0.0.0, port: TCP/port

How can I tell the qBittorrent to use direct connections with the DHT, as it worked in the old version when flag Use proxy only for torrents is checked.

ExceptionGit on 6 Jan 2020

Use proxy only for torrents (my Socks5 proxy doesn't support UDP connections)

What does "use proxy only for torrents" mean?
If your proxy doesn't support UDP, I'm not surprised DHT doesn't work. I would have expected a different error message below though.

Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [::]:0

It looks like the hostname lookup for your socks5 proxy is failing. I don't know why the error code isn't propagated or rendered correctly though, so it's unclear what kind of failure is happening.

How can I tell the qBittorrent to use direct connections with the DHT, as it worked in the old version when flag Use proxy only for torrents is checked.

In the new version of libtorrent there's only one setting for a proxy, and it assumes you want all traffic to go through it. (I think this is by far the most common expectations among users, that if the proxy doesn't work, they would rather not have any traffic flow any other path).

What's the point in using a proxy if you're announcing your own IP to the DHT? Then you may as well use your own IP to connect to peer. no?

arvidn on 6 Jan 2020

What does "use proxy only for torrents" mean?

Ignore this. It is totally unrelated to libtorrent. If user has this unset, then qbt also uses the proxy for other connections (eg RSS feeds, software version check, search results etc). Aka parts that aren't controlled by libtorrent.

sledgehammer999 on 6 Jan 2020

What does "use proxy only for torrents" mean?

I don’t know what options are dependent between qBittorrent and libtorrent. Therefore, I assumed that the problem was the incorrect use of this option or somewhere else, because there are no more options that are somehow related to the proxy. I unset this option and it did not have any effect on the DHT...

Unset: Use proxy for peer connections
https://github.com/qbittorrent/qBittorrent/blob/dc8f4b776ce578dd45c5415256792c2cb2a6b5b2/src/gui/optionsdialog.ui#L1633-L1645

Set: Use proxy only for torrents
https://github.com/qbittorrent/qBittorrent/blob/dc8f4b776ce578dd45c5415256792c2cb2a6b5b2/src/gui/optionsdialog.ui#L1646-L1658

What's the point in using a proxy if you're announcing your own IP to the DHT? Then you may as well use your own IP to connect to peer. no?

I want the proxy server is only used for tracker connections and make all other connections directly. What I wrote earlier: https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-568455968 https://github.com/qbittorrent/qBittorrent/issues/11692#issuecomment-567801444

ExceptionGit on 7 Jan 2020

I want the proxy server is only used for tracker connections and make all other connections directly.

And what's the point of that?
Do you consider the DHT a tracker? It functions as a tracker and you would announce to it directly, not via the proxy.

arvidn on 7 Jan 2020

And what's the point of that?

When all connections to trackers are banned on my network, I can’t get seeds in private trackers (where dht is disabled for torrents). If I use proxies for trackers, I can get seeds.
When the tracker is public (where dht is enabled for torrents), I want dht working (without a proxy).

Do you consider the DHT a tracker? It functions as a tracker and you would announce to it directly, not via the proxy.

No, I don't conside the DHT a tracker when tracker private. And I see the option the proxy server is only used for tracker connections in the config, which should do this and did it in the old version4.1.9.

I believe that if qBittorrent working fine before, but now it working differently, then this is a bug and not a feature. I provided all logs, configs to help fix that. I can’t disable proxy and leave from private torrents ~600 torrent files or if I enable proxy leave from magnet torrents ~2000 torrent files where is used DHT.

ExceptionGit on 7 Jan 2020

Can't someone else test my build apart from @ExceptionGit and report if DHT and udp trackers are working via proxy?
Link to my build (again): https://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735_v2.7z

sledgehammer999 on 7 Jan 2020

I'll do it tonight. ETA 3 hours

USBhost on 7 Jan 2020

Can't someone else test my build apart from @ExceptionGit and report if DHT and udp trackers are working via proxy?
Link to my build (again): https://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735_v2.7z

udp trackers still do not work, DHT only works if its turned off and on and its very slow.
Use Proxy for Peer connections
Any Interface
All IPv4 addresses

(N) 2020-01-07T00:54:01 - qBittorrent v4.2.1 started
(N) 2020-01-07T00:54:01 - Running in portable mode. Auto detected profile folder at: C:/Users/USBhost/Downloads/qbittorrent_4.2.1_x64_patched_for_issue_11735_v2/profile
(I) 2020-01-07T00:54:01 - Trying to listen on: {33FC9A4A-4BF2-4E12-A02D-C6EC90432C08}:21027
(N) 2020-01-07T00:54:01 - Peer ID: -qB4210-
(N) 2020-01-07T00:54:01 - HTTP User-Agent is 'qBittorrent/4.2.1'
(I) 2020-01-07T00:54:01 - DHT support [OFF]
(I) 2020-01-07T00:54:01 - Local Peer Discovery support [OFF]
(I) 2020-01-07T00:54:01 - PeX support [OFF]
(I) 2020-01-07T00:54:01 - Anonymous mode [OFF]
(I) 2020-01-07T00:54:01 - Encryption support [ON]
(W) 2020-01-07T00:54:01 - Couldn't load GeoIP database. Reason: The system cannot find the path specified.
(N) 2020-01-07T00:54:01 - Options were saved successfully.
(I) 2020-01-07T00:54:01 - Successfully listening on IP: fe80::21f1:1b41:6bc9:c555%8, port: UDP/21027
(I) 2020-01-07T00:54:01 - Successfully listening on IP: 192.168.1.147, port: UDP/21027
(C) 2020-01-07T00:54:01 - Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [fe80::21f1:1b41:6bc9:c555%8]:0
(C) 2020-01-07T00:54:01 - Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [fe80::21f1:1b41:6bc9:c555%8]:0
(C) 2020-01-07T00:54:01 - Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [fe80::21f1:1b41:6bc9:c555%8]:0
(N) 2020-01-07T00:54:01 - 'censored ?' restored.
(W) 2020-01-07T00:54:11 - Couldn't download GeoIP database file. Reason: The remote host name was not found (invalid hostname)
(N) 2020-01-07T00:55:11 - Options were saved successfully.
(I) 2020-01-07T00:55:11 - Trying to listen on: 0.0.0.0:21027
(I) 2020-01-07T00:55:11 - Successfully listening on IP: 0.0.0.0, port: UDP/21027
(C) 2020-01-07T00:55:11 - Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [::]:0
(C) 2020-01-07T00:55:11 - Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [::]:0

However if I enable DHT while its running it finds the proxy's IP and i start finding nodes but slowly. After some time DHT finds peers for the torrent (all peers uses uTP), but the udp trackers still don't work.

(I) 2020-01-07T00:58:20 - DHT support [ON]
(W) 2020-01-07T00:58:20 - Restart is required to toggle PeX support
(N) 2020-01-07T00:58:20 - Options were saved successfully.
(I) 2020-01-07T00:58:28 - Local Peer Discovery support [ON]
(N) 2020-01-07T00:58:28 - Options were saved successfully.
(I) 2020-01-07T00:58:29 - Detected external IP: 46.166.186.206

If DHT is on at start up it does not find any nodes nor the proxy's ip.

(N) 2020-01-07T01:18:21 - qBittorrent v4.2.1 started
(N) 2020-01-07T01:18:21 - Running in portable mode. Auto detected profile folder at: C:/Users/USBhost/Downloads/qbittorrent_4.2.1_x64_patched_for_issue_11735_v2/profile
(I) 2020-01-07T01:18:21 - Trying to listen on: 0.0.0.0:21027
(N) 2020-01-07T01:18:21 - Peer ID: -qB4210-
(N) 2020-01-07T01:18:21 - HTTP User-Agent is 'qBittorrent/4.2.1'
(I) 2020-01-07T01:18:21 - DHT support [ON]
(I) 2020-01-07T01:18:21 - Local Peer Discovery support [OFF]
(I) 2020-01-07T01:18:21 - PeX support [OFF]
(I) 2020-01-07T01:18:21 - Anonymous mode [OFF]
(I) 2020-01-07T01:18:21 - Encryption support [ON]
(W) 2020-01-07T01:18:21 - Couldn't load GeoIP database. Reason: The system cannot find the path specified.
(N) 2020-01-07T01:18:21 - Options were saved successfully.
(I) 2020-01-07T01:18:21 - Successfully listening on IP: 0.0.0.0, port: UDP/21027
(C) 2020-01-07T01:18:21 - Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [::]:0
(C) 2020-01-07T01:18:21 - Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [::]:0
(N) 2020-01-07T01:18:21 - censored ?' restored.
(W) 2020-01-07T01:18:32 - Couldn't download GeoIP database file. Reason: The remote host name was not found (invalid hostname)
(W) 2020-01-07T01:20:03 - Restart is required to toggle PeX support
(N) 2020-01-07T01:20:03 - Options were saved successfully.

If i turn DHT off then On again it starts working and the proxy's ip is known.

(I) 2020-01-07T01:22:57 - DHT support [OFF]
(W) 2020-01-07T01:22:57 - Restart is required to toggle PeX support
(N) 2020-01-07T01:22:58 - Options were saved successfully.
(I) 2020-01-07T01:23:02 - DHT support [ON]
(W) 2020-01-07T01:23:02 - Restart is required to toggle PeX support
(N) 2020-01-07T01:23:02 - Options were saved successfully.
(I) 2020-01-07T01:23:02 - Detected external IP: 46.166.186.206

USBhost on 7 Jan 2020

@sledgehammer999 Do you want me to lend you my PIA socks5 proxy password for you to test around?

USBhost on 7 Jan 2020

Following; thanks for all those who are working toward a solution. All public trackers are "Not Working" with my PIA Proxy Active

nmadole on 12 Jan 2020

Can't someone else test my build apart from @ExceptionGit and report if DHT and udp trackers are working via proxy?
Link to my build (again): https://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735_v2.7z

I tried this when you first posted it, and it worked perfectly... All trackers worked, and I was able to connect to nearly a thousand peers.

Now it doesn't work again. Only http trackers work, and most torrents only get one or two connections, if any.

2020-01-12 17_24_15-qBittorrent v4 2 1 Web UI
2020-01-12 17_26_53-qBittorrent v4 2 1 Web UI

AussieEevee on 12 Jan 2020

The patched version is not working for me either ...

nmadole on 12 Jan 2020

@USBhost what is proxy_hostname set to? Can you resolve it with dig on the command line?

arvidn on 13 Jan 2020

I downgraded to 4.1.9 for now, and it's working perfectly again. Going to stick with this version for a bit.

AussieEevee on 14 Jan 2020

👍1

@sledgehammer999 Would you mind making another test build with this patch https://github.com/arvidn/libtorrent/pull/4249 ?

I've tested this with the PIA SOCKS5 proxy, and it "works". i.e. I do get a DHT routing table, I get peer connections, both uTP and TCP. However, I haven't really looked closely at whether I get as many peer connections and whether I get the same transfer rates.

The main theory of why this would be an improvement over current 1.2 branch is that it really just opens up a single SOCKS5 UDP tunnel, instead of multiple ones. And perhaps some proxy providers don't like the same user to open more than one at a time.

arvidn on 14 Jan 2020

👀1

I'd like to throw in my experience with the patched version (qbittorrent_4.2.1_x64_patched_for_issue_11735_v2.7z) that could possibly give insight into what's happening and a potential temporary workaround fix and a potential permanent fix. This is using NordVPN's Socks5.

The problem:
I know that 100% if I don't get the "Detected external IP: x.x.x.x" message in the log, then none of the trackers work even though DHT, PeX and LSD (I'll just call this group DHT from now on) says "working" in the tracker tab of each torrent. What also happens is that I can't get any new DHT peers and DHT nodes remain at 0. I can, however, still connect and download/upload to DHT peers that I already have saved from a previous qB program open. So it sounds like without the "Detected external IP" message, the outside world can't contact me, but I can contact the outside world to start a peer connection. It also sounds like the trackers and DHT nodes require that they can contact me before I'm allowed to connect to them.

And whenever I don't get the "external IP detected" message I see:
Socks5 error: SOCKS5 error. op: sock_read ec: End of file ep: x.x.x.x:x

Followed by:
Socks5 error: SOCKS5 error. op: connect ec: A connect request was made on an already connected socket ep: x.x.x.x:x

This happens 3 times in a row. And I assume that it's because when I go to "optional IP addresses to bind to (requires restart)" in the advanced settings I see 3 IPv4 addresses (192.1.168.x , ::1 , and 127.0.0.1). It doesn't matter if I try to bind to just one of those addresses; qB would still fail to detect an external IP most of the time when starting the program.

My workaround:
So to get the external IP address to pop up in the log, I used to have to restart qB over and over again. Now instead, I have to do the following, which has a higher success rate: In the "optional IP addresses to bind to (requires restart)" setting, I swap between the following two settings: IPv6 addresses and IPv4 addresses. If I swap between "All addresses" and one of those two, then nothing happens. It seems that if I swap between IPv6 and IPv4, then the settings take effect without requiring a restart. My guess is that there's code there to restart the whole Socks5 connection attempt. This code is not being executing when the Socks5 connection fails, though (or at least not doing it immediately).

So if I were to code a temporary hack-job fix to this, it'd be to see if an external IP address is detected. And then if it's not after a period of time, realize that the Socks5 is not actually connected. Then take the code from the "optional IP addresses to bind to (requires restart)" setting change from IPv6 to IPv4 to reattempt the Socks5 connection.

What I think is going on:
Since we have this error: Socks5 error: SOCKS5 error. op: connect ec: A connect request was made on an already connected socket ep: x.x.x.x:x It appears that the socket connection isn't properly getting terminated when you close qB. You can duplicate this bug by just simply successfully detecting an external IP, closing the program, and then restarting the program immediately. You'd almost be guaranteed to get the error. Now what I think happens is that after a few seconds, the socket is terminated somewhere due to a timeout (whether by the VPN or your computer). qB isn't necessarily the one terminating the socket, because if you close qB and then wait 10 seconds or so, you'll be able to get the "detected external IP" message in the log on the next restart (so it seems like the connection is terminated several seconds after qB is already closed). However, I might still get 1 or 2 error messages about the socket still being connected after the detected external IP message, which I assume means that 1-2 out of the 3 IPv4 addresses it could have binded to failed, but one managed to work because it timed out and terminated during the 10 second wait.

Additional information on why I think this is happening:
Back in version 4.1.x, whenever I'd close qB with the socks5 proxy, it would leave a zombie process in the task manager. This doesn't happen if I don't use the socks5 proxy. It also doesn't happen if no torrents are loaded (and thus no socks5 connections are made) even with a socks5 proxy enabled. Opening qB again wouldn't work if this zombie process existed. So I'd have to terminate qB through the task manager to get qB to open again. Version 4.2.0 fixed this issue. I'm able to close qB with a socks5 proxy enabled and there'd never be a zombie process. However, I believe that the zombie process is created in the first place because the socks5 socket connection fails to terminate. And even if that connection is terminated, the zombie process doesn't know and remains there. I assume that in version 4.2, it ignores the fact that the socks5 socket connection is still connected and still terminates the program anyway. That's great and all, but that would mean that on the next restart of qB, the socket connection would still be connected and therefore a new socks5 connection would fail.

Additional (most likely unrelated) information:
When I choose "All addresses" to bind to, qB tries to listen on:
Trying to listen on: 0.0.0.0:x,[::]:x

I assume that it's 0.0.0.0 because it's actually trying to listen on all addresses and instead of saying multiple addresses, it just gives you a blank one. But this leads to the following error:
Socks5 error: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [::]:0

This seems obvious and qB should probably just skip the hostname_lookup for ip 0.0.0.0.

regoapps on 14 Jan 2020

my suspicion is that most SOCKS5 providers don't like a single machine or user to have multiple UDP tunnels open and make new tunnels replace old ones. So, since libtorrent is currently opening redundant tunnels, the order of them being opened matters, only when the main interface's tunnel is opened last will it work.

I suspect that when libtorrent detects a new external IP, it re-opens listen sockets and it happens to open them in the right order to make it work.

In the patch I posted earlier, I fix the issue of opening multiple SOCKS5 tunnels, so there will be only one (at least one per source IP). The issue of trying to connect to the socks proxy and getting the error that the socket is already connected, is (most likely) a separate issue, and probably less important. It suggests that when re-opening listen interfaces/sockets, the tunnels aren't torn down correctly, and causes the next attempt to open them to fail. But in the typical case, they probably shouldn't be closed to begin with.

arvidn on 14 Jan 2020

Some more tests:
I had two computers on the same router run qB and I managed to get each to reach the "detected external ip" message and connect to the trackers and download/upload the same exact torrent, even though both are using the same username/password and same exact NordVPN socks5 server/ip address. So if my test means what I think it means, NordVPN is capable of running multiple socks5 tunnels from the same source ip/user and that my issue is different from the one you have with PIA.

When the patch for qB is posted, I'll give it a try and let you know if it fixes my issues. If it doesn't, I really hope that someone would write code to restart the socks5 connection if it doesn't reach the point in the log where it says "Detected external IP". I found another way to restart the socks5 connection by changing the listening port number in the settings. But I wish I didn't have to keep doing this manually.

regoapps on 15 Jan 2020

I'm pretty sure the causation is the other way around. "detected external IP" is the result of the DHT and peer connections working. Good data point on multiple tunnels though!

arvidn on 15 Jan 2020

I'm pretty sure, too. But I have no other way in the logs to tell me if a socks5 connection was made successfully since the log isn't very verbose, so I'm just using the "Detected external ip" message as a point in the flow that indicates that we successfully connected to socks5. I'm pretty sure a successful socks5 connection is made successfully before the "Detected external ip" message comes up, since I'm able to connect to trackers successfully even without that "Detected external ip" message showing up by turning DHT off (because with DHT turned off, the "detected external ip" message never shows up even if the socks5 connection was successful or not).

Anyway, it sounds like we have two different issues: Yours with PIA not liking multiple socks5 tunnels. And mine and a few others (calvilasboasjr, doxavk, possibly everyone else as well including PIA users), whose NordVPN (and other socks5) can connect to multiple socks5 tunnels, but doesn't always connect successfully (possibly because the socks5 socket isn't being torn down properly, so qB can't reuse the socket - according to the error messages). In both our cases, qB doesn't reattempt to connect to socks5 unless you restart the program or add a new torrent or change the port IP or change the ip address that it binds to from "ipv6 addresses only" to (all addresses or all ip4 addresses or to any of the ip4 addresses).

So I would just like a build where it does attempt to reconnect socks5 on failure automatically instead of us having to do it manually. That's all.

regoapps on 15 Jan 2020

I'd like to also add another data point:
Even after qB successfully connects to socks5 and the trackers/dht are working and getting peers, qB does sometimes stop working after adding a new torrent. Perhaps it's because adding a new torrent causes qB to try to reconnect to socks5 or something and that may cause it to fail (which becomes a permanent fail since it never tries to reconnect on its own). What's also odd is that if I had peers connected prior to this failure, the peers are still connected and downloading/uploading to me. So it seems like the socks5 connection is still alive, but qB no longer uses it to connect to trackers/dht. And then of course when I change the UPnP/Nat-PMP port number around, I can eventually get qB to reconnect to socks5 successfully, get the "detected external ip" message again, and the trackers are back to working again.

regoapps on 15 Jan 2020

@regoapps @sledgehammer999 @arvidn
Guys, there is away to turn qBitTorrent more Verbose as possible?!
I mean, if you guys could add this feature for us. "Better Verbose Mode"

Maybe with more details we can share more datas and try to find solutions for its issues.

What do you think guys?!

calvilasboasjr on 15 Jan 2020

More data points: Using wireshark to monitor traffic, I can confirm that after closing out qB with peers still download/uploading via Socks5, after restarting qB, the peers are still connected via Socks5 even though the trackers/DHT are "unreachable" by Socks5. So it does seem like the socket isn't torn down properly and because it wasn't torn down properly, Socks5 couldn't connect because the socket was already connected. And qB seems to still know to use the old Socks5 socket to connect with peers, but doesn't seem to know to use it for trackers/DHT.

I also downgraded to different versions of qB to look at the behavior of Socks5. It seems like all the 4.1.x versions do the same thing where the peers can connect via Socks5 from a previous session while the tracker/DHT aren't connected yet.

I also noticed that in version 4.1.x, it also has issues with connecting to Socks5 and doesn't always display the "External IP" message right away. Sometimes it'd be 3 minutes later before it displays it. This most likely means that even in 4.1.x it struggles to connect to Socks5. If version 4.1.x had Socks5 error messages in the log, I'd bet that it'd say the same thing as what it says in version 4.2.x (that the socket is already connected and therefore no new one is created). So it seems like the issue with connecting to Socks5 has been around for quite a while.

But the key difference between 4.1.x and 4.2.x is that in 4.1.x it reattempts to connect to Socks5 after it failed automatically. And in 4.2.x, it never does. I wish I could just fix this issue by downgrading to 4.1.x, but all versions of 4.1.x are bad too because they leave a zombie process in Windows 10 if you close the program while the program had a Socks5 connection active.

regoapps on 16 Jan 2020

UDP tunnels are a bit special in socks5. It's a TCP connection to set up the tunnel, but there's no message to tear it down. Instead, the TCP connection is kept open, and idle, for the duration of the tunnel. While the tunnel is up, UDP packets can flow via it, but they need an additional socks5 header for routing.

Once the process exits, all UDP and TCP sockets are shut down for sure. There's no way to have a socket open without a process owning it. However, you may still see incoming UDP packets via the tunnel, in case the proxy is still letting packets through.

So, when you say: "I can confirm that after closing out qB with peers still download/uploading via Socks5", what is the symptom you see exactly?

If you actually see packets being sent in wireshark, you can see which source port is thas, and figure out which process is sending them. I suspect qbt is still running if this happens though.

arvidn on 16 Jan 2020

Sorry for not making it clearer. This is what I do:

Open wireshark, see no activity.

Open qB, download a torrent and wait for peers to connect and download/upload. Verify that peers are using your socks5 proxy via wireshark.

While the peers are in the middle of transmitting, close qB. All activity stops. At this point, if I were using qB 4.1, a zombie process is left in the task manager, while qB 4.2 closes immediately. The zombie process does nothing: no disk or network activity or memory size change.

After killing qB, when I open qB again, the peers are connected immediately and still transmitting through the proxy, even though the proxy isn’t able to connect to trackers or DHT.

Even when I change the proxy settings, wireshark still shows peers transmitting through the original proxy IP that I had. Even if the trackers switch to the new proxy, the old peers are still using the old proxy until eventually they all switch to the new one.

Maybe this might give some insight into what’s going on? Any way that qB can recognize the socket that is being used to transmit to peers and use that to connect to trackers/DHT?

regoapps on 16 Jan 2020

I'll add my 2¢ to this since I'm seeing something similar. Close QB and
the Window closes, but the process doesn't terminate. Under Windows 10
Pro I have to open Task Manager and manually kill the QB process. This
always happens with 4.1.x, sometimes happens with 4.2.x. 4.2.x is
better behaved from 4.1.x, but still a long way from working. I'm using
PIA for my proxy service, and I'll admit the problem could also be in
PIA-SOCK5 Proxy. Even if the problem is in PIA, there must be a
workaround for PIA which works.

On 1/16/2020 12:32 PM, Arvid Norberg wrote:
>

UDP tunnels are a bit special in socks5. It's a TCP connection to set
up the tunnel, but there's no message to tear it down. Instead, the
TCP connection is kept open, and idle, for the duration of the tunnel.
While the tunnel is up, UDP packets can flow via it, but they need an
additional socks5 header for routing.

Once the process exits, all UDP and TCP sockets are shut down for
sure. There's no way to have a socket open without a process owning
it. However, you may still see incoming UDP packets via the tunnel, in
case the proxy is still letting packets through.

So, when you say: "I can confirm that after closing out qB with peers
still download/uploading via Socks5", what is the symptom you see exactly?

If you /actually/ see packets being /sent/ in wireshark, you can see
which source port is thas, and figure out which process is sending
them. I suspect qbt is still running if this happens though.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/11735?email_source=notifications&email_token=AOATW64ROBQODYG3MNXYX7TQ6C76DA5CNFSM4J6OCB7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJFOJ7A#issuecomment-575333628,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOATW66YL73WU6S7RG2IXGDQ6C76DANCNFSM4J6OCB7A.

RandomInhabitant on 16 Jan 2020

👍1

Any further word on a fix for this?

HnyBear on 20 Jan 2020

A "fix" would require that the "cause" be well understood and affected
code identified. From what I've been able to observe it looks like
we're still trying to nail down "symptoms". This isn't a simple problem.

If I'm wrong, then someone please explain the "cause" of this behavior
and identified code.

On 1/20/2020 12:03 AM, HnyBear wrote:
>

Any further word on a fix for this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/11735?email_source=notifications&email_token=AOATW65ZCR3B2KLZ5CV4RXDQ6VLETA5CNFSM4J6OCB7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJLWOOY#issuecomment-576153403,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOATW6YIENU5FL2WZQQTXJTQ6VLETANCNFSM4J6OCB7A.

RandomInhabitant on 20 Jan 2020

@HnyBear I've landed the main patch (in libtorrent) that I think will at least significantly improve the situation. I'm not able to reproduce any of the issues in my own tests (not using qbt) with a PIA SOCKS5 proxy. There are a few more to land, perhaps most importantly this UPnP related patch.

Once I believe libtorrent RC_1_2 branch is good, I'll ping @sledgehammer999 here again for a test build.

arvidn on 20 Jan 2020

👍2

@sledgehammer999 @glassez @Chocobo1
These new additions to the libtorrent documentation also mention SOCKS5 proxies, might be of interest:
https://github.com/arvidn/libtorrent/pull/4267

FranciscoPombal on 20 Jan 2020

@sledgehammer999 I think RC_1_2 is in a good place now. It has some fixes that I think may improve or fix these problems. If it doesn't, it has slightly better logging. I think it would be good to get a test build of qbt on top of RC_1_2

arvidn on 21 Jan 2020

👍1

Really looking forward to a build to try this out.

amsterdampaul on 21 Jan 2020

I'm looking forward to the new version. Thanks for the work. I have another data point for you guys. I can get the patched qbt 4.2.1 to consistently fail with socks5 even after it worked before. You just have to put your computer to sleep and when it wakes up again, you'll get a socks5 error and trackers/dht will stop working. This is the socks5 error:

1/21/2020 1:15 PM - Socks5 error: SOCKS5 error. op: hostname_lookup ec: The requested name is valid, but no data of the requested type was found ep: 107.181.164.80:1080 1/21/2020 5:16 AM - Socks5 error: SOCKS5 error. op: sock_read ec: The network connection was aborted by the local system ep: 107.181.164.80:1080 1/21/2020 5:10 AM - Detected external IP: 107.181.164.81

Interestingly enough, socks5 still works in other ways. For example, I'm still able to retrieve and parse RSS through the socks5 proxy, and I'm still able to download/upload to peers that I was connected to prior to putting my computer to sleep. Only the trackers/dht will stop working.

regoapps on 21 Jan 2020

While I don't have the patched version installed to offer logging info, I've stumbled upon some additional info which could be useful:

I added a bunch of manual http trackers to get around this problem. However, it seems like contacting trackers stops or stalls out on the first udp tracker if one appears in the list. The torrents will sit there with all the behavior in this issue, until I remove that first udp tracker, then MAGIC! It picks up all the seeds and starts trucking along.

aaronmgriffin on 24 Jan 2020

While I don't have the patched version installed to offer logging info, I've stumbled upon some additional info which could be useful:

I added a bunch of manual http trackers to get around this problem. However, it seems like contacting trackers stops or stalls out on the first udp tracker if one appears in the list. The torrents will sit there with all the behavior in this issue, until I remove that first udp tracker, then MAGIC! It picks up all the seeds and starts trucking along.

It's actually enough to just pick any tracker and update it's position (click any of the two arrows on the right hand side). This will "magically" start everything like you described.

Splike on 24 Jan 2020

Is anything happening? do we have progress on this?
My 4.1.9.1 is now become unstable on me. really need a working 4.2.x build

amsterdampaul on 24 Jan 2020

@Splike in your case, do you have any HTTP trackers or does poking around the trackers fix UDP trackers too?
This is all still when using a SOCKS5 proxy, right?

arvidn on 24 Jan 2020

For my side it's a SOCKS5 proxy where I've checked and unchecked all the
options to send all traffic through the proxy.

It's not 100% of the time though. Some things work just fine even WITH udp
trackers. It's so strange

On Fri, Jan 24, 2020, 10:19 AM Arvid Norberg notifications@github.com
wrote:

@Splike https://github.com/Splike in your case, do you have any HTTP
trackers or does poking around the trackers fix UDP trackers too?
This is all still when using a SOCKS5 proxy, right?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/11735?email_source=notifications&email_token=AAAAUCKIUA6ZKIZW2SIJ7HTQ7MIKVA5CNFSM4J6OCB7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJ3JXYI#issuecomment-578198497,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAAUCNDJFIF6N3DLMGVHJDQ7MIKVANCNFSM4J6OCB7A
.

aaronmgriffin on 24 Jan 2020

@arvidn I'm using PIA SOCKS5 proxy on qbit v4.2.1
Looking more closely, almost all my udp trackers are "Not Working", but both http and https trackers work for me.

The single udp tracker working is the one with tier 0. So it seems that when one works, the rest don't.

Splike on 25 Jan 2020

I am wondering if this issue with socks will ever get fixed in qbittorrent..

amsterdampaul on 27 Jan 2020

I just use version 4.1.9.1 for now. Then I keep my qB running all the time even if there are no torrents. And if my computer ever sleeps or my network connection ever fails, I run a .bat script that kills qB in the task manager (otherwise it leaves a zombie process) and reopens it. Turns out that qB’s socks5 stops working in version 4.1.x as well when my computer sleeps, so this socks5 issue has been around for a very long time (or more likely, some Windows 10 update broke it). That’s what I’ve done so far to get it working almost all the time.

regoapps on 27 Jan 2020

@regoapps It is interesting you mention that this has been around for a while. I've faced this socks5 issue many times over the past versions, well before 4.2.x. In 4.1.7 till 4.1.9, it has been mostly stable, but I have same situation as you.

Also, yes, if you stop qBittorrent, it always seems to leave this zombie process. Only through task manager can you kill it.

majora2007 on 27 Jan 2020

Please fix this. I cannot use my proxies...

seemslikeali on 28 Jan 2020

And if my computer ever sleeps or my network connection ever fails, I run a .bat script that kills qB in the task manager (otherwise it leaves a zombie process) and reopens it. Turns out that qB’s socks5 stops working in version 4.1.x as well when my computer sleeps, so this socks5 issue has been around for a very long time

This sounds like a separate issue. I don't recall it ever being reported, but as far as I can tell, it's unrelated to this ticket, which is about socks5 UDP working at all. You're saying that if the computer sleeps and wakes up, the socks5 UDP tunnel is not re-established?

arvidn on 28 Jan 2020

The zombie process only appears only when I use a socks5 proxy. Doesn’t happen if I don’t. So it might be related.

It’s been reported before but is closed with a solution that doesn’t work for me. The windows update said that needs to be removed doesn’t exist on my computer and others have reported that it happens even on a fresh Windows install: https://github.com/qbittorrent/qBittorrent/issues/9190

If I put my computer to sleep, UDP trackers and DHT stops connecting whether I’m only 4.1.9.1 or 4.2.1. Old established peers can still connect via the socks5 proxy. So it’s pretty much the same scenario as qB 4.2 on start-up (most of the time).

Another way to get UDP trackers and DHT to stop working is to remove qB from the windows firewall and then put it back in again. This severs the network connection and qB can’t recover from that.

regoapps on 28 Jan 2020

@regoapps this is a separate issue and should have its own ticket. Here's an attempt to address it in libtorrent: https://github.com/arvidn/libtorrent/pull/4290

arvidn on 29 Jan 2020

I wonder if as a workaround, it would be possible to have an option "Use proxy only for peer connections and not tracker connections", i.e. retrieve peers from tracker without any proxy, and do the p2p file transfers thru proxy, assuming that there has to be a way to retrieve peers from the tracker without having the tracker leak our public IP to other peers. However, I'm not very well versed on how trackers work at a fundamental level, please correct me if that's not possible.

AgentRev on 4 Feb 2020

👍1

the tracker would record your IP address and assume you can accept incoming connections from that IP. It would be much simpler to fix the bug than to add this feature (which also seems questionable to me).

I believe it has been fixed in the recently released libtorrent-1.2.4. At the very least, the situation has improved a lot. I would be interested in hearing if people are still having problems with it and what the symptoms are.

arvidn on 9 Feb 2020

Since the next update of qB seems to be taking a while, I'll tell you guys the workaround solution I have now to get Socks5 to work almost 100% of the time on Windows.

First, I use qB 4.1.9.1 and not 4.2 because 4.2 doesn't connect to socks5 100% of the time. qB 4.1.9.1 will connect to socks5 eventually almost all the time. I say "eventually", because sometimes it is a bit slow to connect to socks5, but it will at least reattempt to connect it after a while unlike qB 4.2.

Next, to get around the "zombie process after close" bug, create a .bat file with whatever name you want (e.g. restartqb.bat) with the following contents in it: https://pastebin.com/JAdYTb7c

What this does is ask Windows for admin privileges to be able to kill the qB process in the task manager. I have UAC (User Access Control) set to allow this to run without needing user interaction. The last line of the restartqb.bat file should be edited to wherever you've installed qB. It will restart qB for you after killing it. You'll need this restartqb.bat file for later.

Now, create a copy of this restartqb.bat file with a new name (e.g. killqb.bat) and delete the last line of the killqb.bat file so that it doesn't restart qB. Whenever you want to close qB, you should only use this new killqb.bat file to close qB because closing qB any other way risks leaving a zombie process. Important: Don't use the X button to close qB and don't use the "On downloads done: Exit qBittorrent" option or else you'll risk leaving a zombie process (which prevents qB from opening again).

Finally, there's another bug. The udp servers will stop working with socks5 if your computer sleeps. To get around this, open your Task Scheduler. Now create a new task. Add a new trigger.

Begin the task: On an event
Log: System
Source: Kernel-Power
Event ID: 131
Note: If Event ID 131 doesn't work for you, try Event ID 1. This is the trigger for when your computer wakes up from sleep.

Next, go to the Action tab, and add a new action.

Action: Start a program
Program/script: (put the location of where you put that restartqb.bat file that you created earlier - NOT the killqb.bat file).

And that should be it. Now qB should run reliably with socks5.

@arvidn Is there a way to test libtorrent-1.2.4 now? I'd love to try it out.

regoapps on 9 Feb 2020

It’s all open source. You just need to figure out how to build it and qbt (or find someone to do it for you). I don’t really have a windows machine.

arvidn on 9 Feb 2020

@sledgehammer999 new test build please?

Ryrynz on 11 Feb 2020

Sorry guys, I was really busy in real life.
Here is another build based on v4.2.1 and latest code from 1.2.x libtorrent (https://github.com/arvidn/libtorrent/commit/ad83b1c0eb293b63c69f7879ca6ba2381369f77f)

Link: https://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735_v3.7z

sledgehammer999 on 16 Feb 2020

👍7

There’s a patch against libtorrent that hasn’t landed yet that I believe fixes this issue. I would like to have at least one person confirm it fixes their issue before I land it though. Please make a test build agains: https://github.com/arvidn/libtorrent/pull/4331

arvidn on 17 Feb 2020

👍2

Actually, this issue was supposed to have been fixed by the 1.2.4 release, but people reported issues with that one too, which I’ve attempted to fix with that patch.

arvidn on 17 Feb 2020

👍1

Sorry guys, I was really busy in real life.
Here is another build based on v4.2.1 and latest code from 1.2.x libtorrent (arvidn/libtorrent@ad83b1c)

Link: https://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735_v3.7z

I tried this patch 4.2.1 build, but for me the DHT nodes never move from zero. go back to 4.1.9.1 and they go above zero.. so cannot say, for me, that it helped

amsterdampaul on 17 Feb 2020

@sledgehammer999 i think it would be good if QBitTorrent would log all error alerts, including tracker errors

arvidn on 17 Feb 2020

I'm running into this issue currently, here are the logs if it helps:

(N) 2020-02-18T19:24:59 - qBittorrent v4.2.1 started
(N) 2020-02-18T19:24:59 - Using config directory: /home/qbtuser/.config/qBittorrent/
(I) 2020-02-18T19:24:59 - Trying to listen on: 0.0.0.0:15721,[::]:15721
(N) 2020-02-18T19:24:59 - Peer ID: -qB4210-
(N) 2020-02-18T19:24:59 - HTTP User-Agent is 'qBittorrent/4.2.1'
(I) 2020-02-18T19:24:59 - DHT support [ON]
(I) 2020-02-18T19:24:59 - Local Peer Discovery support [ON]
(I) 2020-02-18T19:24:59 - PeX support [ON]
(I) 2020-02-18T19:24:59 - Anonymous mode [OFF]
(I) 2020-02-18T19:24:59 - Encryption support [ON]
(I) 2020-02-18T19:24:59 - UPnP / NAT-PMP support [ON]
(I) 2020-02-18T19:25:00 - GeoIP database loaded. Type: GeoLite2-Country. Build time: Tue Dec 10 07:06:53 2019.
(N) 2020-02-18T19:25:00 - Using built-in Web UI.
(W) 2020-02-18T19:25:00 - Couldn't load Web UI translation for selected locale (en_US).
(N) 2020-02-18T19:25:00 - Web UI: Now listening on IP: *, port: 8888
(I) 2020-02-18T19:25:00 - Successfully listening on IP: 0.0.0.0, port: UDP/15721
(I) 2020-02-18T19:25:00 - Successfully listening on IP: 2600:2108:f:8000:52e5:49ff:feee:41f8, port: TCP/15721
(I) 2020-02-18T19:25:00 - Successfully listening on IP: 2600:2108:f:8000:52e5:49ff:feee:41f8, port: UDP/15721
(I) 2020-02-18T19:25:00 - Successfully listening on IP: fe80::52e5:49ff:feee:41f8%enp5s0, port: TCP/15721
(I) 2020-02-18T19:25:00 - Successfully listening on IP: fe80::52e5:49ff:feee:41f8%enp5s0, port: UDP/15721
(C) 2020-02-18T19:25:00 - Unable to resume torrent '8643b406a95a9a87a7cb2605152b992d8cb94bcb'.
(I) 2020-02-18T19:25:00 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: UDP/15721
(W) 2020-02-18T19:25:00 - Couldn't download GeoIP database file. Reason: The remote host name was not found (invalid hostname)

Treverr on 19 Feb 2020

@sledgehammer999 in case you missed it, another test build please against arvidn/libtorrent#4331?

Ryrynz on 19 Feb 2020

there's some developments here: https://github.com/arvidn/libtorrent/issues/4325
I wouldn't bother with libtorrent 4331. I will provide another patch that I have more confidence in as soon as possible (but it may be this weekend).

arvidn on 19 Feb 2020

👍2

Sorry guys, I was really busy in real life.
Here is another build based on v4.2.1 and latest code from 1.2.x libtorrent (arvidn/libtorrent@ad83b1c)

Link: https://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735_v3.7z

Okay, I tried this but unfortunately udp and http tracker url still not working. In the meantime whilst waiting for the next patch I will continue running client with no socks5 proxy server and NordVPN App alongside. Thank-you for all your hard work trying to sort this out :)

condoghost on 1 Mar 2020

Okay, I tried this but unfortunately udp and http tracker url still not working. In the meantime whilst waiting for the next patch I will continue running client with no socks5 proxy server and NordVPN App alongside. Thank-you for all your hard work trying to sort this out :)

Thank you for testing, but that build is already outdated. It would be good if you can help test the following patch: https://github.com/arvidn/libtorrent/pull/4339.

@sledgehammer999 can you post a Windows build for people to test with the latest libtorrennt 1.2 commits + https://github.com/arvidn/libtorrent/pull/4339?

FranciscoPombal on 1 Mar 2020

@sledgehammer999 I can test on ubuntu if you can give me a build as well

Treverr on 4 Mar 2020

I get one end of file and then one already open error, after startup. Then some download work but DHT and UDP trackers stay broken.

EDIT: using the v3 build.

8-3-2020 17:47 - Socks5 error: SOCKS5 error. op: sock_open ec: Already open ep: <proxy-server-ip>:1080
8-3-2020 17:47 - Socks5 error: SOCKS5 error. op: sock_read ec: End of file ep: <proxy-server-ip>:1080
8-3-2020 17:47 - Detected external IP: <proxy-exitpoint-ip>
8-3-2020 17:47 - Couldn't download GeoIP database file. Reason: The remote host name was not found (invalid hostname)
8-3-2020 17:47 - Successfully listening on IP: <internal-ip>, port: UDP/51959
8-3-2020 17:47 - Options were saved successfully.
8-3-2020 17:47 - Web UI: Now listening on IP: 127.0.0.1,<two-internal-ips>, port: 8085
8-3-2020 17:47 - Web UI translation for selected locale (en) has been successfully loaded.
8-3-2020 17:47 - Using built-in Web UI.
8-3-2020 17:47 - GeoIP database loaded. Type: GeoLite2-Country. Build time: di dec 17 20:59:54 2019.
8-3-2020 17:47 - Encryption support [ON]
8-3-2020 17:47 - Anonymous mode [OFF]
8-3-2020 17:47 - PeX support [ON]
8-3-2020 17:47 - Local Peer Discovery support [ON]
8-3-2020 17:47 - DHT support [ON]
8-3-2020 17:47 - HTTP User-Agent is 'qBittorrent/4.2.1'
8-3-2020 17:47 - Peer ID: -qB4210-
8-3-2020 17:47 - Trying to listen on: <internal-ip>:0
8-3-2020 17:47 - Using config directory: <app-roaming-dir>
8-3-2020 17:47 - qBittorrent v4.2.1 started

EraYaN on 8 Mar 2020

@arvidn as of 1.2.5 only the DHT issue remains, right?

FranciscoPombal on 8 Mar 2020

I don't think there is an issue actually. No more than usual with the DHT. The thing is that the DHT doesn't refresh everything all the time, it will gradually ping and time-out old peers and get new ones. So, switching network interfaces will cause a glitch in the DHT. But I'm pretty sure it recovers eventually, it might just not be all that quick.

arvidn on 8 Mar 2020

could someone make a build based on libtorrent RC_1_2?

arvidn on 8 Mar 2020

@arvidn

ssue actually. No more than usual with the DHT. The thing is that the DHT doesn't refresh everything all the time, it will gradually ping and time-out old peers and get new ones. So, switching network interfaces will cause a glitch in the DHT. But I'm

Ok, I was assuming from this https://github.com/arvidn/libtorrent/issues/4325#issuecomment-595485626 that it wasn't recovering at all.

FranciscoPombal on 8 Mar 2020

I am still needing to completely restart qbit and occasionally needing to pause then start the torrents to get them downloading again.

HnyBear on 8 Mar 2020

@HnyBear is this with libtorrent RC_1_2 branch?

arvidn on 8 Mar 2020

Whatever build was last posted by sledgehammer in here. The one he posted 21 days ago.

HnyBear on 8 Mar 2020

Okay, I tried this but unfortunately udp and http tracker url still not working. In the meantime whilst waiting for the next patch I will continue running client with no socks5 proxy server and NordVPN App alongside. Thank-you for all your hard work trying to sort this out :)

Thank you for testing, but that build is already outdated. It would be good if you can help test the following patch: arvidn/libtorrent#4339.

@sledgehammer999 can you post a Windows build for people to test with the latest libtorrennt 1.2 commits + arvidn/libtorrent#4339?

Do we have a build yet we can test with? Thank-you.

condoghost on 9 Mar 2020

Disclaimer: I'm not a developer/maintainer from this project or any other (_use at your own risk_)

Here's a Windows build of qBittorrent 4.2.1 with libtorrent 1.2.5 I compiled using the wiki page instructions from related branches below:

qBittorrent-4_2_x Branch
118af03534e5ded6d3c8323b5dbeeff57b177193

libtorrent-RC_1_2 Branch
bc666052c7f77183fd3cade654d8521426f40404

Download qBittorrent 4.2.1 with libtorrent 1.2.5

qBittorrent 4 2 1 self-compiled

xavier2k6 on 10 Mar 2020

Disclaimer: I'm not a developer/maintainer from this project or any other (_use at your own risk_)

Here's a Windows build of qBittorrent 4.2.1 with libtorrent 1.2.5 I compiled using the wiki page instructions from related branches below:

qBittorrent-4_2_x Branch
118af03534e5ded6d3c8323b5dbeeff57b177193

libtorrent-RC_1_2 Branch
bc666052c7f77183fd3cade654d8521426f40404

Download qBittorrent 4.2.1 with libtorrent 1.2.5

Sadly for me this did not solve the issue.
Open using this binary and I get no DHT nodes over socks5 proxy even after many minutes.
switch back to the 4.1.9.1 binary and I get 292 within few seconds..

amsterdampaul on 10 Mar 2020

@amsterdampaul do you get any error messages in the log?

arvidn on 10 Mar 2020

@amsterdampaul do you get any error messages in the log?

No, I only have logging about torrent file processing and then it prints out my ext IP.

do I need to enable extra logging somewhere?

amsterdampaul on 10 Mar 2020

Disclaimer: I'm not a developer/maintainer from this project or any other (_use at your own risk_)

Here's a Windows build of qBittorrent from the master repo with libtorrent 1.2.5 I compiled using the wiki page instructions from related branches below:

qBittorrent-master Branch
f80b7affd9bc75adea62323e1d0cdf5bdf83fb85

libtorrent-RC_1_2 Branch
bc666052c7f77183fd3cade654d8521426f40404

Download qBittorrent Master Build with libtorrent 1.2.5

qBittorrent 4 3 0 self-compiled

xavier2k6 on 10 Mar 2020

does qbt master enable more logging?

arvidn on 11 Mar 2020

does qbt master enable more logging?

I honestly don't know the answer to that, I compiled a build from master in case there had been some related fix included as nothing from master has been merged in to 4.2.x branch since 17 dec'19

xavier2k6 on 11 Mar 2020

Disclaimer: I'm not a developer/maintainer from this project or any other (_use at your own risk_)

Here's a Windows build of qBittorrent from the master repo with libtorrent 1.2.5 I compiled using the wiki page instructions from related branches below:

qBittorrent-master Branch
f80b7affd9bc75adea62323e1d0cdf5bdf83fb85

libtorrent-RC_1_2 Branch
bc666052c7f77183fd3cade654d8521426f40404

Download qBittorrent Master Build with libtorrent 1.2.5

I used that build but still no connection to UDP trackers when added via magnet-links with socks5 proxy on (torguard proxy supports udp). I tested it with:

magnet:?xt=urn:btih:0f9bde94c78cfb8a61627fdc82efe18460d570ee&dn=Kali%20Linux%20-%20An%20Ethical%20Hacker%27s%20Cookbook%20-%20End-to-end%20penetrati&tr=udp%3a%2f%2ftracker.leechers-paradise.org%3a6969&tr=udp%3a%2f%2fzer0day.ch%3a1337&tr=udp%3a%2f%2fopen.demonii.com%3a1337&tr=udp%3a%2f%2ftracker.coppersurfer.tk%3a6969&tr=udp%3a%2f%2fexodus.desync.com%3a6969

When starting a regular torrentfile-download it works. Log also shows correct external (proxy) IP. The magnet-torrent stalls at downloading metadata.

23.03.20 15:05 - UPnP/NAT-PMP: Fehler beim Portmapping, Meldung: could not map port using UPnP: no router found
23.03.20 15:04 - 'Kali Linux - An Ethical Hacker's Cookbook - End-to-end penetrati' zur Liste der Downloads hinzugefügt.
23.03.20 15:03 - Erkenne externe IP: 185.156.172.154
23.03.20 15:03 - 'ubuntu-18.04.4-desktop-amd64.iso' zur Liste der Downloads hinzugefügt.
23.03.20 15:03 - Erste und letzte Teile zuerst laden: Aus, Torrent: 'ubuntu-18.04.4-desktop-amd64.iso'
23.03.20 15:03 - 'Kali Linux - An Ethical Hacker's Cookbook - End-to-end penetrati' wurde von der Übertragungsliste entfernt.
23.03.20 15:02 - 'Kali Linux - An Ethical Hacker's Cookbook - End-to-end penetrati' wiederhergestellt.
23.03.20 15:02 - Lausche erfolgreich auf IP: ::1, Port: UDP/61587
23.03.20 15:02 - Lausche erfolgreich auf IP: XXX, Port: UDP/61586
23.03.20 15:02 - Lausche erfolgreich auf IP: XXX, Port: UDP/61585
23.03.20 15:02 - Lausche erfolgreich auf IP: XXX, Port: UDP/61584
23.03.20 15:02 - Lausche erfolgreich auf IP: 127.0.0.1, Port: UDP/61583
23.03.20 15:02 - Lausche erfolgreich auf IP: XXX, Port: UDP/59205
23.03.20 15:02 - Einstellungen wurden erfolgreich gespeichert.
23.03.20 15:02 - IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: So Mrz 1 01:39:31 2020.
23.03.20 15:02 - UPnP / NAT-PMP Unterstützung [EIN]
23.03.20 15:02 - Verschlüsselungsunterstützung [EIN]
23.03.20 15:02 - Anonymer Modus [EIN]
23.03.20 15:02 - PeX-Unterstützung [EIN]
23.03.20 15:02 - Lokale Peers (LPD) finden [EIN]
23.03.20 15:02 - DHT-Unterstützung [EIN]
23.03.20 15:02 - HTTP Benutzer-Agent ist 'qBittorrent/4.3.0alpha1'
23.03.20 15:02 - Peer-ID:-qB4300-
23.03.20 15:02 - Trying to listen on: 0.0.0.0:0,[::]:0
23.03.20 15:02 - Using config directory: C:/Users/XXX/AppData/Roaming/qBittorrent/
23.03.20 15:02 - qBittorrent v4.3.0alpha1 gestartet

migasQ on 23 Mar 2020

@migasQ does it work with a qBT build that uses libtorrent-1.2.3? or any other 1.2.x version? Is that the complete log? you don't see any error messages?

@sledgehammer999 I don't see any socks5 alerts in the log, does qbt print those?

arvidn on 23 Mar 2020

@migasQ does it work with a qBT build that uses libtorrent-1.2.3? or any other 1.2.x version? Is that the complete log? you don't see any error messages?

@sledgehammer999 I don't see any socks5 alerts in the log, does qbt print those?

@arvidn
Unfortunately qBittorrent does not log much by default, especially libtorrent stuff. Logging can be increased somewhat if it is configured with --enable-debug but even then that will not include the libtorrent stuff you are interested in.

@sledgehammer999 @Chocobo1 @glassez
I think is has become apparent that we need either a branch, build-time configuration or something to enable much more libtorrent logging. Otherwise diagnosing these libtorrent connectivity issues will continue to be very hard. Many users with many varied use-cases are doing everything properly (posting logs, screenshots, etc) when reporting problems, but the logs all look the similar and don't seem to indicate any problem.

A while back I tried to semi-successfully add some alert logging to try to solve an issue (https://github.com/qbittorrent/qBittorrent/issues/11879), I think we have to invest in something like that.

FranciscoPombal on 23 Mar 2020

I think is has become apparent that we need either a branch, build-time configuration or something to enable much more libtorrent logging.

"Currently" - If compiling libtorrent via the wiki instructions, it has debug-symbols=on logging=off so maybe logging should be changed to "on" when compiling??.....

There doesn't seem to be any logging "that I can see" for Qt either which there seems to be quiet a few issues for too so I'd be a "+1" in favor of more detailed logging where appropriate & wiki documentation to be updated/edited accordingly.

xavier2k6 on 23 Mar 2020

@xavier2k6 the logging=off feature in libtorrent is only controlling low-level debug logging. Things like being able to get a log entry for every bittorrent message being sent or received. All important error messages are still supported and should be logged by qbt (but it sounds like some of them aren't)

arvidn on 23 Mar 2020

@xavier2k6 the logging=off feature in libtorrent is only controlling low-level debug logging. Things like being able to get a log entry for every bittorrent message being sent or received. All important error messages are still supported and should be logged by qbt (but it sounds like some of them aren't)

Ah, I see......more internal work so on qbt's part.

xavier2k6 on 23 Mar 2020

@sledgehammer999 I don't see any socks5 alerts in the log, does qbt print those?

We haven't yet, I think we should add them anyway.
https://www.libtorrent.org/reference-Alerts.html#socks5_alert (new in 1.2.4)

Chocobo1 on 24 Mar 2020

As someone not very familiar with the qBT code; I would think it makes sense to have a black-list of alerts being logged, rather than a white-list. At least my impression is that there's effectively a white list of alerts considered important enough to log. Perhaps there could be a setting to log all alerts in the error category coming out of libtorrent. I don't think there would be that many more alerts. tracker error alerts is a notable example of alerts being filtered in the log.

arvidn on 24 Mar 2020

👍1

Just confirming qBittorrent v4.2.2 using Proxy Server SOCKS5? udp trackers are not working same as before. As soon as I set Proxy Server None and "Force reannounce", udp trackers start working. All your hard work continuing to sort out a solution is very much appreciated. Thank-you!

condoghost on 25 Mar 2020

@condoghost did this work in a previous release of qBT? If so, did it also work when you enabled force-proxy?

If it didn't work with force-proxy, you may have been misled to believe the proxy worked. In early versions of libtorrent, configuring a proxy was "best effort". i.e. if the proxy didn't support UDP (for example), UDP packets would be sent directly to the destination. This meant that configuring a proxy that didn't work at all (e.g. just some random IP), things would still work, but the proxy wasn't used.

arvidn on 25 Mar 2020

Won't turning off 'use proxy for peer connections' defeat the purpose of masking your IP from being tracked by others? Sure you can still have 'Use proxy only for torrents' checked, but doesn't that simply just transfer the content of the torrent through the proxy? Aren't you still 'announcing' that your IP (unmasked) is on the swarm.

I found this thread b/c I was having an issue with all the trackers being listed as Status = 'Not working'. What @condoghost said worked for me too, but isn't the whole point of the option to use SOCKS5 to mask your traffic/IP completely? Seems like this is just a half-baked solution...

Please correct me if I'm wrong, this is just my current understanding. I've found tons of threads on the trackers not working, but can't seem to find one that explains the issue clearly. There are also lots of closed Git issues, but none of them seem to address or explain the underlying problem. If I'm following, qBittorrent uses libtorrent... is qBittorrent going to get updated to the latest libtorrent (that I would assume addresses some of these SOCKS5 and tracker issues).

austinjordan on 26 Mar 2020

👀1

but isn't the whole point of the option to use SOCKS5 to mask your traffic/IP completely? Seems like this is just a half-baked solution...

The question is: how will you do it with Tor SOCKS5 proxy?

Even if we ignore the recommendation not to use Tor for torrents, I still haven't found a way to fully Tor-proxify both tracker and peer connections - torrents simply don't download and upload. I suppose it is the same with other proxies. The only thing that seems to work is Tor proxy to trackers. Have you different experience?

emanruse on 26 Mar 2020

How is this still not fixed in 4.2.2? Are we ever going to get a fix? It's been months.

HnyBear on 29 Mar 2020

@HnyBear

How is this still not fixed in 4.2.2? Are we ever going to get a fix? It's been months.

4.2.2 fixed part of the issues (VPNs now work correctly when "any interface" is selected). 4.2.3 will be released shortly with improved SOCKS5 error logging (https://github.com/qbittorrent/qBittorrent/pull/12232) so that hopefully the remaining issues can be fixed, either on qBittorrent's side or on libtorrent's side.

FranciscoPombal on 29 Mar 2020

👍1

I have any interface selected and it still requires me to restart several times a day to get it downloading again.

HnyBear on 29 Mar 2020

I have any interface selected and it still requires me to restart several times a day to get it downloading again.

Please provide more details to reproduce (exact steps, qBIttorrent settings you're using, whether or not you're using VPN/SOCKS5, etc) and go post over at https://github.com/qbittorrent/qBittorrent/issues/12253

FranciscoPombal on 29 Mar 2020

@condoghost did this work in a previous release of qBT? If so, did it also work when you enabled force-proxy?

If it didn't work with force-proxy, you may have been misled to believe the proxy worked. In early versions of libtorrent, configuring a proxy was "best effort". i.e. if the proxy didn't support UDP (for example), UDP packets would be sent directly to the destination. This meant that configuring a proxy that didn't work at all (e.g. just some random IP), things would still work, but the proxy wasn't used.

No I haven't been misled that the proxy worked in earlier versions. Proxy worked fine with v4.1.9.1 I "prove" this with every new version of qBittorrent ever since I discovered by chance a few years back that proxy in uTorrent did not work. I cross check using IP-Leak and IP Find Check. v4.2.0, v4.2.1 and v4.2.2 qBittorrent SOCKS 5 Proxy udp trackers clearly not working. Turn off SOCKS 5 Proxy, close restart clinet, and previously loaded udp trackers working. Turn Sock 5 Proxy on, close and reload client, previous loaded udp trackers that worked without Socks 5 continue downloading with Proxy SOCKS-5 set on - though clearly showing not working - and newly loaded torrents with udp trackers don't start downloading and show not working.

As for "a proxy that didn't work" and "just some random IP"? I know when a proxy doesn't work, I clearly know that with IP Leak. In anycase, I change my proxy regularly. With the proxy I set in qBittorrent where udp trackers are not working, it's the same P2P proxy I use in NordVPN Desktop App outside qBittorrent with Sock-5 proxy set off. Use it inside qBittorrent SOCKS-5 on udp trackers not working, use it outside qBittorrent SOCKS-5 proxy set off udp trackers working. Again I use IP Leak each and every time to check the proxy is working both inside and outside of qBittorrent so, no - it isn't a proxy that didn't work at all or just some "random IP".

I hope I've made this clear. I don't use qBittorrent with Proxy SOCKS-5 set with a proxy IP that isn't working. I'm fully aware a proxy IP can stop working, go down for maintenance or whatever whilst qBittorrent is running but for sure I've only ever been caught out with this "once". In real terms - an ideal world - I would expect qBittorrent to stop should a Proxy SOCK-5 setting stop connecting through the designated IP but no doubt someone will come back "that's impossible to code" or some such statement.

So, how do I survive using qBittorrent? Well, I didn't like the line spacing with v4.2.2 so I went back to v4.2.1 and run my proxy outside qBittorrent. It isn't the "ideal" because I'm forced to use that same proxy for all connections - browser, client, youtube, whatever. I prefer using proxy within the client because I then have complete freedom using, for example a non P2P proxy within one browser, a non P2P UK proxy for UK content such as BBC iPlayer, in a second browser, a non P2P US proxy in a third browser for US content - can't do this when using an app.

No - this isn't the proxy, this is qBittorrent libtorrent. That or NordVPN proxies no longer work within qBittorrent libtorrent for udp trackers since v1.9.1 but somehow I don't think NordVPN could ever be THAT selective "work with this version but not that version" :)

condoghost on 2 Apr 2020

@HnyBear

How is this still not fixed in 4.2.2? Are we ever going to get a fix? It's been months.

4.2.2 fixed part of the issues (VPNs now work correctly when "any interface" is selected). 4.2.3 will be released shortly with improved SOCKS5 error logging (#12232) so that hopefully the remaining issues can be fixed, either on qBittorrent's side or on libtorrent's side.

Sorry, but "no", your statement "4.2.2 fixed part of the issues (VPNs now work correctly when "any interface" is selected)"? When I set Proxy SOCKS-5 ON udp trackers do not show working and newly loaded torrents do not start downloading. I set Proxy Socks-5 OFF, close restart client, udp trackers in loaded torrents show working and torrents start down loading. Set Proxy SOCK-5 ON, close and re-open client, udp trackers of previously loaded torrents show not working, but torrents start downloading. Force announce on previously loaded udp trackers showing not working, eventually show working. Load a new torrent udp trackers not working and torrent doesn't start downloading. Force announce newly loaded trackers still not working and torrent not downloading.
Now we can continue doing this time after time, as I have done - set on, close restart, check, set off close restart check - as many times as we like we get exactly the same result every time.
Proxy SOCKS-5 set ON within qBittorrent v4.2.0 v4.2.1 v4.2.2? udp trackers do not show working and newly loaded torrents will never start downloading. We can play around with this as many times we like. Sometimes the udp start working sometimes previously loaded torrents start downloading but for sure newly loaded torrent do not show working and do not start downloading. I've tried this on some 30 occasions now with 60 different proxies, same result every time but hey, we are all very mush appreciative of all the effort going in to solving this.
As for "error logging" and "logs" and all that good stuff? Sorry but until I see a simple detailed instruction on the set-up of qBittorrent error logging and logs and reports I'm simply not in a position to "help". I'd love to-do but this 68-year-old-head needs to keep it "simple" these days.
Again, I'm very very grateful for all the hard work everyone is putting in to solve this regardless reading "4.2.2 fixed part of the issues (VPNs now work correctly when "any interface" is selected)" :)
I fully realise and fully appreciate this isn't an "easy solve".
Stay safe now - I myself on a 12-week lockdown. Don't be going "stir crazy" with the 99% Coronavirus-related news!

condoghost on 2 Apr 2020

👍1

I cannot reproduce this issue on ubuntu. I'm using this command line to test:

./client_test -f client-test.log -s . --alert_mask=error,connect,tracker --proxy_hostname=proxy-nl.privateinternetaccess.com --proxy_port=1080 --proxy_type=socks5_pw --proxy_username=XXX --proxy_password=XXX ubuntu-19.10-desktop-amd64.iso.torrent

And I make outgoing uTP connections and DHT nodes.

Looking in wireshark, I see this (TCP) connection to the socks5 proxy:

=> 00000000  05 02 00 02                                        ....
<=     00000000  05 02                                              ..
=> 00000004  01 08 78 32 38 33 30 36  35 38 0a XX XX XX XX XX   ..x28306 58.XXXXX
=> 00000014  XX XX XX XX XX                                     XXXXX
<=     00000002  01 00                                              ..
=> 00000019  05 03 00 01 00 00 00 00  00 00                     ........ ..
<=     00000004  05 00 00 01 6d c9 9a e9  af d5                     ....m... ..

So:

socks5 handshake (supports unathenticated and username+password)
proxy picks 2, username+password
send username+passeword
ok
UDP ASSOCIATE request (no requested destination address)
OK, UDP relay at 109.201.154.233:45013

The UDP packets are then wrapped in the SOCKS5 UDP header. For example:

                              00 00 00 01 79 83             ....y.
63 56 da bb 64 31 3a 61 64 32 3a 69 64 32 30 3a   cV..d1:ad2:id20:
16 24 3d 5d 5e 0c eb 0f 15 dc 16 9c 48 d4 bd 39   .$=]^.......H..9
ef 91 6e 20 39 3a 69 6e 66 6f 5f 68 61 73 68 32   ..n 9:info_hash2
30 3a 24 3e db 47 32 20 17 28 1d 66 3a fa 96 59   0:$>.G2 .(.f:..Y
e0 77 ed fb 46 c3 65 31 3a 71 39 3a 67 65 74 5f   .w..F.e1:q9:get_
70 65 65 72 73 31 3a 74 32 3a 5a 88 31 3a 76 34   peers1:t2:Z.1:v4
3a 4c 54 01 25 31 3a 79 31 3a 71 65               :LT.%1:y1:qe

This is an outgoing DHT message with the SOCKS5 header:

2 reserved zero bytes
fragment 0
address type 1 (IPv4)
destination address (4 bytes)
destination port (2 bytes)
the DHT packet

The protocol is described in RFC1928.

What do you see in wireshark? What does the SOCKS5 proxy say?

arvidn on 2 Apr 2020

To anyone having issues in this thread, try 4.2.3.

For the people with proxy issues, more specifically, if you can compile from source, test https://github.com/arvidn/libtorrent/pull/4498 please.

FranciscoPombal on 3 Apr 2020

To anyone having issues in this thread, try 4.2.3.

For the people with proxy issues, more specifically, if you can compile from source, test arvidn/libtorrent#4498 please.

I have tried 4.2.3 with my socks5 proxy and it still fails for me.

this is what I have in the log with 4.2.3 (even after 10mins I have zero DHT nodes showing)

03/04/2020 17:28 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: XXX.XXX.XXX.XXX:32768
03/04/2020 17:28 - Detected external IP: XXX.XXX.XXX.XXX
03/04/2020 17:28 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: XXX.XXX.XXX.XXX:32768
03/04/2020 17:28 - Ignoring SSL error, URL: "https://nyaa.uk/favicon.ico", errors: "The issuer certificate of a locally looked up certificate could not be found. No certificates could be verified"
03/04/2020 17:28 - UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: Invalid Arguments
...
03/04/2020 17:28 - Successfully listening on IP: 192.168.0.50, port: UDP/51042
03/04/2020 17:28 - Options were saved successfully.
03/04/2020 17:28 - Watching local folder: "F:\QBT_In"
03/04/2020 17:28 - IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: Wed Apr 1 01:49:13 2020.
03/04/2020 17:28 - UPnP / NAT-PMP support [ON]
03/04/2020 17:28 - Encryption support [ON]
03/04/2020 17:28 - Anonymous mode [ON]
03/04/2020 17:28 - PeX support [ON]
03/04/2020 17:28 - Local Peer Discovery support [ON]
03/04/2020 17:28 - DHT support [ON]
03/04/2020 17:28 - HTTP User-Agent is 'qBittorrent/4.2.3'
03/04/2020 17:28 - Peer ID: -qB4230-
03/04/2020 17:28 - Trying to listen on: 192.168.0.50:51042
03/04/2020 17:28 - Using config directory: C:/Users/amste/AppData/Roaming/qBittorrent/
03/04/2020 17:28 - qBittorrent v4.2.3 started

Log with 4.1.9.1 works, and after a minute or two I start to see DHT Nodes climb to the hundreds.

03/04/2020 18:25 - External IP: XXX.XXX.XXX.XXX
03/04/2020 18:25 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: UDP/51042
03/04/2020 18:25 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: TCP/51042
...
03/04/2020 18:25 - qBittorrent is successfully listening on interface 192.168.0.50 port: UDP/51042
03/04/2020 18:25 - qBittorrent is successfully listening on interface 192.168.0.50 port: TCP/51042
03/04/2020 18:25 - Options were saved successfully.
03/04/2020 18:25 - Watching local folder: "F:\QBT_In"
03/04/2020 18:25 - GeoIP database loaded. Type: GeoLite2-Country. Build time: Tue Dec 10 16:06:53 2019.
03/04/2020 18:25 - UPnP / NAT-PMP support [ON]
03/04/2020 18:25 - Embedded Tracker [OFF]
03/04/2020 18:25 - Encryption support [ON]
03/04/2020 18:25 - Anonymous mode [ON]
03/04/2020 18:25 - PeX support [ON]
03/04/2020 18:25 - Local Peer Discovery support [ON]
03/04/2020 18:25 - DHT support [ON]
03/04/2020 18:25 - HTTP User-Agent is 'qBittorrent/4.1.9.1'
03/04/2020 18:25 - Peer ID: -qB4191-
03/04/2020 18:25 - qBittorrent is trying to listen on interface 192.168.0.50 port: 51042
03/04/2020 18:25 - qBittorrent v4.1.9.1 started

amsterdampaul on 3 Apr 2020

@arvidn WIth 4.2.3, the logs now have the SOCKS5 error messages. See the comment above, for example.

FranciscoPombal on 3 Apr 2020

Excuse me if this is the wrong place to post this,
but these are my current SOCKS5 errors from the log when trying to connect to a SOCKS5 NordVPN server using the new qbittorrent 4.2.3

4/5/2020 5:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: 192.168.116.1:8888
4/5/2020 5:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: 98.142.213.12:1080
4/5/2020 5:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 98.142.213.12:1080
4/5/2020 5:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [::1]:8888
4/5/2020 5:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [fe80::f5c3:b129:853c:d728%6]:8888
4/5/2020 5:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [fe80::5dd1:6105:c65:7930%20]:8888
4/5/2020 5:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: [fe80::14fd:46cd:cb1b:8c50%16]:8888
4/5/2020 5:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: 127.0.0.1:8888
4/5/2020 5:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: Unknown error ep: 192.168.216.1:8888

I'm port forwarding from my router properly on port 8888 to my PC.

I don't know if this info is helpful or not. It's such a current issue that I haven't been able to find any way to fix it.

galacticboy2009 on 5 Apr 2020

@arvidn another log ahoy.

FranciscoPombal on 5 Apr 2020

Hi, it is hard to follow in the thread of comments if the following PR (https://github.com/arvidn/libtorrent/pull/4498/files) has indeed "fixed" the issue for anyone. Well it has for me. I do not have any SOCKS5 errors in the logs anymore.

To compile it I used the Arch Linux AUR package https://aur.archlinux.org/packages/libtorrent-rasterbar-git/ and modified it to check out proxy-interface branch. Yes I am running Manjaro Linux, an Arch Linux variation.
The version of QBittorrent is 4.2.3.

Happy to help provide more information if needed.

mederel on 9 Apr 2020

@mederel thanks for testing and posting the results. You're right about this thread getting to big.
This issue should probably be closed after an official qBIttorrent release is made with that fix included.

In the meantime, it would be great if more people could test with that libtorrent PR as well to further validate the result.

FranciscoPombal on 9 Apr 2020

For me, on windows 10, the socks5 errors still occur, meaning 4.2.2 and 4.2.3 is unusable.

amsterdampaul on 9 Apr 2020

For me, on windows 10, the socks5 errors still occur, meaning 4.2.2 and 4.2.3 is unusable.

Yes, the fix has not landed in any stable version yet. You have to compile from source with https://github.com/arvidn/libtorrent/pull/4498 to test the fix.

FranciscoPombal on 9 Apr 2020

@FranciscoPombal Hopefully Sledgehammer can get a 4.2.4 release sorted in the next week or two, looks to be a fairly important bug fix release in the same vein as 4.2.3.

Ryrynz on 9 Apr 2020

Libtorrent 1.2.6 needs to be released with that PR merged first. If you
would like to aid the process, participate in code review and testing the
PRs up on the libtorrent side.

On Thu, Apr 9, 2020, 7:27 AM Ryan notifications@github.com wrote:

@FranciscoPombal https://github.com/FranciscoPombal Hopefully
Sledgehammer can get a 4.2.4 release sorted in the next week or two, looks
to be a fairly important bug fix release in the same vein as 4.2.3.

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

NotTsunami on 9 Apr 2020

arvidn seems to be pretty good getting commits done in a timely manner, I'm sure we'll be seeing this merged and 1.2.6 soon enough ;)

Ryrynz on 9 Apr 2020

Socks5 and this is the error I have right now.

4/9/2020 5:10 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.167:1080
4/9/2020 5:10 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: 46.166.188.248:1080

HnyBear on 9 Apr 2020

@HnyBear

Socks5 and this is the error I have right now.

4/9/2020 5:10 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.167:1080
4/9/2020 5:10 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: 46.166.188.248:1080

Which version? 4.2.3 or compiled from source with https://github.com/arvidn/libtorrent/pull/4498?

FranciscoPombal on 9 Apr 2020

@FranciscoPombal @arvidn arvidn/libtorrent#4498 is commit355bb905cd9dfb6eeed66a6fe639b4e739bc30fd correct?

xavier2k6 on 9 Apr 2020

@xavier2k6

@FranciscoPombal @arvidn arvidn/libtorrent#4498 is commit355bb905cd9dfb6eeed66a6fe639b4e739bc30fd correct?

Correct. If you can provide a Windows test build, for the people with proxy issues to test, that would be really great.

FranciscoPombal on 9 Apr 2020

Correct. If you can provide a Windows test build, for the people with proxy issues to test, that would be really great.

qBittorrent 4.2.3 release or base off of master?

xavier2k6 on 9 Apr 2020

@xavier2k6 I think off of master would be best, since it includes another network-related fix that did not make it into 4.2.3: https://github.com/qbittorrent/qBittorrent/pull/12430

FranciscoPombal on 9 Apr 2020

👍1

@HnyBear

Socks5 and this is the error I have right now.

4/9/2020 5:10 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.167:1080
4/9/2020 5:10 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: 46.166.188.248:1080

Which version? 4.2.3 or compiled from source with arvidn/libtorrent#4498?

4.2.3

HnyBear on 9 Apr 2020

@xavier2k6 I think off of master would be best, since it includes another network-related fix that did not make it into 4.2.3: #12430

@FranciscoPombal
Here's a test build for people with this issue:
qbittorrent master with libtorrent #4498

xavier2k6 on 9 Apr 2020

🎉2 👍1

@amsterdampaul @galacticboy2009 @HnyBear
Anyone having proxy troubles please try the build posted by xavier in the comment above. If you still have issues, post the logs with the errors.

FranciscoPombal on 9 Apr 2020

@amsterdampaul @galacticboy2009 @HnyBear
Anyone having proxy troubles please try the build posted by xavier in the comment above. If you still have issues, post the logs with the errors.

Well I have mixed results: One the one hand I now directly have DHT connections with a socks5 proxy, which are increasing over time. Also UDP trackers are shown as working but its actually never downloading any data (with or without proxy activated). All torrents are in the status "stalled" or "downloading metadata" (for magnet torrent I freshly added). But there are no errors in the log. I justed compared 4.1.9 to see if I broke something but everything is working as expected there.

I tested booth @xavier2k6 win Version and a linux version I compiled from the current master and https://github.com/arvidn/libtorrent/pull/4498 included (the proxy-interface branch).

migasQ on 9 Apr 2020

My results with the test build on Windows are not the same as @MigasQ. I am able to download without issue (torrents are not stalled), but UDP trackers are all showing "Not working."

More info after further testing-
On 4.2.3 some UDP trackers connect and my connection status is green ("Online").
On the test build, no UDP trackers connect and my connection status is yellow ("No direct connections").

crafty35a on 10 Apr 2020

@amsterdampaul @galacticboy2009 @HnyBear @FranciscoPombal @xavier2k6
Anyone having proxy troubles please try the build posted by xavier in the comment above. If you still have issues, post the logs with the errors.

NIIIICE. I just launched that build and can confirm the SOCKS5 errors from the Execution Log are gone and my downloads seem happy. That being said usually a restart does temporarily fix pending downloads but WITH SOCKS5 errors. I'll leave the application open for a while and report back, but no SOCKS5 errors on startup is promising.

*Edit/Update: Nope, SOCKS5 error is back after running for a few minutes and torrents are 'stalled'... spoke to soon.

austinjordan on 10 Apr 2020

Having this issue on Ubuntu 18.04. Will try the new build Thanks!

Does this build cover qbitorrent-nox?

Fyb3roptik on 10 Apr 2020

Having this issue on Ubuntu 18.04. Will try the new build Thanks!

Does this build cover qbitorrent-nox?

The new build posted by xavier is for Windows only, and for the regular GUI version. If you are on Ubuntu, you can compile from source with latest libtorrent + https://github.com/arvidn/libtorrent/pull/4498

FranciscoPombal on 10 Apr 2020

@austinjordan @crafty35a please post your logs if there are errors.

FranciscoPombal on 10 Apr 2020

@crafty35a @migasQ I assume you have troubles with UDP trackers _only_ when using SOCKS5?

FranciscoPombal on 10 Apr 2020

@FranciscoPombal I'm not seeing any errors in the test build logs. 4.2.3 continues to throw Socks5 errors.

Regarding your other question, I'm now seeing a few UDP trackers connect even on the test build. Not sure what has changed vs. last night, sorry.

Test build still shows "no direct connections," 4.2.3 shows connectable (isn't this supposed to be impossible?)

crafty35a on 10 Apr 2020

@amsterdampaul @galacticboy2009 @HnyBear
Anyone having proxy troubles please try the build posted by xavier in the comment above. If you still have issues, post the logs with the errors.

Well I have mixed results: One the one hand I now directly have DHT connections with a socks5 proxy, which are increasing over time. Also UDP trackers are shown as working but its actually never downloading any data (with or without proxy activated). All torrents are in the status "stalled" or "downloading metadata" (for magnet torrent I freshly added). But there are no errors in the log. I justed compared 4.1.9 to see if I broke something but everything is working as expected there.

I tested booth @xavier2k6 win Version and a linux version I compiled from the current master and arvidn/libtorrent#4498 included (the proxy-interface branch).

For me this build does not fix my issue.
logs

10/04/2020 17:18 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: XXX.XXX.XXX.XXX:32768
10/04/2020 17:18 - Ignoring SSL error, URL: "https://rarbg.me/favicon.ico", errors: "The host name did not match any of the valid hosts for this certificate"
...
10/04/2020 17:18 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: XXX.XXX.XXX.XXX:32768
...
10/04/2020 17:18 - Successfully listening on IP: 0.0.0.0, port: UDP/51042
10/04/2020 17:18 - Options were saved successfully.
10/04/2020 17:18 - Watching local folder: "F:\QBT_In"
10/04/2020 17:18 - IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: Wed Apr 1 01:49:13 2020.
10/04/2020 17:18 - UPnP / NAT-PMP support [ON]
10/04/2020 17:18 - Encryption support [ON]
10/04/2020 17:18 - Anonymous mode [ON]
10/04/2020 17:18 - PeX support [ON]
10/04/2020 17:18 - Local Peer Discovery support [ON]
10/04/2020 17:18 - DHT support [ON]
10/04/2020 17:18 - HTTP User-Agent is 'qBittorrent/4.3.0alpha1'
10/04/2020 17:18 - Peer ID: -qB4300-
10/04/2020 17:18 - Trying to listen on: 192.168.0.50:51042
10/04/2020 17:18 - Using config directory: C:/Users/amste/AppData/Roaming/qBittorrent/
10/04/2020 17:18 - qBittorrent v4.3.0alpha1 started

amsterdampaul on 10 Apr 2020

@amsterdampaul can you disable "Download trackers's favicon" in advanced settings.

xavier2k6 on 10 Apr 2020

@amsterdampaul can you disable "Download trackers's favicon" in advanced settings.

did that, this is what I get in log, it didnt seem to make any difference to be seeing DHT nodes appear in the counter after X minutes.

10/04/2020 17:38 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: XXX.XXX.XXX.XXX:32768
10/04/2020 17:38 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: XXX.XXX.XXX.XXX:32768
...
10/04/2020 17:38 - Successfully listening on IP: 0.0.0.0, port: UDP/51042
10/04/2020 17:38 - Options were saved successfully.
10/04/2020 17:38 - Watching local folder: "F:\QBT_In"
10/04/2020 17:38 - IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: Wed Apr 1 01:49:13 2020.
10/04/2020 17:38 - UPnP / NAT-PMP support [ON]
10/04/2020 17:38 - Encryption support [ON]
10/04/2020 17:38 - Anonymous mode [ON]
10/04/2020 17:38 - PeX support [ON]
10/04/2020 17:38 - Local Peer Discovery support [ON]
10/04/2020 17:38 - DHT support [ON]
10/04/2020 17:38 - HTTP User-Agent is 'qBittorrent/4.3.0alpha1'
10/04/2020 17:38 - Peer ID: -qB4300-
10/04/2020 17:38 - Trying to listen on: 192.168.0.50:51042
10/04/2020 17:38 - Using config directory: C:/Users/amste/AppData/Roaming/qBittorrent/
10/04/2020 17:38 - qBittorrent v4.3.0alpha1 started

with 4.1.9.1
10/04/2020 17:40 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: UDP/51042
10/04/2020 17:40 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: TCP/51042
10/04/2020 17:40 - External IP: XXX.XXX.XXX.XXX
10/04/2020 17:40 - qBittorrent is successfully listening on interface 192.168.0.50 port: UDP/51042
10/04/2020 17:40 - qBittorrent is successfully listening on interface 192.168.0.50 port: TCP/51042
10/04/2020 17:40 - Options were saved successfully.
10/04/2020 17:40 - Watching local folder: "F:\QBT_In"
10/04/2020 17:40 - GeoIP database loaded. Type: GeoLite2-Country. Build time: Tue Dec 10 16:06:53 2019.
10/04/2020 17:40 - UPnP / NAT-PMP support [ON]
10/04/2020 17:40 - Embedded Tracker [OFF]
10/04/2020 17:40 - Encryption support [ON]
10/04/2020 17:40 - Anonymous mode [ON]
10/04/2020 17:40 - PeX support [ON]
10/04/2020 17:40 - Local Peer Discovery support [ON]
10/04/2020 17:40 - DHT support [ON]
10/04/2020 17:40 - HTTP User-Agent is 'qBittorrent/4.1.9.1'
10/04/2020 17:40 - Peer ID: -qB4191-
10/04/2020 17:40 - qBittorrent is trying to listen on interface 192.168.0.50 port: 51042
10/04/2020 17:40 - qBittorrent v4.1.9.1 started

amsterdampaul on 10 Apr 2020

Having this issue on Ubuntu 18.04. Will try the new build Thanks!
Does this build cover qbitorrent-nox?

The new build posted by xavier is for Windows only, and for the regular GUI version. If you are on Ubuntu, you can compile from source with latest libtorrent + arvidn/libtorrent#4498

I could do that, but I will just wait for a new build. I can deal with it for now. I would rather not dirty up my linux box if I dont have to. Thanks though!

Fyb3roptik on 10 Apr 2020

@Fyb3roptik

I could do that, but I will just wait for a new build. I can deal with it for now. I would rather not dirty up my linux box if I dont have to. Thanks though!

Friendly reminder you can test by running from the build folder without executing the traditional sudo make install at the end (and install libtorrent to a custom prefix rather than /usr/lib), thus not "dirtying up" your installation.

FranciscoPombal on 10 Apr 2020

After about 3.5 hours, these Socks5 errors popped up on the test build:

(W) 2020-04-10T12:04:23 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 194.59.250.234:1085
(W) 2020-04-10T12:04:28 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: 96.44.144.114:1085

crafty35a on 10 Apr 2020

@arvidn sorry to nag about this again, but since https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-608537869 there have been a few posts with SOCKS5 errors in the logs that could be of use to you.

FranciscoPombal on 10 Apr 2020

yeah, I believe there is still an issue there. It's on my list

arvidn on 10 Apr 2020

Hi guys... Can anyone post the link with last build for I test now?!
Thanks.

calvilasboasjr on 10 Apr 2020

I use SOCKET5, so I wanna test...

calvilasboasjr on 11 Apr 2020

Here, the log was:

11/04/2020 00:10 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: xxx.xxx.xxx.xxx:1000
11/04/2020 00:10 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: xxx.xxx.xxx.xxx:1000
11/04/2020 00:10 - Couldn't download IP geolocation database file. Reason: An unknown network-related error was detected
11/04/2020 00:10 - 'Westxxxxxxxxx' restored.
11/04/2020 00:10 - Successfully listening on IP: 0.0.0.0, port: UDP/55555
11/04/2020 00:10 - Options were saved successfully.
11/04/2020 00:10 - Couldn't load IP geolocation database. Reason: The system cannot find the path specified.
11/04/2020 00:10 - UPnP / NAT-PMP support [ON]
11/04/2020 00:10 - Encryption support [FORCED]
11/04/2020 00:10 - Anonymous mode [ON]
11/04/2020 00:10 - PeX support [ON]
11/04/2020 00:10 - Local Peer Discovery support [ON]
11/04/2020 00:10 - DHT support [ON]
11/04/2020 00:10 - HTTP User-Agent is 'qBittorrent/4.3.0alpha1'
11/04/2020 00:10 - Peer ID: -qB4300-
11/04/2020 00:10 - Trying to listen on: 0.0.0.0:55555,[::]:55555
11/04/2020 00:10 - Using config directory: C:/Users/xxx/AppData/Roaming/qBittorrent/
11/04/2020 00:10 - qBittorrent v4.3.0alpha1 started

calvilasboasjr on 11 Apr 2020

With the same settings, 3.3.16 works.

calvilasboasjr on 11 Apr 2020

@xavier2k6 Apparently https://github.com/qbittorrent/qBittorrent/pull/12430 _might_ have caused a pretty nasty regression: https://github.com/qbittorrent/qBittorrent/issues/12443; investigation in progress (personally, I cannot reproduce though). If you could post another SOCKS5 test build for Windows but without that particular qBittorrent commit, that would be great.

FranciscoPombal on 11 Apr 2020

@calvilasboasjr in the meantime, please try the build at https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-611737913

FranciscoPombal on 11 Apr 2020

ok... moment...

calvilasboasjr on 11 Apr 2020

This was the Build that I tested...
HTTP User-Agent is 'qBittorrent/4.3.0alpha1'

calvilasboasjr on 11 Apr 2020

11/04/2020 00:10 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: xxx.xxx.xxx.xxx:1000
11/04/2020 00:10 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: xxx.xxx.xxx.xxx:1000
11/04/2020 00:10 - Couldn't download IP geolocation database file. Reason: An unknown network-related error was detected
11/04/2020 00:10 - 'Westxxxxxxxxx' restored.
11/04/2020 00:10 - Successfully listening on IP: 0.0.0.0, port: UDP/55555
11/04/2020 00:10 - Options were saved successfully.
11/04/2020 00:10 - Couldn't load IP geolocation database. Reason: The system cannot find the path specified.
11/04/2020 00:10 - UPnP / NAT-PMP support [ON]
11/04/2020 00:10 - Encryption support [FORCED]
11/04/2020 00:10 - Anonymous mode [ON]
11/04/2020 00:10 - PeX support [ON]
11/04/2020 00:10 - Local Peer Discovery support [ON]
11/04/2020 00:10 - DHT support [ON]

11/04/2020 00:10 - HTTP User-Agent is 'qBittorrent/4.3.0alpha1' <<------------

11/04/2020 00:10 - Peer ID: -qB4300-
11/04/2020 00:10 - Trying to listen on: 0.0.0.0:55555,[::]:55555
11/04/2020 00:10 - Using config directory: C:/Users/xxx/AppData/Roaming/qBittorrent/

11/04/2020 00:10 - qBittorrent v4.3.0alpha1 started <<--------------

calvilasboasjr on 11 Apr 2020

👍1

@xavier2k6 Apparently #12430 _might_ have caused a pretty nasty regression: #12443; investigation in progress (personally, I cannot reproduce though). If you could post another SOCKS5 test build for Windows but without that particular qBittorrent commit, that would be great.

Ok, I will make a test build from previous commit 342eec7

It will probably be tomorrow morning before I post it though....

xavier2k6 on 11 Apr 2020

🎉1

@arvidn what commit from libtorrent do you want applied to new test build?

xavier2k6 on 11 Apr 2020

https://github.com/arvidn/libtorrent/pull/4498

but I have not yet addressed the "already open" issue people have posted

arvidn on 11 Apr 2020

@arvidn let me know here so when it's sorted & I will base the test build from that commit then. Thanks.

xavier2k6 on 11 Apr 2020

@crafty35a @migasQ I assume you have troubles with UDP trackers _only_ when using SOCKS5?

No with and without SOCKS5 - thats why I was confused. BUT!

@xavier2k6 Apparently #12430 _might_ have caused a pretty nasty regression: #12443; investigation in progress (personally, I cannot reproduce though). If you could post another SOCKS5 test build for Windows but without that particular qBittorrent commit, that would be great.

That did the trick. After setting the network-interface in the advanced settings to my actual network interface and not leaving it on the default setting I now get connections and it's actually downlaoding something. I will keep it running over the night and see if any SOCKS5 errors occur in the next hours.

@xavier2k6 Apparently #12430 _might_ have caused a pretty nasty regression: #12443; investigation in progress (personally, I cannot reproduce though). If you could post another SOCKS5 test build for Windows but without that particular qBittorrent commit, that would be great.

Ok, I will make a test build from previous commit 342eec7

It will probably be tomorrow morning before I post it though....

When the build is ready I will test it as well (or compile it by myself, depending on my time tomorrow).

migasQ on 11 Apr 2020

Errors I'm getting on the alpha build 4.3.0.alpha1

4/10/2020 8:02 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 109.201.154.207:1080
4/10/2020 8:02 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: 46.166.190.149:1080

HnyBear on 11 Apr 2020

I tried the Windows build from @xavier2k6 and it at first seemed to work perfectly just like magic, but then it crashed unexpectedly after a few hours and I'm not sure if there is any way to find a log that would explain that crash.

I've opened it a few more times, and sometimes I still get SOCKS5 proxy errors, but most of the time with some coercing it works, before it crashes without fail after a while.

Seems to be on the right track though. I don't know if any of this will help, but I'll be happy to try any future Windows builds. I'm a noob over here.

galacticboy2009 on 12 Apr 2020

but I have not yet addressed the "already open" issue people have posted

@galacticboy2009 I will provide another test build as soon as @arvidn gives me the go ahead that he has addressed the "already open" issue

In relation to the crash, can you look at event viewer & see if there's anything in the application logs at around the time of the crash which mentions qBittorrent.

Also, can you post your logs, taking care to remove any torrent info.

xavier2k6 on 13 Apr 2020

@FranciscoPombal have the go ahead needed now from libtorrent side, I've noticed changes in master relating to network interfaces etc so will I compile qBittorrent from latest master commit 5d1072 or do you still want to go with master 342eec7? I could do both (seperate - builds) if needed??

xavier2k6 on 13 Apr 2020

@xavier2k6

@FranciscoPombal have the go ahead needed now from libtorrent side, I've noticed changes in master relating to network interfaces etc so will I compile qBittorrent from latest master commit 5d10724

Yes, go for that one, 5d10724 (it's an important fix). Eventually a build with https://github.com/qbittorrent/qBittorrent/pull/12487 will also come in handy, but let's deal with one thing at a time.

I assume you'll be using the latest libtorrent RC_1_2 commit + https://github.com/arvidn/libtorrent/pull/4498 on top for the build?

FranciscoPombal on 13 Apr 2020

@galacticboy2009 I will provide another test build as soon as @arvidn gives me the go ahead that he has addressed the "already open" issue

In relation to the crash, can you look at event viewer & see if there's anything in the application logs at around the time of the crash which mentions qBittorrent.

Also, can you post your logs, taking care to remove any torrent info.

Event viewer reports an "Apphang" unknown error from qBittorrent, and that's it.
I've also discovered that the crash seems to only occur when I have qBittorrent minimized.
So I'm keeping it open/maximized for now.

It ran all night last night (at least since 5AM) though it ended up giving a SOCKS5 error at 7:15AM,
right at 1h30m of runtime.
(however, the program is still running, not crashed)

I opened the connection settings dialog,
edited the VPN server URL to be slightly wrong,
hit apply, then came back and edited it back again.
At that point, my torrents started working with no errors.

Using the exact same settings.
All it took was forcing qBittorrent to "reset" the VPN connection, basically.

4/13/2020 7:15 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_open ec: Already open ep: 196.247.50.13:1080
4/13/2020 7:15 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 196.247.50.13:1080
4/13/2020 5:45 AM - Detected external IP: 196.247.50.14
[CENSORED ALL THE TORRENTS FROM HERE]
4/13/2020 5:45 AM - Successfully listening on IP: 0.0.0.0, port: UDP/8888
4/13/2020 5:45 AM - Options were saved successfully.
4/13/2020 5:45 AM - Encryption support [ON]
4/13/2020 5:45 AM - Anonymous mode [ON]
4/13/2020 5:45 AM - PeX support [ON]
4/13/2020 5:45 AM - Local Peer Discovery support [ON]
4/13/2020 5:45 AM - DHT support [ON]
4/13/2020 5:45 AM - HTTP User-Agent is 'qBittorrent/4.3.0alpha1'
4/13/2020 5:45 AM - Peer ID: -qB4300-
4/13/2020 5:45 AM - Trying to listen on: 0.0.0.0:8888,[::]:8888
4/13/2020 5:45 AM - Using config directory: C:/Users/galac/AppData/Roaming/qBittorrent/
4/13/2020 5:45 AM - qBittorrent v4.3.0alpha1 started

galacticboy2009 on 13 Apr 2020

@galacticboy2009 I imagine this is a build without this recent libtorrent patch, right? https://github.com/arvidn/libtorrent/pull/4498

arvidn on 13 Apr 2020

@galacticboy2009 I imagine this is a build without this recent libtorrent patch, right? arvidn/libtorrent#4498

That was from the previous build (which had not yet addressed the "already open" issue people had reported)

Below is a new build from qBittorrent master 5d10724 with libtorrent 5a0e681 based off of arvidn/libtorrent#4498

Test Build

qbittorrent master 5d10724 with libtorrent 5a0e681 patch #4498

xavier2k6 on 14 Apr 2020

🎉3

@galacticboy2009 I imagine this is a build without this recent libtorrent patch, right? arvidn/libtorrent#4498

That was from the previous build (which had not yet addressed the "already open" issue people had reported)

Below is a new build from qBittorrent master 5d10724 with libtorrent 5a0e681 based off of arvidn/libtorrent#4498

Test Build

qbittorrent master 5d10724 with libtorrent 5a0e681 patch #4498

for me this build do not fix my problem with getting no DHT nodes if I am using my socks5 proxy.

Logs, constantly log these errors:
14/04/2020 09:33 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.142.163:32768
14/04/2020 09:33 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.142.163:32768
14/04/2020 09:33 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.142.163:32768
14/04/2020 09:33 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.142.163:32768
14/04/2020 09:33 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.142.163:32768

over and over...

amsterdampaul on 14 Apr 2020

@amsterdampaul it looks like your socks5 server keeps closing your connection. Are you sure it supports the socks5 UDP ASSOCIATE command?

arvidn on 14 Apr 2020

@amsterdampaul it looks like your socks5 server keeps closing your connection. Are you sure it supports the socks5 UDP ASSOCIATE command?

Its a paid-for service, and works fine with v4.1.9.1

amsterdampaul on 14 Apr 2020

works fine with v4.1.9.1

I'm not sure which version of libtorrent that is using, but before the force_proxy setting was removed, the default behavior was to simply not use the proxy if it didn't work. Which was problematic for a few reasons, one of them being that it's not obvious to users when the proxy isn't working.

arvidn on 14 Apr 2020

@amsterdampaul

Its a paid-for service, and works fine with v4.1.9.1

In that case, can you ask tech-support whether or not they support the socks5 UDP ASSOCIATE command? It could simply be that it was silently failing before (https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-613304214)

FranciscoPombal on 14 Apr 2020

👍1

No issues so far in about 10 hours on the latest test build from @xavier2k6.

crafty35a on 14 Apr 2020

🎉1

Only error I"ve seen all night so far but then again I didn't really have anything new downloading.

4/14/2020 3:39 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.154.214:1080

HnyBear on 14 Apr 2020

@HnyBear if that only happens rarely (say once an hour, or less often) it's expected. The proxy then probably have a limit on how long it allows connections to stay open

arvidn on 14 Apr 2020

The timeout error returned, but so far UDP trackers are still working, and I am still able to download.

(W) 2020-04-14T09:56:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 88.202.177.243:1085

crafty35a on 14 Apr 2020

@amsterdampaul

Its a paid-for service, and works fine with v4.1.9.1

In that case, can you ask tech-support whether or not they support the socks5 UDP ASSOCIATE command? It could simply be that it was silently failing before (#11735 (comment))

I asked them, and the advise me to use biglyBT as that works fine with their socks5 service...

amsterdampaul on 14 Apr 2020

I asked them, and the advise me to use biglyBT as that works fine with their socks5 service...

Not sure what BiglyBT does differently, but this could be useful info for @arvidn.

FranciscoPombal on 14 Apr 2020

I asked them, and the advise me to use biglyBT as that works fine with their socks5 service...

That doesn't sound like a "yes, we support UDP" to me :)
It could just be that BiglyBT doesn't support uTP and nobody notices that DHT doesn't work. I'm not saying this is the case, I'm saying that based of the information in this thread that is one possibility.

Not sure what BiglyBT does differently, but this could be useful info for

Wireshark would tell.

arvidn on 14 Apr 2020

I asked them, and the advise me to use biglyBT as that works fine with their socks5 service...

That doesn't sound like a "yes, we support UDP" to me :)
It could just be that BitlyBT doesn't support uTP and nobody notices that DHT doesn't work. I'm not saying this is the case, I'm saying that based of the information in this thread that is one possibility.

Not sure what BiglyBT does differently, but this could be useful info for

Wireshark would tell.

I will try capture the traffic with wireshark.

they pointed me at this ticket https://github.com/qbittorrent/qBittorrent/issues/7838

but as I said above I work fine I stick to v4.1.9.1, and based on the stats I see in glasswire a lot of data is flowing via that socks5 proxy, so I am reasonably confident it is getting used by the client v4.1.9.1

Correct me if I am wrong, but many of the other VPN solutions are not a simple as entering a proxy hostname/port/user/password in the client. I dont want to use a VPN for all connections on my client. I just want the torrent client to send its traffic safely..

I go and try to capture something in wireshark

amsterdampaul on 14 Apr 2020

keep in mind that the wireshark capture will contain your username and password in clear text, so you might want to scrub that, or change username and password afterwards.

I've been testing with PIA's socks5 proxy (with no problems), and I posted the packets I saw for the UDP ASSOCIATE command (with password scrubbed). I can't seem to find which ticket I posted that in though.

EDIT: it was further up this thread, it had just been collapsed by github. here.

arvidn on 14 Apr 2020

22+ hours now on the latest test build and everything continues to work. I have two socks5 related semaphore timeout errors in the log, but I'm not seeing any adverse effects.

crafty35a on 15 Apr 2020

👍1

@xavier2k6 @amsterdampaul https://github.com/arvidn/libtorrent/pull/4498 has landed

FranciscoPombal on 15 Apr 2020

🎉1

New master TEST build with a fix UDP ASSOCIATE SOCKS5 connection retry from libtorrent.

qBittorrent master commit e030fc0 with libtorrent RC_1_2 commit ebc2bfc

xavier2k6 on 16 Apr 2020

New master TEST build with a fix UDP ASSOCIATE SOCKS5 connection retry from libtorrent.

qBittorrent master commit e030fc0 with libtorrent RC_1_2 commit ebc2bfc

It's working well with SOCKS5. I will let it running for a couple of hours and see if there are any SOCKS5 reconnection issues. Also it was not necessary to specify the network interface, I could leave it on any interface in the Advanced settings.

migasQ on 17 Apr 2020

👍1

New master TEST build with a fix UDP ASSOCIATE SOCKS5 connection retry from libtorrent.

qBittorrent master commit e030fc0 with libtorrent RC_1_2 commit ebc2bfc

This is the only error I'm getting after running all night.

4/17/2020 6:20 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.154.132:1080

HnyBear on 17 Apr 2020

After 12h of seeding/ downloading (also adding new magnet torrents after a couple of hours), I am only getting a SOCKS5 connection was closed error after it was seeding for a long time. But the SOCKS5 still works because after I added a new magnet torrent it directly started to find seeders and started downloading. Good job @arvidn, @sledgehammer999, @xavier2k6 and @FranciscoPombal ! I think the SOCKS5 related DHT, UDP trackers, meta data stalling, etc. erros I experienced in the past seem to be resolved!

migasQ on 18 Apr 2020

🎉1

I've been having SOCKS5 issues for several years. I finally had to just set up a VM running a full proxy connection and a qbit babysitter to restart the app if and when the proxy disconnected. I'd love to be able to ditch the VM and go back to just a simple socks5. I've been following a few of these threads waiting for a solution. Gonna test this newest test build and cross my fingers!

Cunningcory on 18 Apr 2020

as far as I can tell, the vast majority of issues are solved now. If the server disconnects, libtorrent will reconnect. This is expected to happen every now and then as the SOCKS5 connection is idle and long lived.

However, there are still a few failure cases where libtorrent will not try again, for example, if the hostname lookup fails for the proxy server, or if the socks5 server IP cannot be reached. To do this properly, there would need to be some kind of back-off timer, to avoid hammering some poor IP.

Fixing these cases is not very high priority right now, since I think they only affect very few people and not very often.

arvidn on 18 Apr 2020

as far as I can tell, the vast majority of issues are solved now. If the server disconnects, libtorrent will reconnect. This is expected to happen every now and then as the SOCKS5 connection is idle and long lived.

However, there are still a few failure cases where libtorrent will not try again, for example, if the hostname lookup fails for the proxy server, or if the socks5 server IP cannot be reached. To do this properly, there would need to be some kind of back-off timer, to avoid hammering some poor IP.

Fixing these cases is not very high priority right now, since I think they only affect very few people and not very often.

I think as soon as 4.2.4 is released, we can close this thread and open a new one specifically to track _infrequent_ SOCKS5 disconnects.

@sledgehammer999 what are your plans for the release date of 4.2.4? It seems all of the more important issues have been resolved (there are a couple of important PRs that have not yet been merged, but are almost there). Same on the libtorrent side. In fact, 1.2.6 should be nearing official release, but the remaining stuff in the milestone at this point is not that important.

FranciscoPombal on 18 Apr 2020

New master TEST build with a fix UDP ASSOCIATE SOCKS5 connection retry from libtorrent.

qBittorrent master commit e030fc0 with libtorrent RC_1_2 commit ebc2bfc

Is this 4.2.3 or 3.4.0alpha? I downloaded an earlier build and it was 4.3.0alpha.

RabidWolf on 18 Apr 2020

@RabidWolf it's an updated alpha build

xavier2k6 on 18 Apr 2020

Thanks will wait for 3.2.4

RabidWolf on 18 Apr 2020

Back to not downloading after a day or so. Seeing this error.

4/18/2020 8:03 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: The semaphore timeout period has expired ep: 109.201.154.207:1080
4/18/2020 8:03 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 109.201.154.216:1080
4/18/2020 8:03 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.186.196:1080
4/18/2020 8:02 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 109.201.152.23:1080

HnyBear on 20 Apr 2020

👍3

Same here unfortunately, here is the log.

(W) 2020-04-19T16:01:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 68.71.244.34:1085
(I) 2020-04-19T16:04:03 - Detected external IP: 68.71.244.38
(W) 2020-04-19T16:16:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 68.71.244.38:1085
(I) 2020-04-19T16:21:09 - Detected external IP: 88.202.177.231
(W) 2020-04-19T16:28:20 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 88.202.177.231:1085
(I) 2020-04-19T16:31:44 - Detected external IP: 96.44.147.106
(W) 2020-04-19T17:00:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 96.44.147.106:1085
(I) 2020-04-19T17:05:54 - Detected external IP: 173.44.37.82
(W) 2020-04-19T17:34:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 173.44.37.82:1085
(I) 2020-04-19T17:39:06 - Detected external IP: 194.59.250.234
(W) 2020-04-19T18:21:54 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 194.59.250.234:1085
(W) 2020-04-19T18:22:01 - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 88.202.177.238:1085

crafty35a on 20 Apr 2020

👍4

Mine has also crapped out. What a bummer. I was hoping this was fixed. My log would get this message every few hours:

4/20/2020 6:32 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.161:1080

This was followed five minutes later with a new IP detection:

4/20/2020 6:37 AM - Detected external IP: 109.201.152.234

This didn't seem to be an issue for a while, but most recently instead of getting a new IP detection, I instead got a new error message immediately following it:

4/20/2020 5:38 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 109.201.138.233:1080
4/20/2020 5:38 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: End of file ep: 109.201.154.198:1080

The handshake error seems to be the one that permanently kills the connection.

Cunningcory on 21 Apr 2020

For whatever reason, this completely cleared up doing a fresh ubuntu install. I havent had to restart the service in about a week and a half! I sure hope you guys can get it figured out!

Fyb3roptik on 21 Apr 2020

An observation:

I have two torrents that will not work with SOCKS5 on. They were begun after qBittorrent sat idle for ~1 day. I've restarted, paused and unpaused, changed the host and put it back, unchecked authentication and rechecked, and every combo of these steps you can think of. No love.

However, if I pause the second one and turn off the proxy server, the first will start. Now if I enable the proxy server with authentication and "use proxy only for torrents" unchecked (my normal settings), then resume the second one, it will start. I haven't gone so far as to check the reported IP of the second torrent using the TorGuard torrent, but I will soon.

If anyone can test and confirm/deny this, it might help.

coreyemtp on 21 Apr 2020

I did run the CheckMyIPTorrent torrent, and it is indeed hiding my IP:

21.04.2020 06:42:23 | 109.201.138.225 | qBittorrent/4.3.0alpha1
21.04.2020 06:41:39 | 46.166.137.203 | qBittorrent/4.3.0alpha1
21.04.2020 06:41:37 | 46.166.137.203 | qBittorrent/4.3.0alpha1

Interesting that it switched IPs so quickly.

coreyemtp on 21 Apr 2020

New "Windows x64" TEST build linked below.

Based from these commits:
qBittorrent master commit https://github.com/qbittorrent/qBittorrent/commit/8ed63d69dedabc113a00e89faf53c1ea19a9e14e & libtorrent RC_1_2 commit https://github.com/arvidn/libtorrent/commit/a9968916ca82366f1c236af59aaecb9bc94ffe73

Test Build Link

xavier2k6 on 21 Apr 2020

Is this the same 4.3.0alpha1 posted last week?

HnyBear on 21 Apr 2020

Is this the same 4.3.0alpha1 posted last week?

No, it's a new build based on latest commits...

xavier2k6 on 21 Apr 2020

Is this the same 4.3.0alpha1 posted last week?

No, it's a new build based on latest commits...

Ok just wondering because it still shows as 4.3.0alpha1

HnyBear on 21 Apr 2020

Ok just wondering because it still shows as 4.3.0alpha1

Yeah that version string does not change between alpha builds.

FranciscoPombal on 21 Apr 2020

Do I have HTTPS trackers: yes

Replaced qbittorrent executable & pdb with: "qBittorrent master (3.4.0alpha1) commit 8ed63d6 libtorrent (1.2.6) RC_1_2 commit a996891.zip"

What happened lower memory increment rate (i think not sure), but commit size keeps going up 3.8G as of this writing (23 minutes running).

UltraHKR on 21 Apr 2020

It seems almost all of the issues have been addressed in the changes made in qBittorrent/libtorrent since this issue was opened. The remaining identified issues have to do with some rarer SOCKS5 proxy disconnects that have been acknowledged here: https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-615831521.

Thus, now that 4.2.4 is released, bringing the fixes to all of the user base, I think it is time to close this, as it's getting too long and contains a lot of comments about stuff that is already fixed.
I will open a new issue report to track specifically the SOCKS5 disconnect issue (EDIT: here https://github.com/qbittorrent/qBittorrent/issues/12583).

Anyone having further connectivity issues not related to the aforementioned SOCKS5 issue, please open a separate issue report.

A big thank you to everyone who participated in testing, debugging, and discussing this issue.

FranciscoPombal on 23 Apr 2020

Qbittorrent: Proxies and UDP issues (no DHT/magnet/metadata/UDP trackers)

Most helpful comment

All 218 comments

Test Build

Test Build

Related issues