1659672 - WebRTC ICE gathering fails in completely pure LAN environment

Status: UNCONFIRMED

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

Description

[lexugeyky]

Attachment: about:webrtc report.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

WebRTC doesn't work under completely LAN environment (without outer Internet access).
Sorry, but I am not specialized in WebRTC or related field but instead a normal Linux user. So if I am wrong, please point out.
I hosted a local snapdrop server (https://github.com/RobinLinus/snapdrop) that functions totally.
However, if I cut the Internet access on router when I am testing to transfer file across devices, it fails ONLY on Firefox (chrome works fine, and so does Safari).
More specifically, the console of the webpage says "WebRTC ICE Gathering failed, add a TURN Server and see about:webrtc".

Related source code in snapdrop:
https://github.com/RobinLinus/snapdrop/blob/308aabac3243559706f20e4d129908da87c2ed1c/client/scripts/network.js

Actual results:

As said above, the console of the webpage says "WebRTC ICE Gathering failed, add a TURN Server and see about:webrtc".

Peers (devices) can see each other, but they cannot transfer files. Also, the webpage said "You are offline".

Expected results:

There should be no "You are offline" prompt and no ICE Gathering failed error just as what Chrome did.

I suspect it is an implementation defect concerning pure LAN environment. Not sure if I am right.

Comment 1

[Byron Campen [:bwc]]

This is probably because you're connecting to your webserver via loopback, and you're in mode 2 because snapdrop does not request mic/camera permissions (see https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-12#section-5.2 and https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-12#section-6.2). Firefox does not allow loopback addresses to be gathered as ICE candidates by default (although you can change this using the "media.peerconnection.ice.loopback" pref in about:config).

Try reaching the webserver on your machine's "real" IP address, and see if that helps.

Comment 2

[lexugeyky]

Attachment: ICE gathering failure persists with option enabled and access from "real" IP address.

Comment 3

[lexugeyky]

Attachment: Chrome made file transfer without issue.

Comment 4

[lexugeyky]

Attachment: New errors coming out with option enabled and access from "real" IP.

Comment 5

[lexugeyky]

Thanks for your assistance!
I tested firstly with the "real" IP address, which is 192.168.12.1. However, ICE gathering issue persists.
I then enabled the loopback option, trying again with "real" IP. Even though ICE gathering seemed to be disappeared first, there were new errors coming out like Cannot set remote answer in state stable and cannot set local offer when createOffer has not been called.

Another observation: under Internet access, even though I can transfer file without issue, there are also ICE Gathering failure in console output (firefox only).

Thanks for your patience and support.

Comment 6

[lexugeyky]

Just for curious, is it possible that this issue could be certification related? (the local webpage is insecure, not under https protocol).

Comment 7

[Byron Campen [:bwc]]

Can I see about:webrtc for these new cases?

Comment 8

[Byron Campen [:bwc]]

I do not think using http should matter in cases where there is no camera or mic access.

Comment 9

[lexugeyky]

Attachment: about:webrtc report regarding NEW CASE

Comment 10

[lexugeyky]

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

Can I see about:webrtc for these new cases?

Sure, I have uploaded the new debug page for the case where "real" IP is being used and option enabled.

Comment 11

[Byron Campen [:bwc]]

So comment 9 looks like it might be a case where mDNS lookups aren't working for some reason.

Could you try this on Nightly, and post about:webrtc? about:webrtc has gotten a lot more detailed lately.

Comment 12

[lexugeyky]

Attachment: Nightly about:webrtc 127.0.0.1 page

This about:webrtc page is gathered under Firefox nightly build with option media.peerconnection.ice.loopback enabled on local loopback page (127.0.0.1)

Comment 13

[lexugeyky]

Attachment: Nightly about:webrtc 192.168.12.1 page

This about:webrtc page is gathered under Firefox nightly build with option media.peerconnection.ice.loopback enabled on "real" IP address (192.168.12.1)

Comment 14

[Byron Campen [:bwc]]

I see that there's a STUN server provided, but it is unreachable for some reason. That hints that a firewall is getting in the way here somehow, although that does not appear to be what is causing this to fail.

For the case in comment 12, it does seem that our interface gathering code is not coping with a localhost address, even though the pref is set to enable their use. What platform are you on?

For the case in comment 13, I see ICE gathering, then succeeding, so a connection is established. Then, about 4.4 seconds after the first negotiation, JS gets into a tight loop creating and setting a local description over and over (1023 times over about 0.8 seconds). That indicates to me that there's a bug in the snapdrop code, which is probably why this case is not working.

Comment 15

[lexugeyky]

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

I see that there's a STUN server provided, but it is unreachable for some reason. That hints that a firewall is getting in the way here somehow, although that does not appear to be what is causing this to fail.

For the case in comment 12, it does seem that our interface gathering code is not coping with a localhost address, even though the pref is set to enable their use. What platform are you on?

For the case in comment 13, I see ICE gathering, then succeeding, so a connection is established. Then, about 4.4 seconds after the first negotiation, JS gets into a tight loop creating and setting a local description over and over (1023 times over about 0.8 seconds). That indicates to me that there's a bug in the snapdrop code, which is probably why this case is not working.

I am on Linux 5.7.16 (nixos-unstable).

Hmmmm, if it is a bug in snapshot, then why would it work in the case of Chromium...but thanks for your explanation.

Comment 16

[lexugeyky]

s/snapshot/snapdrop/

Comment 17

[lexugeyky]

The reason that STUN server is unreachable might be these cases were all not connected to the outer Internet. Also, it seems like for both cases (comment 12 and 13), they complained about failed to find default addresses. Is that related?

Thanks for your support.

Comment 18

[Byron Campen [:bwc]]

(In reply to lexugeyky from comment #15)

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

I see that there's a STUN server provided, but it is unreachable for some reason. That hints that a firewall is getting in the way here somehow, although that does not appear to be what is causing this to fail.

For the case in comment 12, it does seem that our interface gathering code is not coping with a localhost address, even though the pref is set to enable their use. What platform are you on?

For the case in comment 13, I see ICE gathering, then succeeding, so a connection is established. Then, about 4.4 seconds after the first negotiation, JS gets into a tight loop creating and setting a local description over and over (1023 times over about 0.8 seconds). That indicates to me that there's a bug in the snapdrop code, which is probably why this case is not working.

I am on Linux 5.7.16 (nixos-unstable).

Hmmmm, if it is a bug in snapshot, then why would it work in the case of Chromium...but thanks for your explanation.

There is lots of code out there that works on Chrome but not Firefox because the author never tested on Firefox. Sometimes the difference is due to subtle differences in timing between Firefox and Chrome, or sometimes due to Chrome and Firefox implementing the standards in differing degrees of fidelity (sometimes subtle, sometimes not-so-subtle).

Comment 19

[Byron Campen [:bwc]]

(In reply to lexugeyky from comment #17)

The reason that STUN server is unreachable might be these cases were all not connected to the outer Internet. Also, it seems like for both cases (comment 12 and 13), they complained about failed to find default addresses. Is that related?

Thanks for your support.

I only see "failed to find default addresses" in cases where 127.0.0.1 is involved; keep in mind that the logging on that page is for all PeerConnections combined, so earlier attempts (using 127.0.0.1) are going to show up there unless you restart the browser (or, bug 1626278 happens).

Comment 20

[Byron Campen [:bwc]]

This appears to be primarily a problem with localhost interface gathering, and some additional unrelated webcompat problem with snapdrop.