Enabling listening on tcp port when proxy is used for peer connections #7726
Conversation
|
@Masong19hippows that link appears to be broken. Is that text posted anywhere else? |
|
it's not surprising the HTTP proxy specification from 1997 defines proxy as an intermediary for making requests. That was essentially the only thing you could do with HTTP. The Socks5 protocol (which is also called "proxy") does in fact support incoming connections, both over TCP and UDP. I wouldn't consider that text a compelling argument to change libtorrents behavior. I think enumerating the legitimate use cases might be. Either way, if there is a compelling argument, I think it would be best to guard it under a new setting, rather than changing behavior for everyone. |
Unfortunately, it doesn't look like it. However, it still cached on my machine via google amp. I just coped the text article and here it is. Patch qBittorrent: Listening on port while using proxy First things first, to achieve that, we need a proxy where we can set up port forwarding on it, then we modify and compile qbittorrent ourselves. A VPN can work, but that requires UPnP/PMP support of the VPN, which many lacks in. And also, use with caution, if you do not want to expose your IP address accidentally, always use a VPN. Recently, I came across a situation where I need to do some seeding, but the network I was on requires a proxy to gain access to the Internet. Naively, I set up the proxy settings in qbittorrent, quickly found out that it did not work at all. After some long nights searching and digging, it turned out that the library qbittorrent (along with several other FOSS torrenting software) depends on, libtorrent, on some recent versions, completely disables port listening while Use proxy for peer connections is enabled, to avoid network traffic leakage, rendering it impossible to do seeding at all while using a proxy. But the authors never make this clear, and I suspect that qbittorrent authors haven't even realized this behavior. The setting page on qbittorrent doesn't reflect the change in port listening section at all when you enable proxy for peers. So here come the easier parts. We find the corresponding conditional code, modify, patch, then recompile libtorrent. No changes in qbittorrent are needed, only libtorrent. Check out my patch file listen-when-proxy-on.patch based on v2.0.7 of libtorrent at end of this article. Since I'm on archlinux (and yes, BTW, I'm using arch :D), patching software is relatively convenient. Go grab the PKGBUILD script from arch offical package page https://archlinux.org/packages/extra/x86_64/libtorrent-rasterbar/ (source files link), add our patch into prepare() section like this: prepare() { Fire up qbittorrent and set a fixed listening port, say 7890; Disclaimer: qBittorrent and libtorrent are FOSS, the patch shared here is also free from restrictions. Please comply with your local regulations, use with caution and at your own risks. listen-when-proxy-on.patch: diff --git a/src/session_impl.cpp b/src/session_impl.cpp // if we don't proxy peer connections, don't apply the special logic for
@@ -5473,7 +5473,7 @@ namespace {
@@ -5611,7 +5611,7 @@ namespace { if (!s->natpmp_mapper
|
src/session_impl.cpp
Outdated
| // the natpmp constructor may fail and call the callbacks | ||
| // into the session_impl. | ||
| s->natpmp_mapper = std::make_shared<natpmp>(m_io_context, *this, listen_socket_handle(s)); | ||
| ip_interface ip; | ||
| ip.interface_address = s->local_endpoint.address(); | ||
| ip.netmask = s->netmask; | ||
| std::strncpy(ip.name, s->device.c_str(), sizeof(ip.name) - 1); | ||
| ip.name[sizeof(ip.name) - 1] = '\0'; | ||
| s->natpmp_mapper->start(ip); |
There was a problem hiding this comment.
it doesn't make any sense to disable NAT-PMP entirely. this seems unrelated to the intention of this patch
There was a problem hiding this comment.
I think this was just a mistake on my end. It was not my intention to disable nat-pmp entirely. Rather, it was to enable the ability to use it regardless of proxy.
It does not. The socks4 protocol specifies bind and connect commands while the socks5 protocol specifies auth and the udp communication commands. Bind in the socks4 protocol is defined as: "The client connects to the SOCKS server and sends a BIND request when and in the socks5 spec: "It is expected that the client side of an application protocol will This is not facilitating inbound connections in the traditional sense, rather it facilitates inbound connections on an already existing outbound connection. In the spec, it used ftp as an example, and I think this is perfect because ftp needs at least 2 connections to the client, one inbound and one outbound. I think this explains it better than I could. If we were to hack the bind command in order to listen and forward ports, the qbittorrent host would first need to send an outbound connect command to all potential leachers. This would require massive changes and its more hacky than it should be. There are applications that extend/break the socks protocol (like ssh) to include the support of inbound connections. However, this is not something outlined in the socks protocol itself, and so it shouldn't be treated as such in my opinion.
I was more just trying to point out that the proxy server itself should not facilitate inbound connections, because this was used in the past issues to justify libtorrent behavior. I have been using this PR with qbittorrent for awhile now and I honestly haven't noticed any issues. Before, the seeding wasn't working well. As for the use cases, I see this as removing an artificial limitation rather than adding a feature. The use case would be that the user would get full seeding/leaching potential. It honestly works so well that I had to limit the number of inbound connections because it overloaded my socks5 server and used all of the ports on my system.
That makes sense. I just did a quick and dirty thing to try and get the conversation started, but I am willing to learn and expand this. |
qbittorrent disables the listening tcp port when the option "Use proxy for peer connections" is enabled. This is mentioned in #21134 and #8718.
I don't believe this should be the case as its a fundamental misunderstanding of what the proxy should do. Proxies are only for outbound connections and should not change behavior of incoming connections. This is outlined in the http proxy spec as defining a proxy as a service for making requests.
I think the current implementation is an artificial limitation set by libtorrent rather than the protocol itself. There are plenty of reasons to still accept incoming connections while using the proxy for outbound connections. A very reason is for networks that require a proxy for internet.
This pull request is heavily based on this article.