1185197 - ice.tcp is breaking ICE if multi-process (e10s) is on

Status: RESOLVED FIXED

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

Description

[AjayG]

Attachment: aboutWebrtc.html

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.134 Safari/537.36

Steps to reproduce:

Enabled media.peerconnection.ice.tcp in 41.0a2 (2015-07-17) (Firefox Developer Edition).
Peer connection is not generating any candidates.


Actual results:

Failed to parse Remote TCP candidates,
No candidates are generated


Expected results:

Firefox should generate both UDP & TCP candidates,
Ice check should complete with either UDP or TCP.
By default UDP should be high priority, if UDP is not reachable then only it should fallback to TCP

Comment 1

[Nils Ohlmeier [:drno]]

I failed to reproduce the problem with 41 and 42 on my Mac.
Today I also tried 41 on Linux like in this report with the provided test URL, but it just works fine for me.

The error message in the attached log "Error parsing attribute: candidate:2 1 tcp 1019216383 192.168.1.93 0 typ host tcptype active" just indicates that parsing failed, because of the 0 port number in that candidate. This candidate is suppose to use port 9 instead of zero. But as we would ignore a candidate with port 9 the end result is the same in this case. So this is not the root cause of the problem.

From looking at the provided log file it looks like gathering never started or failed.

AjayG could you please re-run the test with the ICE debug logs turned on?
You need to set the environment variables like described here: https://wiki.mozilla.org/Media/WebRTC/Logging#ICE.2FSTUN.2FTURN
Please set the R_LOG_LEVEL to 9 to capture everything. Note: you need to capture stdout into a file, as that is the information I'm looking for.

Comment 2

[AjayG]

@Nils, still issue is reproducing for me in FF-41.0a2 (2015-07-21) on CentOS-6.6 .

Startup command in bash:
R_LOG_DESTINATION=stderr R_LOG_LEVEL=4 R_LOG_VERBOSE=1 ./firefox -profilemanager -no-remote

Please check below Logs:

(ice/WARNING) ICE(PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html)): No STUN servers specified
(ice/NOTICE) ICE(PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html)): No TURN servers specified
(ice/WARNING) ICE(PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html)): Error parsing attribute: candidate:2 1 tcp 1019216383 192.168.1.93 0 typ host tcptype active
(ice/WARNING) ICE(PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html)): peer (PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html):default) specified bogus candidate
(ice/WARNING) ICE(PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html)): Error parsing attribute: candidate:5 1 tcp 1019216383 202.65.134.117 0 typ host tcptype active
(ice/WARNING) ICE(PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html)): peer (PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html):default) specified bogus candidate
(ice/NOTICE) ICE(PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html)): peer (PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html):default) no streams with non-empty check lists
(ice/NOTICE) ICE(PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html)): peer (PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html):default) no streams with pre-answer requests
(ice/NOTICE) ICE(PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html)): peer (PC:1437495313663606 (id=2147483653 url=https://mydomain.com/screenshare/screensharingtest.html):default) no checks to start

Please find full webrtc-internals at https://www.dropbox.com/s/ketcf81r3d9w6zo/aboutWebrtc2.html?dl=0

Comment 3

[Nils Ohlmeier [:drno]]

I tried reproducing this now in a VM with CentOS-6.6, but no luck. I'm guessing this must be something in your setup/environment.

Unfortunately the log you provide still gives no clues of what could be going wrong here. Could I ask you to re-run it like this:

R_LOG_DESTINATION=stderr R_LOG_LEVEL=9 R_LOG_VERBOSE=1 ./firefox -profilemanager -no-remote 2>&1 | tee ice.log

Basically this runs with the highest ICE logging level we have. Unfortunately the logging goes to stdout/stderr and does not show up on the about:webrtc page. So that's why the command above redirect that into the 'tee' command which writes it into the file 'ice.log'. Feel free to name the file differently. You can also use '>' instead of the 'tee' command if you prefer that.

The file is probably going to be big. Feel free to compress it. And you can send it to me via email if you prefer the privacy, or attach it here (putting it into Dropbox like you did before works as well).

Comment 4

[AjayG]

@Nils, Now i started the Firefox with below command,
R_LOG_DESTINATION=stderr R_LOG_LEVEL=9 R_LOG_VERBOSE=1 ./firefox -profilemanager -no-remote 2>&1 | tee ice.log

Attached ice.log at https://www.dropbox.com/s/0zofibq7vedn2y3/ice.log?dl=0
Attached new webrtc-internals at https://www.dropbox.com/s/x3kxx7eie8qwyj1/aboutWebrtc3.html?dl=0

Comment 5

[Nils Ohlmeier [:drno]]

Thank you that log file finally gave me the needed clue. I think I'm able to reproduce your problem now. Did you by any chance enabled the "Enable multi-process Firefox Developer Edition" (that is an option on the "General" tab of your Preferences)?
If so, please turn it off for ICE TCP testing. That should hopefully "fix it" for now.

Comment 6

[Byron Campen [:bwc]]

Are we gathering UDP candidates, though?

Comment 7

[Nils Ohlmeier [:drno]]

(In reply to Byron Campen [:bwc] from comment #6)
> Are we gathering UDP candidates, though?

Yes we do. And that raises the interesting question: should we fail gathering in case one socket or interface did not worked/failed?
I'm leaning towards: we should ignore all failures during gathering as long as we gather at least one candidate.

Comment 8

[Byron Campen [:bwc]]

The logging in comment 4 seems to indicate that we gathered a UDP candidate, but that for some reason it was never used?

Comment 9

[AjayG]

(In reply to Nils Ohlmeier [:drno] from comment #5)
> Thank you that log file finally gave me the needed clue. I think I'm able to
> reproduce your problem now. Did you by any chance enabled the "Enable
> multi-process Firefox Developer Edition" (that is an option on the "General"
> tab of your Preferences)?
> If so, please turn it off for ICE TCP testing. That should hopefully "fix
> it" for now.

@Nils, if i disabled multi-process mode it is working fine
So issue is not with the Platform, now i was able to reproduce on windows as well :)

Comment 10

[Nils Ohlmeier [:drno]]

Thanks for the feedback.

Most likely we will fix this shortly via bug 1187472.

Comment 11

[Nils Ohlmeier [:drno]]

Just manually verified in 42.0a1 (2015-08-03) that the problem is successfully fixed via bug 1187472.

As this problem is only exposed by the user actively changing a pref, and e10s is only available in Nightly and DevEdition, I'm calling this fixed (although it is technically only fixed in 42).