1202452 - Internal socket error in UDPSocketParent.cpp:168, "peer specified too many components"

Status: RESOLVED INVALID

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

Description

[Jukka Jylänki]

Attachment: webrtc_connect_fail.txt

I am testing an application that performs WebRTC data channel communication for low latency games networking. The game is an Emscripten ported native game that has a native version of the game as well, in addition to the HTML5 JS page. The test is being conducted in a LAN environment (same wifi network).

Running two in-game clients in Firefox+Firefox works, as well as Chrome+Chrome clients (developer reports native app+Chrome works as well, but due to another issue I have not yet been able to completely verify). However, when running as a native app+Firefox, the connection is not established correctly, and I am seeing the following interesting log messages in about:webrtc:

(ice/ERR) ICE(PC:1441636610928000 (id=4294967501 url=http://localhost:8000/******.html)): duplicate priority 1686052863 candidate srflx(IP4:192.168.14.6:58248/UDP|asm.************.com:3478) and candidate srflx(IP4:192.168.14.6:58248/UDP|asm.************.com:3478)
(generic/ERR) UDP socket error:Internal error at c:/builds/moz2_slave/m-cen-w64-ntly-000000000000000/build/src/dom/network/UDPSocketParent.cpp:168
(ice/WARNING) ICE(PC:1441636610928000 (id=4294967501 url=http://localhost:8000/******.html)): couldn't create socket for address IP6:[2001:0:9d38:6ab8:853:1588:3f57:f1f9]:0/UDP
(ice/ERR) ICE(PC:1441636610928000 (id=4294967501 url=http://localhost:8000/******.html)): peer (PC:1441636610928000 (id=4294967501 url=http://localhost:8000/******.html):default) specified too many components
(ice/WARNING) ICE(PC:1441636610928000 (id=4294967501 url=http://localhost:8000/******.html)): peer (PC:1441636610928000 (id=4294967501 url=http://localhost:8000/******.html):default) specified bogus candidate

See the full log in attachment.

I am not yet at all sure which component in this whole architecture is in fault, but the log message "internal error" directly indicates some kind of bug in Firefox. How does the log look to WebRTC expert eyes?

Comment 1

[Eric Rescorla (:ekr)]

My initial reaction is that the internal_error is something else. However, let's try to simplify things: please disable e10s and retry.

Also, please provide the rest of the information from about:webrtc, including the SDP and the candidate pair list.

Comment 2

[Jukka Jylänki]

Attachment: webrtc_connect_fail_2.txt

Comment 3

[Jukka Jylänki]

Attached log with more info. How does that look? Also tried in a non-e10s window, but that did not make a difference.

Comment 4

[Eric Rescorla (:ekr)]

So, there's something immediately wrong here: the native app is generating the wrong number
of candidates. Here's the a=candidates lines you are generating:

a=candidate:0 1 UDP 2128609535 192.168.14.3 50381 typ host
a=candidate:0 2 UDP 2128609535 192.168.14.3 50381 typ host

The second integer (1 or 2) is the <component-id> but DataChannels only should be sending
one component. That's what's generating the error:

(ice/ERR) ICE(PC:1441644250178000 (id=2147483659 url=http://localhost:8000/******.html)): peer (PC:1441644250178000 (id=2147483659 url=http://localhost:8000/******.html):default) specified too many components

This shouldn't cause total failure, however, but it's concerning. It also looks like you are trying to do TURN but it's failing to actually get relayed candidates. Are you providing a TURN server? If so, please try to strip out the candidates from the native side (which appears to be offerer). That will let me see just the TURN transactions without interference from the STUN checks.

Comment 5

[Eric Rescorla (:ekr)]

Also, what code base is your native client based on?

Comment 6

[Maire Reavy [:mreavy]]

(In reply to Jukka Jylänki from comment #3)
> Attached log with more info. How does that look? Also tried in a non-e10s
> window, but that did not make a difference.

Jukka -- Do you have access to the app or source?  Is it easy for you to talk to the developers and get them to tweak it?  Perhaps even better: can you give Ekr access so he can try this directly?

Ekr -- I realize you're driving this today. I also know the f2f is later this week and you're busy.  And Jukka told me privately that he needs a fix for this ASAP;  so I may ask Byron to take this over from you tomorrow unless it's resolved or mostly resolved by end of today.  (I realize "resolution" may largely be explaining to the game devs what they need to change in the source.)  Thanks.

Comment 7

[Jukka Jylänki]

Thanks for the quick diagnosing Eric!

I don't have the sources to the server side components, only to the client html page. I'll let the developers know, and CC you into the communication with them, they should be able to provide us with the necessary details.

Comment 8

[Eric Rescorla (:ekr)]

(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #6)
> (In reply to Jukka Jylänki from comment #3)
> > Attached log with more info. How does that look? Also tried in a non-e10s
> > window, but that did not make a difference.
> 
> Jukka -- Do you have access to the app or source?  Is it easy for you to
> talk to the developers and get them to tweak it?  Perhaps even better: can
> you give Ekr access so he can try this directly?
> 
> Ekr -- I realize you're driving this today. I also know the f2f is later
> this week and you're busy.  And Jukka told me privately that he needs a fix
> for this ASAP;  so I may ask Byron to take this over from you tomorrow
> unless it's resolved or mostly resolved by end of today.  (I realize
> "resolution" may largely be explaining to the game devs what they need to
> change in the source.)  Thanks.

Thanks Maire,

This seems pretty straightforward now--we're basically waiting for feedback
from the developers. When I hear back from them, I'll loop in Byron as needed.

Comment 9

[Nils Ohlmeier [:drno]]

To answer your initial quesiton/concern: 

I think these two belong together:

(generic/ERR) UDP socket error:Internal error at c:/builds/moz2_slave/m-cen-w64-ntly-000000000000000/build/src/dom/network/UDPSocketParent.cpp:168
(ice/WARNING) ICE(PC:1441644250178000 (id=2147483659 url=http://localhost:8000/******.html)): couldn't create socket for address IP6:[2001:0:9d38:6ab8:853:1588:3f57:f1f9]:0/UDP

Basically it tells us that for whatever reason Firefox failed to create a IPv6 UDP socket. But that is totally benign as it only means no IPv6 candidate gets created, and from a quick glance it looks like our code simply continuous with the remaining interfaces/IP addresses.

Comment 10

[Nils Ohlmeier [:drno]]

To me that log looks like we never get any responses directly between Firefox and the native app on the 192.168.x.x network. And at the same time strange things are happening with the TURN relay.

An alternative to what Ekr recommended as a next step would be to remove the TURN relay from your setup, as I understand/assume that this should all work on the local LAN without any need for a relay, right?
If that assumption is correct and you want to debug first the communication between Firefox and the app without the relay I would recommend to:
1) fix/remove the additional ICE candidate from the native app
2) remove the TURN relay from the setup
3) increase the log level (https://wiki.mozilla.org/Media/WebRTC/Logging#ICE.2FSTUN.2FTURN) on the Firefox side and get us a copy of these logs

Comment 11

[Eric Rescorla (:ekr)]

The reporters privately sent me a log that suggested that ICE is working and DTLS is at least starting, so I think it's still confusing.

Comment 12

[Nils Ohlmeier [:drno]]

As far as I understand the email communication on this topic this issue has been resolved on the side of the native app.

If you disagree feel free to re-open.