Can't get hole-punching tutorial to work reliably #2609
Comments
|
Thanks for the detailed report @alexander-camuto. Very much appreciated. I still need to give this more thought, though I have a first idea:
Does D and E have particularly long RTT to R but short RTT to A? I am asking, as hole punching is quite time dependent. In case these nodes are close to A but far from R, the noise in the RTT measurement for hole punching might be the cause. |
Varying the IP is rare, varying the port is more usual on endpoint dependent port mapping NATs. Just to make sure, are D and E behind NATs that change the port depending on the remote endpoint they are talking to? |
|
@mxinden thanks so much for your prompt reply
|
|
@alexander-camuto is D and E significantly closer to A than B and C to A? |
|
@mxinden D-A RTT is roughly 20ms and B-A RTT is roughly 13ms, so of the same order / approximately equidistant. |
|
@alexander-camuto still facing the issue? Any other information that might be helpful to debug this? |
|
@mxinden had to switch focus for a bit. Issue still persists but will try and come back to this to generate more information we can debug off of. |
|
i seem to be experiencing the same issue, what's confusing me is how did this Malformed multiaddress get here My Setup:
What i tried doing:
but still get the error |
|
just now i tried switching the setup while using the dcutr client example and same libp2p-server
using the above setup i was able to get |
Indeed surprising. Not sure where this is from. Does the
What error is shown when the connection resets? Is the relayed connection or the direct connection reset? |
4 tasks
|
Also see #2679 which might make debugging a bit easier. |
|
No it does no contain a single So the listener is trying to dial a non listening port of the Dialer. here are some logs that might help: NB: i am still using libp2p-server as the relay, since i got same results with relay_v2 listener:Dialer: |
|
I think i maybe found an explanation for what is causing that After an what seems to me only the first established relayed connection to a private peer. The relay is telling us that our public address is it's PeerID, Thus we advertise it to other peers (via Identify?) |
Sorry for not flagging this earlier. This is likely due to a bug in the TCP transport which has been fixed in #2670. @T2JOESl4m2ZpNC would you mind testing it once more with the latest release |
|
Indeed the newer version seems to have fixed it. i also tried the it's really cool seeing it traverse NAT |
Any hints why it does not always work?
Even though I implemented most of the hole punching protocols, it still feels somewhat magical to me as well. Thanks for the feedback. Very much appreciated. Hope rust-libp2p is useful for you. |
|
sorry for the late reply
No idea, just tested today with the same built client and same setup and i punched through every time |
|
Logs of a successful traversal: DialerListener |
|
I am closing here since (a) parts of this discussion has stalled and (b) parts of the problems have been resolved. In case you are still facing issues with our hole punching stack, please open a new issue. Very much appreciate your input here and thus your help improving rust-libp2p. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Can't get hole-punching tutorial to work reliably
I am currently trying to get the hole-punching tutorial to work across a network of identical ubuntu-server 21.10 nodes (6 Mac Minis 8GB of RAM from late 2012 solely running ubuntu-server, behind different home networks in the same city). The main variable across the nodes is thus different ISPs / routers / home network setups.
I have one relay set up, let's call it R, a listening client A and 4 other nodes that are clients attempting to dial A, let's call them {B,C,D,E}.
B and C are able to establish a direct connection to A via R reliably (the opposite also holds true - when B and C are the listeners, A this time as a dialing client is able to establish a direct connection to B and C).
Issues appear for nodes D and E. Both are able to establish an outbound circuit with the relay and the listening client is able to initiate a direct connection request for the relayed connection. Issues then appear when trying to establish this direction connection (see below).
I've also double checked that none of the machines are behind difficult NATs (i.e whether the NAT varies the machine's IP depending on destination) and that they don't require hair-pinning for NAT traversal.
Node A listener logs when Node D and E are dialing
The A-D (and A-E) connection fails on the listener side, whereby a strangely formed Multiaddr eventually causes an error (see last line). Node D eventually just issues a timeout message.
Sanity Check: Laptop dialing node A -- dialing logs
Issues also crop up on the dialer's end when attempting to hole punch to Node A using my personal laptop. Though this could be because the laptop is behind a difficult NAT (i.e the machine's IP depends on destination), I've had others replicate this issue (attempting to direct connect to A via R) on their personal laptops (on different home networks) but I can't verify the properties of their NATs to confirm a pattern.
The text was updated successfully, but these errors were encountered: