Qbittorrent: No connections/torrents won't start when using a proxy server

[qtipbailey]

qBittorrent version and Operating System:

qBittorrent 4.0.0, Windows 10 (Fall Creators Update)

What is the problem:

No connections when using a Socks5 proxy server. Adding a Torrent with over 1000 seeds stays at "downloading metadata" with 0 seeds and 0 peers. Appears unable to make any connections. Downgrade to qBittorrent 3.3.16 OR turn off proxy server (bad) and torrents immediately start.

What is the expected behavior:

Should be able to connect and torrents should start downloading like they always have in version 3

Steps to reproduce:

Add any torrent and use a proxy server (btguard, etc.)

[MatrixView]

Same issue after my upgrade to v4. I downgraded to v3.3.16 and it connects again with a socks5 proxy.

[sledgehammer999]

What does your log show?
(censor IPs and torrent hashes/names)

[MatrixView]

@sledgehammer999
Here are my logs for both v4 and v3.3.16:

------------ qBT v4.0 log ------------does NOT work!!!----------------
(N) 2017-11-20T08:56:20 - qBittorrent v4.0.0 started
(I) 2017-11-20T08:56:20 - qBittorrent is trying to listen on any interface port: 6881
(N) 2017-11-20T08:56:22 - Peer ID: -qB4000-
(N) 2017-11-20T08:56:22 - HTTP User-Agent is 'qBittorrent/4.0.0'
(I) 2017-11-20T08:56:22 - DHT support [ON]
(I) 2017-11-20T08:56:22 - Local Peer Discovery support [ON]
(I) 2017-11-20T08:56:22 - PeX support [ON]
(I) 2017-11-20T08:56:22 - Anonymous mode [ON]
(I) 2017-11-20T08:56:22 - Encryption support [FORCED]
(I) 2017-11-20T08:56:22 - Embedded Tracker [OFF]
(I) 2017-11-20T08:56:22 - GeoIP database loaded. Type: GeoLite2-Country. Build time: ma nov 6 20:14:59 2017.
(N) 2017-11-20T08:56:24 - Options were saved successfully.
(N) 2017-11-20T08:56:32 - Successfully parsed the provided IP filter: 0 rules were applied.
(I) 2017-11-20T08:56:33 - Python version: 2.7.11
(I) 2017-11-20T08:56:33 - Python found in PATH: C:\Windows\system32;.....{long line of folders}
(I) 2017-11-20T08:56:38 - External IP: {ip from proxy-provider}


------------ qBT v3.3.16 log ----------works correctly!!!--------------
(N) 2017-11-20T09:47:34 - qBittorrent v3.3.16 started
(I) 2017-11-20T09:47:35 - qBittorrent is trying to listen on any interface port: 6881
(N) 2017-11-20T09:47:35 - Peer ID: -qB33G0-
(N) 2017-11-20T09:47:35 - HTTP User-Agent is 'qBittorrent/3.3.16'
(I) 2017-11-20T09:47:35 - DHT support [ON]
(I) 2017-11-20T09:47:35 - Local Peer Discovery support [ON]
(I) 2017-11-20T09:47:35 - PeX support [ON]
(I) 2017-11-20T09:47:35 - Anonymous mode [ON]
(I) 2017-11-20T09:47:35 - Encryption support [FORCED]
(I) 2017-11-20T09:47:35 - Embedded Tracker [OFF]
(I) 2017-11-20T09:47:35 - GeoIP database loaded. Type: GeoLite2-Country. Build time: ma nov 6 20:14:59 2017.
(N) 2017-11-20T09:47:36 - Options were saved successfully.
(I) 2017-11-20T09:47:37 - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/6881
(I) 2017-11-20T09:47:37 - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP_SSL/4433
(I) 2017-11-20T09:47:37 - qBittorrent is successfully listening on interface :: port: TCP/6881
(I) 2017-11-20T09:47:37 - qBittorrent is successfully listening on interface :: port: TCP_SSL/4433
(I) 2017-11-20T09:47:37 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/6881
(I) 2017-11-20T09:47:37 - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/6881
(I) 2017-11-20T09:47:37 - qBittorrent is successfully listening on interface :: port: TCP/6881
(I) 2017-11-20T09:47:37 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/6881
(I) 2017-11-20T09:47:37 - External IP: {ip from proxy-provider}
(N) 2017-11-20T09:47:38 - Successfully parsed the provided IP filter: 0 rules were applied.
(I) 2017-11-20T09:47:38 - Python version: 2.7.11
(I) 2017-11-20T09:47:38 - Python found in PATH: C:\Windows\system32;.....{long line of folders}

The obvious missing lines in v4.0 are the interface listening. Although it does get a correct proxy-ip Hopefully you can fix this... So thx a lot in advance!

[codelaaheetee]

Same issue. Using SOCKS5 disconnects the qB 4.0.0 (x64) client, showing 0 nodes and a red icon. Disabling the SOCKS5 the client connects instantly, showing hundreds of nodes and a green icon.

I therefore installed other clients (Vuze and Bittorrent) and non of them disconnect when SOCKS5 is enabled.

Installing the previous qB 3.3.13 (x64) (WIndows 10), SOCKS5 works perfectly.

[sledgehammer999]

Can you post a screenshot of your proxy settings in qbt?
@codelaaheetee Do you have anonymous mode on?

In case you don't know about anonymous mode:

anonymous_mode defaults to false. When set to true, the client tries to hide its identity to a certain degree. The peer-ID will no longer include the client's fingerprint. The user-agent will be reset to an empty string. Trackers will only be used if they are using a proxy server. The listen sockets are closed, and incoming connections will only be accepted through a SOCKS5 or I2P proxy (if a peer proxy is set up and is run on the same machine as the tracker proxy). Since no incoming connections are accepted, NAT-PMP, UPnP, DHT and local peer discovery are all turned off when this setting is enabled.

So that explains the 0 nodes and non-working magnet links.
Have you tried with that setting off?
Have you tried a .torrent file instead? (possibly with http trackers)

[QLaughable]

I have the same issue using SOCKS5, fine when no proxy is enabled, I tried turning anonymous mode off but still no connections. Added a torrent with a file that had http trackers but that didn't get any connections either.

[sledgehammer999]

@arvidn any ideas on how to proceed? FYI, those builds are using 1.1.5+git096ce54faea01

[arvidn]

is force_proxy set by any chance?

[arvidn]

it looks like the UDP sockets aren't being opened. This patch doesn't look right: https://github.com/arvidn/libtorrent/commit/096ce54faea0126b4ce0028ce04c3baebebbd9fc#diff-8775d2d9460d9b7a42d64f06511742d7R1888

[sledgehammer999]

is force_proxy set by any chance?

Guys do you have the option `Disable connections not supported by proxies" enabled?

@arvidn we enable force_proxy by default.

it looks like the UDP sockets aren't being opened. This patch doesn't look right: arvidn/libtorrent@096ce54#diff-8775d2d9460d9b7a42d64f06511742d7R1888

Hmm, ok. Then I should wait for a patch.

[sledgehammer999]

it looks like the UDP sockets aren't being opened. This patch doesn't look right:

One user tells that http trackers didn't work either. @QLaughable is the status of http trackers as "Working"?

[QLaughable]

Yeah, I have that enabled.

[QLaughable]

It shows as not working but I only have one torrent with a http tracker so I guess it could just be not working

[qtipbailey]

Yes I did have `Disable connections not supported by proxies" enabled. Unchecked that and torrent started.
However, that was also enabled in the previous version and was never a problem. I am looking at both versions on different machines.

[arvidn]

something like this perhaps? https://github.com/arvidn/libtorrent/pull/2540

[DaBomby]

Similar issue posted here: https://github.com/qbittorrent/qBittorrent/issues/7775

[qtipbailey]

Ah, yes. My problematic torrents were added via magnet links so that would be DHT, yes?

[dudeman27]

Getting the same error. When it's an HTTP tracker, the message returned is "(-1) A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond"

If it's a UDP tracker, the message is "(-1) Bad file descriptor"

Turning off the SOCKS5 proxy makes them start downloading instantly.

Tried adding .torrent and magnet links. Same results. Settings attached (X'd out proxy and username). Reverting to 3.3.16 makes everything work as expected.

[dezza]

I have both checked

Use proxy for peer connection [x]
Disable connections not supported by proxies [x]

Downgrading to 3.3.36 also made connections available instantly for me.

[Ncrpts]

Confirmed issue, had to downgrade to 3.3.16 too

shame this was pushed to stable with such a huge issue

[calvilasboasjr]

Corfirmed issue and I had to downgrade to 3.3.16 too.

But, before downgrade I made a test in qB 4.0.0 and works.
But, I feel no security anymore.

Steps the test on qB 4.0.0:
IF I CHECK THIS OPTION: Disable connections not supported by proxies [x]
I MUST SELECT MY ENCRYPTION MODE: "Prefer encryption" or "Disable encription"

Resuming....
This 2 options ("Disable connections not supported by proxies" and "Encryption Mode") have A BIG ISSUE on qB 4.0.0

If you enable one, you must disable another.

I always had this two options enabled on 3.3.16... So I downgrade..
And now everything working again.

[WardenHDresden]

Same issue here. My SOCKS5 Proxy worked perfectly before 4.0.0, and now doesn't even appear to attempt to connect to it. Here's my Execution Log:

11/21/2017 11:49 AM - UPnP/NAT-PMP: Port mapping successful, message:  successfully mapped port using UPnP. external port: TCP/8080 11/21/2017 
11:49 AM - UPnP/NAT-PMP: Port mapping successful, message:  successfully mapped port using UPnP. external port: TCP/6881 
11/21/2017 11:49 AM - External IP: xxx.xxx.xxx.xxx (My ISP provided IP Address) 
11/21/2017 11:49 AM - Options were saved successfully. 
11/21/2017 11:49 AM - Web UI: Now listening on IP: *, port: 8080 
11/21/2017 11:49 AM - GeoIP database loaded. Type: GeoLite2-Country. Build time: Mon Nov 6 
12:14:59 2017. 
11/21/2017 11:49 AM - UPnP / NAT-PMP support [ON] 11/21/2017 11:49 AM - Embedded Tracker [OFF] 
11/21/2017 11:49 AM - Encryption support [ON] 11/21/2017 11:49 AM - Anonymous mode [OFF] 
11/21/2017 11:49 AM - PeX support [ON] 
11/21/2017 11:49 AM - Local Peer Discovery support [ON] 
11/21/2017 11:49 AM - DHT support [ON] 
11/21/2017 11:49 AM - HTTP User-Agent is 'qBittorrent/4.0.0
11/21/2017 11:49 AM - Peer ID: -qB4000- 
11/21/2017 11:49 AM - qBittorrent is trying to listen on any interface port: 6881 
11/21/2017 11:49 AM - qBittorrent v4.0.0 started

'

[arvidn]

this issue has been resolved here https://github.com/arvidn/libtorrent/pull/2540

[sledgehammer999]

Guys I just uploaded 4.0.1 build against latest code from libtorrent 1.1.x branch. Can you check if your problem is fixed?

[qtipbailey]

Yes, 4.0.1 is working normally for me now.

[QLaughable]

Can confirm now working in 4.0.1, thanks for the quick fix.

[sledgehammer999]

Thank @arvidn too.

[codelaaheetee]

Installed 4.0.1 and it seems to be working.. however the connection icon is still red and states "Offline. This usually means that qBittorrent failed to listen on the selected port for incoming connections." I did not change anything of my network equipment of firewall etc. since 3.3.13... and come to think of it, many versions previously published.

I do get a 100+ nodes and downloading and uploading works. I also tested if the VPN service is working properly using ipMagnet tracking tool and it's does. Below's the log.

2017-11-22 04:13 - 'ipMagnet Tracking Link' resumed. (fast resume)
2017-11-22 04:13 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: UDP/8999
2017-11-22 04:13 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: TCP/8999
2017-11-22 04:13 - External IP: 109.136.86.11
2017-11-22 04:13 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/8999
2017-11-22 04:13 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/8999
2017-11-22 04:13 - Options were saved successfully.
2017-11-22 04:13 - GeoIP database loaded. Type: GeoLite2-Country. Build time: Mon Nov 6 20:14:59 2017.
2017-11-22 04:13 - UPnP / NAT-PMP support [ON]
2017-11-22 04:13 - Embedded Tracker [OFF]
2017-11-22 04:13 - Encryption support [ON]
2017-11-22 04:13 - Anonymous mode [OFF]
2017-11-22 04:13 - PeX support [ON]
2017-11-22 04:13 - Local Peer Discovery support [ON]
2017-11-22 04:13 - DHT support [ON]
2017-11-22 04:13 - HTTP User-Agent is 'qBittorrent/4.0.1'
2017-11-22 04:13 - Peer ID: -qB4010-
2017-11-22 04:13 - qBittorrent is trying to listen on any interface port: 8999
2017-11-22 04:13 - qBittorrent v4.0.1 started

I also tried different connection configurations without any change. Below shows the configuration that I've always used, without problems.

Enable protocols: TCP and µTP

[x] Use UPnP / NAT-PMP port forwarding from my router
[ ] Use different port on each startup

[SOCKS5] Host: xxx.vpnserviceprovider.com port: 1080
[x] Use proxy for peer connections
[x] Disable connections not supported by proxies
[ ] Use proxy only for torrents

[x] Enable DHT (decentralized network) to find more peers
[x] Enable Peer Exchange (PeX) to find more peers
[x] Enable Local Peer Discovery to find more peers

After having restarting qBittorrent or even rebooting the system a couple of times, the icon stays red and keeps claiming the client is offline. Yet, it's downloading and uploading just fine.. although, the speed graph does shows a lot of spikes and valleys. It seems all over the place. It was much more smooth using 3.3.13.

[dudeman27]

Thanks @sledgehammer999 and @arvidn . 4.0.1 fixed the UDP tracker issue. Not sure if there's a separate issue open for HTTP trackers. If not, this one should be re-opened. HTTP trackers aren't working and are sending the message "(-1) A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond."

[calvilasboasjr]

@sledgehammer999 and @arvidn
Hey guys, the problem persist on qb 4.0.1.

When the 2 options in red is ON, no torrent start download.
Just not work.

This same configurations on qb 3.3.16 work flawless. Work 100%.
But, in qt 4.0.1 no connections is started, no download, no seed, no peers, nothing.

DETAILS LOG CONNECTIONS
I saw that in 3.3.16, the program try the connection "UPnP/NAT-PMP" 3 times, and in 4.0.1 just 2 times.

DETAILS ICON CONNECTIONS
In qb 3.3.16 the connection icon below was yellow and green when torrent starts.
In qb 4.0.1 the connection icon below was always red and not changes.

LOGs and PICTURES below..

qBittorrent v4.0.1

22/11/2017 10:04 - External IP: X.X.X.X
22/11/2017 10:04 - UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: no router found
22/11/2017 10:04 - UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: no router found
22/11/2017 10:02 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using NAT-PMP. external port: UDP/51503
22/11/2017 10:02 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using NAT-PMP. external port: TCP/51503
22/11/2017 10:02 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/51503
22/11/2017 10:02 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/51503
22/11/2017 10:02 - Options were saved successfully.
22/11/2017 10:02 - GeoIP database loaded. Type: GeoLite2-Country. Build time: seg nov 6 20:14:59 2017.
22/11/2017 10:02 - UPnP / NAT-PMP support [ON]
22/11/2017 10:02 - Embedded Tracker [OFF]
22/11/2017 10:02 - Encryption support [FORCED]
22/11/2017 10:02 - Anonymous mode [ON]
22/11/2017 10:02 - PeX support [ON]
22/11/2017 10:02 - Local Peer Discovery support [ON]
22/11/2017 10:02 - DHT support [ON]
22/11/2017 10:02 - HTTP User-Agent is 'qBittorrent/4.0.1'
22/11/2017 10:02 - Peer ID: -qB4010-
22/11/2017 10:02 - qBittorrent is trying to listen on any interface port: 51503
22/11/2017 10:02 - qBittorrent v4.0.1 started

qBittorrent v3.3.16

22/11/2017 10:13 - External IP: X.X.X.X
22/11/2017 10:13 - UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: no router found
22/11/2017 10:13 - UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: no router found
22/11/2017 10:13 - UPnP/NAT-PMP: Port mapping failure, message: could not map port using UPnP: no router found
22/11/2017 10:10 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using NAT-PMP. external port: 51503
22/11/2017 10:10 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using NAT-PMP. external port: 51503
22/11/2017 10:10 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using NAT-PMP. external port: 51503
22/11/2017 10:10 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/51503
22/11/2017 10:10 - qBittorrent is successfully listening on interface :: port: TCP/51503
22/11/2017 10:10 - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/51503
22/11/2017 10:10 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/51503
22/11/2017 10:10 - qBittorrent is successfully listening on interface :: port: TCP_SSL/4433
22/11/2017 10:10 - qBittorrent is successfully listening on interface :: port: TCP/51503
22/11/2017 10:10 - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP_SSL/4433
22/11/2017 10:10 - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/51503
22/11/2017 10:10 - Options were saved successfully.
22/11/2017 10:10 - GeoIP database loaded. Type: GeoLite2-Country. Build time: seg nov 6 20:14:59 2017.
22/11/2017 10:10 - UPnP / NAT-PMP support [ON]
22/11/2017 10:10 - Embedded Tracker [OFF]
22/11/2017 10:10 - Encryption support [FORCED]
22/11/2017 10:10 - Anonymous mode [ON]
22/11/2017 10:10 - PeX support [ON]
22/11/2017 10:10 - Local Peer Discovery support [ON]
22/11/2017 10:10 - DHT support [ON]
22/11/2017 10:10 - HTTP User-Agent is 'qBittorrent/3.3.16'
22/11/2017 10:10 - Peer ID: -qB33G0-
22/11/2017 10:10 - qBittorrent is trying to listen on any interface port: 51503
22/11/2017 10:10 - qBittorrent v3.3.16 started

[DaBomby]

@dudeman27 and @calvilasboasjr - I can confirm the same situation. That is, with the settings mentioned enabled, it still does not work. It is NOT fixed and I agree that there appears to be a separate unresolved issue.

[Sartan4455]

If it helps, I can confirm this issue persists on 4.0.1 windows 10. I filed a bug because my search skills apparently were lackluster(searched for dht nodes 0 and dht nodes). #7734

[qtipbailey]

Magnet links are fixed but now regular torrents are broken? Torrent won't even try to start just goes immediately to "stalled". Here is log:

11/22/2017 2:49 PM - 'gimp-2.8.22-setup.exe' added to download list.
11/22/2017 2:49 PM - 'gimp-2.8.22-setup.exe' was removed from the transfer list and hard disk.

That's it. Nothing else happening.

[qtipbailey]

Do I need to start a new issue? This link is a legal torrent for Gimp. 3000+ seeds but it doesn't work.
http://www.legittorrents.info/download.php?id=c691c817f7310ab3e7851576814dfc167bb52740&f=gimp-2.8.22-setup.exe.torrent

[sledgehammer999]

All of you who still see problems with proxies can you test the linked build?
It is qbt 4.0.1 against libtorrent 1.1.4. (just replace the files of your install. take backups of the originals)
Link: http://builds.shiki.hu/temp/qbittorrent-4.0.1_with_libtorrent-1.1.4_for_issue_7734.7z

[DaBomby]

@sledgehammer999 I just tested your linked build. It is working for me now. :1st_place_medal:

Is there a reason that libtorrent 1.1.5 wasn't used? https://github.com/arvidn/libtorrent/releases

[dudeman27]

@sledgehammer999 Got an error about UDP trackers timing out ((-1) timed out), but it started working anyways shortly after (time out was probably a tracker issue).

HTTP trackers giving the same message about a connection attempt failing. If I revert to 3.3.16 then the same HTTP tracker works.

It's implied but to be clear, this was on the linked build.

[sledgehammer999]

Can you help me pinpoint the faulty libtorrent commit?
I have compiled qbittorrent against 3 commits of libtorrent between 1.1.4 and 1.1.5.
Test those and report which are working. That way we can narrow it down further.
Thank you.
Link: http://builds.shiki.hu/temp/qbittorrent-4.0.1_various_libt_versions_for_issue_7734.7z

[calvilasboasjr]

@sledgehammer999

maybe I had a clu.
I just made a test with your new release.
http://builds.shiki.hu/temp/qbittorrent-4.0.1_various_libt_versions_for_issue_7734.7z

First I tried with a public torrent, in this case o GIMP. WORKS!
BUT, with private torrent sites and private ".torrent" files, NOT WORKS!

With PUBLIC TORRENTS, the qb establishe UDP connections.
With PRIVATE TORRENTS, the qd try to establishe HTTPS connections and failure.

For both I used the same settings
-> SOCKS5.
-> Encryption Mode = Require Encription
-> [x] Disable connections not supported by proxies (Checked)

LOG
24/11/2017 00:59 - External IP: x.x.x.x
24/11/2017 00:59 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using NAT-PMP. external port: UDP/51503
24/11/2017 00:59 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using NAT-PMP. external port: TCP/51503
24/11/2017 00:59 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/51503
24/11/2017 00:59 - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/51503
24/11/2017 00:59 - qBittorrent is successfully listening on interface :: port: TCP/51503
24/11/2017 00:59 - Options were saved successfully.
24/11/2017 00:59 - GeoIP database loaded. Type: GeoLite2-Country. Build time: seg nov 6 20:14:59 2017.
24/11/2017 00:59 - UPnP / NAT-PMP support [ON]
24/11/2017 00:59 - Embedded Tracker [OFF]
24/11/2017 00:59 - Encryption support [FORCED]
24/11/2017 00:59 - Anonymous mode [ON]
24/11/2017 00:59 - PeX support [ON]
24/11/2017 00:59 - Local Peer Discovery support [ON]
24/11/2017 00:59 - DHT support [ON]
24/11/2017 00:59 - HTTP User-Agent is 'qBittorrent/4.0.1'
24/11/2017 00:59 - Peer ID: -qB4010-
24/11/2017 00:59 - qBittorrent is trying to listen on any interface port: 51503
24/11/2017 00:59 - qBittorrent v4.0.1 started

PICS

[sledgehammer999]

@calvilasboasjr which of the 3 builds did work?
For the https tracker: In that treeview there is a Message column. What does it say for that tracker?

[calvilasboasjr]

@sledgehammer999
1 - I tested with the link you share in your last comment above.
2 - The message says:

If you send me a email, I can send to you the torrent file for you test.

[sledgehammer999]

@calvilasboasjr that link is a zip file that contains 3 builds of qbt. Which of the 3 did you use?

[calvilasboasjr]

@sledgehammer999
When I click on http://builds.shiki.hu/temp/qbittorrent-4.0.1_various_libt_versions_for_issue_7734.7z
I download the file and Unzip, I find 2 files inside:
There is only 2 files inside.
qbittorrent.exe and qbittorrent.pdb

[calvilasboasjr]

@sledgehammer999

But, the zip came with a folder named: qbittorrent-4.0.1_with_libtorrent-1.1.4_for_issue_7734
So, I believe that I tested qbittorrent-4.0.1 with libtorrent-1.1.4

[sledgehammer999]

I just downloaded http://builds.shiki.hu/temp/qbittorrent-4.0.1_various_libt_versions_for_issue_7734.7z
It contains 3 folders inside. And each folder has a qbittorrent.exe and qbittorrent.pdb file.
Are you sure you didn't click an earlier link I had posted?
Can you redownload the link I provided in this comment?

[calvilasboasjr]

@sledgehammer999

You are correct.
This link you provide now have 3 folders inside.

But I still believe that I tested
qbittorrent 4.0.1
Libtorrent 1.1.4

[sledgehammer999]

But I still believe that I tested
qbittorrent 4.0.1
Libtorrent 1.1.4

Can you test those 3 folders and tell me which works which doesn't? I want the name of the folder, the commit hash to be more specific. The libtorrent versions string isn't accurate enough.

[calvilasboasjr]

@sledgehammer999

I tried all 3 folders and no one works. :(
Trey all report the same message:

# PIC USING 4.0.1 In black, only the name of the file.

# PIC USING 3.3.16 Here, working, no message at all.

LOG of 4.0.1
24/11/2017 11:16 - External IP: x.x.x.x
24/11/2017 11:16 - 'gimp-2.8.22-setup.exe' resumed. (fast resume)
24/11/2017 11:16 - 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' resumed. (fast resume)
24/11/2017 11:16 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using NAT-PMP. external port: UDP/51503
24/11/2017 11:16 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using NAT-PMP. external port: TCP/51503
24/11/2017 11:16 - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/51503
24/11/2017 11:16 - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/51503
24/11/2017 11:16 - qBittorrent is successfully listening on interface :: port: TCP/51503
24/11/2017 11:16 - Options were saved successfully.
24/11/2017 11:16 - GeoIP database loaded. Type: GeoLite2-Country. Build time: seg nov 6 20:14:59 2017.
24/11/2017 11:16 - UPnP / NAT-PMP support [ON]
24/11/2017 11:16 - Embedded Tracker [OFF]
24/11/2017 11:16 - Encryption support [FORCED]
24/11/2017 11:16 - Anonymous mode [ON]
24/11/2017 11:16 - PeX support [ON]
24/11/2017 11:16 - Local Peer Discovery support [ON]
24/11/2017 11:16 - DHT support [ON]
24/11/2017 11:16 - HTTP User-Agent is 'qBittorrent/4.0.1'
24/11/2017 11:16 - Peer ID: -qB4010-
24/11/2017 11:16 - qBittorrent is trying to listen on any interface port: 51503
24/11/2017 11:16 - qBittorrent v4.0.1 started

[calvilasboasjr]

@sledgehammer999

If you send me your email, I can send to you the ".torrent" file for you to test.

[dudeman27]

@sledgehammer999 None of the 3 builds worked for HTTP trackers. All worked for UDP trackers. Got the same message that I posted here: https://github.com/qbittorrent/qBittorrent/issues/7734#issuecomment-346527522

[DaBomby]

Similar to issue https://github.com/qbittorrent/qBittorrent/issues/7911 and issue https://github.com/qbittorrent/qBittorrent/issues/7825 and issue https://github.com/qbittorrent/qBittorrent/issues/7824 and issue https://github.com/qbittorrent/qBittorrent/issues/7838.

[dezza]

Still an issue for me also

[Hiltronix]

@sledgehammer999

For what it's worth, I was having the same issues with v.4.0 and v.4.0.1, so I'll offer my feedback in case it helps.

I use a Socks5 proxy with PIA, which worked fine on all 3.x builds till v.4.x. v.4.x downloads stalled unless I turned off the proxy. After seeing your post (copied below) and replacing the 2 files in the zip, it's worked fine for me the last few days.

I use proxy auth, have "Use proxy only for torrents" off, and "Encryption mode: Require encryption".

--
sledgehammer999

All of you who still see problems with proxies can you test the linked build? It is qbt 4.0.1 against libtorrent 1.1.4. (just replace the files of your install. take backups of the originals) Link: http://builds.shiki.hu/temp/qbittorrent-4.0.1_with_libtorrent-1.1.4_for_issue_7734.7z

[noohi]

@sledgehammer999, confirming the same as Hiltronix reported above, 4.0.1 and 4.0.2 still do not work, but with your linked "custom" binaries, it does.
Hope that helps.

[marc0nline]

So we should use this or will there be a software update pushed soon?

[marc0nline]

4.0.3 seem to be working except I get and indicator at the bottom stating it not connected.

update nope not working.

[TwitchKappa]

4.0.3 says off-line, the custom build link above 4.0.1 says online

[dezza]

Still a problem

[marc0nline]

Why did they close this one it still not working?

[mdinslage]

I know this says closed, but I am having this problem on 4.0.3. Downgrading to 3.3.16 fixed my problem. Will revisit again when 4.0.4 is released.

[arvidn]

is anyone that's seeing this error using libtorrent-1.1.6? (that's the version my fix made it into)

[Hiltronix]

@arvidn
Is there a Windows build available to try that has libtorrent 1.1.6? The current version 4.0.3 is using libtorrent-rasterbar v 1.1.5.

I'm willing to try it.

[sledgehammer999]

Can you guys try the folllowing build? It is v4.0.3 based on libtorrent 1.1.6+git2a4f056 (latest available from their repo).
Do you still experience problems? If yes, which ones?
Link: http://builds.shiki.hu/temp/qbittorrent_4.0.3_with_libtorrent_2a4f056_for_issue_7734.7z

[TwitchKappa]

DHT populates over 300, but the status still says off-line and looking at the trackers tab there are zeros on the DHT row for any torrent I looked at. 3.3.16 still seems to be working properly.

[Hiltronix]

@sledgehammer999
I'm now using the qBit 4.0.3 with libtorrent 1.0.6 fix. I'm not seeing the stalled downloads, but am I seeing the same offline notification and zeros as TwitchKappa explains.

[sledgehammer999]

@arvidn

the same offline notification

This is caused because libtorrent::session::is_listening() is returning false.

@TwitchKappa @Hiltronix

and zeros for DHT

AFAIK DHT needs udp support from your proxy. Not all proxies do that. Are you sure your proxy supports it?
PS: Is there any easy way to test proxies without paying for one?

[Hiltronix]

@sledgehammer999
I am not an expert on the BT protocol. I was simply confirming what TwitchKappa observed, in case it was relevant. I use Private Internet Access, and I don't know if their proxy supports UDP. I will ask them and give you feedback when they reply.

[Hiltronix]

@sledgehammer999
To follow up on your question, as to whether the proxy service I'm using supports UDP.

I asked PIA, "I'm wondering if the SOCKS 5 proxy service supports UDP packets?". The answer is not exactly straight forward, so I will paste the answer. I also did not ask this person about security. So I don't know why he answered the way he did.

PIA support answered:
"Regarding your question:
The UDP connection is slower, but yes, more secure than TCP.
The SOCKS 5 proxy is handling this internally with both.
Depending on the usage it will be either one or the other.
The user cannot change the connection type."

[TwitchKappa]

I'm also using private Internet access proxy. qbittorrent-4.0.1_with_libtorrent-1.1.4_for_issue_7734 iis the only 4.x version that shows status online for me and properly connects to other DHT peers. tthe newest build you just posted is worse, aand none of the official bbuilds work either. thanks for continuing to investigate this issue @

[funkspock]

@sledgehammer999 @Hiltronix @arvidn can confirm that PIA supports UDP, wireshark log using 3.3.16 included in #8002 none of the 4.x versions work. I think best way forward is do a diff on the proxy code that was changed in 3.3.16: libtorrent 1.0.11.0 vs. the newest with regard to the DHT

[mdinslage]

Just tested 4.0.4 today and I still have the same problem with SOCKS5 proxy. Connection status is red and connecting to peers is spotty at best, I can connect to peers but it takes a long time and is noticeable slower. Went back to using 3.3.16 for now.

[marc0nline]

i think the developer has giver up on us.

[Tsusai]

Can you guys try the folllowing build? It is v4.0.3 based on libtorrent 1.1.6+git2a4f056 (latest available from their repo).
Do you still experience problems? If yes, which ones?
Link: http://builds.shiki.hu/temp/qbittorrent_4.0.3_with_libtorrent_2a4f056_for_issue_7734.7z

I recently switched to nordvpn's SOCKS5 proxy, and this compiled build works, while the official 4.0.4 does not for me.

[Henrik2]

Can you guys try the folllowing build? It is v4.0.3 based on libtorrent 1.1.6+git2a4f056 (latest available from their repo).
Do you still experience problems? If yes, which ones?
Link: http://builds.shiki.hu/temp/qbittorrent_4.0.3_with_libtorrent_2a4f056_for_issue_7734.7z

This build works for me.

[marc0nline]

I tried this a couple of months ago it doesn’t work for me, I reverted back to 3.16

Marc

---

From: Henrik2 [e-mail]
Sent: Wednesday, March 14, 2018 4:29:43 PM
To: qbittorrent/qBittorrent
Cc: marc0nline; Comment
Subject: Re: [qbittorrent/qBittorrent] No connections/torrents won't start when using a proxy server (#7734)

Can you guys try the folllowing build? It is v4.0.3 based on libtorrent 1.1.6+git2a4f056 (latest available from their repo).
Do you still experience problems? If yes, which ones?
Link: http://builds.shiki.hu/temp/qbittorrent_4.0.3_with_libtorrent_2a4f056_for_issue_7734.7z

I recently switched to nordvpn's SOCKS5 proxy, and this compiled build works, while the official 4.0.4 does not for me.

This build works for me.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/qbittorrent/qBittorrent/issues/7734#issuecomment-373163803, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AbRnBAYh47cycSGKOJTRDAAhT0SxAQBjks5teX22gaJpZM4Qjz_F.

[bobloadmire]

is there any update on this? having same issues with PIA vpn

[loxia01]

I was having the same issue when using Mullvad VPN SOCKS5 proxy (see setup settings below)
https://mullvad.net/en/guides/bittorrent/

For me, changing the enabled protocol from TCP to TCP _and_ µTP fixed the problem for most torrents.

But for some torrents I have to disable anonymous mode and enable DHT for it to work.

I am using v4.0.4 on Windows 10.

[bobloadmire]

i believe TCP and uTP are enabled by default. mine were, not dice.

[Drumstix42]

Same issue here on 4.0.4. Tried above linked 4.0.3 build but no difference.
Downgrading to 3.3.16 worked as suggested above.

New versions definitely still broken for Proxy / SOCKS5

[arvidn]

it's possible that some SOCKS5 proxies don't support hostnames as destination addresses for UDP packets. If you experience this issue, it may be worth trying disabling the proxy_hostnames setting.

[Drumstix42]

@arvidn Where would this be set? I'll give it a try again on the newer version, though I'm less inclined to update again since everything is working on this version.

[arvidn]

well, I did a search in the qbt repository here on github, and it doesn't seem like it exposes a way to change this option, and it defaults to true. But if you're building qbt from source, you could try adding a line here:

https://github.com/qbittorrent/qBittorrent/blob/041b86981f9057babb207d677218b69cb80d6b47/src/base/bittorrent/session.cpp#L1276

saying something like:

settingsPack.set_bool(libt::settings_pack::proxy_hostnames, false);

[Drumstix42]

@arvidn I am not doing any source building but perhaps this will help someone else out with enough know-how and the same problem on 4.x.x+.

Cheers.

[arvidn]

ok. let's ping @sledgehammer999. The reason I'm suspecting the proxy may not support domain names is https://github.com/arvidn/libtorrent/issues/1373#issuecomment-379218727

[Maxattax97]

I am having some similar issues on QBittorrent 4.0.4. A great many torrents do not function at all. Here are screenshots of my settings:

As an example, this torrent does not work:
Linux Mint 18.3 XFCE 64 Bit

I have set a large list of trackers to be automatically added. None of them will connect, even if I force reannounce:

udp://tracker.coppersurfer.tk:6969/announce
udp://tracker.open-internet.nl:6969/announce
udp://tracker.skyts.net:6969/announce
udp://tracker.piratepublic.com:1337/announce
udp://tracker.opentrackr.org:1337/announce
udp://9.rarbg.to:2710/announce
udp://p4p.arenabg.com:1337/announce
udp://public.popcorn-tracker.org:6969/announce
udp://wambo.club:1337/announce
udp://trackerxyz.tk:1337/announce
udp://tracker4.itzmx.com:2710/announce
udp://tracker2.christianbro.pw:6969/announce
udp://tracker1.wasabii.com.tw:6969/announce
udp://tracker.zer0day.to:1337/announce
udp://tracker.xku.tv:6969/announce
udp://tracker.vanitycore.co:6969/announce
udp://inferno.demonoid.pw:3418/announce
udp://open.facedatabg.net:6969/announce
udp://mgtracker.org:6969/announce
udp://ipv4.tracker.harry.lu:80/announce
udp://tracker.mg64.net:6969/announce
udp://thetracker.org:80/announce
udp://open.stealth.si:80/announce
http://tracker.city9x.com:2710/announce
udp://tracker.tiny-vps.com:6969/announce
udp://tracker.halfchub.club:6969/announce
udp://tracker.grepler.com:6969/announce
udp://tracker.files.fm:6969/announce
udp://tracker.dler.org:6969/announce
udp://tracker.desu.sh:6969/announce
udp://tracker.cypherpunks.ru:6969/announce
udp://explodie.org:6969/announce
udp://bt.xxx-tracker.com:2710/announce
udp://tracker.torrent.eu.org:451/announce
http://retracker.mgts.by:80/announce
http://0d.kebhana.mx:443/announce
udp://retracker.lanta-net.ru:2710/announce
http://retracker.telecom.by:80/announce
udp://tracker.christianbro.pw:6969/announce
udp://tracker.bluefrog.pw:2710/announce
udp://tracker.acg.gg:2710/announce
wss://tracker.openwebtorrent.com:443/announce
wss://tracker.fastcast.nz:443/announce
wss://tracker.btorrent.xyz:443/announce
ws://tracker.btsync.cf:2710/announce
udp://zephir.monocul.us:6969/announce
udp://tracker.tvunderground.org.ru:3218/announce
udp://pubt.in:2710/announce
udp://tracker.kamigami.org:2710/announce
udp://retracker.coltel.ru:2710/announce
udp://peerfect.org:6969/announce
udp://tracker.uw0.xyz:6969/announce
https://open.kickasstracker.com:443/announce
https://open.acgnxtracker.com:443/announce
https://evening-badlands-6215.herokuapp.com:443/announce
http://tracker.opentrackr.org:1337/announce
http://torrent.nwps.ws:6969/announce
http://retracker.spark-rostov.ru:80/announce
http://retracker.bashtel.ru:80/announce
http://open.kickasstracker.com:80/announce
http://open.acgtracker.com:1096/announce
http://open.acgnxtracker.com:80/announce
udp://z.crazyhd.com:2710/announce
udp://tracker.swateam.org.uk:2710/announce
udp://tracker.justseed.it:1337/announce
udp://tracker.cyberia.is:6969/announce
udp://sd-95.allfon.net:2710/announce
udp://santost12.xyz:6969/announce
udp://sandrotracker.biz:1337/announce
udp://retracker.nts.su:2710/announce
udp://packages.crunchbangplusplus.org:6969/announce
udp://104.238.198.186:8000/announce
http://tracker2.itzmx.com:6961/announce
http://tracker.vanitycore.co:6969/announce
http://tracker.torrentyorg.pl:80/announce
http://tracker.tfile.me:80/announce
http://tracker.mg64.net:6881/announce
http://tracker.electro-torrent.pl:80/announce
http://torrentsmd.me:8080/announce
http://share.camoe.cn:8080/announce
http://servandroidkino.ru:80/announce
http://p4p.arenabg.com:1337/announce
http://omg.wtftrackr.pw:1337/announce
http://mgtracker.org:6969/announce
http://fxtt.ru:80/announce
http://bt.dl1234.com:80/announce
http://agusiq-torrents.pl:6969/announce
http://104.238.198.186:8000/announce

Only DHT, PeX, and LSD are marked as "Working", although no peers come out of it...

I have used this proxy before and I know it works. I've tried any combination of disabling the proxy, disabling anonymous mode, and disabling encryption to no avail. Let me know if I can do anything to help or provide more test results.

P.S. given the number of comments with people having problems, this issue should probably be reopened.

[arvidn]

I have used this proxy before and I know it works.

@Maxattax97 are you sure it works with forwarding UDP packets to hostnames? i.e. not IP addresses. It doesn't look like qBT exposes the option to perform name lookups locally, but by capturing the traffic to the tracker with wireshark should be enough to tell you who's at fault. qbt or the proxy

[mdinslage]

I can compile from source, but I am not understanding exactly what you mean above. Do I need to change the code or am i adding "settingsPack.set_bool(libt::settings_pack::proxy_hostnames, false);"

[arvidn]

my understanding is that you will have to change the code and rebuild, yes. At least as far as I can tell, this setting is not exposed by qBT's UI

[mdinslage]

Ok one thing I did try was qbittorrent 3.3.16 with libtorrent-rasterbar-1.1.6 and the problem appeared. This is making me wonder if the problem lies with libtorrent and not qbittorrent. I am thinking about trying a different socks5 proxy provider also.

qbittorrent 3.3.16 + libtorrent-rasterbar-1.0.11 is the last version combo that works for me as of now

[qtipbailey]

I thought it was already confirmed a while back that the issue was with the new libtorrent version but nothing was ever done about it. Anyway, I'm not 1337 enough to compile myself.

[arvidn]

but nothing was ever done about it

@qtipbailey you should read the thread all the way from the top. there was a patch, it was merged, there was a build and people confirmed it fixed the problem.

Now, it sounds like there may still be a problem. Please provide details to understand what's happening.

[qtipbailey]

Ok sorry bout that. I've read everything but only as the comments have come in over the last few months. And by nothing being done about it I just meant the "production" version still doesn't work right, at least for me. I didn't intend to insinuate anything.

[mdinslage]

Well now I am lost, I compiled libtorrent-rasterbar-1.1.7 and qbittorrent-4.0.4 and I still get a no connections with my SOCKS5 proxy but when downloading a test torrent, everything is behaving as normal. Here is a screenshot https://www.dropbox.com/s/4e5xqb1e3s1ruac/qbitt-4.0.4.png?dl=0

as you can see I got a red no connections status, but I am getting full bandwidth saturation and I am connected to peers. So I don't know what is going on.

[arvidn]

my assumption of what that red "no connections" status means is that you don't have any incoming connections. Indicating an error either with the listen socket, or that you're NATed. Proxies normally don't support incoming connections either, so I don't think this is surprising.

[mdinslage]

So to clarify, with 3.3.16/1.0.11 everything works as expected, I can download and upload through my SOCKS5 proxy. With 4.0.4/1.1.7 it seems I can now connect to peers and download but I can't upload, or at least that is what I am seeing with my own testing. And the cause of this is possibly my proxy server and not with qbittorrent? Not seeing how that makes sense, I have checked my router settings and the my specified ports are open and my firewall is not blocking the traffic. Anything you can think if I should try?

Here is a screenshot of working proxy
https://www.dropbox.com/s/yjhnwe53vfbm4ap/3.3.16.png?dl=0

Thanks for your help BTW. :)

[lggjm]

Just commenting that I have the same problem as well. Sometimes pausing and starting the torrents repeatedly will eventually get them to connect and start downloading. Mine just shows a bunch of peers in the swarm but none ever connect, like 0(52) 0 (75), again, works with anything under v. 4, 4.0.4 still broken...

[arvidn]

@mdinslage a screenshot does not help, please provide a whireshark dump. However, your description suggests that there's nothing wrong with the proxy itself per-se. If you can connect to peers, you can upload to peers that are interested in you. Presumably none of the peers you connect to are. Perhaps because peers download the full torrent in less than the re-announce interval, and the only way to get connected to interested peers is by having them connect to you. So, do you get incoming connections with the old version?

@lggjm when you say you "have the same problem", do you refer to the problem @mdinslage just described? i.e. you can connect to peers and download, but you cannot upload. Btw, do UDP trackers work? (this is the thing I'm suspecting be the most likely thing not to work when proxying hostnames).

I ask because your description of the problem seems different.

Just to clarify, normally you cannot receiving incoming connections via a SOCKS proxy. The way you can get incoming connections is by having uTP enabled (at least for incoming connections) and then announce over a UDP tracker or the DHT. Both of those will use the same UDP proxy tunnel, and both will convey the correct external port that your proxy is listening on.

[funkspock]

@arvidn please refer to the wireshark output I pasted here: https://github.com/qbittorrent/qBittorrent/issues/8002

Also, just to let you test everything I will email to your gmail my socks5 proxy information so you can test for yourself 3.316 and v4.x, I trust that you wont misuse my account ;-)

[mdinslage]

@arvidn Thank you for the clarification. And yeah a screenshot is worthless, I will get you dumps if I continue to have problems, but for now I can download. I will test more thoroughly on a live distro.

[mdinslage]

@arvidn Everything is fine now for me with 4.0.4/1.1.7. I just ran a torrent with plenty of seeds and peers and I am getting incoming and outgoing traffic. My connection status still says offline but everything is working 100% and the execution log says everything is fine. Thanks again for your help.

[funkspock]

@mdinslage can you confirm/test the following with your socks5 proxy: add a torrent/magnet file and before you start the torrent, remove all trackers. Then start the torrent and verify whether peers/seeds are gathered via DHT with anonymous mode on. see for settings my post #8002

[mdinslage]

@funkspock Just tested, No I am not able to gather peers via DHT alone with anonymous mode on with 4.0.4/1.1.7 :(. Testing again with 3.3.6/1.0.11 and everything works correctly.

[lggjm]

@arvidn Ok, probably not the 'exact' same problem, or maybe I'm not explaining it correctly. Sometimes it ends up connecting, sometimes it does not, even for torrents with hundreds of seeds/peers. It shows that there are sufficient seeds/peers, but it will not connect to any, or connect just to a couple out of hundreds at relatively low speeds. The thing about incoming connections I know about, it has not been an issue until this update. I'm not sure if 4.0.3 broke things for me or 4.0.4, but it definitely worked earlier than v. 4. This must be a bug of some sort because I have not changed anything in the qbittorrent settings, router, or my pc. The DHT takes forever to make any connections, and then when it does, it peaks, and then goes back down to 0 over time. When I disable the proxy (PIA), the torrents work much better. When I enable it, it's almost impossible to download anything, as I said, even super popular torrents with hundreds of seeds. There seems no rhyme nor reason to it, because sometimes it will stall, then I will just toggle pause/start on the torrent and eventually after like 20 toggles it suddenly connects to like 50 peers and starts downloading instantly. Same proxy works without any problems in Deluge (another torrent app I use), so it doesn't seem to be the proxy. I've tried all kinds of combinations in the settings, but pretty much nothing works with the proxy. I have switched over to Deluge for the time being simply because I need a client which works with my socks5 proxy and all encryption and security features enabled. It's no good if it cannot download anything or works in a crippled fashion. If it's of any practical interest, I use magnet links for most of my torrenting.

[orientalsniper]

I'm having issues too, running a 4.0.4 docker build, the connection icon is red when I have "Disable connections not supported by proxies" checked, when I uncheck it, the connection icon is green, I'm also using Private Internet Access.

[Henrik2]

Anyone tried v4.1.0?

[arvidn]

@sledgehammer999 you may want to consider tweaking the connection icon, as it seems to be interpreted as something slightly different than just "have receive incoming connection" (which I assume it means). Or maybe it should just be disabled when using a proxy (with a tooltip saying you can't have incoming connections when using a proxy)

[qtipbailey]

Yeah I just tried 4.1.0 and it just stuck on "downloading metadata". Connection status says Offline. Zero connections/seeds/peers.

[marc0nline]

I've given up on Qbit. The last 4 updates have been no better then the last. I have to constantly restart to get it to work and I have the same issue with Proxy Sock5 that every else is having. Qbit is feeling more and more like a BETA program with 4.0._. I went back to BiglyBT (a fork of VUZE) at least its consistently does what is suppose to do.

[arvidn]

@funkspock that's just a transcript of packets. I can't tell what's in them. Are they DHT packets?

I've tried this with my test client in head of the libtorrent 1.1.x branch (RC_1_1) and I'm not seeing any problems at all. I'm using the PIA SOCKS5 proxy, both with and without anonymous mode. The DHT bootstraps correctly and I can tell from my wireshark dump that it's going via the proxy.

[WingGithub]

4.1.0 started working with PIA SOCKS5 as soon as I enabled the proxy server authentication, which for some reason was turned off. Yay, finally!

[lggjm]

I initially had success with 4.1.0, but it seems after a few hours of testing like it only works for SOME torrents, and not others. About half of the torrents I added start downloading and work as expected, the other half do not. There is some improvement, however, because now they at least manage to see seeds and peers in the swarm, but they will not connect to any, or will connect to a few only, and then stall. When I compare by using Deluge, all of the same torrents work as expected, so again I am ruling out the fault with PIA or with the torrents themselves. Vuze and Tixati work as well. The issue seems to be something with QB still...

[Hiltronix]

v.4.1.0 (when using PIA Proxy) is working better for me. It didn't initially. I had some torrents downloading when I shut the older version down. Initially when 4.1.0 came up, torrents stalled, as did new torrents I added. I cleared the queue, disabled the proxy service, toggled proxy auth, applied settings with proxy disabled and then again after enabling, and then restarted qBit. Then it worked. I don't know which of this things made a difference, but it appeared to fix something. The last few days, it's been working "normally" for me. Meaning that I have always (with all versions of qBit) had the occasional stalled torrents with PIA proxy, and had to restart qBit to fix it. So for me, this stalling issue is back to qBit "normal". Thanks.

[funkspock]

@arvidn it was indeed a transcript of packets (dump), i wish i could tell you more if i knew more about it.
Just tested v4.1.0 and can confirm the following:

• using PIA proxy and anonymous mode, when qBit is started DHT shows that its connected and peers build upto 200 peers.
• connection icon is colored red (connection status offline). [this is weird!]
• when starting a torrent none of the announcements work: DHT or PEX or trackers all fail, which in essence does not allow any torrent to start.
  Hope this information helps to track and find the bug.

[funkspock]

@arvidn I think I found the issue: i unchecked the option "disable connections not supported by proxies"
Now its all working fine incl. green connection icon.
I even did a torrent ip-leak test to verify whether ip was leaked but it seems that the proxy is correctly used as it shows the proxy ip.

So I guess a closer look needs to be paid at how this feature works as its blocking the connection(s) somehow. I would highly welcome this feature to be enabled because we want to be sure that no information is leaked:
"Only talks to http(s) trackers via (any) proxy"
"Only talks to udp trackers via SOCKS5/I2P proxy"
Im guessing because of "Disables UPnP & NAT-PMP" which is part of this feature its not working.

[qtipbailey]

The thing is, I always had that option checked in version 3 and didn't have any problem so something still isn't right. In fact, I use BTGuard proxy and they specifically tell you to have that option checked in order to properly use their service. What are the ramifications of unchecking that option?

[arvidn]

@funkspock I can reproduce this and will figure out what’s going on. Thanks for the report!

[arvidn]

Please give this patch a try! https://github.com/arvidn/libtorrent/pull/3020

[mdinslage]

I will also test that patch on my virtual machine as soon as I get home and report back.

[sledgehammer999]

Here a build of v4.1.0 using https://github.com/arvidn/libtorrent/pull/3020
Link: https://builds.shiki.hu/temp/qbittorrent_4.1.0_x64_patched_libt_for_issue_7734.7z

[mdinslage]

Working a 100% here with patch 3020. Patched and compiled from source for Linux and used sledgehammer999 patched build for windows.

[funkspock]

@sledgehammer999 thank you for providing the build quickly to test.

@arvidn I can confirm that everything is working now with the flag checked for "Disable connections not supported by proxies" on the windows build of sledgehammer999.

Couple of quick questions, would appreciate if you can answer in detail.
"Use UPnP / NAT-PMP port forwarding from my router" is grayed out under the Options > Connections menu, however it seems its enabled based on the application log.

1. I presume this is the correct behavior? [I have no issue with this as everything is working, its just a observation].

1. Are the features "Only talks to http(s) trackers via (any) proxy" and "Only talks to udp trackers via SOCKS5/I2P proxy" now enabled?

2. Are "the features "Disables Local Peer Discovery" and "Disables UPnP & NAT-PMP" enabled? based on application log they seem enabled. [I have no issue with this as everything is working, its just a observation].

3. Is Local Peer Discovery traffic going through the proxy or just disabled?

4. Is PeX (peerexchange) support when enabled, all traffic going through the proxy?

5. Is DHT traffic all going through the proxy?

6. Look forward hearing from you what the problem was and how you solved it.

Thank you

12-5-2018 11:01 - Successfully parsed the provided IP filter: 216920 rules were applied.
12-5-2018 11:01 - External IP: [proxy ip is shown here]
12-5-2018 11:01 - qBittorrent is successfully listening on interface 192.168.2.1 port: UDP/28026
12-5-2018 11:01 - qBittorrent is successfully listening on interface 192.168.2.1 port: TCP/28026
12-5-2018 11:01 - Options were saved successfully.
12-5-2018 11:01 - GeoIP database loaded. Type: GeoLite2-Country. Build time: di mei 1 18:47:28 2018.
12-5-2018 11:01 - UPnP / NAT-PMP support [ON]
12-5-2018 11:01 - Embedded Tracker [OFF]
12-5-2018 11:01 - Encryption support [FORCED]
12-5-2018 11:01 - Anonymous mode [ON]
12-5-2018 11:01 - PeX support [ON]
12-5-2018 11:01 - Local Peer Discovery support [ON]
12-5-2018 11:01 - DHT support [ON]
12-5-2018 11:01 - HTTP User-Agent is 'qBittorrent/4.1.0'
12-5-2018 11:01 - Peer ID: -qB4100-
12-5-2018 11:01 - qBittorrent is trying to listen on interface 192.168.2.1 port: 28026
12-5-2018 11:01 - qBittorrent v4.1.0 started

[calvilasboasjr]

Hello @sledgehammer999 and @arvidn .

First of All, I want to thank you for your support...

Look, I tested your last build, and it still have problems with private torrent...
I'm using sockc5 and require encrypt.
Both version (v3.3.16 and v4.1.0) have the same setting.
The same configurations of the picture below.
Please, see the picture below...

[arvidn]

that's a problem with the tracker. it's not sending back a valid response

[calvilasboasjr]

@arvidn and @sledgehammer999

One of the first actions the program executes, when a start a new torrent, is to collect the metadata for the torrent and on the connection, I see the STATUS = UPDATING.....
I noticed this in v3.3.16.

So what I did: THE TEST!

1 - I set both version v3.3.16 and v4.1.0 to download on the same folder.

2 - I started a new torrent on v3.3.16 and waited for it to collect the Metadata, STATUS = UPDATING, and when it started downloading, I paused the torrent and closed the program.

3- So I opened v4.1.0 and it continued to download the torrent I had started in v3.3.16.

4 - Now I added a new torrent file directly on v4.1.0, but the torrent NOT started. The STATUS not going to UPDATE satus...

So, maybe I'm wrong, but I believe that v4.1.0 have a problem on this Metadada captures from the server, cos in my test, the v4.1.0 not work for start a new torrent, but work if you start the torrent on v3.3.16 and swap to v4.1.0..

[calvilasboasjr]

@arvidn and @sledgehammer999

And another thing...

you said that: "that's a problem with the tracker. it's not sending back a valid response"

But, I'm using on both version v3.3.16 and v.4.1.0 the same torrent file from the same tracker.
So, why v.4.1.0 not "understanding" the tracker response and v3.3.16 can?!

[arvidn]

the best way to find out would be to see what the actual tracker request is, and perhaps if or how it differs from the previous version. If they are different, but the magnet link or .torrent file is the same, it's possible the .torrent file is using an invalid encoding that previously was interpreted in a different way, or if it's a magnet link, that the info-hash is parsed incorrectly (this sounds far-fetched though). But seeing the magnet link or .torrent file in that case would be useful.

Since the tracker uses https, it's going to be tricky to capture the request in wireshark, it may be easier to enable logging, which will print the request to the log.

In either case, there is also a problem with the tracker, because it's supposed to respond with a bencoded object, and it isn't in your case.

[calvilasboasjr]

@arvidn

I'll send the torrent file for you to test.

[Cunningcory]

@sledgehammer999 Thanks for the test build. Icon is now green and says connected. Issue still persists. Client must be restarted several times to connect. Instead of trackers saying "Not working" they say "Not contacted".

[lggjm]

Just tried 4.1.1; again, most torrents never start. Issue persists...

[Couchy]

Same here - no UDP trackers unless I uncheck "disable connections not supported by proxies". Any chance of getting the fix into 4.1.2?

[rickdoesburg]

Having the same issue on 4.1.1. Stuck on 'downloading Metadata'.

[ExchequerNL]

I am having the same issue with downloading metadata. Using Private Internet Access and sock5.

Right now there are 3 stuck in the queue. When I pause and unpause them one of them starts. Just repeated that 'trick' a few times and now the second one also started.

http://tracker.trackerfix.com:80/announce | Not working | 0 |  
-- | -- | -- | --
udp://9.rarbg.me:2710 | Working | 34 |  
udp://9.rarbg.to:2710 | Working | 34 |  
udp://open.demonii.com:1337/announce | Not working | 0

The exact same tracker is NOT working on a different torrent.

[Cammac7]

Having this same issue on 4.1.1
@Piccirello

Edit: Resolved the issue by changing my proxy port to 1090.
(Seems unrelated to this issue)

[Maxattax97]

I imagine some of you are in the same boat as I was, so I'll share some scripts to get a few of you back online while we wait for bug fixes... I gotta say, I was really missing qBittorrent when I had to switch to Deluge for a few files.

This solution requires a VPN, but acts very similarly to a proxy. It opens a tunnel interface but does not forward all traffic over it. Instead, you bind qBittorrent to the VPN's interface and route exclusively torrent traffic through it. Very convenient when you want to seed files but not have your browser display content in German all the time.

My provider is NordVPN, which services proxies on their servers alongside OpenVPN. My configuration files closely match their publicly available client files.

background.ovpn

# Default configuration from NordVPN below:
client
proto udp
remote [ REDACTED ] 1194
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0
explicit-exit-notify 3
remote-cert-tls server
#mute 10000
comp-lzo
verb 3
pull
fast-io
cipher AES-256-CBC
auth SHA512

# Begin custom configuration:
# Give our interface a name for ease of use.
dev torrent
dev-type tun

# Only open a tunnel, but do not redirect all traffic.
pull-filter ignore redirect-gateway.

# These are just annoying...
mute-replay-warnings

# Place your username and password in here.
auth-user-pass /home/max/.vpn/login.txt

# Execute a script after the tunnel is constructed.
script-security 2
up /home/max/.vpn/setup_vpn.sh
up-restart

<ca>
-----BEGIN CERTIFICATE-----
[ REDACTED ]
-----END CERTIFICATE-----
</ca>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
[ REDACTED ]
-----END OpenVPN Static key V1-----
</tls-auth>

setup_vpn.sh

#!/bin/bash
# Written based on instructions found here: http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html

table="nord"
tunnel="$1"
ip_addr="$4"
net_span="${ip_addr}/24"
gateway="$(echo "$ip_addr" | awk -F'[.]' '{ print $1 "." $2 "." $3 "." 1 }')"

echo "Forwarding $ip_addr on $net_span via $gateway ..."

ip route add "$net_span" dev "$tunnel" src "$ip_addr" table "$table" > /dev/null 2>&1
ip route add default via "$gateway" table "$table" > /dev/null 2>&1
ip route add "$net_span" dev "$tunnel" src "$ip_addr" > /dev/null 2>&1
ip rule add from "$ip_addr" table "$table" > /dev/null 2>&1

echo "Routing of table $table complete!"

login.txt

[email protected]
password

And here is a system service to start the VPN on boot and keep it running in the background:

background-tunnel.service

[Unit]
Description=Background VPN Tunnel

[Service]
ExecStart=/usr/sbin/openvpn --config /home/max/.vpn/background.ovpn
User=root
Group=root

[Install]
WantedBy=multi-user.target

Copy the systemd service to /usr/lib/systemd/system/

$ sudo systemctl enable background-tunnel.service
$ sudo systemctl start background-tunnel.service

Go into qBittorrent, Tools > Preferences > Advanced > Network Interface, and set it to torrent (assuming that's what you named your tunnel interface).

Your up and down speeds should start moving after the VPN comes on. The tunnel is also persistent (and qBittorrent is listening to a single, explicit interface), so if there is a disconnect, you will not leak.

[tastyratz]

I'm joining this parade, this is something that has happened to me for a long time and it's pretty annoying. I've just restarted qb frequently to get around it.

[axzxc1236]

Also having this issue with socks5 proxy and qBottorrent 4.15.

[GlennToms]

Also having this issue v4.1.5 Docker image

[jfortier]

:+1: for v4.1.5 having this issue using NordVPN and OS X 10.14.3

[douglasparker]

I am also having this issue with qBittorrent v4.1.5 while using a NordVPN socks5 proxy running on Ubuntu 18.04.2 LTS.

[arvidn]

which version of libtorrent is that?
and everyone who says "proxy", do they mean socks5 proxy?

[axzxc1236]

which version of libtorrent is that?

qBittorrent 4.1.5 (from Ubuntu stable PPA) comes with libtorrent 1.1.11.0

and everyone who says "proxy", do they mean socks5 proxy?

Yes, I do mean Socks5 proxy.

[goldriver2]

same probleme here, 4.15 on windows configured with socks5 with Ipvanish, the download does not start. I had to stop and retstart qB mny times to have torrent to start

[Auth-0]

same problem here. 4.1.5 configured on Windows with SOCKS5, for Torguard. qBittorent doesn't work but if I use he same settings on a very old uTorrent, it works fine.

[ariel-frischer]

Same problem here using v4.1.5, SOCKS5, no vpn.

[Whippix]

Similar issue in 4.1.5. Private tracker torrents gives error "invalid port number" when using a VPN and a SOCKS5 proxy that the VPN guided me to set up.

These torrents do start if unchecking the box for "disable connections not supported by proxies".

Does unchecking this box defeat the purpose?

[GlennToms]

Yes. This will cause the torrents to use your normal connection and not the VPN.

[sledgehammer999]

Guys I know this isn't an actual solution but you can try this workaround: When you setup your VPN (and login) it creates a network interface in the local machine. Why don't you tell qbittorrent to route all the traffic through that specific interface without setting up a SOCKS proxy?
You can choose a specific interface in Tools->Options...->Advanced->Network Interface
(don't forget to unset the proxy settings if you apply this method).

Once you restart qbittorrent it should route all traffic through the VPN.

[shmacdaddy]

Guys I know this isn't an actual solution but you can try this workaround: When you setup your VPN (and login) it creates a network interface in the local machine. Why don't you tell qbittorrent to route all the traffic through that specific interface without setting up a SOCKS proxy?
You can choose a specific interface in Tools->Options...->Advanced->Network Interface
(don't forget to unset the proxy settings if you apply this method).

Once you restart qbittorrent it should route all traffic through the VPN.

No luck, I changed the network interface to ethernet 3 and after restart I still cannot download meta data

[Whippix]

Guys I know this isn't an actual solution but you can try this workaround: When you setup your VPN (and login) it creates a network interface in the local machine. Why don't you tell qbittorrent to route all the traffic through that specific interface without setting up a SOCKS proxy?
You can choose a specific interface in Tools->Options...->Advanced->Network Interface
(don't forget to unset the proxy settings if you apply this method).

Once you restart qbittorrent it should route all traffic through the VPN.

I forgot to mention but actually I have already done this. There is a guide for qbittorent on my VPN's (Mullvad) website that says to do that in order to prevent connections if the VPN drops. This guide also explained the setup for SOCKS5 on qbittorent.

Going back to my previous question however; If I uncheck "disable connections not supported by proxies", but I still have the network interface set to only my VPN, does this mean that the data still comes through the VPN, and that with the interface setup it still acts as a backup kill-switch to the one built into the VPN client?

[linsui]

Persist on 4.1.6. With socks5 proxy udp is broken.

[dkowis]

I just built libtorrent-rasterbar v1.1.13 and then built 4.1.7 of qbittorrent on a FreeBSD jail. I also have zero udp connections through both 3proxy and dante. I assume this is still a real problem :(

I saw various patches and things, that I believe have been included, but I'm unsuccessful with any UDP operations.

[jjhplus9]

I just upgraded from 4.1.5 to 4.1.7 in the hope of finding a fix - but the issue persists

[arvidn]

I just tested libtorrent 1.2 using client_test (a basic test client). This works for me, verified in wireshark, using private internet access's SOCKS5 proxy.

client_test --proxy_type=3 --proxy_username=<...> --proxy_password=<...> --proxy_hostname=proxy-nl.privateinternetaccess.com --proxy_port=1080 --force_proxy=1 ~/Downloads/Haywyre\ -\ Panorama_\ Discover.torrent

so, the questions is: does qBT do anything differently? or are the failures caused by an underlying SOCKS5 authentication failure and the error isn't propagated properly to the user?

[dkowis]

@arvidn qBittorrent is built against libtorrent 1.1, not 1.2. Perhaps that's the problem?
Do you know if qBittorrent can be built against 1.2?

(commented using the wrong account earlier)

[arvidn]

in RC_1_1 I had to hard code force_proxy to be enabled, because that option isn't exposed in client_test. but this still worked for me.

client_test -L <...>:<...> -P proxy-nl.privateinternetaccess.com:1080 ~/Downloads/Haywyre\ -\ Panorama_\ Discover.torrent

[dkowis]

I'm not familiar with the exact source code that qBittorrent is using. I know it's not a proxy authentication issue. I wish one of the qBittorrent maintainers would chime in.

[jjhplus9]

I have the issue but do not use authentication on my SOCS5 proxy which is on localhost

[arvidn]

@jjhplus9 what proxy software are you running? and are you confident it supports UDP?
(I suppose TCP should still work though)

[jjhplus9]

It used to work just fine with earlier (pre 4.something) releases of
qbittorrent and still works with other clients
Yes, I am sure. 👍

On Tue, Sep 10, 2019 at 6:51 PM Arvid Norberg [e-mail]
wrote:

@jjhplus9 https://github.com/jjhplus9 what proxy software are you
running? and are you confident it supports UDP?
(I suppose TCP should still work though)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qbittorrent/qBittorrent/issues/7734?email_source=notifications&email_token=ANEUVCBTSSOXIRB6ZHHB66LQI7NA3A5CNFSM4EEPH7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6L6MJI#issuecomment-530048549,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANEUVCBNWWXQT3CNE3LFV43QI7NA3ANCNFSM4EEPH7CQ
.

[funkspock]

@arvidn I can confirm: no issues with the following version and configuration with PIA proxy.
Note: I dont use any trackers (I remove these), I use magnet links and peers are discovered via DHT and PEX.

qBittorent 4.1.7 (Libtorrent 1.1.13.0)
DHT support [ON]
UPnP / NAT-PMP support [ON]
Embedded Tracker [OFF]
Encryption support [FORCED]
Anonymous mode [ON]
PeX support [ON]
Local Peer Discovery support [ON]

Enabled protocol [TCP and uTP]
Type proxy [SOCKS5]
Use proxy for peer connections [SELECTED]
Disable connections not supported by proxies [SELECTED]
Use proxy only for torrents [NOT SELECTED]
Authentication [SELECTED]

[dkowis]

@arvidn I can confirm: no issues with the following version and configuration with PIA proxy.
Note: I dont use any trackers (I remove these), I use magnet links and peers are discovered via DHT and PEX.

What socks5 proxy are you using? Could you share that configuration in a pastebin?

I have this exact same configuration set up, but I get no UDP traffic at all. Have tried both dante and 3proxy.

[calvilasboasjr]

@arvidn, version 4.1.7 x64, with socket5 works.

qBittorrent v4.1.7 started
UPnP / NAT-PMP support [ON]
Embedded Tracker [OFF]
Encryption support [FORCED]
Anonymous mode [ON]
PeX support [ON]
Local Peer Discovery support [ON]
DHT support [ON]
HTTP User-Agent is 'qBittorrent/4.1.7'

[Treverr]

@calvilasboasjr I'm running the same settings/version on Linux and still have the same issue with my NordVPN Socks5 proxy.

[calvilasboasjr]

@Treverr have you check the vpn address and door that you enter in qbittorrent?!

[Treverr]

@calvilasboasjr yes, if I restart qbit it starts to work. After sometime running though it quits working.

[myminpins]

I use uTorrent and the socks5 with vpn was working perfectly until this weekend when something messed up my computer. I restored it from a backup and everything is exactly the same EXCEPT my torrents will not download or seed using my socks5 with Nord VPN.

Doesn't make sense that it was working perfectly before and now it isn't. I tried bittorrent, qbittorrent, deluge but my go to is uTorrent and none of them will work! Very frustrating. Any ideas? There are tons of seeders and only one leecher for the torrents I'm trying lately so as to get it working but 0 seeds, 0 peers nothing happening.

[ltGuillaume]

Have you set "Network interface (requires restart)" by any chance? Assuming you reinstalled Windows/network adapter/restored a system backup, the network adapter name/id could have changed, so you need to set that option again.

[myminpins]

Have you set "Network interface (requires restart)" by any chance? Assuming you reinstalled Windows/network adapter/restored a system backup, the network adapter name/id could have changed, so you need to set that option again.

I've never changed that before. And I've restored before but I'll definitely look into it. Thanks

[myminpins]

Have you set "Network interface (requires restart)" by any chance? Assuming you reinstalled Windows/network adapter/restored a system backup, the network adapter name/id could have changed, so you need to set that option again.

No go :( Still won't connect with socks5 Nord VPN on. So frustrating.

[dezza]

Have you guys considered socks5 proxy don’t forward ports afaik? IIRC
socks5 is only used for tracker communication.

Could it be a misconception from a developers viewpoint e.g. libtorrent or
similar that believes that “Port open” should mean both proxy and actual
connection?

Cuz if its the case, it might not be intended that it shows as
unconnectable.

On Sun, 13 Oct 2019 at 23.08, myminpins [e-mail] wrote:

Have you set "Network interface (requires restart)" by any chance?
Assuming you reinstalled Windows/network adapter/restored a system backup,
the network adapter name/id could have changed, so you need to set that
option again.

No go :( Still won't connect with socks5 Nord VPN on. So frustrating.

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

>

Best Regards/Venlig Hilsen Christoffer Aasted

• (GPG https://pgp.mit.edu/pks/lookup?op=get&search=0xAB87D7C744ABD20D)*

[myminpins]

Have you guys considered socks5 proxy don’t forward ports afaik? IIRC socks5 is only used for tracker communication. Could it be a misconception from a developers viewpoint e.g. libtorrent or similar that believes that “Port open” should mean both proxy and actual connection? Cuz if its the case, it might not be intended that it shows as unconnectable.

So what does that mean for me then? :)

[arvidn]

SOCKS4 only supports outgoing TCP connections. SOCKS5 supports two-way UDP (meaning it forwards the return packets) and it also supports a weird kind of incoming TCP connection, but really only tailored for the way FTP used to work back in the day, unfortunately not to accept multiple incoming connections on the same port.

My experience though (which is getting kind of dated by now) is that it's quite common for SOCKS5 proxies to not support UDP. I believe the most popular ones do though, like dante. It works by creating a TCP connection to authenticate and set up the UDP tunnel, and then leave that TCP connection open. UDP packets are sent and received with an additional SOCKS5 header, for routing information.

[myminpins]

IF I enable UDP support, it works fine - but not on the private tracker sites. It works in EZTV etc but on other sites I go to that are private, no go at all. No seeding, no leeching. Nothing. Updating forever.

[dkowis]

Dante and 3proxy are supposed to, but I haven't ever had it working.

[myminpins]

Lots of people seem to have trouble with socks5 proxies and torrenting. Is there another way to torrent and hide from your ISP? That works reliably?

[ltGuillaume]

Errr, AFAIK SOCKS5 does not encrypt your torrent traffic, nor does it hide the fact that you're torrenting from your ISP. It only hides your IP from trackers and other torrent users.

Only a proper OpenVPN/IKEv2 setup will actually hide the fact that you're torrenting from your ISP, too.

[myminpins]

Errr, AFAIK SOCKS5 does not encrypt your torrent traffic, nor does it hide the fact that you're torrenting from your ISP. It only hides your IP from trackers and other torrent users.

If you use the login to your VPN, far as I know, it encrypts all your torrenting traffic from your ISP

[ltGuillaume]

Errr, AFAIK SOCKS5 does not encrypt your torrent traffic, nor does it hide the fact that you're torrenting from your ISP. It only hides your IP from trackers and other torrent users.

If you use the login to your VPN, far as I know, it encrypts all your torrenting traffic from your ISP

The login is just for authentication, so that you can use the SOCKS5 proxy, because you paid for using it. That doesn't change the fact that SOCKS5 doesn't encrypt your traffic.

[myminpins]

Errr, AFAIK SOCKS5 does not encrypt your torrent traffic, nor does it hide the fact that you're torrenting from your ISP. It only hides your IP from trackers and other torrent users.

If you use the login to your VPN, far as I know, it encrypts all your torrenting traffic from your ISP

The login is just for authentication, so that you can use the SOCKS5 proxy, because you paid for using it. That doesn't change the fact that SOCKS5 doesn't encrypt your traffic.

So the VPN is not encrypting traffic using a socks5 proxy? So why does anyone use it for torrenting then?

[ltGuillaume]

So the VPN is not encrypting traffic using a socks5 proxy? So why does anyone use it for torrenting then?

It still hides your IP from other torrent users, such as rightsholders that are searching for IP addresses to use in their copyright trolling practices.

[myminpins]

So the VPN is not encrypting traffic using a socks5 proxy? So why does anyone use it for torrenting then?

It still hides your IP from other torrent users, such as rightsholders that are searching for IP addresses to use in their copyright trolling practices.

That makes sense

[jjhplus9]

I installed v4.2.0alpha2 and magnet links are now working again.
I hope this fix survives to the stable release!

[Cunningcory]

UPDATE: Just testing this solution and it did not work for me. It's not connecting after sitting overnight. Perhaps it will help someone else with a different issue, but doesn't seem to help my problem.

Possible solution was posted in another issues thread. It pointed to this link: https://www.reddit.com/r/VPNTorrents/comments/4dgup2/connectiontimeout_issues_when_using_socks5_proxy/

TLDR; Instead of using the web address of a proxy server, perform an NSlookup on the address and use a direct IP address instead. I'm going to keep testing torrents for the next 48 hours or so before I try switching over from my current solution (VPN running on a virtual machine).

I put this here because it took me a while to figure out and despite quite a bit of searching the answer to this issue doesn't seem to be readily floating around the internet.

This can happen using a number of torrent clients (I tested with uTorrent and qBitTorrent) and any number of proxy providers (Private Internet Access, TorGuard, etc).

The issue: when using the proxy, after a period of time passes (different for everyone, I will explain below), you'll add a torrent successfully but the client will not connect to peers and no progress will be made on the download until you restart the program or make changes to the connection settings and apply them.

Cause: Proxy providers like PIA and TorGuard have many different IP addresses associated with the proxy address they provide you. PIA, for instance, uses proxy-nl.privateinternetaccess.com. The issue with using an address tied to many different IP addresses is that when your torrent client initiates the connection to the proxy, it does a dns lookup and is returned a specific ip address (from the numerous different ones) and uses that to establish the connection. When it attempts to keep this connection alive the client does not recheck to see if DNS has pulled a different address since the initial connection. Meanwhile, DNS actually has resolved a different IP. Essentially, because proxy services are load balancing between many IPs and the IP you resolve will likely be different every time, until torrent clients include an update feature of some kind for proxies, you'll need to use a static IP for the proxy address.

Fix: Perform an NSlookup on your proxy address. It will return a list of addresses (note that if you execute this command more than once the first IP address returned each time will be different!). Take any one of the addresses returned from the NSlookup and use that in your proxy setting.

This behavior isn't a big deal if you're using a local client that you can simply close and reopen. But if you're using a torrent server of some kind or accessing it via your phone, remote WEB-UI, etc, then if can be a real hassle to add a torrent and have it sit there doing nothing. I've seen a lot of people simply write scripts that restart their client every 30 minutes, etc, but that is really not an ideal solution but rather a clunky work around.

Hope that saves someone some time. Cheers.

[arvidn]

there was a bug fixed in libtorrent recently, that will be included in the upcoming libtorrent-1.2.3 release (soon). It was specifically affecting UDP messages over SOCKS5 sent to hostnames (as opposed to IP addresses).

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

[4luk]

there was a bug fixed in libtorrent recently, that will be included in the upcoming libtorrent-1.2.3 release (soon). It was specifically affecting UDP messages over SOCKS5 sent to _hostnames_ (as opposed to IP addresses).

arvidn/libtorrent#4154

Thanks hopfully this will fix the issue. Any eta on release date?

[sledgehammer999]

V4.2.1 includes that fix.
Others still facing proxy+UDP issues follow issue ##11735

[4luk]

V4.2.1 includes that fix.
Others still facing proxy+UDP issues follow issue ##11735

Did a fresh install on 2 different windows 10 computers and still have the same issue with magnet links stuck on downloading metadata
No issue with version 3.3.16
Using nordvpn
Will check out 11735 thanks

[sledgehammer999]

Apparently you don't read very well the comments in #11735

[ccyclone]

I've installed 4.2.1 and it is still presenting the issue of stalled/no connections over socks5 via hostname. If I lookup the ip for my socks5 server and put in the ip address it works fine.

This doesn't work for long as the socks5 server apparently rotates ip addresses regularly and an entered ip address won't be valid in 5-10 minutes. So still no working solution for this issue.

[arvidn]

@ccyclone interesting! Could you tell us more about the system you run qbt on? windows? version?
Do you have a log with socks5 error messages in it? I recall in one report the host name lookup failed but the error code suggested it had succeeded, which seems suspicious.

[Treverr]

FWIW I am using the IP address, and I still have this issue. I have resorted to restarting QB every hour and that seems to mostly mitigate the issue but obviously isn't optimal.

I have this installed on Linux Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-72-generic x86_64) running qb v 4.2.1

[q-DOESNOT-beat-torrent]

Q peers,

Trully speaking, - for serveral months I've been [re]reading this subj, and step by step learning-inverstigating-practicing... All this time I wanted to wonder whether it's only my-noob sees the decision is on the top?

... Got registered only I realized we've got same issues but different base sourse...

Re my case, I notice capacities and performance rough decrease after enabling an external proxy (ie sort of Hola, etc.). Then, as for you, re-lunch works (next to the re-launch, of course, as you always get a spare hour for check-process, ha-ha).

So my suggestion was the Proxy option to be filled in with your current internet connection

...Well, this message is easier to count as offtop right away I well-qoolme-bit myself on this board! :)

Cheers,
qoolBitTorrent adorer

ps. Just to stress that my issue anyway is serious, then I'll check my idea, and I ready to get in touch and participate in my sub-case.

[arvidn]

the issue of dropping SOCKS5 UDP tunnels after a while and/or when computer going to sleep and waking up may have been fixed in libtorrent RC_1_2 branch (not released yet).

According to the SOCKS5 specification, a UDP tunnel stays open for as long as the TCP connection stays open. But the TCP connection is completely idle, which means the only way to detect losing connection is by TCP keepalives. The default timeouts of TCP keepalive on all major operating systems are hours.

What changed is that I made attempts to lower the TCP keepalive timeouts to 30 seconds, with the hope that a disconnect would be detected soon after it happened. There is no standard way of setting these timeouts, so it includes some linux, BSD and Windows specific code.

It would be great if anyone would give it a try.

[diverge3]

qbittorrent 4.2.1 on Linux/container
Proxy configured with IP

I've encountered constant issues with qbittorrent running in a container using a SOCKS5 proxy that just stops being able to communicate. If the container is restarted everything works fine, for "some" period of time, but no longer than a few hours. I haven't been able to tie it down to a specific amount of time. When in the bad state torrents will not start for 12+ hours and a restart of the container is the only thing that will fix it.

The behavior I see is via netstat that on container start qbittorrent establishes multiple TCP connections to the proxy address, which is specified with an IP. These connections are created even though there are no torrents loaded on the UI.

root@b4ae33b65db0:/# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 172.17.0.5:36742 1xx.xxx.xx2.xxx:1085 ESTABLISHED
tcp 0 0 172.17.0.5:36740 1xx.xxx.xx2.xxx:1085 ESTABLISHED
tcp 0 0 172.17.0.5:36748 1xx.xxx.xx2.xxx:1085 ESTABLISHED
tcp 0 0 172.17.0.5:36746 1xx.xxx.xx2.xxx:1085 ESTABLISHED
tcp 0 0 172.17.0.5:36744 1xx.xxx.xx2.xxx:1085 ESTABLISHED

If after a container start a torrent is added the connectivity works as expected. There are a large number of additional TCP connections created for the transfer. After the transfer is complete and the torrent is automatically removed, some of the TCP connections to the proxy are kept open for over 10 minutes but no packets are being transmitted or received during that time.

Why must the SOCKS5 connection be kept active when there are no active torrents? Wouldn't it make more sense to only establish a connection when a torrent is active/started? The server side of the proxy connection is likely using an idle timeout so it is likely closing the connection after no traffic, while it appears that qbittorrent keeps the session active forever.

If this is indeed the case, the behavior I see where torrents won't start for hours when in the bad state also points to qbittorrent not being able to detect that they are in a bad state. I don't see any errors in the log, but no communication to the proxy is occurring.

If a keepalive was implemented on the qbittorrent side, would a general network issue (like internet going down temporarily) be detected? Right now real requests for a new torrent don't cause qbittorrent to detect a bad proxy connection and restart them. If the keepalive just sends a packet every x seconds but does not verify that the server-side is still receiving traffic then how would any bad session be identified and re-established?

For my specific use case where a torrent is fetched maybe once every 12-24 hours and then automatically deleted after completion, with nothing being active in between them, having the proxy connection stay active seems like the wrong design. Once there are no torrents active for more than a few minutes the sessions should be closed. A new session would then be created when a torrent goes active.

I just saw 4.2.2 is out. I'll give that a try and see if the behavior is the same. The release notes don't mention anything about proxy connections.

[FranciscoPombal]

@diverge3 4.2.2 fixed some VPN/proxy issues due to recent libtorrent 1.2.x versions, but has other issues (https://github.com/qbittorrent/qBittorrent/issues/12253).
Wait for 4.2.3 which should be released shortly with improved proxy error logging and stay tuned on those tickets.

[arvidn]

Why must the SOCKS5 connection be kept active when there are no active torrents?

Because the DHT runs regardless of whether you have active torrents. DHT traffic runs over UDP. SOCKS5 UDP tunneling requires a TCP connection to open the UDP tunnel (and the TCP connection need to stay open to keep the UDP tunnel open, even though there is no traffic).

Wouldn't it make more sense to only establish a connection when a torrent is active/started?

TCP peer connections are tunneled over individual SOCKS5 connections, and they are opened "on demand" so to speak. But I think it makes sense to run the DHT regardless. uTP peer connections and UDP trackers use the same UDP tunnel as the DHT as well.

The server side of the proxy connection is likely using an idle timeout so it is likely closing the connection after no traffic, while it appears that qbittorrent keeps the session active forever.

libtorrent is reading from the idle TCP connection to detect when the other side closes it (so it can be re-opened). However, it seems like this connection can be closed without libtorrent detects it. In recent libtorrent I have therefore enabled shorter TCP keep-alives, in an attempt to detect when the proxy closes the UDP tunnels.

[diverge3]

Because the DHT runs regardless of whether you have active torrents. DHT traffic runs over UDP. SOCKS5 UDP tunneling requires a TCP connection to open the UDP tunnel (and the TCP connection need to stay open to keep the UDP tunnel open, even though there is no traffic).

When I last saw this behavior there were no active UDP sessions to the proxy, only the TCP sessions. Maybe I am misunderstanding how the traffic is sent to the proxy, does the UDP packet get sent to the proxy over TCP? I see other UDP sessions to the proxy server IP at other times, especially when a torrent is active, but there are often hours when no UDP sessions are seen (likely because no torrents are active).

On another note, I reconfigured the host OS to have a tcp_keepalive_time of 600, and that appears to have cleared up the issue with the firewall closing the sessions due to inactivity. Not ideal since it impacts everything on the machine, but I think it should be ok for my environment.

[zvodd]

Seems this bug had a regression after v4.1.9.1
Currently SOCKS5 is working on v4.1.9.1 x64 Windows.
Tested v4.2.1, some connections work, (Downloads do not work).
Tested v4.2.3, fails to connect to SOCKS5 completly.

[xavier2k6]

@zvodd this issue is closed, go here #11735 & try the test build from https://github.com/qbittorrent/qBittorrent/issues/11735#issuecomment-617230156