webrtc: correctly report incoming packet address on muxed connection #2586
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The address in ReadFrom should be the address of the received packet and not the address of the first packet received from the peer. If the interface used to send the first packet disallows incoming packets, this will lead to a connection not being established.
The simplest way to test this is to use tailscale. Packets originated from tailscale address can be sent to localhost addresses, packets from localhost can't be sent to tailscale listeners. So if the first packet from the dialer is from the tailscale interface, the connection will never be established because muxedConnection.ReadFrom will always return the address of the packet as the tailscale address and we will ignore all reachable localhost packets.
My theory is that this is what is causing flakiness like the one observed here: https://github.com/libp2p/go-libp2p/actions/runs/6312484104/job/17138640142?pr=2584
The difference being the interface is a docker interface on the machine.
The change is inline with the pion provided udp_mux implementation: https://github.com/pion/ice/blob/master/udp_muxed_conn.go#L140. They maintain a list of addresses on the connection, we keep this list on the udpmux.
Also fixes: #2536