Proxies and UDP issues (no DHT/magnet/metadata/UDP trackers) #11735
Comments
|
Should this be pinned? |
|
This is the test build mentioned above based on arvidn/libtorrent#4202 and on 4.2.1 with below patch applied. Link: http://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735.7z diff: diff --git a/src/base/bittorrent/session.cpp b/src/base/bittorrent/session.cpp
index a4cf15107..b86e83219 100644
--- a/src/base/bittorrent/session.cpp
+++ b/src/base/bittorrent/session.cpp
@@ -4211,6 +4211,9 @@ void Session::handleAlert(const lt::alert *a)
case lt::external_ip_alert::alert_type:
handleExternalIPAlert(static_cast<const lt::external_ip_alert*>(a));
break;
+ case lt::socks5_alert::alert_type:
+ handleSocks5Alert(static_cast<const lt::socks5_alert*>(a));
+ break;
#if (LIBTORRENT_VERSION_NUM >= 10200)
case lt::alerts_dropped_alert::alert_type:
handleAlertsDroppedAlert(static_cast<const lt::alerts_dropped_alert *>(a));
@@ -4623,6 +4626,11 @@ void Session::handleListenFailedAlert(const lt::listen_failed_alert *p)
#endif
}
+void Session::handleSocks5Alert(const lt::socks5_alert *p)
+{
+ LogMsg(tr("Socks5 error: %1").arg(QString::fromLocal8Bit(p->message().c_str())), Log::CRITICAL);
+}
+
void Session::handleExternalIPAlert(const lt::external_ip_alert *p)
{
lt::error_code ec;
diff --git a/src/base/bittorrent/session.h b/src/base/bittorrent/session.h
index 4591f4477..859b9abad 100644
--- a/src/base/bittorrent/session.h
+++ b/src/base/bittorrent/session.h
@@ -576,6 +576,7 @@ namespace BitTorrent
void handleListenFailedAlert(const lt::listen_failed_alert *p);
void handleExternalIPAlert(const lt::external_ip_alert *p);
void handleSessionStatsAlert(const lt::session_stats_alert *p);
+ void handleSocks5Alert(const lt::socks5_alert *p);
#if (LIBTORRENT_VERSION_NUM >= 10200)
void handleAlertsDroppedAlert(const lt::alerts_dropped_alert *p) const;
#endif |
No. |
sledgehammer999
changed the title
|
Can i post this here? When I used QBittorrent Version 3.3.16 + Socks5 proxy + Nordvpn = Show on EXECUTION LOG TAB: When I used QBittorrent Version 4.2.0 + Socks5 proxy + Nordvpn = Show on EXECUTION LOG TAB: The same settings was made for both version 3.3.16 and 4.2.0. |
|
@calvilasboasjr did you even read my 2 previous comments? |
Log (no error Test:
Result:
In my case, I want to connect to trackers through a proxy and make all other connections directly. |
|
@ExceptionGit There is a slight possibility that the posted build didn't have the patch applied. I reuploaded it. Can you download the same file again and test? |
|
@sledgehammer999 Yes, file hashes have been updated. Config:
Log (no error "Socks5 error: %1", wait ~8min): Config:
Log (no error "Socks5 error: %1", wait ~10min): I think my old proxy server version does not return error for libtorrent. |
|
@sledgehammer999 you can test the build and logging by just setting a random hostname and port as a socks5 proxy, and ensure you get the After having thought a bit more about this, I think one issue, that may not have existed in libtorrent-1.1.x, is that the socks5 proxy logic sits on the individual socket object layer. That means that if you have multiple interfaces (which one is likely to have), each interface will trigger a socks5 connection and tunnel. This is not ideal, and I can understand if socks proxies frown upon that behavior and only let the first one (or the last one) in. For example, when just testing this now, I get these listen interface by default: As a quick hack to avoid this, I think setting
I'm leaning towards (2), but maybe there's should be a more generic rule around filtering listen interfaces as well. For instance, all those Does anyone have any opinions? |
Yes it does print errors if I point to eg
Guys, if you want to test the above, go to Advanced settings and choose |
Sorry - I did not understand "to enclose them in "code" tags" as I could not find "click the relevant button from the toolbar present above the comment input box which has a tooltip "Insert code". The loglines will be posted suitable for easy reading." Link: http://builds.shiki.hu/temp/qbittorrent_4.2.1_x64_patched_for_issue_11735.7z extracted to folder and ran from that folder. qBittorrent v4.2.1 Set Tools, Options, Connections Proxy Server Socks5, Authentication, OK Preloaded torrents with URL http trackers: some are Working, some are Not Working, Loaded torrent with URL udp trackers: all trackers Not Working, have 0-Seeds, have 0-Peers, and torrent is not downloading. Looking at qBittorrent v4.2.1 Execution Log I see no errors and these are the lines copied one-by-one ... qBittorrent v4.2.1 Set Tools, Options, Connections Proxy Server (None) OK. Closed client. Deleted App Data Local Temp Files. Restarted client. URL udp trackers Working, have Seeds, have Peers, and torrent is downloading. Looking at qBittorrent v4.2.1 Execution Log I see no errors and these are the lines copied one-by-one ... |
This is my case (if I set a non-existent network address), but no error
|
|
I'm looking at one which has these characteristics Usually when data actually flows it is from one of these sources: Is the code base which uses trackers separate from the code base which handles DHT/PeX/LSD? Sorry in advance, I just noticed these trackers aren't UDP, but I figure this might be useful toward figuring out what is going on. |
|
@RandomInhabitant http trackers do not go through the same path as udp trackers, when using a socks5 proxy. |
|
Guys, I don't know if you noticed that: Versions 3.3.16 and 4.2.0 and using VPN on SOCKET5: I noticed that in both versions, when I add a new torrent, the torrent DOES NOT AUTOMATICALLY START! So when I click the PAUSE and START buttons a few times: Result: Please make this test and comment. Thanks. |
|
there's also no application layer timeout on the connection attempts to the socks5 proxy. If the other machine does not respond with port-unreachable and the network doesn't respond with host-unreachable, the connection attempt may take several minutes before failing. The test build only print socks5 errors to the logs, not attempts to connect (for instance). So make sure you give any test runs plenty of time to fail. |
|
Understand. What I mean is, when I do this kind of action, PAUSE-START, the torrent starts faster. |
|
22+ hours now on the latest test build and everything continues to work. I have two socks5 related semaphore timeout errors in the log, but I'm not seeing any adverse effects. |
|
@xavier2k6 @amsterdampaul arvidn/libtorrent#4498 has landed |
|
New master TEST build with a qBittorrent master commit e030fc0 with libtorrent RC_1_2 commit ebc2bfc |
It's working well with SOCKS5. I will let it running for a couple of hours and see if there are any SOCKS5 reconnection issues. Also it was not necessary to specify the network interface, I could leave it on any interface in the Advanced settings. |
This is the only error I'm getting after running all night.
|
|
After 12h of seeding/ downloading (also adding new magnet torrents after a couple of hours), I am only getting a SOCKS5 connection was closed error after it was seeding for a long time. But the SOCKS5 still works because after I added a new magnet torrent it directly started to find seeders and started downloading. Good job @arvidn, @sledgehammer999, @xavier2k6 and @FranciscoPombal ! I think the SOCKS5 related DHT, UDP trackers, meta data stalling, etc. erros I experienced in the past seem to be resolved! |
|
I've been having SOCKS5 issues for several years. I finally had to just set up a VM running a full proxy connection and a qbit babysitter to restart the app if and when the proxy disconnected. I'd love to be able to ditch the VM and go back to just a simple socks5. I've been following a few of these threads waiting for a solution. Gonna test this newest test build and cross my fingers! |
|
as far as I can tell, the vast majority of issues are solved now. If the server disconnects, libtorrent will reconnect. This is expected to happen every now and then as the SOCKS5 connection is idle and long lived. However, there are still a few failure cases where libtorrent will not try again, for example, if the hostname lookup fails for the proxy server, or if the socks5 server IP cannot be reached. To do this properly, there would need to be some kind of back-off timer, to avoid hammering some poor IP. Fixing these cases is not very high priority right now, since I think they only affect very few people and not very often. |
I think as soon as 4.2.4 is released, we can close this thread and open a new one specifically to track infrequent SOCKS5 disconnects. @sledgehammer999 what are your plans for the release date of 4.2.4? It seems all of the more important issues have been resolved (there are a couple of important PRs that have not yet been merged, but are almost there). Same on the libtorrent side. In fact, 1.2.6 should be nearing official release, but the remaining stuff in the milestone at this point is not that important. |
Is this 4.2.3 or 3.4.0alpha? I downloaded an earlier build and it was 4.3.0alpha. |
|
@RabidWolf it's an updated alpha build |
|
Thanks will wait for 3.2.4 |
|
Back to not downloading after a day or so. Seeing this error. |
|
Same here unfortunately, here is the log. |
|
Mine has also crapped out. What a bummer. I was hoping this was fixed. My log would get this message every few hours:
This was followed five minutes later with a new IP detection:
This didn't seem to be an issue for a while, but most recently instead of getting a new IP detection, I instead got a new error message immediately following it: The handshake error seems to be the one that permanently kills the connection. |
|
For whatever reason, this completely cleared up doing a fresh ubuntu install. I havent had to restart the service in about a week and a half! I sure hope you guys can get it figured out! |
|
An observation: I have two torrents that will not work with SOCKS5 on. They were begun after qBittorrent sat idle for ~1 day. I've restarted, paused and unpaused, changed the host and put it back, unchecked authentication and rechecked, and every combo of these steps you can think of. No love. However, if I pause the second one and turn off the proxy server, the first will start. Now if I enable the proxy server with authentication and "use proxy only for torrents" unchecked (my normal settings), then resume the second one, it will start. I haven't gone so far as to check the reported IP of the second torrent using the TorGuard torrent, but I will soon. If anyone can test and confirm/deny this, it might help. |
|
I did run the CheckMyIPTorrent torrent, and it is indeed hiding my IP: 21.04.2020 06:42:23 | 109.201.138.225 | qBittorrent/4.3.0alpha1 Interesting that it switched IPs so quickly. |
|
New "Windows x64" TEST build linked below. Based from these commits: |
|
Is this the same 4.3.0alpha1 posted last week? |
No, it's a new build based on latest commits... |
Ok just wondering because it still shows as 4.3.0alpha1 |
Yeah that version string does not change between alpha builds. |
This comment has been minimized.
This comment has been minimized.
|
It seems almost all of the issues have been addressed in the changes made in qBittorrent/libtorrent since this issue was opened. The remaining identified issues have to do with some rarer SOCKS5 proxy disconnects that have been acknowledged here: #11735 (comment). Thus, now that 4.2.4 is released, bringing the fixes to all of the user base, I think it is time to close this, as it's getting too long and contains a lot of comments about stuff that is already fixed. Anyone having further connectivity issues not related to the aforementioned SOCKS5 issue, please open a separate issue report. A big thank you to everyone who participated in testing, debugging, and discussing this issue. |
and others
This is to gather all relevant bug reports about proxies and UDP connection issues(no DHT, no magnet/metadata working, no UDP trackers working etc)
These came into being after the 4.2.0 release which uses libtorrent 1.2.0. Libtorrent 1.2.x doesn't have the
force_proxysetting that libtorrent 1.1.x did. This option, when false, allowed direct connections to DHT/metadata/μTP peers/UDP trackers when the proxy didn't support UDP connections.In libtorrent 1.2.x this was deemed non-sensical and if the proxy doesn't support UDP connections then all the above will not work. No direct connection will be attempted.
Anonymous mode doesn't play a role in this.
There is a slight chance that libtorrent code doesn't correctly detect UDP support by the proxy. So the purpose of the thread is to help debug and forward details to the libtorrent author.
For the time being the libtorrent author has provided a PR(arvidn/libtorrent#4202) which logs socks5 related errors. I will provide a test builds shortly.
The text was updated successfully, but these errors were encountered: