1698141 - mDNS ICE candidates breaks WebRTC-P2P connection between two computers on same private LAN

Status: NEW

(Core :: WebRTC: Networking, defect, P2)

Description

[jazzmatazz]

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:

1. Open http://demo.monaserver.ovh/tests/p2pConnection.html on Firefox on computer A and click on button "test"
2. 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

[BugBot [:suhaib / :marco/ :calixte]]

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

[Michael Froman [:mjf]]

A few interesting data points (all tested between 2 separate computers):

1. 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).
2. It works when "test" button is pressed on Chrome (Win10) first to Firefox(Mac).
3. It works for Firefox(Mac) to Firefox(Mac).
4. It works in either direction Firefox(Mac) to Chrome(Mac).

Dan, any thoughts on where to look first?

Comment 3

[jazzmatazz]

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

[Dan Minor [:dminor]]

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

[Michael Froman [:mjf]]

For my reference, https://bugzilla.mozilla.org/show_bug.cgi?id=1691189#c4 has instructions on rust logging, etc.

Comment 6

[Michael Froman [:mjf]]

NI myself to look back at this.

Comment 7

[Michael Froman [:mjf]]

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.

Comment 8

[jazzmatazz]

Any news about this issue? (It looks that I can aways reproduce it)

Comment 9

[Michael Froman [:mjf]]

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?

Comment 10

[Byron Campen [:bwc]]

I'm pretty swamped at the moment.