qBittorrent 🚀 - SOCKS5 proxy disconnect issue due to insufficient retries

I just love every year or so having to re-follow a new thread on basically the same issue since the others keep getting closed without being fixed. SOCKS5 has never worked for me, and I've always tried newer builds without any difference, including the next to last one posted on the most recent closed discussion. I'm in the middle of testing the current build and was going to give feedback, but the thread was closed. Can I give feedback here?

This is the build I'm testing: https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-617230156

The build before this timed out after a day or so, which has been the main issue for several years now. No errors yet on the linked build, but it hasn't been 24 hours yet.

Cunningcory on 23 Apr 2020

👍7

@Cunningcory

I just love every year or so having to re-follow a new thread on basically the same issue since the others keep getting closed without being fixed. SOCKS5 has never worked for me, and I've always tried newer builds without any difference, including the next to last one posted on the most recent closed discussion. I'm in the middle of testing the current build and was going to give feedback, but the thread was closed. Can I give feedback here?

Umm, yes? Did you read https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-618101331? This issue report was opened specifically to track this disconnect issue, which is the important thing now. The other thread was already filled with unrelated information. It is easier to track this single issue with a clean slate.

This is the build I'm testing: #11735 (comment)

The build before this timed out after a day or so, which has been the main issue for several years now. No errors yet on the linked build, but it hasn't been 24 hours yet.

Might as well test with 4.2.4, it has been officially released. But to be honest, until further changes happen in libtorrent, it is likely that some SOCKS5 issues will remain, as noted in https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-615831521

FranciscoPombal on 23 Apr 2020

Is this where we're suppose to come if we're still having socks5 issues? If so this is the error I keep getting then it hangs with nothing downloading.

4/22/2020 6:30 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.172:1080

HnyBear on 23 Apr 2020

👍3

Is this where we're suppose to come if we're still having socks5 issues? If so this is the error I keep getting then it hangs with nothing downloading.

4/22/2020 6:30 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.172:1080

@HnyBear
Just for clarification, is this with the build from https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-617230156 or the official 4.2.4 that has been released?

xavier2k6 on 23 Apr 2020

The 11735 build

HnyBear on 23 Apr 2020

SOCKS5 has never worked for me, and I've always tried newer builds without any difference

@Cunningcory Same issue here, but I've found that Qbittorrent v 4.1.9.1 doesn't disconnect my SOCKS5 connection at all (first with PrivateInternetAccess, then with TorGuard). All of the versions before it (starting with 4.0) and after it did, but 4.1.9.1 is good. I have no idea why, just letting you know if you want to use it while this issue gets fixed. I haven't tried 4.2.4 yet so perhaps I'm mistaken and everything is fine now, but I've had to wrestle with this program so much the last few years I'm taking a break and staying on what works.

Direct download link for v4.1.9.1 I found for you: https://www.fosshub.com/qBittorrent-old.html?dwl=qbittorrent_4.1.9.1_x64_setup.exe

It's hosted here in case you need a different download, or 32-bit: https://www.fosshub.com/qBittorrent-old.html

That's not a point of spite, by the way. I love you guys working on this and I wish you luck. I'm just gonna take a seat and hope for the best.

GregariousJB on 23 Apr 2020

👍2

@GregariousJB Thanks! I'm currently testing this alpha build, but if that fails on me I'll try 4.1.9.1. My solution has been to run torrents on a virtual machine that runs the full proxy instead of SOCKS5. I STILL have to run a babysitter program that restarts Qbit anytime the proxy has to reconnect, though!

Cunningcory on 23 Apr 2020

the best thing to do, for someone experiencing socks5 not working and wanting it to be fixed, is to post a wireshark dump of the UDP ASSOCIATE socks5 connection. Ideally just that TCP stream, to keep the noise down.

It probably won't get fixed unless it breaks (or is demonstrated breaking) for someone able to fix it.

arvidn on 23 Apr 2020

I suppose this specific issue isn't about socks5 not working, it's about it working and then getting the "semaphore timeout period expired" and it no longer working. I believe this is a windows phenomenon, is that right?

arvidn on 23 Apr 2020

I suppose this specific issue isn't about socks5 not working, it's about it working and then getting the "semaphore timeout period expired" and it no longer working.

It's definitely working for a while before it stops working, from what the users say. I don't know enough about this to be sure that the exact cause for the transition from working -> not working is then getting the "semaphore timeout period expired" though.

I believe this is a windows phenomenon, is that right?

No idea, honestly. Most of the qBittorrent on user base is on Windows, but that does not necessarily mean this only affects Windows. We'd some Linux/macOS users that use this to confirm.

FranciscoPombal on 23 Apr 2020

Still getting the handshake error with 11735 :(

Cunningcory on 24 Apr 2020

@Cunningcory do you have a link to "the handshake error"? Or could you describe what you mean by it?

arvidn on 24 Apr 2020

@arvidn This is what @Cunningcory means below (from previous issue/thread) https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-616854964

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

xavier2k6 on 24 Apr 2020

👍2

@arvidn Xavier is correct, that's the error. This is why I don't understand why the other thread was locked down as the discussion was troubleshooting "proxies and UDB issues". I guess this is just to get more specific to SOCKS5? It just feels like having to start from scratch with the troubleshooting.

For me and seems most people this has always been the issue for years. You start qbittorrent and everything is working fine with SOCKS5. Then you return later and it isn't working. You then restart the Qbit (maybe several times) and then it works again for a brief amount of time. This is the problem I have always had, so I guess I'm confused as to what other issues have been fixed.

@GregariousJB I'm trying 4.1.9.1 now but I don't have high hopes. I'll let you know!

Cunningcory on 24 Apr 2020

👍3

@Cunningcory most of the issues fixed in socks5 recently were related to regressions in libtorrent 1.2.x that were exposed as qBT transitioned over to the new version of libtorrent

arvidn on 24 Apr 2020

This is why I don't understand why the other thread was locked down as the discussion was troubleshooting "proxies and UDB issues". I guess this is just to get more specific to SOCKS5? It just feels like having to start from scratch with the troubleshooting.

The other issue was closed because it was an "umbrella issue" for many different problems, most of which have been fixed. The notable exception is this one SOCKS5 issue. So this issue was opened to:

deal _specifically_ with this SOCKS5 problem, without having to sift through huge amounts of unrelated information in between
clearly indicate that everything else is fixed

Of course, some things have to be copy-pasted back here, but it's not much in this case (anyone can copy-paste 2 log lines), so I think it's worth it.

FranciscoPombal on 25 Apr 2020

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

arvidn on 25 Apr 2020

I've upgraded to 4.2.4 and still have the error below. IF there is more info I can provide please let me know.

4/24/2020 6:03 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 109.201.154.133:1080

HnyBear on 25 Apr 2020

4.2.4 running in a docker container
No permanent disconnect issues yet, but some temporary.
The log shows this error 8 times before successfully reconnecting

(W) 2020-04-24T13:05:00 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 123.45.67.8:1080
(I) 2020-04-24T13:06:59 - Detected external IP: 123.45.67.8

sdkane on 25 Apr 2020

socks5 is not working for me with this version, but I don't see anything on the terminal. Do I need to launch it with a parameter or do I need a specific build to see debug messages?

[pink@gram qbittorrent-4.2.4]$ ldconfig -p | grep libtorrent
        libtorrent.so.21 (libc6,x86-64) => /usr/lib/libtorrent.so.21
        libtorrent.so (libc6,x86-64) => /usr/lib/libtorrent.so
        libtorrent-rasterbar.so.10 (libc6,x86-64) => /usr/lib/libtorrent-rasterbar.so.10
        libtorrent-rasterbar.so (libc6,x86-64) => /usr/lib/libtorrent-rasterbar.so
[pink@gram qbittorrent-4.2.4]$ qbittorrent --version
qBittorrent v4.2.4

eduardoxfurtado on 25 Apr 2020

@xavier2k6 can you provide a Windows build with https://github.com/arvidn/libtorrent/pull/4579 please?

FranciscoPombal on 25 Apr 2020

~@FranciscoPombal Just finished compiling...will upload soon & edit this message.~

@arvidn below are the three main errors being experienced by users in this thread.

Message: SOCKS5 error. op: handshake ec: End of file

Message: SOCKS5 error. op: sock_read ec: End of file

Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired

@HnyBear @Cunningcory @GregariousJB care to give below a try.

Based off of qBittorrent master https://github.com/qbittorrent/qBittorrent/commit/480e732694392cc39d65c7e6394f57274d8fb025 & https://github.com/arvidn/libtorrent/pull/4579/commits/cb318bedc5e337ca7dea80db0174725b770e61db

windows x64 test build with patch for retry failed socks5 server connections

xavier2k6 on 25 Apr 2020

👍3

Found the log on ~/.local/share/data/qBittorrent/logs/qbittorrent.log

(N) 2020-04-25T00:30:54 - qBittorrent v4.3.0alpha1 started
(N) 2020-04-25T00:30:54 - Using config directory: /home/pink/.config/qBittorrent/
(I) 2020-04-25T00:30:54 - Trying to listen on: 0.0.0.0:8473,[::]:8473
(N) 2020-04-25T00:30:54 - Peer ID: -qB4300-
(N) 2020-04-25T00:30:54 - HTTP User-Agent is 'qBittorrent/4.3.0alpha1'
(I) 2020-04-25T00:30:54 - DHT support [ON]
(I) 2020-04-25T00:30:54 - Local Peer Discovery support [OFF]
(I) 2020-04-25T00:30:54 - PeX support [ON]
(I) 2020-04-25T00:30:54 - Anonymous mode [ON]
(I) 2020-04-25T00:30:54 - Encryption support [ON]
(I) 2020-04-25T00:30:54 - IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: Tue. Mar. 31 19:49:13 2020.
(N) 2020-04-25T00:30:54 - Options were saved successfully.
(I) 2020-04-25T00:30:54 - Successfully listening on IP: 127.0.0.1, port: UDP/8473
(I) 2020-04-25T00:30:54 - Successfully listening on IP: 192.168.0.115, port: UDP/8473
(I) 2020-04-25T00:30:54 - Successfully listening on IP: ::1, port: UDP/8473
(I) 2020-04-25T00:30:54 - Successfully listening on IP: fe80::ac4c:6dde:e86a:ff2e%wlp0s20f3, port: UDP/8473
(W) 2020-04-25T00:30:54 - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: No route to host ep: 127.0.0.1:8473
(W) 2020-04-25T00:30:54 - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: No route to host ep: [::1]:8473
(W) 2020-04-25T00:31:00 - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: No route to host ep: [fe80::ac4c:6dde:e86a:ff2e%wlp0s20f3]:8473
(I) 2020-04-25T00:31:00 - UPnP / NAT-PMP support [OFF]

eduardoxfurtado on 25 Apr 2020

@eduardoxfurtado are you using xavier2k6's build? does socks5 work for you?

arvidn on 25 Apr 2020

SOCKS5 has never worked for me, and I've always tried newer builds without any difference

@Cunningcory Same issue here, but I've found that Qbittorrent v 4.1.9.1 doesn't disconnect my SOCKS5 connection at all (first with PrivateInternetAccess, then with TorGuard). All of the versions before it (starting with 4.0) and after it did, but 4.1.9.1 is good. I have no idea why, just letting you know if you want to use it while this issue gets fixed. I haven't tried 4.2.4 yet so perhaps I'm mistaken and everything is fine now, but I've had to wrestle with this program so much the last few years I'm taking a break and staying on what works.

Direct download link for v4.1.9.1 I found for you: https://www.fosshub.com/qBittorrent-old.html?dwl=qbittorrent_4.1.9.1_x64_setup.exe

It's hosted here in case you need a different download, or 32-bit: https://www.fosshub.com/qBittorrent-old.html

That's not a point of spite, by the way. I love you guys working on this and I wish you luck. I'm just gonna take a seat and hope for the best.

Hey, this has been working for me so far with no errors! Thanks for this! I'm going to give it another day to make sure it doesn't disconnect and then switch to the new test build to see if it works.

@xavier2k6 I don't know if it's an easy task to check the differences between 4.1.9.1 and the most recent build, but I don't get ANY SOCKS5 error on that build so far and torrents are still working. I am checking my torrent IP as well, and it is going through the proxy.

Cunningcory on 26 Apr 2020

👍1

@Cunningcory @GregariousJB it's great that it works on an older version, but it would be best to help fix this issue on libtorrent 1.2.x, so that everything can benefit from it, as apart from this bug, it has many improvements over libtorrent 1.1.x (which is what qbittorrent < 4.2.0 uses).

Be sure to post your results with the test build as soon as you can.

FranciscoPombal on 27 Apr 2020

Still getting error with latest by @xavier2k6 .

4/26/2020 10:19 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 109.201.154.227:1080

HnyBear on 27 Apr 2020

4.1.9.1 stopped working for me. No error messages, but maybe the only difference is the errors aren't logged in that version. Gonna test the new version now.

Cunningcory on 27 Apr 2020

4.1.9.1 stopped working for me. No error messages, but maybe the only difference is the errors aren't logged in that version. Gonna test the new version now.

Really? I think it stopped working for me maybe 2 times since I got it October 2019, running it 24/7 and never shutting down my PC, but I'm unsure if it's related to the SOCKS5 thing or just a random fluke. Going on 6 days now since I rebooted for an unrelated reason and no problems since.

Running Windows 10 LTSC v1809, in case that's relevant.

GregariousJB on 27 Apr 2020

@HnyBear yes, that error is expected. Does SOCKS5 reconnect when that happens? Does socks5 keep working?

arvidn on 27 Apr 2020

@GregariousJB Yeah, I had no error messages but new torrents got stuck at "Downloading metadata...", even though testing my torrent IP showed the proxy was connected. Count yourself lucky! Is it possible you don't have your torrent traffic limited to the proxy alone? You should have "Use proxy only for torrents" selected in the Connection tab. Otherwise it's possible your proxy drops and your connection switches back without you knowing.

Cunningcory on 27 Apr 2020

@Cunningcory

Above settings since I set it up with PrivateInternetAccess around the same time I installed 4.1.9.1, but I switched to Torguard not too long ago.

On that note, which proxy service are you using? Maybe some of them don't play well with SOCKS5 connections? I don't think it's the case, but maybe my issue of getting stuck on "Downloading metadata" was PrivateInternetAccess.

GregariousJB on 27 Apr 2020

I think it would be better avoid posting about other topics than the subject of this ticket. if anyone has additional information to contribute, please do so. I think the most interesting thing right now would be to know whether a build with this patch https://github.com/arvidn/libtorrent/pull/4579 fixes the problem or not.

arvidn on 27 Apr 2020

👍2

@HnyBear yes, that error is expected. Does SOCKS5 reconnect when that happens? Does socks5 keep working?

So far it appears to be reconnecting. I'll let you know if I get any other errors other than these.

4/27/2020 4:01 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.154.237:1080
4/27/2020 3:58 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.137.212:1080

HnyBear on 27 Apr 2020

👍1

@Cunningcory @GregariousJB Please keep the discussion on topic. This is about fixing the problem for 4.2.x and future versions. Whatever additional problems you encounter on 4.1.x won't be fixed, because that branch won't receive more releases. Any workaround is meant to be just a stop-gap measure, we have to move forward.

FranciscoPombal on 27 Apr 2020

@arvidn It is probably not very intuitive that the user _only_ sees SOCKS5 error alerts.

It would be useful to have a way of knowing that dispite an error, the connection has been re-established successfully. Something like a socks5_reconnect_alert or something, so that there can be at least one "SOCKS5 proxy reconnect successful" message for every SOCKS5 proxy error. message.

Otherwise, if the user _only_ sees SOCKS5 proxy error. messages, they might think that stuff is broken, even though the connection might have been successfully re-established each time.

FranciscoPombal on 27 Apr 2020

Sorry to be writing here regarding Proxies and UDP issues (no DHT/magnet/metadata/UDP trackers) #11735 but I couldn't work out how to get my message to @arvidn, @sledgehammer999, @xavier2k6 and @FranciscoPombal and all the others involved contributing, testing, commenting on these Socks-5 issues ...
Just wanted to extend a "BiG Thank-You" for the perseverance and all the hard work you and others since #11735 opened December 22, 2019 and prior.
I know for sure this hasn't been an easy one by any stretch of the imagination and even more so given the onset of this Coronavirus COVID-19 pandemic locking us all down in countries throughout the world.
So, from someone who is extremely grateful, in full-lock-down so far for 7-weeks, a couple of weeks prior to the start of this Official 12-week Lock-Down Notice to those at extreme risk - and very likely to remain in lock-down a while longer after that before taking a peak as to "How it's all going out there" ... "Thank-You", "Thank-You", "Thank-You"!

condoghost on 28 Apr 2020

👍1

@GregariousJB @Cunningcory any feedback for the build in https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-619298534 please? good or bad.

xavier2k6 on 28 Apr 2020

Hi,

I'm on mint linux and am not getting any sonnection at all using a SOCKS5 proxy,m the error in the log is

28/04/2020 18:28 - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 194.35.233.229:1080

I am currently on build 4.2.5
Anything else that you would need from me just ask..

btripz on 28 Apr 2020

@xavier2k6 It's been running for a little over 36 hours and still working. There are two error messages in the log:

4/27/2020 6:19 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.154.226:1080
4/28/2020 12:21 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.186.198:1080

Usually sometime during day two it craps out, so I'll keep an eye out.

Cunningcory on 28 Apr 2020

@Cunningcory As stated here https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-619794089, the error is expected; the important thing is to report whether or not it is reconnecting after it fails: https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-620052684

FranciscoPombal on 28 Apr 2020

@btripz
Compile libtorrent from source with this patch included: https://github.com/arvidn/libtorrent/pull/4579. Then compile qBittorrent with that libtorrent custom build. You should still see the error, but you should also observe that it reconnects on its own.

FranciscoPombal on 28 Apr 2020

@btripz it sounds like your SOCKS5 server isn't accepting the incoming connection. Are you sure 194.35.233.229:1080 is correct?

testing with nc suggest that nothing is listening on that port on that IP:

$ nc 194.35.233.229:1080

arvidn on 28 Apr 2020

@arvidn it's the address and port given to me by my VPN provider, I'll try again..

edit: after getting a new host I manged to download a torrent, however I am now getting plenty of these in my log file but I still appear to be connected...

28/04/2020 20:26 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 195.206.183.191:1080
28/04/2020 20:25 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 195.206.183.191:1080
28/04/2020 20:25 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 195.206.183.191:1080
28/04/2020 20:25 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 195.206.183.191:1080
28/04/2020 20:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 195.206.183.191:1080
28/04/2020 20:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 195.206.183.191:1080

btripz on 28 Apr 2020

@btripz

edit: after getting a new host I manged to download a torrent, however I am now getting plenty of these in my log file but I still appear to be connected...

was this result obtained with 4.2.5 or with a patched build including https://github.com/arvidn/libtorrent/pull/4579?

FranciscoPombal on 28 Apr 2020

@btripz

edit: after getting a new host I manged to download a torrent, however I am now getting plenty of these in my log file but I still appear to be connected...

was this result obtained with 4.2.5 or with a patched build including arvidn/libtorrent#4579?

With 4.2.5.

Edit : I have just added a new torrent and it is downloading without any problems.

btripz on 28 Apr 2020

@btripz Thanks for reporting back, but we're only interested in how it runs with the patch, we already know the limitations of the 4.2.5 release.

FranciscoPombal on 28 Apr 2020

I installed the test build about 36 hours ago, and so far in the log I see three semaphore timeout errors, but everything is still working. I'm not certain that the semaphore timeout error was a 100% indicator of failure before, but so far so good with the reconnection fix.

crafty35a on 28 Apr 2020

👍1

the "semaphore timeout" indicates that the connection to the proxy was terminated (but probably by some timeout or limitation of the local system). The main difference with the most recent patch to libtorrent is that it now tries to re-establish the condition under more circumstances than before. There is no log of this re-establishment though.

arvidn on 29 Apr 2020

@arvidn

There is no log of this re-establishment though.

Do you plan on adding it?

FranciscoPombal on 29 Apr 2020

Do you plan on adding it?

It's not very high on my list right now. Maybe there should be a socks5 log alert, instead of the error alert, and it would be controlled by a new alert mask flag.

arvidn on 29 Apr 2020

👍1

I had a wave of error messages this morning but am still connected! I believe this is the longest I've gone without it disconnecting and needing a restart. Here are the error messages. The only file I had downloading was just an IP check torrent:

4/29/2020 10:51 AM - Detected external IP: 109.201.154.134
4/29/2020 10:45 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.134:1080
4/29/2020 10:44 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.154.130:1080
4/29/2020 10:00 AM - Detected external IP: 109.201.154.130
4/29/2020 9:55 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 46.166.190.152:1080
4/29/2020 9:36 AM - Detected external IP: 46.166.190.152
4/29/2020 9:32 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.152:1080
4/29/2020 9:32 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/29/2020 9:32 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/29/2020 9:32 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/29/2020 9:32 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.154.134:1080
4/29/2020 9:10 AM - Detected external IP: 109.201.154.134
4/29/2020 9:04 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.152:1080
4/29/2020 9:03 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.152:1080
4/29/2020 9:03 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/29/2020 9:02 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/29/2020 9:02 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/29/2020 9:01 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.152:1080
4/29/2020 9:01 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/29/2020 9:01 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.130:1080
4/29/2020 9:01 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 109.201.154.130:1080
4/29/2020 9:00 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.130:1080
4/29/2020 9:00 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.174:1080
4/29/2020 7:40 AM - Detected external IP: 46.166.190.174
4/29/2020 7:34 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.174:1080
4/29/2020 7:33 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.174:1080
4/29/2020 7:33 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 109.201.154.134:1080
4/29/2020 7:32 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.134:1080
4/29/2020 7:32 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/29/2020 7:32 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/29/2020 7:31 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/29/2020 7:31 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/29/2020 7:31 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/29/2020 7:31 AM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 109.201.152.22:1080

The errors in the log don't bother me as long as it stays connected!

Cunningcory on 29 Apr 2020

👍1

that's great. Although, it is a bit disconcerting that the connection to the proxy fails that often. It seems to come in bursts though, so maybe it isn't all that big of a problem.

arvidn on 29 Apr 2020

The connection is no longer working, giving the same symptoms as before (stuck on Downloading metadata). I basically tried to download something during the error message spam. It may eventually reconnect? I'll let it sit for a little while and see. Here are the errors:

4/30/2020 2:37 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.166:1080
4/30/2020 2:35 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 109.201.154.247:1080
4/30/2020 2:34 PM - '********' added to download list.
4/30/2020 2:34 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 2:32 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.134:1080
4/30/2020 2:31 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: No connection could be made because the target machine actively refused it ep: 109.201.152.22:1080
4/30/2020 2:30 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.134:1080
4/30/2020 2:29 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.134:1080
4/30/2020 2:29 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 109.201.154.134:1080
4/30/2020 2:28 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.174:1080
4/30/2020 2:28 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.174:1080
4/30/2020 2:27 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.174:1080
4/30/2020 2:27 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.174:1080
4/30/2020 2:27 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.174:1080
4/30/2020 2:27 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.174:1080
4/30/2020 2:26 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.174:1080
4/30/2020 2:26 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.140:1080
4/30/2020 1:57 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.134:1080
4/30/2020 1:55 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: No connection could be made because the target machine actively refused it ep: 109.201.152.22:1080
4/30/2020 1:53 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: No connection could be made because the target machine actively refused it ep: 109.201.152.22:1080
4/30/2020 1:51 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: No connection could be made because the target machine actively refused it ep: 109.201.152.22:1080
4/30/2020 1:49 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.186.207:1080
4/30/2020 1:48 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.186.207:1080
4/30/2020 1:46 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.134:1080
4/30/2020 1:45 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 109.201.154.134:1080
4/30/2020 1:44 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: No connection could be made because the target machine actively refused it ep: 109.201.152.22:1080
4/30/2020 1:43 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/30/2020 1:43 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/30/2020 1:42 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/30/2020 1:41 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.152:1080
4/30/2020 1:41 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 1:41 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 1:41 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 1:40 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 109.201.154.247:1080
4/30/2020 1:40 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 1:40 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.140:1080

You can see I tried to add a torrent at 2:34. As of now the errors are still happening and have been happening for nearly an hour now.

UPDATE: The proxy reconnected for about three minutes. During that time the torrent already in the queue remained unchanged - still refusing to connect. Starting a new torrent, however, worked. After three minutes, however, the errors continued and adding any new torrent refused to work again.

4/30/2020 2:50 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/30/2020 2:49 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080
4/30/2020 2:49 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.186.207:1080
4/30/2020 2:48 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.186.207:1080
4/30/2020 2:48 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 2:48 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 2:48 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 2:48 PM - '2nd ******' added to download list. (NOW NO LONGER WORKS AGAIN)
4/30/2020 2:47 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.140:1080
4/30/2020 2:47 PM - '2nd ******' was removed from the transfer list and hard disk.
4/30/2020 2:47 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.166:1080
4/30/2020 2:46 PM - Successfully moved torrent: ******. New path: F:\Downloads\temp
4/30/2020 2:46 PM - '2nd *******' added to download list. (WORKED)
4/30/2020 2:44 PM - Detected external IP: 46.166.190.166
4/30/2020 2:37 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.166:1080
4/30/2020 2:35 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 109.201.154.247:1080
4/30/2020 2:34 PM - '*******' added to download list. (NEVER WORKED)
4/30/2020 2:34 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080

UPDATE 2: The proxy eventually reconnected and both files were able to connect and start downloading. For over an hour the proxy was down, spitting out error messages pretty consistently. At least it does seem the torrents will eventually start working again when the client reconnects:

4/30/2020 2:55 PM - Detected external IP: 109.201.154.134
4/30/2020 2:54 PM - Successfully moved torrent: 2nd ******. New path: F:\Downloads\temp
4/30/2020 2:54 PM - Successfully moved torrent: ******. New path: F:\Downloads\temp
4/30/2020 2:51 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.138.237:1080
4/30/2020 2:51 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.152:1080
4/30/2020 2:50 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.152:1080

Cunningcory on 30 Apr 2020

@Cunningcory What's your OS version build number? & are all network drivers up to date?

xavier2k6 on 30 Apr 2020

Windows 10 Pro 1909
Intel(R) I211 Gigabit Network Connection Driver 12.17.10.8

I'll check for updates to both.

Edit: Updated both (Windows just had an optional update). Network driver is now 12.18.9.6. Had to restart the computer. I continued to receive error messages for a few minutes after restarting but then it stabilized. I now haven't had error messages for about an hour. I assume I'll have another wave of them in a day or so, but we'll see.

4/30/2020 3:21 PM - Detected external IP: 109.201.154.130
4/30/2020 3:20 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 109.201.154.247:1080
4/30/2020 3:16 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 3:16 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 109.201.154.247:1080
4/30/2020 3:16 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 109.201.154.247:1080
4/30/2020 3:16 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 109.201.154.247:1080
4/30/2020 3:14 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 3:14 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 3:13 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 109.201.154.247:1080
4/30/2020 3:13 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 109.201.154.247:1080
4/30/2020 3:13 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.166:1080
4/30/2020 3:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 46.166.190.166:1080
4/30/2020 3:12 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 46.166.190.174:1080
4/30/2020 3:11 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 46.166.190.174:1080
4/30/2020 3:11 PM - Successfully listening on IP: 0.0.0.0, port: UDP/53681

Cunningcory on 30 Apr 2020

I'm now up to 3.5 days and everything is still functional. This would have been unheard of before, so at the least the reconnect change seems to have greatly improved the situation.

crafty35a on 1 May 2020

@Cunningcory could have just been instability from the proxy service provider. Do they have a page such as this one (https://www.githubstatus.com/) where you can verify against the timestamps when you had the issues?

FranciscoPombal on 1 May 2020

I'm using PIA and can't find anything like that - certainly not anything that would show minute by minute. These errors come pretty consistently in waves for about an hour or two maybe twice a day from what I can tell.

Cunningcory on 1 May 2020

@Cunningcory

These errors come pretty consistently in waves for about an hour or two maybe twice a day from what I can tell.

Could these times be coinciding with peak hours/maintenance/mandatory reconnection after x hours connected in a row? Or a combination of the 3?

FranciscoPombal on 1 May 2020

I'm far from an expert, but my understanding is that, for whatever reason, proxy servers often disconnect and reconnect connections. This happens even when running the PIA desktop client and results in the same issue (at least in previous versions) of the torrent client ceasing to work until it is restarted. My solution has been to run a virtual machine with the PIA desktop client, Qbittorrent, and a Qbittorrent babysitter program running. When PIA disconnects and reconnects, the babysitter automatically restarts the torrent client. Not the most ideal solution, which is why I'd love to just get SOCKS5 working.

The difference here is the connection seems to be forcibly closed by "the remote host". There's a timeout and what might be a forced waiting period before allowing reconnect. In the meantime the proxy IP address will often change. I don't know if this is an idle timeout or what. I don't know if the torrent client is doing something that's triggering the disconnect or if it's just the normal ebb and flow of the proxy.

More tech savvy people will probably have a better idea. I'm just trying to interpret the error messages based on my own experience. I will say I don't believe the error messages happen at the SAME time every day.

Cunningcory on 1 May 2020

@Cunningcory
I would bet it's PIA forcing the disconnect/reconnect, to clean up idle connections. Shoot them a support email - they might give a conclusive response. Ask something like "do your proxies forcefully disconnect or reconnect after a client has been connected for a long time?".

FranciscoPombal on 1 May 2020

I had a long conversation with PIA support about their socks5. They admit it is overloaded and have plans to add another proxy at some point. I've switched to their VPN program in the mean time and am using the split tunnelling in that to connect for all my qbittorrent needs.

HnyBear on 1 May 2020

🎉1

Great! Looks like on the qBittorrent libtorrent side, everything is solved now. I'll close this once the next stable release of qBIttorrent is released (which will obviously include this libtorrent patch).

FranciscoPombal on 1 May 2020

@HnyBear I think that's a new feature of PIA. Would this test build reconnect to the proxy when treating it as a whole network? My workaround included setting up PIA on a virtual machine, but every time it disconnected Qbittorrent connections would hang until restart. Have you had that issue?

Cunningcory on 1 May 2020

Haven't had enough time to test it. I'll try to let you know if it ends up having issues but PIA's reverse split tunnelling is pretty good so far.

HnyBear on 1 May 2020

Cool, thanks, I think I'll try the same. I set it up and connected it, ran a torrent, disconnected PIA, waited a minute, and then reconnected and the torrent picked back up. I'm not sure if that's the same as PIA disconnecting itself, though. I'm hoping picking back up the SOCKS5 connection would also apply to picking back up the client connection.

Cunningcory on 1 May 2020

Windows 7 NordVPN. First open NordVPN Desktop App to connect to country specified P2P Socks5 VPN, in this instance UK1296 but I have done this 5 or 6 times since updating to v4.2.5. I close App, open qBittorrent, set Connection, Proxy Server Socks5 to that working host. Torrents already in client all HTTP trackers load and Working. Load new torrent UDP trackers Working.
Leave overnight ...
232 SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep:
Torrents already in client all HTTP trackers Working. Load new torrent UDP tracker Working.
Will continue to monitor ...

UPDATE in the meantime I switched hosts a couple of times and also closed/reopened client a couple of times, and also shut down / restarted PC a couple of times.
Since 02/05/2020 10:45 - Detected external IP: 185.253.98.107 there have been no Socks5 proxy errors. I'll keep client running uninterrupted for a few days - if I can keep my wife away from the bloody power switch that is. I will update https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-622960888

Click to show log output

30/04/2020 22:16 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:23 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:23 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:22 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:11 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:11 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:08 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:08 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:08 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:05 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:05 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:05 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:04 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:04 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:04 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:03 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 06:03 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 03:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 03:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 03:11 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:47 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:46 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:46 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:45 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:43 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:43 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:42 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:39 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:39 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:39 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:38 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:38 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:38 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:37 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:34 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:34 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:34 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:34 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:33 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:33 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:33 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:32 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:32 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:32 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:31 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:30 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:30 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:30 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:30 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:29 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:29 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:29 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:28 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:28 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:27 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:27 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:27 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:27 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:26 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:26 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:26 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:25 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:25 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:23 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:23 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:23 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:22 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:22 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:22 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:20 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:20 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:20 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:19 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:19 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:19 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:19 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:18 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:18 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:18 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:18 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:17 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:17 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:16 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:16 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:16 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:11 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:11 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:11 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:10 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:10 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:10 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:09 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:09 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:09 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:08 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:08 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:05 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:05 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:05 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:04 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:03 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:03 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:03 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:02 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:02 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:02 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:02 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:01 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:00 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:00 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
01/05/2020 00:00 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:59 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:59 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:59 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:59 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:58 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:57 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:57 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:56 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:56 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:55 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:55 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:55 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:54 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:54 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:54 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:53 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:52 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:51 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:50 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:50 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:49 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:49 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:49 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:49 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:48 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:47 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:47 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:47 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:46 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:46 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:46 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:45 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:45 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:44 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:41 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:32 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:31 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:29 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:28 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:27 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:26 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:26 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:26 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:25 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:16 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:16 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:16 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:10 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:10 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:09 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:08 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:08 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:07 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:06 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:05 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:05 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 23:03 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:27 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:20 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:20 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:20 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:19 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:19 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:19 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:19 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:18 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:18 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:17 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:17 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 22:17 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
30/04/2020 21:24 - Detected external IP: 185.253.98.107
30/04/2020 21:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080

condoghost on 1 May 2020

👀1

@condoghost Use the test build linked here, it should be able to re-establish connection: https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-619298534

FranciscoPombal on 1 May 2020

@condoghost Are you attempting to use VPN and Sock5 proxy at the same time? Sounds like it, since AFAIK the NordVPN app is only needed for VPN, not proxy. Socks5 is not necessary if you are connected to a VPN.

crafty35a on 1 May 2020

@condoghost Are you attempting to use VPN and Sock5 proxy at the same time? Sounds like it, since AFAIK the NordVPN app is only needed for VPN, not proxy. Socks5 is not necessary if you are connected to a VPN.

No it doesn't "sound like it" at all. Read through what I wrote again. FIRST I open NordVPN app to obtain a working server ID. Obviously I then CLOSE the app, open client, update and set Connection Proxy Server Socks-5 Host with the "working" host.

condoghost on 2 May 2020

@condoghost Use the test build linked here, it should be able to re-establish connection: #12583 (comment)

Okay I will look at that. In the meantime I switched hosts a couple of times and also closed/reopened client a couple of times, and also shut down / restarted PC a couple of times.
Since 02/05/2020 10:45 - Detected external IP: 185.253.98.107 there have been no Socks5 proxy errors. I'll keep client running uninterrupted for a few days - if I can keep my wife away from the bloody power switch that is - and update here ...

UPDATE Haven't installed test build yet, wanted to see how v4.2.5 was running first.
03/05/2020 11:50 24hrs now no further errors reported, http trackers working. Have loaded a number of torrents throughout, observed a few minutes delay longer for udp trackers to start working, manual force reannounce but will leave next time to see if manual force reannounce is actually needed, no issues, no errors. Could be after upgrade to v4.2.5 it took a few re-sets for the client to stabalise or I was just unlucky with setting one host that wasn't so stable. Will update here again in 24hrs or earlier if issues come back ...

condoghost on 2 May 2020

@condoghost errors are still expected to occur with the test build. However, you should observe that it it's able to recover and reconnect.

FranciscoPombal on 2 May 2020

Whilst my problem does not exactly match this on as described. I do have some interesting observations.

I am fortunate to have a lot of machines in the house so have been able to try QBT 4.2.5 on Windows 10 v1909 b18363 and Mac OSX 10.15.4

I have a socks5 proxy from ipvanish.com and I am able to test the same torrent on both the WinPC and the MAC.

I still see constant issues with the Windows version. I have the same settings enabled on MAC and Win versions of 4.2.5 but if I open the torrent on MAC I have 1) hundreds of DHT nodes appear 2) the torrent immediately starts to download and complete.
On the Win instance. zero DHT nodes found, UDP trackers never work, on MAC version the complete opposite.

firewall not enabled on either machine.

Willing to provide extra info if this can help anyone find the issue.

amsterdampaul on 3 May 2020

@amsterdampaul Do you get any socks5 errors in the log?

arvidn on 3 May 2020

None no..

WIN

MAC
Screenshot 2020-05-03 at 19 24 18

Can leave the Windows instance for hours and there will be no DHTs and the torrent will not have started downloading.

such a pity that we cannot put the thing into debug2 and get full logging out of it. (not that I know of)

amsterdampaul on 3 May 2020

Windows 7 qBittorrent v4.2.5 Connection Proxy Server SOCKS5 Host NordVPN uk1296
First SOCKS5 proxy errors since https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-622960888 02/05/2020 10:45 - Detected external IP: 185.253.98.107...
04/05/2020 00:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 185.253.98.106:1080
04/05/2020 00:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: 185.253.98.106:1080
none since, http trackers already loaded are working, have no udp torrents loaded.
Loaded first new udp torrents since SOCKS5 proxy error, trackers not working. Force reannounce udp trackers still not working. Deleted and reloaded udp torrents, trackers still not working. This is a great pity because with this version I had the best results ever with udp torrents, some hitting speeds 8.5MB/s, one torrent loading 130-seeds one time [never had such results before with any versions of qBittorrent].
Okay, I've closed this client v4.2.5 and will look at running the test build #12583 (comment)

condoghost on 4 May 2020

Windows 7 Test Build #12583 (comment) "qBittorrent master commit 480e732 with libtorrent patch 4579" Connection Proxy Server SOCKS5 Host NordVPN uk1296 [using same host as with v4.2.5]
Loaded 5 new udp torrents, trackers on each started instantly, no errors.
Lets see how this goes. Thank-you everyone for your continued hard work.
I'll leave this running and add new udp torrents from time to time. Will provide an UPDATE here in 24-hours ...

UPDATE No issues so far with test build. Getting great download speeds for udp torrents - up to 8.5MB/s with some udp torrents [as good as I get with private http torrents] and many hitting 4MB/s. Fantastic numbers for seed connections - one udp torrent had 189-seed connections simutaneously of 200-seeds. Of course that also means high numbers of peer connections and having to manually manage the blocking of those not sharing or grabbing so much more than they share.
In my opinion, with this Test Build and v4.2.5, qBittorrent has never been this good for udp trackers using Connection Proxy Server Type SOCKS5.
The only SOCKS5 proxy errors I got were when I ran ipleak Torrent Address Detection ...
04/05/2020 13:20 - 'ipleak.net torrent detection' added to download list.
04/05/2020 13:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 185.253.98.106:1080
04/05/2020 13:21 - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: No such host is known ep: 0.0.0.0:55535
04/05/2020 13:22 - 'ipleak.net torrent detection' was removed from the transfer list.
04/05/2020 13:23 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 185.253.98.106:1080
04/05/2020 13:23 - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: No such host is known ep: 0.0.0.0:55535
04/05/2020 13:23 - SOCKS5 proxy error. Message: SOCKS5 error. op: hostname_lookup ec: No such host is known ep: 0.0.0.0:55535
04/05/2020 13:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
04/05/2020 13:24 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
Thank-you everyone. Looking so much better than just "good" :)
Will post new UPDATE comment when the time clock hits 48hrs ...

condoghost on 4 May 2020

Windows 7 Test Build #12583 (comment) "qBittorrent master commit 480e732 with libtorrent patch 4579" Connection Proxy Server SOCKS5 Host NordVPN uk1296 [using same host as with v4.2.5]
Loaded 5 new udp torrents, trackers on each started instantly, no errors.
Lets see how this goes. Thank-you everyone for your continued hard work.
I'll leave this running and add new udp torrents from time to time. Will provide an UPDATE here in 24-hours ...

i have to say I tried that build you mention on my Win10 and I see no difference UDP trackers do not work and I never get any DHT nodes appear. Also no socks5 errors in the log

amsterdampaul on 4 May 2020

@amsterdampaul Please post your settings file of each machine in plain text, taking care to remove any potentially sensitive data. I'm mainly interested in what you have the "Network Interface" and "optional IP address to bind to" settings set to in the advanced settings.

FranciscoPombal on 4 May 2020

@amsterdampaul Please post your settings file of each machine in plain text, taking care to remove any potentially sensitive data. I'm mainly interested in what you have the "Network Interface" and "optional IP address to bind to" settings set to in the advanced settings.

here they are:
qbittorrent_4.2.5_windows10.txt
qbittorrent_4.2.5_mac-osx.txt

amsterdampaul on 5 May 2020

Windows 7 qBittorrent Test Build #12583 (comment) "qBittorrent master commit 480e732 with libtorrent patch 4579"
Connection Proxy Server SOCKS5 Host NordVPN uk1296 [using same host as with v4.2.5]
38hrs: 1,381 SOCKS5 proxy errors between 05/05/2020 23:43 and 06/05/2020 06:47 ...
qbittorrent_4.3.0alpha1-2020-05-06-07-18.txt
06/05/2020 06:47 Torrents already loaded: http trackers working.
06/05/2020 06:47 Added udp torrent: all trackers working and torrent instantly starts downloading
06/05/2020 06:55 Added udp torrent: all trackers working and torrent instantly starts downloading
06/05/2020 07:17 and 07:27 14 SOCKS5 proxy errors ...
qbittorrent_4.3.0alpha1-2020-05-06-07-25.txt
Will leave client running and report again in 24hrs ...

condoghost on 6 May 2020

@condoghost

06/05/2020 07:17 and 07:27 14 SOCKS5 proxy errors ...

As stated above, errors are expected even with the test build. Some are unavoidable, the proxy can just decide to disconnect you, which will result in an error. However, it should be able to reconnect after the error occurs, unlike the regular build. So the important thing is whether you see qBIttorrent managing to reconnect successfully or not.

FranciscoPombal on 6 May 2020

Quick update- 9+ days of stability here. Looking forward to a stable build with this fix incorporated! Great work to all involved.

crafty35a on 6 May 2020

👍1

@condoghost

06/05/2020 07:17 and 07:27 14 SOCKS5 proxy errors ...

As stated above, errors are expected even with the test build. Some are unavoidable, the proxy can just decide to disconnect you, which will result in an error. However, it should be able to reconnect after the error occurs, unlike the regular build. So the important thing is whether you see qBIttorrent managing to reconnect successfully or not.

Yes qBittorrent does appear to be managing to reconnect successfully though there is no entry in the execution log that highlights this, just lists of SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 185.253.98.106:1080
I'm still adding txt file here given every now and then I get SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: 185.253.98.106:1080 and having continuous lists of error messages must impact the efficiency of the client.
Between 06/05/2020 07:28 and 07/05/2020 13:32 there have been 1,702 SOCKS5 proxy error in two distinct time frames: between 06/05/2020 07:28 and 06/05/2020 07:55 when they stopped having loaded two udp torrents and ipleak.net torrent detection to be assured the proxy was indeed connected and working in the client. The second was between 07/05/2020 01:51 and 07/05/2020 13:32 when I loaded a new udp torrent trackers working and downloading automatically without any intervention on my side. No further SOCKS5 proxy errors reported in the Execution Log since.
qbittorrent_4.3.0alpha1-2020-05-07-14-06.txt
Will leave client running and report again in 24hrs ...

condoghost on 7 May 2020

👍1

@condoghost

Good, I think at this point we have enough confirmation.

Yes qBittorrent does appear to be managing to reconnect successfully though there is no entry in the execution log that highlights this

Such a message could be added later: https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-621120307

FranciscoPombal on 7 May 2020

@amsterdampaul
Looks like your Windows config has an extra Connection\ProxyOnlyForTorrents=false that the mac config does not have. Could it be the cause? Other than that, maybe an interface selection problem in qBittorrent? On Windows try setting the interface and IP address to bind to to something specific in the advanced settings.

FranciscoPombal on 7 May 2020

@amsterdampaul
Looks like your Windows config has an extra Connection\ProxyOnlyForTorrents=false that the mac config does not have. Could it be the cause? Other than that, maybe an interface selection problem in qBittorrent? On Windows try setting the interface and IP address to bind to to something specific in the advanced settings.

good spot, but sadly with both set the same the mac version works perfectly (little snitch shows me it is only using the socks proxy) and the win10 version just doesnt work for me..

But if I fire up Win10 v4.1.9.1 it works just fine, and glaswire shows me that 4.1.9.1 is using the socks proxy.. 4.1.9.1 shows DHT nodes counting up very quickly. 4.2.x has never done that for me.

I guess I am just unlucky and there are not many people who use a socks5 proxy with the latest windows10 versions.

amsterdampaul on 7 May 2020

@amsterdampaul
Looks like your Windows config has an extra Connection\ProxyOnlyForTorrents=false that the mac config does not have. Could it be the cause? Other than that, maybe an interface selection problem in qBittorrent? On Windows try setting the interface and IP address to bind to to something specific in the advanced settings.

good spot, but sadly with both set the same the mac version works perfectly (little snitch shows me it is only using the socks proxy) and the win10 version just doesnt work for me..

But if I fire up Win10 v4.1.9.1 it works just fine, and glaswire shows me that 4.1.9.1 is using the socks proxy.. 4.1.9.1 shows DHT nodes counting up very quickly. 4.2.x has never done that for me.

I guess I am just unlucky and there are not many people who use a socks5 proxy with the latest windows10 versions.

Actually one more update!..
Using one of the latest builds that have been posted
(qBittorrent master commit 480e732 with libtorrent patch 4579 )

and setting the interface and address, I get it worked as expected.
and UDP trackers work over the socs5 proxy and DHT nodes start counting up within seconds of starting the GUI..

Now this does seem to be progress! thank you

amsterdampaul on 7 May 2020

@amsterdampaul but it does not work if listening interface/optional ip to bind to are set to any/any in the advanced settings? I think it _should_ also work in that case.

FranciscoPombal on 7 May 2020

Anyone having trouble with this just FYI I commented on some earlier threads b/c I thought something was wrong with my SOCKS5 proxy or something, turns out if I uncheck the Torrent Queuing option the client works perfectly. May not work for everyone but this solved all the head-aches I was having with occasionally have to restart qBittorrent due to downloads not starting, etc.

austinjordan on 8 May 2020

Anyone having trouble with this just FYI I commented on some earlier threads b/c I thought something was wrong with my SOCKS5 proxy or something, turns out if I uncheck the Torrent Queuing option the client works perfectly. May not work for everyone but this solved all the head-aches I was having with occasionally have to restart qBittorrent due to downloads not starting, etc.

Yeah, the queuing system is a known source of problems. Mainly because it is not really obvious that _all_ started torrents, not just those that have download/upload activity, count towards the "Maximum active torrents" limit. People assume that "Maximum active torrents" should be the sum or maximum or a close approximation of "max active downloads" + "max active uploads". To make matters worse "don't count slow torrents towards limits" does _not_ apply to "maximum active torrrents", just the other 2.

Anyway, this is not the case for @amsterdampaul , as their queuing is disabled.

FranciscoPombal on 8 May 2020

@condoghost

Good, I think at this point we have enough confirmation.

Yes qBittorrent does appear to be managing to reconnect successfully though there is no entry in the execution log that highlights this

Perhaps at this point we don't have enough confirmation as to "why so many continuous SOCKS5 proxy errors" when I know this proxy continues working and hasn't been interrupted working during this client session.

Windows 7 qBittorrent Test Build #12583 (comment) "qBittorrent master commit 480e732 with libtorrent patch 4579"
No change - still using Connection Proxy Server SOCKS5 Host NordVPN uk1296

Summary of Activity since 07/05/2020
07/05/2020 18:09 Only udp torrent removed from client
07/05/2020 19:23 and 07/05/2020 20:04 42 SOCKS5 errors: SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep:
All http trackers are status Working
07/05/2020 20:05 ran ipleak Torrent Address detection reports IP address - NordVPN server is working
07/05/2020 20:06 '1st new udp torrent' added to client
udp trackers Not Working
Forced reannounce udp trackers Not Working
07/05/2020 20:09 ipleak removed from client
07/05/2020 20:11 '2nd udp torrent' added to client
udp trackers start Working, data is Downloading
Made decision to leave udp torrent Seeding with at least 1-Peer Uploading
09/05/2020 15:20 42-hours since last SOCKS5 proxy error
No further errors since 07/05/2020 20:11
qbittorrent_4.3.0alpha1-2020-05-09-14-24.txt
Perhaps SOCKS5 proxy errors are only occurring during periods when there are no udp torrents in the client actively seeding.
In a single session if I don't have any udp torrents in the client at all, only http torrents Seeding, SOCKS5 proxy errors do not occur.
Once I load a udp torrent in the client it appears a short period of time after that single udp torrent is removed - perhaps coincidence perhaps not - SOCKS5 proxy errors occur.
When I leave a single udp torrent in the client Seeding with trackers Working and at least 1-Seed Uploading, SOCKS5 proxy errors do not occur.

Thank-you for all your help. I'll not be reporting further on this unless something dramatically changes whilst running this Test Build. Stay Healthy Stay Safe.

condoghost on 9 May 2020

Probably worth mentioning that I've now been stable for over a month with the test build. Looking forward to a stable release!

crafty35a on 28 May 2020

Probably worth mentioning that I've now been stable for over a month with the test build. Looking forward to a stable release!

That's great to hear!

(In case you want to give it a whirl)
Here's the latest Windows test build of 4.3.0(Alpha1) I compiled with listed libraries:

qBittorrent master   | 4.3.0 +git a1faef0
libtorrent-rasterbar | 1.2.6 +git 2622792
Qt                   | 5.14.2
OpenSSL              | 1.1.1g
zlib                 | 1.2.11
Boost                | 1.73

Download Link

I haven't included the Qt 5.15 library as I'm currently having compilation issues with it.

xavier2k6 on 28 May 2020

Which thread are we suppose to be following for socks 5 issues now? I've lost track.

HnyBear on 30 May 2020

Which thread are we suppose to be following for socks 5 issues now? I've lost track.

This one (as in - the one you've just posted that question)

xavier2k6 on 30 May 2020

although, if it isn't "issue due to insufficient retries", it would be a bit misleading to post in this thread (since that's its title)

arvidn on 30 May 2020

Probably worth mentioning that I've now been stable for over a month with the test build. Looking forward to a stable release!

That's great to hear!

(In case you want to give it a whirl)
Here's the latest Windows test build of 4.3.0(Alpha1) I compiled with listed libraries:
qBittorrent master   | 4.3.0 +git a1faef0
libtorrent-rasterbar | 1.2.6 +git 2622792
Qt                   | 5.14.2
OpenSSL              | 1.1.1g
zlib                 | 1.2.11
Boost                | 1.73
Download Link

I haven't included the Qt 5.15 library as I'm currently having compilation issues with it.

@xavier2k6 What's new with this 1?

RabidWolf on 30 May 2020

@condoghost

Good, I think at this point we have enough confirmation.

Yes qBittorrent does appear to be managing to reconnect successfully though there is no entry in the execution log that highlights this

Such a message could be added later: #12583 (comment)

Let me just repeat again "No qBittorent does not appear to be managing to reconnect successfully every time"
For example, when I close client to shutdown PC. When I reopen client after restarting PC, all torrents with udp trackers are showing Not Working and seeds peers are not listed though some that were downloading before client was closed will actually now start to downloading.
I must Forced reannounce on each torrent with udp trackers Not Working once maybe twice maybe three times before udp trackers Working, torrent displays seeds and peers, and those torrents that were not downloading when I restarted the client now start to download.
This test build qBittorrent v4.3.0alpha1 (64-bit) is so much better but still we get instances where it is not managing to reconnect successfully every time.
Without an entry in the execution log to show reconnect successful as well as an entry to log a Forced reannounce is performed it is difficult to see how this may be progressed for investigation.
Is it 'livable with'? Yes, but only if we manually check from time to time that new udp torrents added are indeed Working and existing udp torrents are Working too.
Thank-you. Stay healthy stay safe.

condoghost on 4 Jun 2020

@condoghost is this a regression? does it work in any earlier version?
It sounds like torrents are starting before the SOCKS connection has been established, and the announces fail. Presumably the next announce would work, but that might be a few minutes later, when it's retrying.

Is that consistent with your observation?

arvidn on 4 Jun 2020

4.3.0 Alpha1 has not solved the problem for me. Still stuck at 'Retrieving metadata'

casnewydd on 4 Jun 2020

@casnewydd is it a regression?

arvidn on 4 Jun 2020

@casnewydd is it a regression?

Sorry, not very tech savvy when it comes to this.

casnewydd on 4 Jun 2020

did it used to work in an earlier version? and are the symptoms you see what's described in the ticket or are they different?

arvidn on 4 Jun 2020

4.3.0 Alpha1 has not solved the problem for me. Still stuck at 'Retrieving metadata'

Did you compile the build yourself or are you using a build from here & if yes - which one?

xavier2k6 on 4 Jun 2020

I've just tried using a different client and am having the same problem with that.

casnewydd on 4 Jun 2020

I manged to get it working by ticking 'Use different port on each startup' in Connection .

Can someone else try it and see if it works for them?

casnewydd on 4 Jun 2020

@condoghost is this a regression? does it work in any earlier version?
It sounds like torrents are starting before the SOCKS connection has been established, and the announces fail. Presumably the next announce would work, but that might be a few minutes later, when it's retrying.

Is that consistent with your observation?

@condoghost is this a regression? in what sense? the sense that this version runs okay for days on end then 'suddenly issues with udp trackers but none with the NordVPN SOCKS server having checked countless times that indeed the server is working no issues.
@condoghost does it work in any earlier version? Yes it appeared to work fine with 4.1.9.9
It works in this beta version much much better than with 4.2.5, 4.2.4 and 4.2.3 but not consistently and as I mentioned, when it does start churning out Socks5 Errors we simply don't know when it successfully reconnects because we don't have that message in our logs.
All I know is that udp trackers stop working, sometimes force reannounce does the trick, other times not, and a clinet shutdown/restart is the only recourse to take. Sometimes no issues with that restart, sometimes preloaded udp torrents start downloading whilst reading Not Working, sometimes force reannounce fixes that other times not.
It sounds like torrents are starting before the SOCKS connection has been established, and the announces fail. Presumably the next announce would work, but that might be a few minutes later, when it's retrying? It may well be, however, often the ONLY recourse is to 'Force announce' before we see udp trackers Working. It could well be that udp trackers are Working and the client isn't recording that! It's a 'mystery'. Client is stable for hours/days, the moment shut it down and restart it can go one of two ways. Either 'stable for days and days' or 'unstable having to constantly check to 'Force reannounce'.
What I can confirm is that just now I shut the client - not a deliberate action on my part, oops - and restarted.
I clearly see in the execution log torrents restored, 8 Socks5 errors 05/06/2020 18:42 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: and then 05/06/2020 18:43 - Detected external IP: in the one udp torrent loaded previously the two trackers Working with no manual force from me - that wasn't the case with the restart yesterday - then 14 more SOCKS5 errors.
Anyway, enough from me. Stay healthy and stay safe.

condoghost on 5 Jun 2020

@RabidWolf

@xavier2k6 What's new with this 1?

ref: https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-636340386

It has the fix from the previous build I supplied for Socks5 issues as per https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-619298534

but also all the latest fixes created from both qbittorrent & libtorrent.

EDIT: Oh, it also has a newer version of the Boost library. 1.73 vs previous 1.72

see ref:

qBittorrent commits

libtorrent commits

Feel free to ask me anything else or if you need any further clarity.

xavier2k6 on 7 Jun 2020

Windows 7 qBittorrent Test Build #12583 (comment) "qBittorrent master commit 480e732 with libtorrent patch 4579"
No change - still using Connection Proxy Server SOCKS5 Host NordVPN

qBittorent v4.3.0alpha1 (64-bit) is not stable sufficiently to just 'let it run in the background with our fingers crossed hoping for the best'

Client has been running continuously since 07/06/2020 18:32.

I have one incomplete udp torrent with trackers Working and one complete udp torrent with trackers Working Seeding.
I have 17 http torrents with trackers Working Seeding.

There have been 2,212 SOCKS5 proxy errors since 07/06/2020 18:32 and 08/06/2020 08:55:
2,210 are Message: SOCKS5 error. op: sock_read ec: End of file ep:IP address:1080
At 07/06/2020 23:29 there is a SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep:same IP address:1080
At 08/06/2020 04:41 there is a SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: same IP address:1080

08/06/2020 08:55 I load a new udp torrent with trackers Not Working; torrent starts downloading indicating Seeds 0(0) Peers 3(5)
There are a further 10 SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep:same IP address:1080
08/06/2020 08:58 I load a second new udp torrent with trackers Not Working; it too starts downloading indicating Seeds 0(0) Peers 6(7)

08/06/2020 09:02 new udp torrents, trackers still Not Working; I 'Force announce' and wait'

08/06/2020 09/07 new udp torrents, trackers are now Working and of course 'still downloading'.

08/06/2020 10:41 there have been no further SOCKS5 proxy errors since loading that second udp torrent at 08:58.

I don't know if the client is truly connected to the NordVPN server during this time period 07/06/2020 18:32 and 08/06/2020 08:55 or the client is 'bypassing' the NordVPN server.

There isn't a message in the client to advise me and only when using the NordVPN App from outside the client can I 'guarantee' the client is auto-disconnected from the network when the NordVPN server is down. However, there are no indications anywhere that the NordVPN server went down and came back up again during this time and when checking with NordVPN they came back advising this specific server has not been down during this time.

ipleak Torrent Address detection reliably informs me EVERYTIME that indeed the NordVPN server is connected to the client, however, ipleak Torrent Address detection tracker is http and as far as I know there aren't issues with http trackers.

I'm not aware of a Torrent Address detection with a udp tracker.

I will look for one but in the meantime I truly fear the client could be 'exposed' at times should udp trackers or http trackers at any time not actually be connected to the SOCKS5 NordVPN server, and activity continues 'blindly' connecting with our true IP-address.

This is a serious concern given this is a very similar issue with using uTorrent where it is CLEAR that using SOCKS5 within that client - for both udp trackers http trackers - is NOT WORKING and probably never has: ipleak Torrent Address detection http reports connection to our true IP-address EVERY TIME when using uTorrent which is why I switched some years back to qBittorrent.

Without a Torrent Address detection udp to verify the situation with qBittorent and udp trackers, there has to be a 'lingering doubt' - no matter how miniscule - with udp trackers.

Perhaps I'm being too 'over cautious' and the 'chance' of http trackers being connected to the SOCKS5 NordVPN server and the udp trackers being connected directly to our true IP-address is simply 'not possible'. But in this day and age we simply cannot take 'not possible' for granted. It has to be 'proven' not to be the case but I guess I can take 'reassurance' this IS not the case given all my http torrents are monitored from the website they were downloaded and that isn't reporting a 'Change of IP address' which it does if I switch NordVPN SOCKS5 servers.

It is indeed too 'complex' for this old brain to fathom the logic that a client can be connected to SOCKS5 server for http torrents showing http trackers Working but not be connected to that same SOCKS5 server for udp torrents showing udp trackers Not Working.
Given these same udp torrents with udp trackers Not Working can clearly be seen to be 'downloading' for an age before the client advises us the udp trackers are indeed Working, it drives us to suppose 'It is indeed a 'mystery'' :)

Thank-you for your time and consideration and apologies for 'waffling on'

Please everyone 'Stay Healthy Stay Safe' as many of us continue to be in 100% Total Lockdown for our own safety during these unprecedented times.

condoghost on 8 Jun 2020

@condoghost please try the build from https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-635505117

xavier2k6 on 8 Jun 2020

@condoghost please try the build from #12583 (comment)

Will do thank-you Give me 48-hours thank-you

condoghost on 8 Jun 2020

@condoghost please try the build from #12583 (comment)

Will do thank-you Give me 48-hours thank-you

The situation continues with this build also. Hours of 'all okay' then hundreds of SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address:1080.
New udp torrents loaded start downloading even though client is reporting the udp trackers Not Working.
Today for example between 09:36 and 14:59 986 SOCKS5 proxy errors. UDP torrents already loaded in client the trackers are showing Not Working. A new UDP torrent loaded to client the trackers are showing Not Working yet the torrent starts downloading and completes the download 9-minutes later and udp trackers are still showing in the client Not Working.
Sometimes have to Force announce for newly loaded udp torrent trackers to show Working and the torrent to start downloading. Other times as in the case just mentioned, udp torrent starts downloading and even completes before udp trackers in the client show Working.
As I have said before 'It's a 'Mystery''. Thank-you for your perseverance with this.
I'll await an update and test that before making comment again.
Stay healthy Stay safe.

condoghost on 14 Jun 2020

yet the torrent starts downloading and completes the download 9-minutes later and udp trackers are still showing in the client Not Working.

Do I understand correctly that everything essentially works as expected except trackers say "Not Working" and you get SOCKS5 errors in the log?

(The SOCKS5 errors are actually expected to happen, and can come in bursts if the provider has an issue where one needs to fail over for instance).

I think the "not working" comes from libtorrent reporting tracker status for each individual listen socket, and qbittorrent expecting just one announce per tracker. I suspect at least that if one listen socket failing to announce (which is expected to happen) "clobbers" the tracker status even though another listen socket succeeds in announcing.

arvidn on 14 Jun 2020

yet the torrent starts downloading and completes the download 9-minutes later and udp trackers are still showing in the client Not Working.

Do I understand correctly that everything essentially works as expected _except_ trackers say "Not Working" and you get SOCKS5 errors in the log?

Some times 'everything essentially works as expected apart from tracker status', other times not.
As I post this comment I loaded a new udp torrent 15/06/2020 20:26. Trackers listed Not Working, Seeds 0(0) Peers 0(0).
Force announce trackers still Not Working, udp torrent still not downloading, existing http torrents are Working and Seeding.
Ping indicates proxy server is working. ipleak iTorrent address detection ndicates proxy server is working.
Client reports a total of 1,592 SOCKS5 proxy errors since client was restarted 15/06/2020 10:29 having switched NordVPN server.
Between 15/06/2020 10:34 and 15/06/2020: 1,588 SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address:1080
3 SOCKS5 proxy errors 15/06/2020 10:36, 15/06/2020 10:39 and 15/06/2020 10:43 Message: SOCKS5 error. op: handshake ec: An existing connection was forcibly closed by the remote host ep: IP address :1080
1 SOCKS5 proxy error 15/06/2020 18:35 Message: SOCKS5 error. op: handshake ec: The semaphore timeout period has expired ep: IP address:1080
Since loading udp torrent at 15/06/2020 20:26, between 15/06/2020 20:29 and 15/06/2020 20:51 there are a further 97 SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep IP address:1080 either 3 or 4 errors reported each minute.
15/06/2020 20:51 udp torrent starts downloading - 25 minutes after loading; udp trackers Working.
15/06/2020 21:05 SOCKS5 proxy errors Message: SOCKS5 error. op: sock_read ec: End of file ep: reporting again. Between 15/06/2020 21:05 and 15/06/2020 21:35 76 further SOCKS5 proxy errors Message: SOCKS5 error. op: sock_read ec: End of file ep:
Client continues to list them 4 a minute.

condoghost on 15 Jun 2020

And simply to 'confirm' that 'no everything is not essentially working as expected' today I loaded 3 new udp torrents. udp trackers Not Working Seeds 0(0) Peers 0(0) and simply would not start downloading regardles Forced reannounce, Pause or anything else I could think.
I Set SOCKS5 Proxy No and closed client. I reopened client and all 3 udp torrents started downloading immediately and udp trackers Working.
I Set Socks5 Proxy Yes with Authentication and close client.
10 minutes later I loaded a new udp torrent which of course opens the client. The 3 previously loaded udp torrents immediately show Seeds and Peers and start downloading even though udp trackers are showing Not Working in the client and we have 9 SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address:1080 and at 16/06/2020 09:07 1 SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: IP address:1080.
No further SOCKS5 proxy errors since and 16/06/2020 09:22 the new udp torrent loaded to open the client? the udp trackers are still Not Working, Seeds are still 0(0), Peers are still 0(0) and this udp torrent is still not downloading.
I close the client.
5-minutes later I reopen the client. the 3 previous udp torrents and the new udp torrent immediately have Seeds and Peers and start downloading.
Each udp torrent has ONE udp tracker Working and ONE udp tracker Not Working.
I check the Detected external IP address with IP Find Check and IP Find Location and confirm it is the NordVPN server.
The no SOCKS5 proxy errors will likely start logging again once these udp torrents are complete and no longer being seeded as appears to be the case time and again with this situation.
I confirm there are no further SOCKS5 proxy errors reported at this time.
UPDATE: udp trackers in all 4 udp torrents are now Working.
UPDATE and as I 'suspected would happen', 11-minutes after all 4 udp torrents have completed downloading and are 'paused' 'Seeding', the SOCKS5 proxy errors. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address:1080 start listing in the log again even though there are no udp trackers of any udp torrents looking to connect as previous paused udp torrents the udp trackers are Not Contacted Yet and these 4 paused udp torrents the udp trackers are Not Working. Perhaps all udp trackers for all udp torrents must be Not Contacted Yet for this never ending loop of SOCKS5 proxy errors to stop. OF course Resuming these 4 udp torrents the status is still Not Working and may well likely remain the case until the client is closed and restarted but then 'I'm no expert'.
It's all a 'Mystery' and like traffic congestion will likely never know the 'cause' once it all frees up or returns time and again.
The most important thing right now? 'Stay healthy Stay safe' as always. Thank-you.

condoghost on 16 Jun 2020

It's all a 'Mystery' and like traffic congestion will likely never know the 'cause' once it all frees up or returns time and again.
The most important thing right now? 'Stay healthy Stay safe' as always. Thank-you.

I downloaded that latest 4.3.0 test build just for fun and it doesn't seem to make any difference at all for me, compared to the official 4.2.5 release.
Which supports condoghost's experience.

Starting the client gives about 12 errors after all the torrents load in.
Usually a mix of these 3 variants:

6/19/2020 9:11 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: XX.XXX.XX.XXX:1080

6/19/2020 9:08 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: connect ec: timed out ep: XX.XXX.XX.XXX:1080

6/19/2020 9:07 PM - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: XX.XXX.XX.XXX:1080

Then a glorious blue success message showing the detected IP.
A few minutes of decent downloading even though 95% of trackers say "Not working"
(Usually 1 or 2 trackers will show Working if it's on a torrent with a 20+ to choose from)

Then some more SOCKS5 errors.

Leaving the client running for days on end does eventually complete torrents, but most of the time opening the client shows 0 bits down / 0 bits up and a mess of SOCKS5 errors.
(though occasionallyyy it'll be downloading away with almost problem, despite the errors.. maybe that's related to the specific torrent being downloaded though)

Reannouncing to all trackers doesn't make them work any better as far as I can tell, sadly.

galacticboy2009 on 20 Jun 2020

Windows test build of 4.3.0(Alpha1) with listed libraries:

qBittorrent master   | 4.3.0 +git 9dfeeb9
libtorrent-rasterbar | 1.2.7 +git 89419b1
Qt                   | 5.15.0
OpenSSL              | 1.1.1g
zlib                 | 1.2.11
Boost                | 1.73

"Windows Test Build" download link below:
qBittorrent master +git 9dfeeb9 with Boost 1.73 + Qt 5.15 + libtorrent 1.2.7 +git 89419b1

xavier2k6 on 20 Jun 2020

"Windows Test Build" download link below:
qBittorrent master +git 9dfeeb9 with Boost 1.73 + Qt 5.15 + libtorrent 1.2.7 +git 89419b1
Thank-you. Downloaded and using now. There's a 2-second delay between loading everything and then Detected external IP: address.
During those 2-seconds 5 SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: IP address.
udp torrents already loaded start downloading though status of udp trackers Not Working for 3-4-5-6-minutes
Loaded three new udp torrents, trackers instantly 'Working' and all started to download.
No further OCKS5 proxy errors at this time. I'll leave it running but will have to do something with every other line 'white' 'grey', this combination causes me 'eyesight issues' as I scroll up scroll down the page - horrible.
But hey, least of any issue right now as we look to Stay Healthy Stay Safe.

condoghost on 25 Jun 2020

came over from uTorrent because it ceased functioning no matter what i did
ver 4.2.5, win 10, centurylink gig fiber servce, Nordvpn service using US p2p specific server address, udp trackers have never worked, even with 'force announce' most http trackers (but not all) work, and no udp's work, here's relevant section of the log
torrents work randomly, up or down, and node count varies wildly, sometimes in mid-low double digits, sometimes in the few hundreds

`6/28/2020 13:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep: 184.170.240.102:1080

6/28/2020 13:36 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:35 - Detected external IP: 184.170.240.103

6/28/2020 13:35 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

6/28/2020 13:34 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080`

stromdriver on 28 Jun 2020

@stromdriver please try the build in this https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-646988383

xavier2k6 on 28 Jun 2020

@stromdriver please try the build in this #12583 (comment)

pretty much same results, all udp trackers show as 'not working', mid double digit nodes

6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:15 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:14 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:13 - Detected external IP: 184.170.240.103
6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:13 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: The semaphore timeout period has expired ep: 184.170.240.102:1080
6/28/2020 17:12 - SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: The semaphore timeout period has expired ep: 184.170.240.102:1080

stromdriver on 29 Jun 2020

@stromdriver are your network drivers up-to-date?

@arvidn still seems to be an issue with UDP?

xavier2k6 on 29 Jun 2020

@stromdriver are your network drivers up-to-date?

@arvidn still seems to be an issue with UDP?

as far as i know? my surface pro just did a couple sizable updates lately and shows as up to date

stromdriver on 29 Jun 2020

Is there any way of telling whether the udp tracker is delivering peers, regardless of whether it says “not working”? I have a feeling qbt attribute A failure for any Endpoint to the whole tracker

arvidn on 29 Jun 2020

"Windows Test Build" download link below:
qBittorrent master +git 9dfeeb9 with Boost 1.73 + Qt 5.15 + libtorrent 1.2.7 +git 89419b1

Now 14-days. SOCKS5 Errors listing again after 3-days. Same issues as before already loaded udp torrents start downloading every time even though status is Not Working; new udp torrents sometimes status will eventually change on some udp trackers but not all after 4-5-minutes and torrent starts downloading, other times need to 'Force announce' and eventually status changes and torrent starts downloading. Sometimes that 'Force announce' updates all trackers Working, other times not.
When it becomes 'impossible' with very slow download, no download, reams of SOCKS5 Errors I shut down client, clear all cache, wait 4-5-minutes, then restart.
Did this three-four times over last 10-days. All seems okay for 24-48-hours then SOCKS5 Errors return, then 'issues' with new udp torrents trackers Not Working. Same again, sometimes just leaving them for 2-3-4-minutes some trackers start working but not all, sometimes 'Force announce' 'instantly' results all udp trackers working, sometimes 'nothing' until 2-3-minutes later it 'springs to life'. Most times already loaded udp torrents automatically start to download even though status is still Not Working'; that status will eventually change to 'Working' even though no SOCKS5 Errors reporting beforehand.
To summarize: 24-48-72-hours no SOCKS5 Errors, no issues. Once SOCKS5 Errors start listing it all becomes 'hit and miss'; sometimes the client 'settles', errors stop listing, and all is okay with status and downloading, othertimes no matter what we do, SOCKS5 Errors keep listing, new udp torrents don't start downloading, udp trackers status remains Not Working, 'Force announce' has no effect whatsoever, and best to shut down client, clear cache of temp files, and restart client. Sometimes that settles the client for another 24-48-72-hours, other times the client returns to an unstable condition straight away, within an hour, two-hours.
One possibility is that having just one udp tracker Not Working on just a single udp torrent where other udp trackers are Working, and all other udp trackers in udp torrents are Working, may be causing the client to fall into this never ending 'loop' where it becomes 'fixated 'on that 'one tracker', new udp torrents with their udp trackers remain queued for 'attention' until the client is 'freed' to attend them - similar to what we would see for example if we have too many things going on with our PC such as mkvmerge, mkvextract, copy paste files, deleting files, scanning files, whilst StaxRip is running at at 98% CPU, everything slows to 'nothingness' until it 'magically' works it all out.
One 'lives with it' but most times when this starts it won't 'sort itself out' without a manual client restart same as sometimes we may be forced to do with our PC in the scenario outlined. Just my 'thinking' always wanting 'logical reasoning'.
Thank-you for your continued efforts. It 'is what it is', a 'magical mystery [tour]' of sorts :)
Stay healthy stay safe.

condoghost on 8 Jul 2020

@condoghost thanks for the info.

Here is a new build on top of latest master with:

logging of all tracker announce error alerts
a little more verbosity on the SOCKS5 alert (not sure if it will help)

:

diff --git a/src/base/bittorrent/session.cpp b/src/base/bittorrent/session.cpp
index af6df18ae..c1a36ce1f 100644
--- a/src/base/bittorrent/session.cpp
+++ b/src/base/bittorrent/session.cpp
@@ -4718,7 +4718,7 @@ void Session::handleStateUpdateAlert(const lt::state_update_alert *p)
 void Session::handleSocks5Alert(const lt::socks5_alert *p) const
 {
     if (p->error) {
-        LogMsg(tr("SOCKS5 proxy error. Message: %1").arg(QString::fromStdString(p->message()))
+        LogMsg(tr("SOCKS5 proxy error. Message: %1 | error.message(): %2").arg(QString::fromStdString(p->message()), QString::fromStdString (p->error.mess      16 age()))
             , Log::WARNING);
     }
 }

diff --git a/src/base/bittorrent/torrenthandleimpl.cpp b/src/base/bittorrent/torrenthandleimpl.cpp
index 062ec56a7..09ddee2da 100644
--- a/src/base/bittorrent/torrenthandleimpl.cpp
+++ b/src/base/bittorrent/torrenthandleimpl.cpp
@@ -1417,6 +1417,9 @@ void TorrentHandleImpl::handleTrackerErrorAlert(const lt::tracker_error_alert *p

     m_trackerInfos[trackerUrl].lastMessage = message;

+    LogMsg(tr("<tracker_error_alert> error: %1 | failure reason: %2")
+        .arg(QString::fromStdString(p->error.message()), p->error_message()), Log::WARNING);
+
     // Starting with libtorrent 1.2.x each tracker has multiple local endpoints from which
     // an announce is attempted. Some endpoints might succeed while others might fail.
     // Emit the signal only if all endpoints have failed.

(any of the 4 builds will do, you can just select the one with latest Qt version and libtorrent RC_1_2 head)

If you can post logs with these alerts, that would be great. Also, please clarify if you're still able to connect and get peers _despite_ the errors shown in the GUI and logs.

FranciscoPombal on 8 Jul 2020

No offence but why do people use socks? It doesn’t provide any sort of encryption...at best you’re hiding your IP from other peers. But your ISP can still detect torrent traffic.

ghost on 12 Jul 2020

For when you don't want all services on a specific server behind a VPN.

I believe socks5 proxies have better performance too.

Douglas Parker

On Sat, Jul 11, 2020, 7:53 PM An0n notifications@github.com wrote:

No offence but why do people use socks? It doesn’t provide any sort of
encryption...at best you’re hiding your IP from other peers. But your ISP
can still detect torrent traffic.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-657166316,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AELEDLVMWUSD27DBSCJSAVDR3EQTHANCNFSM4MOTQNUQ
.

douglasparker on 12 Jul 2020

No offence but why do people use socks? It doesn’t provide any sort of encryption...at best you’re hiding your IP from other peers. But your ISP can still detect torrent traffic.

Of course the 'best solution' is to use an external VPN App but for 'many reasons', as I outline below, this is not the 'ideal' and definitely impacts your browsing experience where some websites and most payment systems specifically will not 'work' with a VPN. Also with two-step verification now becoming more and more 'common', a 'change of IP address' from that used last time triggers a 'red flag' in this scenario especially with Google accounts for example.

Using SOCKS5 VPN Server? own ISP doesn't detect the specifics of the 'traffic' only that there is 'traffic'; and bear in mind it's all about the traffic 'back to you''

As an example, 'ipleak' IDs Your IP addresses, Your IP addresses WebRTC detection, DNS Address, Torrent Address detection, Geolocation detection.
Do this without VPN and a browser set 'Connections Settings' 'Configure Proxies to Access the Internet' 'No proxy' you will see your specific IP-address and your ISP information and all the other 'specifics' with your ISP. More detail can be seen 'checkmyip' and 'iplocation'.
Configure browser 'Manual proxy configuration HTTP Proxy' with VPN US server, for example, and 'tick' Use this proxy for all protocols - SSL Proxy, FTP Proxy, SOCKS5 - all URL traffic is now directed through VPN US server.
Add specific websites in 'No proxy for', a 'White List' if you like, that 'traffic' is 'direct, ISP can identify that traffic 'specifically', but all traffic through 'Manual proxy' is just 'traffic' for want of writing a 'non-technical explanation'.
Run qBittorrent client, whatever client, with no proxy configuration and activate Torrent Address detection ipleak, you see DNS Address is ISP DNS. Set the 'client' with SOCKS5 proxy and 'hopefully' the DNS Address is now VPN server.
Unfortunately uTorrent still 'leaked' when I was using that a few years back which is 'why' I now use qBittorrent client.
Torrent Address detection will now list torrent address but unfortunately this ipleak check is only for http trackers. I've yet to come across a Torrent Address detection for udp trackers.
Using a number of browsers with a different SOCKS5 VPN Server for each, eg browser SOCKS5 US VPN Server and another browser SOCKS5 UK VPN Server, you have the 'freedom' of watching US-specific content on one and UK-specific content on the other.
Some content providers are wiser to this these days and look to 'block' VPN traffic. VPN providers are constantly looking to better this and so this continues back and forth.
Simple things like YouTube country specific content is not so much an 'issue' as Streaming services content is.
Setting a torrent client SOCKS5 VPN specific country server now fits this set-up of using a number of applications across multiple country VPN all from the single PC, laptop, pad, whatever.
Of course an external VPN App is 'better' however 'all traffic' is directed through that 'single country specific VPN server' setting regardless of browser settings, regardless browser 'No proxy for' settings, no matter torrent client settings.
Same issue with browser VPN Add-on - all browser traffic is directed through that 'single country specific VPN server' setting.
Using SOCKS5 is not ideal but it does free you up to connect multiple applications to multiple country VPN servers.

The ideal? VPN App where we get to list applications such as Waterfox browser, Chrome browser, Pale Moon browser, SeaMonkey browser, whatever browser, qBittorrent client, whatever client. Against each we specify the VPN country, server type, security protocol and 'White List' where applicable. Now when we start our PC all is handled automatically in the background, auto-switch to alternate server whenever a server goes down with auto-application 'pause (kill-switch) to prevent any 'traffic leakage'.

We can dream. I keep badgering my VPN service every month or so, I guess I'm 'on a mission'.

Stay healthy, stay safe.

condoghost on 19 Jul 2020

@condoghost thanks for the info.

Here is a new build on top of latest master with:
* logging of all tracker announce error alerts

* a little more verbosity on the SOCKS5 alert (not sure if it will help)
(any of the 4 builds will do, you can just select the one with latest Qt version and libtorrent RC_1_2 head)

If you can post logs with these alerts, that would be great. Also, please clarify if you're still able to connect and get peers _despite_ the errors shown in the GUI and logs.

Okay, I've grabbed this and will start later today, run it this week and get back to you. I'll also clarify if I'm still able to connect and get peers_despite_ the errors shown in the GUI and logs.
I'll get back sooner if I'm 'forced' to shut down the client and restart which has been the only 'answer' at times with 'new' torrents refusing to start.
Stay healthy, stay safe.

condoghost on 19 Jul 2020

👀1 👍1

The errors in the log are expected to happen every now and then, as the SOCKS connection time out for instance. They aren't expected to spam the log continuously though. But those messages are mostly helpful if nothing works. Then they might indicate what's failing.

arvidn on 19 Jul 2020

The errors in the log are expected to happen every now and then, as the SOCKS connection time out for instance. They aren't expected to _spam_ the log continuously though. But those messages are mostly helpful if nothing works. Then they might indicate what's failing.

UPDATE Client running since 19 July 2020 16:37. Attachments 2020-07-20-execution-log.xlsx and 2020-07-20-observations-actions.txt sent to the email address in your profile arvidn. Thank-you.
Stay healthy, stay safe.

UPDATE It is worth mentioning all torrent trackers are http from 20/07/2020 15:48 onwards having deleted all udp torrents at this time.

condoghost on 20 Jul 2020

@condoghost mind uploading the files here, as attachments?

FranciscoPombal on 20 Jul 2020

@condoghost mind uploading the files here, as attachments?

The information is too public uploaded here as 'attachments'. I don't see an email address in your profile?

condoghost on 20 Jul 2020

The information is too public uploaded here as 'attachments'. I don't see an email address in your profile?

The point is to make the data more easily accessible to anyone interested. You can easily redact the sensitive information in the logs/settings.

FranciscoPombal on 27 Jul 2020

The information is too public uploaded here as 'attachments'. I don't see an email address in your profile?

The point is to make the data more easily accessible to anyone interested. You can easily redact the sensitive information in the logs/settings.

"The point is to make the data more easily accessible to anyone interested" Really?
What is there to say. If you believe it is 'okay' to post data in this way for it to be more easily accessible to anyone interested then go ahead and post your data in this way. You can easily include an email address in your profile to have received this data but there we go - you chose not to provide one. Are you a 'developer'? Are you 'working on fixing this'? Somehow I don't think so.

"You can easily redact the sensitive information in the logs/settings" Really? I'm still pondering a polite answer to your 'suggestion' given my earlier posts it is pretty obvious I already know that and have done so in the past.
I have chosen not to remove the 'sensitive information' this time because it is clear that some messages are specific and without the 'sensitive information' it would not be clear what was specific to what.

condoghost on 2 Aug 2020

@condoghost YES @FranciscoPombal is part of the qBittorrent team & YES he "IS" working on fixing this & so is the developer/owner of the libtorrent library @arvidn

There are users like myself & "for clarity" - ("NO, I AM NOT A DEVELOPER") who are also focused on fixing this issue even if we don't experience the issue(s) as outlined in this thread in order to benefit the qBittorrent & even libtorrent user community at large.

"You can't make scrambled eggs without breaking some eggs"...............but first somebody needs to supply those eggs.

Issue can't really be fixed, if not all info is supplied is what I am getting at (all parties involved need to look at the info, fresh pair of eyes/different thought(s)/views etc.)

Some people don't readily supply an email address as bots can pic it up for spam etc.

It is not an unreasonable request to post the redacted info here, but if you decline - that's ok.

Help us, to help you.

xavier2k6 on 2 Aug 2020

The errors in the log are expected to happen every now and then, as the SOCKS connection time out for instance. They aren't expected to _spam_ the log continuously though. But those messages are mostly helpful if nothing works. Then they might indicate what's failing.

Having run this since 14-days now and not had any 'feedback' as to 'where we are at' after submitting logs and observations July 20 I can but update you on my 'experience' since then.
I was under the impression this was primarily a proxy issue with udp trackers but having deleted all udp torrents and running the client since 20/07/2020 15:48 with torrents having only http trackers it highlights to me how unstable the SOCKS5 proxy is.
The client remained fairly stable for 3-4-5 days then became 'unstable' and these last three days has become very 'unpredictable' constantly advising http trackers Not Working requiring many attempts to Pause and Resume. Sometimes Pause http trackers immediately switching to Working, other times not and when Resumed immediately switching to Working or sometimes not. 'bad gateway' constantly coming up across a number of http trackers.
Today it simply has become 'impossible'. I have switched proxy servers 4-times and have lists of " error: An existing connection was forcibly closed by the remote host | failure reason:" and " error: End of file | failure reason:" with any number of http trackers Not Working.
On three restarts the client would not return a Detected external IP message and on two restarts the client returned a Detected external IP of 0.0.0.0!
ipleak.net torrent address detection reported the correct IP address on each occasion.
On the udp tracker front I had to set the client to 'No proxy', close and restart before any of udp trackers on newly loaded udp torrents were Working and for udp torrents to have Seeds, Peers, Down Speed, Up Speed.
I have restarted the client with SOCKS5 proxy server. all 7 udp torrents have Seeds, Peers, Down Speed, Up Speed and all udp trackers are Working. What is 'interesting' is now when the torrent is 'complete' and 'Seeding' and I Pause? udp trackers 'Working' 'update' and then 'Not Working'. This was not happening for many days before today. But then, what can I say, I now see that this does not happen every time, sometimes, sometimes 'not'. I don't see any point in trackers 'working' when the torrent is 'paused' but there we go.
Each of the 15 http torents have the same 3 http trackers. 8 http torrents have all 3 same http trackers working, 3 have one same http tracker Not Working, and 3 have two same http trackers Not Working.

Is there a new build I can grab to continue? Thank-you.
Stay healthy, stay safe.

condoghost on 2 Aug 2020

Is there a new build I can grab to continue?

Not until we have more info/possible patch from @arvidn to go on. (If needed)

xavier2k6 on 2 Aug 2020

@condoghost YES @FranciscoPombal is part of the qBittorrent team & YES he "IS" working on fixing this & so is the developer/owner of the libtorrent library @arvidn

There are users like myself & "for clarity" - ("NO, I AM NOT A DEVELOPER") who are also focused on fixing this issue even if we don't experience the issue(s) as outlined in this thread in order to benefit the qBittorrent & even libtorrent user community at large.

"You can't make scrambled eggs without breaking some eggs"...............but first somebody needs to supply those eggs.

Issue can't really be fixed, if not all info is supplied is what I am getting at (all parties involved need to look at the info, fresh pair of eyes/different thought(s)/views etc.)

Some people don't readily supply an email address as bots can pic it up for spam etc.

It is not an unreasonable request to post the redacted info here, but if you decline - that's ok.

Help us, to help you.

xavier2k6 you make an very interesting point. First you go on about 'Issue can't really be fixed, if not all info is supplied' and then you mention 'Some people don't readily supply an email address as bots can pic it up for spam etc'.
Well, what can I say ...
1) all info has been supplied. It is not for me, a 'user', to work out how this is distributed among 'interested' parties;
2) if @arvidn can provide an email address in 'profile' then so can everyone else who has an interest;
3) your case of an email address being picked-up by bots doesn't wash with me. I use a specific email address for all forums, I don't store others email addresses, I don't save emails sent. This ensures the 'risk' of 'spam' is restricted only to my specific email address which - seriously - is never an issue when one never opens emails that aren't clearly 'specific' and 'known';
4) 'Eggs' have been supplied, 'live with it';
5) I'm not saying it's not a reasonable request to post redacted info here, I'm saying some important 'unredacted info' is pretty 'worthless' when presented in 'redacted' form and if you really think it is so 'straight forward' then I suggest you be seen to be doing so yourself before asking others to do. My current log is already 600 lines and client has been running for less than two-hours. Simplicity is in the eye of the beholder;
6) I've not requested your 'opinion' My post was directed to @FranciscoPomba; and
7) 'Help us, to help you.'? I take exception to that given I appear to be only one of perhaps two? three at most? who have actually 'bothered' to provide info regularly since this issue came up months ago. I don't see others providing this much detail here in this topic so I suggest you be grateful for the help I am providing!

condoghost on 3 Aug 2020

Is there a new build I can grab to continue?

xavier2k6 Not until we have more info/possible patch from @arvidn to go on. (If needed)

More info? What 'more info' is needed? 'Redacted' info which is pretty 'worthless' in real terms given 'the devil is in the detail'? How much 'more info'?
I'm astounded at the lack of courtesy shown here. Apart from 'what does this relate to?' from @arvidn? nothing. No 'feedback', no 'status', no 'progress', nothing.
Time for me to 'move on'. I post 'info' and all I get is 'why can'y you post redacted data?' from others who haven't posted any data whatsoever and then yourself looking to 'justify reasoning' for 'why' I should do something 'more'.
Unbelievable.

condoghost on 3 Aug 2020

I've not requested your 'opinion' My post was directed to @FranciscoPomba

ok, then - I take exception to that

'Help us, to help you.'? I take exception to that given I appear to be only one of perhaps two? three at most? who have actually >'bothered' to provide info regularly since this issue came up months ago. I don't see others providing this much detail here in >this topic so I suggest you be grateful for the help I am providing!

so I suggest you be grateful for the help I am providing!

Ok, first of all - read the OP https://github.com/qbittorrent/qBittorrent/issues/12583#issue-605150325

There has been more than one issue thread about proxies etc
There has been more than one person giving info/help wherever & whenever needed (as much as needed/requested)

If you read through this issue or any other tracker - you will see that I have helped with providing test builds or linked to other builds that @FranciscoPombal built , which you have used.

This is a project that is handled by volunteers in their own personal time!

and to quote you again.

so I suggest you be grateful for the help I am providing!

xavier2k6 on 3 Aug 2020

Is there a new build I can grab to continue?

xavier2k6 Not until we have more info/possible patch from @arvidn to go on. (If needed)

More info? What 'more info' is needed? 'Redacted' info which is pretty 'worthless' in real terms given 'the devil is in the detail'? How much 'more info'?
I'm astounded at the lack of courtesy shown here. Apart from 'what does this relate to?' from @arvidn? nothing. No 'feedback', no 'status', no 'progress', nothing.
Time for me to 'move on'. I post 'info' and all I get is 'why can'y you post redacted data?' from others who haven't posted any data whatsoever and then yourself looking to 'justify reasoning' for 'why' I should do something 'more'.
Unbelievable.

and I am done, to other users experiencing this issue, my apologies but at this time - I am no longer interested in spending my valuable spare time with regard to this, going to spend my time more wisely with my wife & kids.

xavier2k6 on 3 Aug 2020

@FranciscoPombal @arvidn please respond to @condoghost when you get a chance & help him ASAP!!!! with his requests/demands - self entitlement or whatever else anyone wants to call it, I'M DONE!.

xavier2k6 on 3 Aug 2020

More info? What 'more info' is needed? 'Redacted' info which is pretty 'worthless' in real terms given 'the devil is in the detail'? How much 'more info'?

@condoghost The most important information that I would be interested in is some evidence that something in libtorrent is not working as intended. So far I haven't seen anything. If you think that there is a problem in libtorrent, please describe it as clearly and succinctly as possible (ideally in complete sentences and no quoted nebulous words like "stable", explain what you mean instead).

Keep in mind that your proxy disconnecting you, or your internet connection failing, does not indicate a problem in libtorrent. Now, I'm not saying it's your proxy or your internet connection that's causing the issue you experience, I'm saying that I haven't seen anything to suggest it isn't. Ruling out other likely causes of issues would be very useful.

So far, the most prominent description of the problem is that trackers says "Not working" in the qBT UI. This is not actionable information. I don't know the exact conditions of when qBT displays that message, but I'm pretty sure it does it under all kinds of different failures (and in fact, I'm pretty sure it displays that message when trackers are working sometimes too).

Any report based around "qBT says my tracker isn't working" carries extremely little weight in my book, as I'm pretty sure that's not an indication of it not working. Something like "I've turned off DHT, LSD and incoming connections and removed all trackers but this one, and I'm not getting any peers from it via a proxy, but I do get peers when I don't go through a proxy". That would be much more useful information. Because it reports the actual problem.

Obviously it's also a good bug report to say something like: "my tracker is working, but the UI still says it's not working". That should be fixed, and maybe it needs to be fixed before we can get any clarity on the reports in this ticket. But, it's different enough from the topic here that it should be reported separately.

Either way, I think all of the reports in this ticket are different from the title. The title of this ticket was addressed and fixed a long time ago.

@condoghost to round up, I received your logs, but I still don't know what to look for in them, because I don't know what issue you're experiencing. Just pointing to this ticket isn't good enough, because this ticket is about "SOCKS5 proxy disconnect issue due to insufficient retries" and that's not the issue you're experiencing.

arvidn on 3 Aug 2020

arvidn

@condoghost to round up, I received your logs, but I still don't know what to look for in them, because I don't know what issue you're experiencing. Just pointing to this ticket isn't good enough, because this ticket is about "SOCKS5 proxy disconnect issue due to insufficient retries" and that's not the issue you're experiencing.

Your telling me you now 'weeks later' that you can't tell the issues being experienced?

I'm just a 'simple minded user' who reported a problem with SOCKS5 and ended up being re-directed here as a result of 'original threads' being 'closed' and here you see the 'WHY' as Cunningcory commented on Apr 23
I just love every year or so having to re-follow a new thread on basically the same issue since the others keep getting closed without being fixed. SOCKS5 has never worked for me, and I've always tried newer builds without any difference, including the next to last one posted on the most recent closed discussion. I'm in the middle of testing the current build and was going to give feedback, but the thread was closed.
And FranciscoPombal commented on Apr 23
Umm, yes? Did you read #11735 (comment)? This issue report was opened specifically to track this disconnect issue, which is the important thing now. The other thread was already filled with unrelated information. It is easier to track this single issue with a clean slate.
And as Cunningcory then commented on Apr 24
@arvidn Xavier is correct, that's the error. This is why I don't understand why the other thread was locked down as the discussion was troubleshooting "proxies and UDB issues". I guess this is just to get more specific to SOCKS5? It just feels like having to start from scratch with the troubleshooting.
For me and seems most people this has always been the issue for years. You start qbittorrent and everything is working fine with SOCKS5. Then you return later and it isn't working. You then restart the Qbit (maybe several times) and then it works again for a brief amount of time. This is the problem I have always had, so I guess I'm confused as to what other issues have been fixed.
As to ...

This is why I don't understand why the other thread was locked down as the discussion was troubleshooting "proxies and UDB issues". I guess this is just to get more specific to SOCKS5? It just feels like having to start from scratch with the troubleshooting.

FranciscoPombal replied on Apr 24

The other issue was closed because it was an "umbrella issue" for many different problems, most of which have been fixed. The notable exception is this one SOCKS5 issue. So this issue was opened to:
* deal _specifically_ with this SOCKS5 problem, without having to sift through huge amounts of unrelated information in between

* clearly indicate that everything else is fixed
Of course, some things have to be copy-pasted back here, but it's not much in this case (anyone can copy-paste 2 log lines), so I think it's worth it.

When in FACT the ORIGINAL ISSUE WAS and STILL IS EXACTLY AS WAS RAISED in the FIRST place!

And you arvidn on Apr 23
the best thing to do, for someone experiencing socks5 not working and wanting it to be fixed, is to post a wireshark dump of the UDP ASSOCIATE socks5 connection. Ideally just that TCP stream, to keep the noise down.
It probably won't get fixed unless it breaks (or is demonstrated breaking) for someone able to fix it.

Do you really think us 'users' have a clue what you are talking about? I for one certainly don't.

And now you are telling me "this ticket is about "SOCKS5 proxy disconnect issue due to insufficient retries" and that's not the issue you're experiencing."???

I set SOCKS5 and we are on a wing and a prayer if trackers actually work or not, if torrents actually show Seeds, Peers and start downloading uploading or not.
Sometimes the client starts out 'okay' and then goes into a never ending death-dive until we restart and go through the same thing over and over again yet YOU tell me YOU can't tell anything from what is being said?

Seems to me this is a simple case of 'not me guv' 'pass the buck back and forth'.

I set No Proxy and client runs as smooth as silk forever and ever EXCEPT without the proxy the detail of our activity is EXPOSED.

And isn't it interesting, as has been reported time and time again, we can run the client with a proxy with a proxy app running outside the client and we get FULL SECURITY, no leakage, with the client working smoothly no probs yet the moment we set Proxy Server SOCKS5 within the client we're on a wing and a prayer and we get this back and forth qbittorrent client? libtorrent?

I don't know, I'm just a 'user' but between all you 'developers' you should be able to work out this out to some extent!

condoghost on 3 Aug 2020

xavier2k6
@FranciscoPombal @arvidn please respond to @condoghost when you get a chance & help him ASAP!!!! with his requests/demands - self entitlement or whatever else anyone wants to call it, I'M DONE!.

I'm so pleased you are DONE xavier2k6 because you are OUT-OF-ORDER here going on about 'demands' 'self entitlement' 'whatever else anyone wants to call it'!!!

Outrageous that you respond in this fashion. No wonder so many here simply 'give up' and 'move on' with a different client with attitudes like this.

condoghost on 3 Aug 2020

I've not requested your 'opinion' My post was directed to @FranciscoPomba

ok, then - I take exception to that

'Help us, to help you.'? I take exception to that given I appear to be only one of perhaps two? three at most? who have actually >'bothered' to provide info regularly since this issue came up months ago. I don't see others providing this much detail here in >this topic so I suggest you be grateful for the help I am providing!

so I suggest you be grateful for the help I am providing!

xavier2k6
Ok, first of all - read the OP #12583 (comment)

There has been more than one issue thread about proxies etc
There has been more than one person giving info/help wherever & whenever needed (as much as needed/requested)

If you read through this issue or any other tracker - you will see that I have helped with providing test builds or linked to other builds that @FranciscoPombal built , which you have used.

This is a project that is handled by volunteers in their own personal time!

and to quote you again.

so I suggest you be grateful for the help I am providing!

"read the OP [#12583"? Do you really think we haven't read every OP out there on this issue and posted on them too?
Of course we have.
As for 'There has been more than one issue thread about proxies', read my reply above to arvidn where I have included Cunningcory commented on Apr 23 and the 'response' FranciscoPombal commented on Apr 23.

This issue of SOCKS5 where the client shows trackers working and torrents with seeds, peers downloading and uploading suddenly deciding it 'doesn't want to play' with trackers not working and new torrents sat there doing 'nothing', sometimes 'starting', sometimes 'not', to such a point we close the client, clear our cache, temp files, whatever. And when we restart the client, often as not, those torrents 'doing nothing' spring to life showing seeds and peers, downloading and uploading yet trackers showing 'not working', and as likely as not, new torrents then loaded either 'sit there forever doing nothing' with 'trackers not working' or immediately 'spring into life' with trackers immediately working and torrents immediately having seeds, peers, downloading and uploading.

If this is NOT an ISSUE then pardon me for even existing. Is it a qbittorrrent issue or a libtorrent issue? I don't know but for sure it looks like 'no one knows'.

And with arvidn now saying "I think all of the reports in this ticket are different from the title. The title of this ticket was addressed and fixed a long time ago." I and many others with this 'issue' no longer have a clue what is going on if indeed this 'issue' is or has ever been looked at in real terms!

And as for your "and to quote you again.

so I suggest you be grateful for the help I am providing!

You haven't provided any help on this at all except to gripe that I wasn't prepared to post a meaningless redacted file here nor a non-redacted file containing sensitive information!

condoghost on 3 Aug 2020

And just to make it clear now for everyone, this SOCKS5 issue is not going away until it is fixed or we move on to a different client where SOCKS5 is indeed working 'smooth as silk' same as with qbittorrrent version 4.1.9.1

I can't believe I've been through 11 versions/patches/whatever since then only to be told now 'whatever it is that's the issue it isn't to do with this ticket because this ticket has been fixed even though it remains open'!!!

condoghost on 3 Aug 2020

@condoghost, please keep in mind that many people are subscribed to notifications here because we experienced the issue in the ticket. We are getting emails every.single.time you reply here, and frankly, none of the comments are very relevant. If you are replying 4x within an hour, maybe just take a pause and keep it all to one reply instead?

crafty35a on 3 Aug 2020

crafty35a commented 34 minutes ago
@condoghost, please keep in mind that many people are subscribed to notifications here because we experienced the issue in the ticket. We are getting emails every.single.time you reply here, and frankly, none of the comments are very relevant. If you are replying 4x within an hour, maybe just take a pause and keep it all to one reply instead?

Interesting. I sincerely hope to see a similar post addressed to xavier2k6 given his 3 replies here and given I was replying to those addressed to me.

As for 'please keep in mind that many people are subscribed to notifications here because we experienced the issue in the ticket', please pick-up and keep in mind as I have done with regard to arvidn's comment "Either way, I think all of the reports in this ticket are different from the title. The title of this ticket was addressed and fixed a long time ago." which simply leaves us in the dark as to what it is we are actually experiencing and if indeed what we are experiencing is even understood and being worked on.

Me? I'm now in the middle of re-installing 4.1.9.1 and if 'that works for me' I'm staying with that and no longer commenting here on this 'ticket' given that arvidn is telling us 'this ticket is not my issue and this 'ticket' has been addressed and fixed a long time ago'. I'll await the opening of a 'relevant ticket' that will be followed through to resolution.

I'll check-in now and again to grab any 'patches' or 'whatever' but I'm done spending months providing 'information' only to be now told the information provided is 'not relevant' or 'to whatever' or 'not technical whatever'.

As with the volunteers here I too am 'volunteering' my input and for those looking at this, developing a 'fix' or whatever', an 'update', a 'status', 'whatever', for us to know 'how the issue is seen', 'what more is required from us' 'progress or not toward a solution' would most definitely make a difference rather than weeks of 'no comment', not even letting us know when info is provided whether it is helpful or not.

And that's it from me. Any comment addressed to me specifically, 'condoghost', will not be addressed unless it's a request for clarification, new info, to test a 'patch', a 'fix' or whatever. Thank-you.

20-weeks into lockdown? Stay healthy, stay safe.

condoghost on 3 Aug 2020

You start qbittorrent and everything is working fine with SOCKS5. Then you return later and it isn't working. You then restart the Qbit (maybe several times) and then it works again for a brief amount of time. This is the problem I have always had

I see. That's good to know. (This was not clear to me from your emails). According to your logs, this issue is not caused by "insufficient retries". It's retrying about 3 times per minute, and the SOCKS5 proxy keeps closing the connection.

(for future reference, storing log files as plain-text makes the much easier to work with than .xls)

Also, I don't actually know what you mean by "http torrent" and "udp torrent". At first I thought you mean HTTP tracker and UDP tracker. But you use those terms also. Do you mean a torrent with only HTTP trackers is an HTTP torrent? and a torrent with only UDP trackers is a UDP torrent?

According to your log, it looks like your SOCKS5 provider doesn't have very good support for UDP, or you have some quota that you overrun and that's why the start to disconnect you.

This seems to come up a lot, perhaps I should make a tool that just tests and diagnoses SOCKS5 proxies.

arvidn on 3 Aug 2020

I'm now in the middle of re-installing 4.1.9.1

If an older version work with your SOCKS5 proxy, that would be very useful information as well, because that would suggest that the issue is not the SOCS5 proxy, but indeed in libtorrent. However, if it works, please make extra sure your traffic actually is going through the proxy. One of the changes that triggered all this is related to silently falling back to not using a proxy if it doesn't work. So, make sure it works, not just appear to work.

arvidn on 3 Aug 2020

@condoghost

Interesting. I sincerely hope to see a similar post addressed to xavier2k6 given his 3 replies here and given I was replying to those addressed to me.

3 replies from me!!!! have you even read this thread or any of the other threads I have commented more than 3 times here & have supplied numerous test builds for users experiencing this issue & actually in different threads.

Outrageous that you respond in this fashion. No wonder so many here simply 'give up' and 'move on' with a different client with attitudes like this.

YOU are the one with the attitude, I'm trying to help not only you but others experiencing this issue & you tell me basically in no uncertain terms, Hey I didn't ask for your opinion but before that you attacked @FranciscoPombal by saying he wasn't even on the qBittorrent team etc.

Are you a 'developer'? Are you 'working on fixing this'? Somehow I don't think so.

20-weeks into lockdown?

Maybe...............it's that that's taking it's toll on people here..........

There are other things people have to focus in real life & as I said, it's maintained by volunteers & the owner/maintainer hasn't been seen or contactable in months so please be aware of that fact.....we don't know if they are dead or alive.

For me personally, my mother just got diagnosed with cancer the other day so maybe "my attitude" as you put it could be down to that or it simply wasn't attitude & it was mistaken as that. (took me up wrong)

Also some of the other threads were closed as some issues were fixed plus they just grew & grew & new ones like this thread were opened.

We all have things going on in our lives but regardless we still try to help each other out in something that we care about & that we can feel like we can contribute too/make some small difference in this crazy world...right now.

I myself am going to take a breather & again I apologise to all that are getting the notifications etc & are affected & YES, I can understand the frustrations that you all may feel that it's not fully sorted to what you may or may not expect.........but there's a good team/contributores here so please bare with them & with the help of @arvidn from libtorrent, the issues may fully get resolved.

@FranciscoPombal I personally apologize to you as the OP & as part of the qBittorreent Team for having this thread go off-topic.

xavier2k6 on 3 Aug 2020

I just throw in the comment that in QBT 4.1.9.1 the socks part just worked fine.. #ifitaintbroke..
I have gone back to running 4.1.9.1 as its the only stable version on and up-to-date windows10 box with a 1Gig fiber connection via SOCK5 proxy

amsterdampaul on 3 Aug 2020

I just throw in the comment that in QBT 4.1.9.1 the socks part just worked fine

Can you confirm that you did assert that the traffic is going through the proxy as well? with something like tcpdump or wireshark.

arvidn on 3 Aug 2020

Alright...

First of all, @xavier2k6 thanks for standing up for me in my absence, that's much appreciated. There's nothing to apologize for. We all have our personal lives to deal with.

@condoghost

Let me address a few points:

It is most productive to post logs/settings in plain text for _everyone_ to examine them, not just one person. The "personal information" that needs to be redacted is not much and not relevant for the troubleshooting of this problem in particular, as many others. Many problems have been fixed thanks to many users promptly posting such information on demand, why can't you? Especially since you have been so willing thus far to share your findings and experience, which is much appreciated.
Please don't take this personally, but after so many replies in this thread, I feel the need to call out your somewhat disorganized posting form (example: https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-667672141). Once or twice is understandable (e.g., one might be in a hurry), but it is persistent, and makes it very tiring to read and hard to follow your posts.
I think that lately, you might have been missing the point about what was being asked of you:

You start qbittorrent and everything is working fine with SOCKS5. Then you return later and it isn't working. You then restart the Qbit (maybe several times) and then it works again for a brief amount of time. This is the problem I have always had

We already know that. We also know that libtorrent now correctly retries the connection every time it goes down. We were just asking you to confirm to the best of your ability, whether or not the reason the retries were sometimes failing, and why they started failing in the first place, was due to qBittorrent/libtorrent, or some other issue with the proxy itself (some other users had mentioned that PIA's SOCKS5 was unreliable or something like that, for example).

Looking at the latest posts in this discussion, the latter seems to be the case, so I think this issue can be considered solved.The proxy doesn't disconnect anymore due to _insufficient retries_. To the best of our newfound knowledge, the only disconnects observed now are due to issues with the proxy itself.

The good news is that any "test" build with the SOCKS5 libtorrent fix is working as intended, the bad news is that it will take a while before an "official" build is released with the fix due to @sledgehammer999's disappearance. Also, no matter how hard qBittorrent/libtorrent tries to reconnect, you will still have issues if the proxy you are using is not up to the task (https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-668068716):

According to your log, it looks like your SOCKS5 provider doesn't have very good support for UDP, or you have some quota that you overrun and that's why the start to disconnect you.

This seems to come up a lot, perhaps I should make a tool that just tests and diagnoses SOCKS5 proxies.

I'm going easy on you out of respect for your past contributions, and due to empathizing with the frustration caused by this issue. These kinds of tirades against volunteer members and contributors will not be tolerated next time.
@amsterdampaul see https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-668071210 (emphasis mine):

If an older version work with your SOCKS5 proxy, that would be very useful information as well, because that would suggest that the issue is not the SOCS5 proxy, but indeed in libtorrent. However, if it works, please make extra sure your traffic _actually_ is going through the proxy. One of the changes that triggered all this is related to silently falling back to not using a proxy if it doesn't work. So, make sure it works, not just appear to work.

Before 4.2.x/libtorrent 1.2.x, some/all traffic was not actually going through the proxy. There are/were multiple issues opened on both issue trackers about this. It was not working, it only _appeared_ to work.
Now that it actually works as intended, some people are running into issues with the proxies themselves.

FranciscoPombal on 4 Aug 2020

@amsterdampaul see #12583 (comment) (emphasis mine):

If an older version work with your SOCKS5 proxy, that would be very useful information as well, because that would suggest that the issue is not the SOCS5 proxy, but indeed in libtorrent. However, if it works, please make extra sure your traffic actually is going through the proxy. One of the changes that triggered all this is related to silently falling back to not using a proxy if it doesn't work. So, make sure it works, not just appear to work.

Before 4.2.x/libtorrent 1.2.x, some/all traffic was not actually going through the proxy. There are/were multiple issues opened on both issue trackers about this. It was not working, it only appeared to work.
Now that it actually works as intended, some people are running into issues with the proxies themselves.

Update: Paul
yes I can confirm with 4.1.9.1 I do see all my connections going via the SOCKS5 proxy addresses only.
I monitor it with NetLimiter4 (Glasswire now removed and replaced with netlimiter)
I see all the connections active and changing but all against the socks proxy address.

amsterdampaul on 5 Aug 2020

@amsterdampaul it would be very helpful if you could post the interaction with the proxy in the old and the new version, to give some hints of why it's disconnecting you. I cannot reproduce this issue with any of the SOCKS5 proxy providers I have access to.

It's actually not clear from your message that the new version doesn't work. Is that the case? Both old and new version working would not be surprising.

arvidn on 5 Aug 2020

I just throw in the comment that in QBT 4.1.9.1 the socks part just worked fine.. #ifitaintbroke..
I have gone back to running 4.1.9.1 as its the only stable version on and up-to-date windows10 box with a 1Gig fiber connection via SOCK5 proxy

Thanks so much for this comment!!
I came here from https://github.com/qbittorrent/qBittorrent/issues/11735

No idea why that one was closed, I have that exact issue. UDP tracker based torrents didn't work.

I downgraded my qb to this version and everything is working as expected again!

All hail version 4.1.9.1!

nayab9 on 12 Aug 2020

@nayab9

No idea why that one was closed, I have that exact issue. UDP tracker based torrents didn't work.

The explanation is in the closing comment...
https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-618101331

If you are not getting reconnected automatically after SOCKS5 disconnects, use the test build linked here https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-619298534.

If it is the case that previously (4.1.9.1) there was no need for reconnection (even if reconnection works fine now with the linked test build), please post more information as requested in this comment: https://github.com/qbittorrent/qBittorrent/issues/12583#issuecomment-669511251. arvidn is the libtorrent developer, and he is so far not able to reproduce the frequent disconnects - it might be an issue with the SOCKS5 provider itself.

FranciscoPombal on 12 Aug 2020

I wanted to add to this. Testing with the latest 4.2.5 version with a SOCKS5 proxy, it still does not work. The error presented within QB is:

_SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: End of file ep:_

I have spent a lot of time reading this thread and several others from a few builds ago where this same issue existed. I, like many others, have a fully updated Windows 10 system with fiber internet connectivity. I know that my SOCKS5 proxy provider is NOT the issue.

This appears to be a persistent issue that would be nice to have resolved by now. I had stopped using QB for the last 8 months due to this issue, hoping to come back to it and it would be resolved. Sadly, that does not appear to be the case.

DaBomby on 12 Aug 2020

Testing with the latest 4.2.5 version with a SOCKS5 proxy, it still does not work.

Try the test build linked in FranciscoPombal's last reply, not 4.2.5. These fixes have not yet made it to an official build.

crafty35a on 12 Aug 2020

@DaBomby

SOCKS5 proxy error. Message: SOCKS5 error. op: handshake ec: End of file ep:

I don't think this is the most common kind of error. This is the handshake failing. Are you sure you're sending the correct username and password?

I know that my SOCKS5 proxy provider is NOT the issue.

Could you get a wireshark capture of the TCP conection to your SOCKS5 proxy. Specifically the one with the UDP_ASSOCIATE message in it (we are still talking about UDP over SOCKS, right?)

Such capture would show exactly what is being sent when and by whom. It can then be compared to the specification to know which side has a problem.

Out of curiosity, how do you know your SOCKS5 proxy is not the cause? Do you have packet capture already, that demonstrates correct behavior of the proxy?

arvidn on 12 Aug 2020

@arvidn

Regarding the handshake failing, that is an interesting thought. I intentionally typed in the username wrong, tested, nothing. I retyped in the correct username and password, tested, and now I get the following error ... over and over and over and over again.

_SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep:_

Same issue, no connection, does not work.

DaBomby on 12 Aug 2020

SOCKS5 proxy error. Message: SOCKS5 error. op: sock_read ec: End of file ep:

I'm pretty sure that sock_read is the way libtorrent waits for the proxy to "hang up". It's not supposed to hang up soon, but I would expect proxies to keep the connection open for, at least, tens of minutes.

Keeping the connection open is what keeps the UDP tunnel open. When the TCP connection is severed, libtorrent will reconnect, in order to open the UDP tunnel.

arvidn on 12 Aug 2020

I am experiencing this too, and this is the first run of qBittorrent. Using a SOCKS5 proxy. All HTTP trackers work fine, but NONE of the UDP trackers work. UDP trackers say "Not working". I just came from using uTorrent (for over a decade) and never had this issue with it at all when using a SOCKS5 proxy.

asheroto on 6 Sep 2020

@asheroto Recent master commits + libtorrent RC_1_2 commits have fixes for this issue. Try the build with libtorrent 1.2.10 from here: master from https://github.com/qbittorrent/qBittorrent/actions instead>. With such a build, SOCKS5 connections will be retried when they fail.

You may see messages of the form SOCKS5 proxy error. Message: in the execution log (or the text log files). This means there was an error (which can, and most often is, due to external factors, like the SOCKS5 proxy not working correctly or being down or something), and libtorrent retries. Regardless of how many errors you see reported, check whether or not the announces are being successful or not in general and if you get peers from such announces; that's how you know if it's working or not. It is important to realize that getting these errors is not necessarily "bad"; most often they just mean something went wrong temporarily and the connection was retried, which means everything is working as intended.

FranciscoPombal on 6 Sep 2020

@asheroto Recent master commits + libtorrent RC_1_2 commits have fixes for this issue. Try the build with libtorrent 1.2.10 from here: EDIT (FranciscoPombal): . With such a build, SOCKS5 connections will be retried when they fail.

How do I download that? I don't see a link anywhere.

HnyBear on 6 Sep 2020

👀1

It looks like it's stuck building.

FYI - just to confirm it's not a proxy issue - I used a program called Proxifier to proxy all traffic with qBittorrent.exe through my SOCKS5 proxy and it does indeed work that way (setting a proxy to none inside qBittorrent + using Proxifier to proxy traffic)

asheroto on 6 Sep 2020

@asheroto Recent master commits + libtorrent RC_1_2 commits have fixes for this issue. Try the build with libtorrent 1.2.10 from here: EDIT (FranciscoPombal): . With such a build, SOCKS5 connections will be retried when they fail.

You may see messages of the form SOCKS5 proxy error. Message: in the execution log (or the text log files). This means there was an error (which can, and most often is, due to external factors, like the SOCKS5 proxy not working correctly or being down or something), and libtorrent retries. Regardless of how many errors you see reported, check whether or not the announces are being successful or not in general and if you get peers from such announces; that's how you know if it's working or not. It is important to realize that getting these errors is not necessarily "bad"; most often they just mean something went wrong temporarily and the connection was retried, which means everything is working as intended.

Hello,

The builds finally completed. I tried each of the two and still no luck with the SOCKS5 proxy enabled. No DHT, no UDP trackers, only HTTP.

asheroto on 6 Sep 2020

@asheroto did you test UDP traffic with proxifier?

arvidn on 6 Sep 2020

@asheroto did you test UDP traffic with proxifier?

Yes, indeed I did. If using Proxifier, UDP+DHT works, using uTorrent w/proxy UDP+DHT works, using qBittorrent w/proxy only HTTP works. I'm an MCSE sysadmin am very aware of how to configure each of these with the correct settings. I've used the same settings, same server & port number, but qBittorrent just doesn't work with SOCKS5 proxy.

Side note: qB also does NOT work with an HTTPS proxy. In uTorrent + Proxifier an HTTPS proxy is a choice, but in qB it is not available. Even if I select HTTP and use port 443, it does not work, so I'm assuming there's no support for HTTPS. My VPN provider does have an HTTP proxy, and using that with qB does work. But of course that's insecure, plus using HTTP or HTTPS does not support UDP traffic, which is a big need in torrent traffic because of its widespread popularity and adoption not only in trackers but also DHT.

Thank you for looking into this. I really like qBittorrent, if it would just work with a SOCKS5 proxy it would be perfect. For now I had to revert to using uTorrent or qB with Proxifier.

asheroto on 8 Sep 2020

Any updates on this? Thanks for your help.

asheroto on 10 Sep 2020

@asheroto I'm very curious to know if you can tell any difference between the SOCKS5 traffic libtorrent sends vs. proxifier (or any other proxy software that works), in Wireshark.

I've spent a fair amount of time analysing the libtorrent network traffic to SOCKS5 proxies, specifically the TCP connection to open the UDP tunnel, as well as the UDP packets being proxied, which are wrapped in a SOCKS5 header.

As far as I can tell, libtorrent is speaking the protocol correctly, according to my reading of RFC 1928.

If you would spot an error in any of the messages libtorrent sends, or really just any difference between libtorrent and a working example, it would be extremely helpful!

arvidn on 10 Sep 2020

Thanks for looking into this. I saw where you posted an issue on the libtorrent GitHub issues page without a good response.

I will analyze a packet cap of the traffic. Meanwhile, can you see if you can grab the error category from socks_category() as mentioned here? http://getfr.org/pub/dragonfly-release/usr-local-share/doc/libtorrent-rasterbar/docs/single-page-ref.html

Will report back soon. Thanks.

asheroto on 10 Sep 2020

You can use one from this list if you don't already have one. https://spys.one/en/socks-proxy-list/

asheroto on 10 Sep 2020

Meanwhile, can you see if you can grab the error category from socks_category() as mentioned here? http://getfr.org/pub/dragonfly-release/usr-local-share/doc/libtorrent-rasterbar/docs/single-page-ref.html

I don't understand what you mean by this.

arvidn on 11 Sep 2020

What I meant to say was... do you receive any error messages from libtorrent regarding SOCKS5 proxy errors when configured?

asheroto on 11 Sep 2020

do you receive any error messages from libtorrent regarding SOCKS5 proxy errors when configured?

Yes. The SOCKS5 connection that sends the UDP ASSOCIATE command, to open the UDP tunnel, sits idle and gets disconnected regularly. Every time that happens libtorrent posts a socks5 error alert, but it also reconnects, to re-open the UDP tunnel.

arvidn on 11 Sep 2020

Have you seen this issue happen on Linux and Windows? I have only tested it on Windows. It seems as though this is a libtorrent issue, eh?

asheroto on 17 Sep 2020

How do I download the latest version for this bug? I had to format and reinstall do to building a new PC and I can't seem to find a working link for Windows anywhere.

HnyBear on 7 Oct 2020

How do I download the latest version for this bug? I had to format and reinstall do to building a new PC and I can't seem to find a working link for Windows anywhere.

@HnyBear You can use below build:

Windows test build of 4.3.0(Alpha1) with listed libraries:

qBittorrent master   | 4.3.0 commit: 39e8eb0
libtorrent-rasterbar | 1.2.10 commit: 687d2a2
Qt                   | 5.15.1
OpenSSL              | 1.1.1h
zlib                 | 1.2.11
Boost                | 1.74

Download Link

xavier2k6 on 7 Oct 2020

Thank you very much.

HnyBear on 7 Oct 2020

How do I download the latest version for this bug? I had to format and reinstall do to building a new PC and I can't seem to find a working link for Windows anywhere.

@HnyBear You can use below build:

Was having the same issue where UDP trackers (as well as DHT) weren't working with a SOCKS5 proxy and this build fixes it. Unfortunately, the application is constantly crashing instead.

acffordyce973 on 12 Oct 2020

Unfortunately, the application is constantly crashing instead.

Do you have any crashdumps?
need more info?!

xavier2k6 on 12 Oct 2020

It'll crash after a few minutes of opening, although it seems to be linked to torrents with a high number of trackers (100+). Going back to 4.2.5 and removing/finishing all torrents will fix it until another large tracker torrent is added.

qBittorrent version: v4.3.0alpha1 (64-bit)
Libtorrent version: 1.2.10.0
Qt version: 5.15.1
Boost version: 1.74.0
OpenSSL version: 1.1.1h
zlib version: 1.2.11
OS version: Windows 10 Version 2004 10.0.19041 x86_64

Caught signal: SIGABRT

#  0 qbittorrent.exe      0x00007ff771cb3c6b straceWin::getBacktrace()[ app\stacktrace_win.h : 213 ]
#  1 qbittorrent.exe      0x00007ff771cb59c5 sigAbnormalHandler(signum)[ app\main.cpp : 344 ]
#  2 qbittorrent.exe      0x00007ff772c9e217 raise(signum)[ minkernel\crts\ucrt\src\appcrt\misc\signal.cpp : 541 ]
#  3 qbittorrent.exe      0x00007ff772ca8bd8 abort()[ minkernel\crts\ucrt\src\appcrt\startup\abort.cpp : 64 ]
#  4 qbittorrent.exe      0x00007ff772115de2 boost::asio::detail::asio_handler_allocate,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > >()[ C:\QBITTORRENT\boost_1_74_0\boost\asio\impl\write.hpp : 368 ]
#  5 qbittorrent.exe      0x00007ff7721154f2 boost_asio_handler_alloc_helpers::allocate >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > > >(s, h)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\detail\handler_alloc_helpers.hpp : 70 ]
#  6 qbittorrent.exe      0x00007ff772114902 boost::asio::detail::hook_allocator,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > >,boost::asio::detail::win_iocp_socket_send_op,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > >,boost::asio::execution::any_executor,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > > >::allocate(n)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\detail\handler_alloc_helpers.hpp : 127 ]
#  7 qbittorrent.exe      0x00007ff7721146cc boost::asio::detail::win_iocp_socket_send_op,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > >,boost::asio::execution::any_executor,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > >::ptr::allocate(handler)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\detail\win_iocp_socket_send_op.hpp : 43 ]
#  8 qbittorrent.exe      0x00007ff772113497 boost::asio::detail::win_iocp_socket_service_base::async_send,libtorrent::aux::allocating_handler & __ptr64,std::_Ph const & __ptr64,std::_Ph const & __ptr64>,342> > >,boost::asio::execution::any_executor,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > >(handler)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\detail\win_iocp_socket_service_base.hpp : 283 ]
#  9 qbittorrent.exe      0x00007ff772113477 boost::asio::basic_stream_socket,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > >::initiate_async_send::operator() >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > > const &,boost::asio::const_buffers_1>(handler)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\basic_stream_socket.hpp : 1006 ]
# 10 qbittorrent.exe      0x00007ff772112fa2 boost::asio::async_result >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > >,void __cdecl(boost::system::error_code,unsigned __int64)>::initiate,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > >::initiate_async_send,boost::asio::detail::write_op >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > > const &,boost::asio::const_buffers_1 const &,int>(token)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\async_result.hpp : 152 ]
# 11 qbittorrent.exe      0x00007ff772112ec2 boost::asio::async_initiate >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > > const &,void __cdecl(boost::system::error_code,unsigned __int64),boost::asio::basic_stream_socket,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > >::initiate_async_send,boost::asio::const_buffers_1 const &,int>(token)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\async_result.hpp : 364 ]
# 12 qbittorrent.exe      0x00007ff772111cc7 boost::asio::basic_stream_socket,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > >::async_write_some,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > > const &>(handler)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\basic_stream_socket.hpp : 855 ]
# 13 qbittorrent.exe      0x00007ff772111c92 libtorrent::proxy_base::async_write_some >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > > >(handler)[ C:\QBITTORRENT\libtorrent-RC_1_2\include\libtorrent\proxy_base.hpp : 124 ]
# 14 qbittorrent.exe      0x00007ff77210f012 boost::asio::detail::start_write_buffer_sequence_op,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > >(stream, buffers, handler)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\impl\write.hpp : 437 ]
# 15 qbittorrent.exe      0x00007ff77210e88c boost::asio::detail::initiate_async_write_buffer_sequence::operator() >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> >,boost::asio::mutable_buffer,boost::asio::detail::transfer_all_t>(handler, buffers, completion_cond)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\impl\write.hpp : 471 ]
# 16 qbittorrent.exe      0x00007ff77210dbd2 boost::asio::async_result >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> >,void __cdecl(boost::system::error_code,unsigned __int64)>::initiate,boost::asio::ssl::detail::io_op >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> >,boost::asio::mutable_buffer const &,boost::asio::detail::transfer_all_t>(initiation, token, , )[ C:\QBITTORRENT\boost_1_74_0\boost\asio\async_result.hpp : 152 ]
# 17 qbittorrent.exe      0x00007ff77210d632 boost::asio::async_initiate >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> >,void __cdecl(boost::system::error_code,unsigned __int64),boost::asio::detail::initiate_async_write_buffer_sequence,boost::asio::mutable_buffer const &,boost::asio::detail::transfer_all_t>(initiation, token, , )[ C:\QBITTORRENT\boost_1_74_0\boost\asio\async_result.hpp : 364 ]
# 18 qbittorrent.exe      0x00007ff77210afae boost::asio::async_write >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> > >(s, buffers, handler)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\impl\write.hpp : 555 ]
# 19 qbittorrent.exe      0x00007ff77210bb7d boost::asio::ssl::detail::io_op >,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> >::operator()(ec, bytes_transferred, start)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\ssl\detail\io.hpp : 204 ]
# 20 qbittorrent.exe      0x00007ff772104266 libtorrent::aux::socket_type::async_write_some,libtorrent::aux::allocating_handler &,std::_Ph const &,std::_Ph const &>,342> >(buffers, handler)[ C:\QBITTORRENT\libtorrent-RC_1_2\include\libtorrent\aux_\socket_type.hpp : 236 ]
# 21 qbittorrent.exe      0x00007ff7721005ac libtorrent::peer_connection::setup_send()[ C:\QBITTORRENT\libtorrent-RC_1_2\src\peer_connection.cpp : 5701 ]
# 22 qbittorrent.exe      0x00007ff772100ad7 libtorrent::peer_connection::send_buffer(buf)[ C:\QBITTORRENT\libtorrent-RC_1_2\src\peer_connection.cpp : 5823 ]
# 23 qbittorrent.exe      0x00007ff7721709e6 libtorrent::web_peer_connection::write_request(r)[ C:\QBITTORRENT\libtorrent-RC_1_2\src\web_peer_connection.cpp : 505 ]
# 24 qbittorrent.exe      0x00007ff7720fbd64 libtorrent::peer_connection::send_block_requests()[ C:\QBITTORRENT\libtorrent-RC_1_2\src\peer_connection.cpp : 4066 ]
# 25 qbittorrent.exe      0x00007ff7720f6ffb libtorrent::peer_connection::incoming_unchoke()[ C:\QBITTORRENT\libtorrent-RC_1_2\src\peer_connection.cpp : 1722 ]
# 26 qbittorrent.exe      0x00007ff7721be4dc libtorrent::web_connection_base::on_connected()[ C:\QBITTORRENT\libtorrent-RC_1_2\src\web_connection_base.cpp : 121 ]
# 27 qbittorrent.exe      0x00007ff7721019ce libtorrent::peer_connection::on_connection_complete(e)[ C:\QBITTORRENT\libtorrent-RC_1_2\src\peer_connection.cpp : 6191 ]
# 28 qbittorrent.exe      0x00007ff772102594 libtorrent::peer_connection::wrap(f, )[ C:\QBITTORRENT\libtorrent-RC_1_2\src\peer_connection.cpp : 217 ]
# 29 qbittorrent.exe      0x00007ff77210891d std::_Func_impl_no_alloc,void,boost::system::error_code const &>::_Do_call()[ C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\functional : 903 ]
# 30 qbittorrent.exe      0x00007ff7720e2b18 libtorrent::ssl_stream,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > > >::handshake(e, h, h)[ C:\QBITTORRENT\libtorrent-RC_1_2\include\libtorrent\ssl_stream.hpp : 312 ]
# 31 qbittorrent.exe      0x00007ff7720ea12a boost::asio::ssl::detail::handshake_op::call_handler,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > > >::*)(boost::system::error_code const &,std::shared_ptr >),libtorrent::ssl_stream,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > > > *,std::_Ph const &,std::shared_ptr > &> >(handler, ec)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\ssl\detail\handshake_op.hpp : 55 ]
# 32 qbittorrent.exe      0x00007ff77210a475 boost::asio::ssl::detail::io_op::*)(boost::system::error_code const &,std::shared_ptr >),libtorrent::ssl_stream *,std::_Ph const &,std::shared_ptr > &> >::operator()(ec, bytes_transferred, start)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\ssl\detail\io.hpp : 299 ]
# 33 qbittorrent.exe      0x00007ff77210f832 boost::asio::detail::write_op::*)(boost::system::error_code const &,std::shared_ptr >),libtorrent::ssl_stream *,std::_Ph const &,std::shared_ptr > &> > >::operator()(ec, bytes_transferred, start)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\impl\write.hpp : 342 ]
# 34 qbittorrent.exe      0x00007ff772116d0b boost::asio::detail::executor_function::complete::*)(boost::system::error_code const &,std::shared_ptr >),libtorrent::ssl_stream *,std::_Ph const &,std::shared_ptr > &> > >,boost::system::error_code,unsigned __int64>,std::allocator >(base, call)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\detail\executor_function.hpp : 115 ]
# 35 qbittorrent.exe      0x00007ff7720b5855 boost::asio::io_context::basic_executor_type,4>::execute(f, f)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\impl\io_context.hpp : 286 ]
# 36 qbittorrent.exe      0x00007ff772115b81 boost::asio::detail::win_iocp_socket_send_op::*)(boost::system::error_code const &,std::shared_ptr >),libtorrent::ssl_stream *,std::_Ph const &,std::shared_ptr > &> > >,boost::asio::execution::any_executor,boost::asio::execution::detail::blocking::never_t,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only >,boost::asio::execution::prefer_only > > >::do_complete(owner, base, result_ec, bytes_transferred)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\detail\win_iocp_socket_send_op.hpp : 100 ]
# 37 qbittorrent.exe      0x00007ff7720541ee boost::asio::detail::win_iocp_io_context::do_one(this_thread, ec, ec)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\detail\impl\win_iocp_io_context.ipp : 468 ]
# 38 qbittorrent.exe      0x00007ff772053dcf boost::asio::detail::win_iocp_io_context::run(ec)[ C:\QBITTORRENT\boost_1_74_0\boost\asio\detail\impl\win_iocp_io_context.ipp : 204 ]
# 39 qbittorrent.exe      0x00007ff772055950 std::thread::_Invoke >,0>(_RawVals)[ C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\include\thread : 43 ]
# 40 qbittorrent.exe      0x00007ff772ca8c70 thread_start(parameter, parameter)[ minkernel\crts\ucrt\src\appcrt\startup\thread.cpp : 97 ]
# 41 KERNEL32.DLL         0x00007ff9c7de7034 BaseThreadInitThunk()
# 42 ntdll.dll            0x00007ff9c9b3cec1 RtlUserThreadStart()

acffordyce973 on 12 Oct 2020

👍1

@FranciscoPombal @arvidn can ye have a look at the stack trace above.

xavier2k6 on 14 Oct 2020

@acffordyce973

Can you try reproducing with the latest experimental build targeting master? https://github.com/qbittorrent/qBittorrent/actions?query=branch%3Amaster

@xavier2k6

no time to investigate in detail, sorry.

FranciscoPombal on 14 Oct 2020

Grabbing qBittorrent-CI-Windows_x64-static-release from https://github.com/qbittorrent/qBittorrent/actions/runs/305705360 and overwriting my current 4.2.5 with all the files from /build/. Will add previously erroneous torrents and report back.

acffordyce973 on 14 Oct 2020

You need not overwrite, you can use both side by side. I'd even recommend backing up the 4.2.5 settings and fastresumes first.

FranciscoPombal on 14 Oct 2020

No issues with that alpha version. UDP trackers are updating on their own and there's no crashes.

acffordyce973 on 15 Oct 2020

👍1

4.3.0 has shipped with the fix. To anyone still having connectivity issues, please open a new issue report with new information, and consider whether it might be a libtorrent issue.

Thank you for your contributions.

FranciscoPombal on 19 Oct 2020

Qbittorrent: SOCKS5 proxy disconnect issue due to insufficient retries

Most helpful comment

All 195 comments

Related issues