Skip to content

ICE negotiation failure for localhost nodes having multiple network interfaces #662

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mangolas opened this issue Mar 27, 2025 · 0 comments

Comments

@mangolas
Copy link

Libp2p tries to update webrtc transport to latest webrtc-rs, but it's smoke test is failing: libp2p/rust-libp2p#5448

Smoke test starts two localhost peers and just tests that they discover each other and starts a connection. After digging into it (as it was initially always the Github runner that failed the smoke test, and locally it passed) it has boiled down to this: if there are more than one networks locally available, ICE negotiation fails randomly.

Before this change 182406d smoke test worked.

When ICE gathering starts and it collects all the local candidates, the ICE agent then starts receive loops for STUN messages per candidate. So in the case of smoke test with two local ipv4 interfaces, there are two receivers on same port on 127.0.0.1 listening and it seems that when by chance the correct receiver can get STUN message with expected candidate, and connection can proceed.

Any idea what would be a correct way to remedy this. It's always the controlled side of ICE agent that get's stuck, it receives the nomination from controlling side, and the sends ping to verify the nominated candidate, but depending on which receive loop the response comes back, it either fails or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant