1691189 - Firefox not responding to mDNS request for WebRTC candidates

Status: UNCONFIRMED

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

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.

Comment 19

[Riccardo]

As a possible mitigation, would it be possible to send a broadcast mDNS response as soon as the .local candidate is generated, without actually starting the mDNS resolver? Most mDNS implementations have a cache to store the hostnames that have previously been resolved which we could take advantage of. And as far as I understand, the windows firewall prompt is only displayed when trying to listen to inbound connections.

Comment 20

[Byron Campen [:bwc]]

I think it should be possible in principle to send an unsolicited announcement, but I don't know if the library we use for mdns would support that. However, it is not totally clear whether this will help. Since the problem case happens when Firefox is the offerer, this announcement would occur when we set the local offer. The other end might not have set the offer yet, and might not even set it until gathering completes, and so will not be listening for unsolicited announcements like this. If we periodically send that announcement, maybe the answerer would see it?

It seems to me that services that aren't doing gUM, aren't using STUN/TURN servers, don't support trickle ICE, and require Firefox to be the offerer, should not be blocking offer/answer until its mDNS queries are responded to. It should complete offer/answer as soon as Firefox is done gathering. There's nothing in webrtc-pc or RFC 9429 about blocking completion of setRemoteDescription on DNS or mDNS lookups for remote candidates.

Comment 21

[Riccardo]

(In reply to Byron Campen [:bwc] from comment #20)

The other end might not have set the offer yet, and might not even set it until gathering completes, and so will not be listening for unsolicited announcements like this.

That's a fair point. However, I'm somewhat confident that's exactly what chromium does, at least on linux; in fact it doesn't even seem that chromium has a mDNS server to reply to queries and that the unsolicited announcement is the only mechanism it relies on.

If we periodically send that announcement, maybe the answerer would see it?

I believe that approach would work in all cases.

It seems to me that services that aren't doing gUM, aren't using STUN/TURN servers, don't support trickle ICE, and require Firefox to be the offerer, should not be blocking offer/answer until its mDNS queries are responded to. It should complete offer/answer as soon as Firefox is done gathering. There's nothing in webrtc-pc or RFC 9429 about blocking completion of setRemoteDescription on DNS or mDNS lookups for remote candidates.

I partially agree, and realistically, the cases where this could be an issue are very limited; the other peer should send its own local candidates to firefox anyway (unless I'm missing something) so it should still be possible to establish a local peer connection. However, when receiving a .local candidate I believe it's reasonable to assume that the hostname is already resolvable (like aiortc does).

Nevertheless, even if it's not a problem for successful connection establishment, I think that it's still an issue if we consider connection time, especially for implementations that block the completion of setRemoteDescription, since connection can't happen until mDNS queries are completed or fail.

Comment 22

[Byron Campen [:bwc]]

I partially agree, and realistically, the cases where this could be an issue are very limited; the other peer should send its own local candidates to firefox anyway (unless I'm missing something) so it should still be possible to establish a local peer connection. However, when receiving a .local candidate I believe it's reasonable to assume that the hostname is already resolvable (like aiortc does).

The reason that the other side's candidates aren't making it back to Firefox is because it hasn't started gathering; this does not start until the local description is set, which has to occur after the setRemoteDescription(offer) completes. This is another reason not to unnecessarily delay sRD. You want to start gathering candidates ASAP.

Given how much of a corner case this is, how unreasonable this corner case is, and how easy it is to implement reasonable behavior that does not cause this corner case (either by not blocking sRD on mDNS, or by switching offer/answer roles, or by using a STUN server), this is not going to be a super high priority for us.