1270477 - Peerconnection fails to initialise with "Can't create RTCPeerConnections when the network is down"

Status: RESOLVED INCOMPLETE

(Core :: WebRTC: Networking, defect)

Description

[Eric Bunyan]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160425115534

Steps to reproduce:

Start firefox when wifi is connected and ethernet is not. Connected via ethernet and disabled wifi. Attempted to use webrtc (either app or apprtc).


Actual results:

The calls failed with:
InvalidStateError: "Can't create RTCPeerConnections when the network is down"



Expected results:

Peerconnection should have been created and the call proceeded to setup. The laptop was connected to the internet, the only change was one attaching the laptop to a dock with an ethernet connection which also disables wifi without restarting Firefox.

Comment 1

[Nils Ohlmeier [:drno]]

Which OS is this on?

I just tried it on Mac OSX and everything was working as expected (call got established via the Ethernet interface).

Comment 2

[Byron Campen [:bwc]]

Just to be clear, is this the sequence of steps?

1. Be connected on wifi.
2. Be connected on ethernet too.
3. Disconnect from wifi.

Or are steps 2 and 3 switched?

Comment 3

[Eric Bunyan]

I'm running Linux (Kubuntu 14.04). Trying to reproduce again it seems a little more complicated than originally appeared. Due to driver issues and sleep the wifi card had disconnected rather than just no longer be connected. I imagine this would also happen with usb or pure dock nics (as macs don't have docks my colleagues who have them plug in a wired NIC via a plug, so this will affect those). 

As a confirmation of steps:
1. Be connected via wifi when Firefox starts.
2. Connect ethernet cable.
3. Disconnect wifi NIC

I can't see why it would not also happen if wifi and ethernet were swapped which would allow mac reproduction with a ethernet dongle. If the ICE code did not change when the SDPARTA changes went in then it may also be possible to produce a similar issue with two NICs if one isn't routable but has an IP, which I don't think would resolve if the NIC was taken stopped after starting Firefox (my memory is hazy as this was with my previous machine when I had an extra NIC which I had to take out to make Firefox work with webrtc).

Comment 4

[Nils Ohlmeier [:drno]]

I can give this a try once more in the office with swapped Ethernet and WiFi on Mac, as it appears that the important part is to disconnect the initial interface somewhat abruptly.

But even if I'm able to replicate the problem this is not a WebRTC issue actually. Because the error gets thrown by JS code way before we instantiate a PeerConnection on the C++ side, let alone starting ICE:
https://dxr.mozilla.org/mozilla-central/source/dom/media/PeerConnection.js#399

So if at all then this is some on-/off-line detection problem.

Comment 5

[Nils Ohlmeier [:drno]]

So I just tried it again with Ethernet as the initial network and turned on Wifi, jacked out the Thunderbolt Ethernet connector and click "join" on appr.tc. Everything was fine.

Can you rule out that by the time you tried to a WebRTC server you had gotten an IP address on the Ethernet?
In case of our office network getting an IPv4 address can take several seconds for some reason. I could see that the IO Service would in such a case claim Firefox is offline, and then you would get the error message.

Comment 6

[Eric Bunyan]

I had been using the network for a few hours on the ethernet and was browsing to my test app, and then to the apprtc site when I encountered the problem. We are using IPv4 and our leases are long enough it would not have been any problem with a slow renew as the machine would had renewed when it came out of sleep and found the wired NIC connected. It also happened with a few tries on my test app, and then a short bit later on the apprtc site.

Comment 7

[Byron Campen [:bwc]]

Well, if you're getting that error while browsing, clearly something is messed up. Nils, does IT have any USB wireless adaptors laying around that you could try with your linux box? I could also order one, but it would be next week before I had it.

Comment 8

[Nils Ohlmeier [:drno]]

IT doesn't have any USB WiFi dongles. So go ahead and order one I would say.

Comment 9

[Nils Ohlmeier [:drno]]

Hi Eric,

are these by any chance the steps to reproduce:

1. Be connected via wifi when Firefox starts.
2. Join a new room on appr.tc
3. Connect ethernet cable.
4. Disconnect wifi NIC
5. Second person joins the room

If so, then I would argue that this is mostly a problem of appr.tc specifically, because they call createOffer() at the time the first party enters the room. And then this old offer with the ICE candidates gets invalidated if you switch networks before the second party joins the room.
The workaround is simply to create the offer only when the second party joins the room. Usually other WebRTC services have therefore turned the offerer/answerer rols around and the second party joining a call create the offer and the first party becomes the answerer.

I was still not able to reproduce this problem, as appr.tc simply logs an error message about the signaling channel (websocket connection) being broken when I switch networks.

That being said Chrome does actually realize that a new interface has come up when I plugin the Ethernet adapter and generates more ICE candidates for the new interface.
I don't think that we even have the capability to get notified if a new NIC appears.

Comment 10

[Nils Ohlmeier [:drno]]

For later reference: 
it looks like we could potentially add the feature of re-acting to network changes. The key words to search for in dxr/mxr are "NS_NETWORK_LINK_DATA_CHANGED" (C++ land) and/or "network-active-changed" (JS land).

Comment 11

[Eric Bunyan]

Sorry for the delay in replying, I was on holiday.

I wasn't in a room, or using webrtc at all when I connected to ethernet and lost the wifi nic, but Firefox was open the entire time. I'm not sure if I had used webrtc in Firefox when I was on wifi, but any window using it had been closed (others were still open, but none with webrtc in use). When I came across the error in our own app, I closed that window and went to apprtc.appspot.com and tested there, which also gave the same error.

Comment 12

[Nils Ohlmeier [:drno]]

As we are not able to reproduce this. Are you still able to reproduce this?

Comment 13

[Eric Bunyan]

I haven't been able to since, though I've noticed that an update at some point meant my wifi stopped getting disabled when connecting to the dock.

Comment 14

[Nils Ohlmeier [:drno]]

In that case I think we should close this. If anyone should encounter this problem again feel free to re-open this ticket so that we can investigate it.