Identify behavior adds observed address, but contains ephemeral port causing AutoNAT probe failure #4153
Comments
|
Note, we observed this behavior when we updated from 0.51 to 0.52. I have tried looking for changes regarding |
|
I found a possible culprit. In the following code, the candidate is passed on before address translation. Lines 1065 to 1094 in 28c4786 In the previous version of this code (before #3954 @thomaseizinger), I think a possible solution is not sending the event before address translation. (I.e. the first line of code above.) |
b-zee
added a commit
to b-zee/rust-libp2p
that referenced
this issue
Jul 5, 2023
The `NewExternalAddrCandidate` event is yielded both before and after address translation. This will cause, in the case of TCP, ephemeral ports to be added as candidate. In turn, that will cause protocols like AutoNAT to fail as these candidates are not actually reachable/external. Fixes libp2p#4153
b-zee
added a commit
to b-zee/rust-libp2p
that referenced
this issue
Jul 6, 2023
The `NewExternalAddrCandidate` event is yielded both before and after address translation. This will cause, in the case of TCP, ephemeral ports to be added as candidate. In turn, that will cause protocols like AutoNAT to fail as these candidates are not actually reachable/external. We will now only yield the original candidate if translation did not apply. Fixes libp2p#4153
b-zee
added a commit
to b-zee/rust-libp2p
that referenced
this issue
Jul 6, 2023
The `NewExternalAddrCandidate` event is yielded both before and after address translation. This will cause, in the case of TCP, ephemeral ports to be added as candidate. In turn, that will cause protocols like AutoNAT to fail as these candidates are not actually reachable/external. We will now only yield the original candidate if translation did not apply. Fixes libp2p#4153
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
When nodes use the Identify behavior, their observed address gets reported. This seems to be added as a candidate for an external address.
When using AutoNAT, these observed addresses might be dialed by a server, resulting a failed
DialErrorreport.Expected behaviour
AutoNAT to succeed.
Actual behaviour
I have tried to reproduce this in an MVP. Our production code yielded this behavior in, say, about 5% of nodes. I do see that the nodes are asking for a probe-back on their ephemeral ports, but it seems the actual listening address is the first that is dial by the server and we get a successful report.
Code is here: https://github.com/b-zee/rust-libp2p/blob/28c4786d4ae05a30c40dde9113831fe3b63f98cf/examples/safe/src/main.rs
Debug Output
Look for
AutoNAT InboundProbeEvent: Request { probe_id: ProbeId(7), peer: PeerId("12D3KooWFAnNTegMwtQhqBejyx1xoMxDULvBKCZYeJrwP1oLr5Wb"), addresses: ["/ip4/127.0.0.1/tcp/10001/p2p/12D3KooWFAnNTegMwtQhqBejyx1xoMxDULvBKCZYeJrwP1oLr5Wb", "/ip4/127.0.0.1/tcp/45072/p2p/12D3KooWFAnNTegMwtQhqBejyx1xoMxDULvBKCZYeJrwP1oLr5Wb"] }This line contains multiple (ephemeral) addresses of the peer which are probed by AutoNAT.
Partial output from our production test:
Debug Output
Possible Solution
Either these addresses not be added at all as candidates, or some mechanism that puts the address without the ephemeral port first, so that results in a successful AutoNAT report?
Version
masterWould you like to work on fixing this bug?
Maybe.
The text was updated successfully, but these errors were encountered: