Can't seed from behind a SOCKS proxy via uTP #6512
Milestone
Comments
|
Seems related to #6001 |
|
@arvidn ? |
|
make sure you have My suspicion is that it has to do with the validation of incoming network interfaces. When listening on a specific interface, but receiving an incoming connection over another interface, that connection is closed because it didn't match the listen interface. a proxy is roughly treated as its own interface and it's configured to not allow incoming connections. Could you try this patch? |
|
This is the log for the leecher. The seeder's log looks the same. The suspicious line is: |
|
I applied the patch you provided. The uTP log did not change much: uTP log |
|
Added peer logging: The only peer logs are from the leecher side. The last "empty" log line is suspicious 🤔 |
|
235.97.29.105:1024 |
|
https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html https://www.thegeekdiary.com/which-network-ports-are-reserved-by-the-linux-operating-system/ I think it's ok but depends on the setup of the host. |
|
@wrtorrent , thanks for suggestion, but port 1024 should be perfectly fine as 1024>1023. Also, this is not real ports and IPs, but just the ports and IPs reported by Tribler SOCKS5 server during tests. This means the Linux kernel never sees these, those exist just as numbers in packets going back and forth over the SOCKS protocol. |
|
@arvidn , any ideas on how to debug this further? |
|
@ichorid the patch I suggested should affect a peers "willingness" to accept an incoming connection via SOCKS5. From the peer log you posted, it looks like you're on the peer making the connection (not accepting it). Did you still patch the other end? If not, it might still be the problem that it won't accept incoming connections from you. |
|
@arvidn both ends run on the same machine, same lib, same process. I guess the second column in the log is the Libtorrent Session pointer or some kind of id. You can see there are two such pointers in the log I provided: EDIT: sorry, the thing you were talking about is the Session log. I omitted the log for the second Session because it looked just the same. I'll provide it for the sake of completeness now. |
|
Seeder session log: Leecher session log: Both sessions run on the same machine. The leecher session starts after the seeder, tries to bind to the default port 6881, fails to do so and then tries port 6882. One suspicious point is the leecher log still showing |
|
Just for the sake of it, I randomized the listen ports: Leecher: The uTP log seems the same 🤷 |
|
@arvidn , any ideas how to proceed with debugging this further? |
This was referenced Oct 21, 2021
|
the best thing I can think of would be to set a breakpoint in the uTP destroy function and see where it's called from, or add more logging around calls to it (with the reason it's called). I still have a suspicion it's related to libtorrent's logic to ensure connections are coming in (and going out) over an "approved" interface (when interfaces are specified). It's possible there are some other places where the proxy-interface is assumed not to accept incoming connections. |
|
Tribler broke after 6aad9a4. Inverting the |
|
Great find. I don't think it's quite as simple as to revert this. The purpose of that check is to ensure that a local listen socket isn't accepting incoming connections when peer connections are supposed to be going through the proxy. I.e. as a safety measure to prevent peers from circumventing your proxy. I'll take a closer look at this. |
|
For example, imagine using an http proxy and enabling proxy peer connections. Any connection accepted by a local listen socket won't be going through the proxy, and shouldn't be allowed. |
|
I haven't looked into it too deep, but thee problem may very well be at the Tribler side. The issue with accepting incoming connections through a proxy is currently that we don't know where to send the data. In Tribler this is currently solved by sending the data to the local listen socket (https://github.com/Tribler/tribler/blob/main/src/tribler-core/tribler_core/modules/tunnel/community/community.py#L561). This would work with libtorrent 1.2.12, but stopped working after the commit I mentioned earlier. Ideally, when libtorrent sends an UDP associate it should include the address with which to communicate in the |
|
I see. Libtorrent (probably) expects those packets to be wrapped in the socks5 udp header. This is all uTP, right? |
|
I agree that it would be good if libtorrent would fill in the IP and port in the UDP Associate command, but in your case, it's the same IP and port, libtorrent just doesn't treat it as coming via the proxy if it doesn't have the socks5 header. |
I've looked into this and Tribler is adding a SOCKS5 header. Without the header libtorrent doesn't respond at all, and with a header it immediately sends a ST_FIN after receiving a ST_SYN. I assume the ST_FIN is sent as a result of the uTP destroy function you mentioned earlier?
Yes, the UDP packets are coming from another libtorrent instance. I assume it's all uTP.
It looks like |
|
Yay, @egbertbouman , long time no see! 😁 🎉 |
|
libtorrent is probably just assuming no proxy supports incoming connections then. this should be fixed. |
|
could you try this patch? |
First of all, this patch is for Libtorrent 2.0. I was not able to apply it to 1.2.14. So, I tried compiling Python bindings with Libtorrent 2.0, but failed to do so with boost-build. Seems like the @arvidn , could you please either:
(I would prefer a 1.2.14 - based patch 😉 ) |
|
I haven't tried backporting the full patch to 1.2.14, but I know from previous testing that removing the proxy check from |
|
@egbertbouman , @arvidn , indeed, removing the proxy check in 1.2.14 ( I guess we will use 1.2.12 for the time being. This issue should probably remain open until #6538 is merged. |
|
I back-ported the fix (but not the test) |
|
@arvidn Log |
|
There were recent improvements to the socks5 support in libtorrent to accept incoming udp packets with the source address as a domain name. as well as the bind address in the udp associate response supporting domain names. Regarding the HTTP proxy, it's unrelated to socks. My guess is that since you can't receive incoming connection, you can't seed to peers who also can't accept incoming connections. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Libtorrent 1.2.14.0
This was first discovered in Tribler hidden seeding test issue, where two Libtorrent sessions are started and connected via SOCKS5 UDP associate protocols via uTP. I managed to capture the log:
uTP log
The log is for two Libtorrent sessions exchanging uTP data locally through Tribler SOCKS5 connections on both sides. This is 100% reproducible, although it will be hard to reproduce outside of Tribler (e.g. via some random SOCKS server), because of all the dynamic port assignments, etc. Also, there seem to be almost to SOCKS5 servers that support UDP association.
The interesting part of the log is:
Seems like the seeder acknowledges the connection and then immediately destroys the uTP stream object for some mysterious reason 💥
The text was updated successfully, but these errors were encountered: