mDNS ICE candidates breaks WebRTC-P2P connection between two computers on same private LAN
Categories
(Core :: WebRTC: Networking, defect, P2)
Tracking
()
People
(Reporter: mathieu.poux, Unassigned)
References
(Blocks 1 open bug)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36
Steps to reproduce:
- Open http://demo.monaserver.ovh/tests/p2pConnection.html on Firefox on computer A and click on button "test"
- Open http://demo.monaserver.ovh/tests/p2pConnection.html on Chrome on computer B and click on button "test"
Actual results:
The P2P connection fails. To do working it again you have to disable "media.peerconnection.ice.obfuscate_host_addresses" in about:config.
Expected results:
The P2P connection should works as it's the case without "media.peerconnection.ice.obfuscate_host_addresses" enabled.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::WebRTC' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•4 years ago
|
||
A few interesting data points (all tested between 2 separate computers):
- I can confirm this fails for Firefox (Mac either v86 or v88) to Chrome (Win10) when "test" button is pressed on Firefox first (eventually shows Error: 408 on Chrome).
- It works when "test" button is pressed on Chrome (Win10) first to Firefox(Mac).
- It works for Firefox(Mac) to Firefox(Mac).
- It works in either direction Firefox(Mac) to Chrome(Mac).
Dan, any thoughts on where to look first?
Reporter | ||
Comment 3•4 years ago
|
||
Yes, it's exactly that! It happens when Firefox button is pressed in first, and not in the others browser combination as you can see. The problem disappears completely if you disable mDNS in Firefox (obfuscate_host_addresses=false), so I think that it's a problem with STUN address resolution between Firefox and Chrome: https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-04.
I can't say anything more unfortunately.
Comment 4•4 years ago
|
||
I'd have a look at wireshark captures for mDNS traffic first and/or try a debug build of Firefox with Rust logging enabled to see what is happening with the mDNS responder. The fact that this is working when the "test" button is pressed first in the other browser makes me think of Bug 1691189.
Comment 5•4 years ago
|
||
For my reference, https://bugzilla.mozilla.org/show_bug.cgi?id=1691189#c4 has instructions on rust logging, etc.
Updated•4 years ago
|
Comment 7•3 years ago
•
|
||
I see lines like:
[2021-04-07T17:48:19Z WARN mdns_service] Could not parse mDNS packet: invalid characters encountered while reading label
It looks like that message originates from here:
https://searchfox.org/mozilla-central/rev/be413c29deeb86be6cdac22445e0d0b035cb9e04/third_party/rust/dns-parser/src/name.rs#76
This doesn't seem to happen with each trial, so may be a false indicator.
Reporter | ||
Comment 8•3 years ago
|
||
Any news about this issue? (It looks that I can aways reproduce it)
Comment 9•3 years ago
|
||
Byron, any chance you'd have a moment to take a look at this since I won't have time until we've finished the libwebrtc uplift?
Description
•