1691189 - Firefox not responding to mDNS request for WebRTC candidates

Status: UNCONFIRMED

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

Description

[Jeremy Lainé]

User Agent: Mozilla/5.0 (Android 11; Mobile; rv:85.0) Gecko/85.0 Firefox/85.0

Steps to reproduce:

I recently added support for mDNS WebRTC candidates in aiortc [1]. While performing interop tests with Firefox I found the following scenario does not work:

• Firefox generates an offer (for example: only datachannel) containing only mDNS candidates
• aiortc receives the offer, calls setRemoteDescription and attempts to resolve the mDNS candidates by issuing an A question
• Firefox does not respond to the mDNS query, no matter how long I wait

After some trial and error, it would seem that Firefox only starts responding to mDNS queries after calling its own setRemoteDescription? The odd thing is that before that it already seems to be listening on port 5353, so what is going on?

[1] Https://github.com/aiortc/aiortc

Actual results:

Firefox did not respond to mDNS queries

Expected results:

Firefox should respond to mDNS queries for candidates as soon as it issues them

Comment 1

[Jeremy Lainé]

Note: I submitted this issue from my phone, but tests were performed against desktop Firefox on Linux

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Networking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Byron Campen [:bwc]]

Any ideas here?

Comment 4

[Dan Minor [:dminor]]

We should start responding to mDNS queries once StartIceChecks [1] is called. It looks like that is called from OnSetDescriptionSuccess [2] which is called for both SetLocalDescription and SetRemoteDescription provided they succeed, so I don't see offhand why we would need to wait for SetRemoteDescription, unless there was an error on SetLocalDescription. There are trace! statements in the mdns code itself [3] that might help track down what is going on, especially in combination with logs from the Gecko signaling code. Here are some instructions on enabling the Rust logging [4]. Wireshark traces might also be useful.

[1] https://searchfox.org/mozilla-central/rev/d537e47349944c0fbd0100bd52c30e493e748c2e/dom/media/webrtc/jsapi/PeerConnectionMedia.cpp#329
[2] https://searchfox.org/mozilla-central/rev/d537e47349944c0fbd0100bd52c30e493e748c2e/dom/media/webrtc/jsapi/PeerConnectionImpl.cpp#2151
[3] https://searchfox.org/mozilla-central/rev/d537e47349944c0fbd0100bd52c30e493e748c2e/dom/media/webrtc/transport/mdns_service/src/lib.rs#224
[4] https://firefox-source-docs.mozilla.org/testing-rust-code/index.html#logging-from-rust-code

Comment 5

[Jeremy Lainé]

Do I need to build a debug version of Firefox to enable traces?

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Thanks Jeremy for reporting,

(In reply to Jeremy Lainé from comment #0)

• Firefox generates an offer (for example: only datachannel) containing only mDNS candidates
• aiortc receives the offer, calls setRemoteDescription and attempts to resolve the mDNS candidates by issuing an A question

Has SLD been called on the Firefox side at this point?

• Firefox does not respond to the mDNS query, no matter how long I wait

When you say you wait, are you waiting before returning the answer? If you return the answer, does it still not respond?

This may still be a bug, but I'm triaging, so I'm trying to understand how much of an issue is this in practice.

Comment 7

[Jeremy Lainé]

To your first question: yes, setLocalDescription has been called. The sequence of events on the browser side is:

• createOffer
• setLocalDescription
• wait for ICE gathering to complete
• send offer to the remote party
• wait for answer
• apply answer using setRemoteDescription

The behaviour can easily be reproduced by using the "webcam" example provided with aiortc:

https://github.com/aiortc/aiortc/tree/main/examples/webcam

As for your second question: aiortc's implementation of setRemoteDescription performs mDNS lookups before returning, so when I say I'm "waiting for mDNS resolution to complete", this is indeed before the answer is sent back to Firefox. Eventually the mDNS lookup times out, leaving aiortc with no remote candidates. It returns an answer to Firefox with no candidates due to pruning. After this, Firefox is willing to reply to mDNS, but it's too late.

Comment 8

[Michael Froman [:mjf]]

(In reply to Jeremy Lainé from comment #5)

Do I need to build a debug version of Firefox to enable traces?

You do need a debug build, but you should not have to build it yourself (unless you'd prefer that). This is a link for a debug linux build:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/cF0VeK4KR3OIUb8JMF6USg/runs/0/artifacts/public/build/target.tar.bz2

Comment 9

[Jeremy Lainé]

Attachment: firefox_mdns.txt

Attached is a log illustrating the issue. If you look at the timestamps, you can see that the mDNS registration occurs only after setRemoteDescription has been called, by which time it's too late.

Comment 10

[Jeremy Lainé]

I had a closer look at PeerConnectionImpl::OnSetDescriptionSuccess and in fact it won't call StartIceChecks() until the signal state is stable, i.e. after the offer/answer is done:

https://searchfox.org/mozilla-central/rev/c24ecdc6f5025ea7e60d0691673de030bd5bf411/dom/media/webrtc/jsapi/PeerConnectionImpl.cpp#2282

This would explain why no mDNS registration occurs until SetRemoteDescription is called!

Comment 11

[Dan Minor [:dminor]]

Responding to mDNS queries was moved to StartIceChecks() to fix Bug 1605815, where users were getting Windows Firewall checks on sites completely unrelated to WebRTC because of browser fingerprinting. I wanted to delay starting the mDNS service until we were reasonably certain the user intended to use WebRTC.

Comment 12

[Byron Campen [:bwc]]

If we want to delay the startup of mDNS until offer/answer concludes, we should also delay the gathering of mDNS candidates until then. This could break services that do not support trickle ICE, and do not call gUM, and make the browser the offerer. Maybe that's fine.

Comment 13

[Jeremy Lainé]

My error case is precisely with an implementation which does not support trickle ICE :)

Comment 14

[jeffwhelpley]

I am having this exactly same issue with Firefox using jssip to connect to a Drachtio SIP server.

As Jeremy reported works fine in Chromium, but issue with mdns in Firefox.

Comment 16

[sk4m1987]

Hi, is there any update in this issue, i am also facing the same, the ice candidates are getting generated with mDNS name(.local)

Comment 17

[chronos1970]

I am also facing this issue on Windows. However, for some reason, it works just fine on the Android version (Firefox v122.1.0). Can someone please take another look at this?

Comment 18

[Byron Campen [:bwc]]

The holdup here is not exactly engineering related; we probably do not want to start mDNS resolution up earlier, because of bug 1605815. It would be pretty bad if most of our windows users got firewall prompts just because they visited a site that is trying to use webrtc for fingerprinting. We could delay the gathering of those candidates until we're ready to start responding to mDNS, which would improve things from a Principle of Least Astonishment standpoint, but I doubt it would help any of these services actually work better. If you aren't doing gUM, aren't using STUN/TURN servers, don't support trickle ICE, aren't willing to use a double-negotiation (the first one to kick off the mDNS, the second to actually do candidate exchange), and require Firefox to be the offerer, this is just not going to work.