go-libp2p
go-libp2p copied to clipboard
fix: QUIC/Webtransport Transports now will prefer their owned listeners for dialing out
Fixes #2913
The issue is presented in https://github.com/libp2p/go-libp2p/issues/2913#issuecomment-2305818394.
The fix here introduces "associations" to refcountedTransports. a libp2p transport can associate itself with the transport used for listening, and then prefer to use that for dialing by passing itself as the association.
I think there's an issue here where we don't have any logic to pick the interface that can actually route the packet.
I've changed this PR completely. I think it's a little cleaner now. Minimal changes to the transports, and leveraging existing logic in the quicreuse package.
Another review please @sukunrt ?
@MarcoPolo I think this may have broken hole punching as it seems to prefer the port which the relay signaled on opposed to the higher available hole punch ports.
Notably removing this line resolves the issue where it tries to establish the hole punch from the origin port 443 even though that port is filtered out in the local and remote available addresses for the punch.
https://github.com/libp2p/go-libp2p/blob/0fde4dcb01d83117495f0c920c34c8f540467d4c/p2p/transport/webtransport/transport.go#L210
@ethan-gallant, can you please open an issue here and outline what your setup is? I don't want this to get lost. Thanks!