[libnice] TCP Passive Ice Candidate Connectivity Issue

[James Huang]

Hi all,

I'm trying to get an openwebrtc iphone-to-iphone stream working, and it
uses libnice as the underlying connectivity manager. It's running on the
1.13 release, but there have been about 14+ months of bug fixes to the
master branch so I've updated to the latest version.

I'm getting the following messages when I try to establish a connection.

ICE failed to establish a connection!
> ICE state changed from connecting to failed


This is a dump of my logs with NICE_DEBUG turned on.
http://pastebin.com/vQtmk4hX

An example below:

With the following ICE candidates
> -----------------------offer sdp-----------------------
> a=candidate:1 1 UDP 2013266431 192.168.1.27 53302 typ host
> a=candidate:2 1 TCP 1019216639 192.168.1.27 0 typ host tcptype active
> a=candidate:3 1 TCP 1015022335 192.168.1.27 55855 typ host tcptype passive
> -----------------------answer sdp-----------------------
> a=candidate:1 1 UDP 2013266431 192.168.1.245 65305 typ host
> a=candidate:2 1 TCP 1019216383 192.168.1.245 0 typ host tcptype active
> a=candidate:3 1 TCP 1015022079 192.168.1.245 52295 typ host tcptype passive



I'm getting a TCP handshake over the tcp-passive port 55855/52295, which
triggers some code in agent.c:

> /* Passive candidates when readable should accept and create a new
>          * socket. When established, the connchecks will create a peer
> reflexive
>          * candidate for it */
> new_socket = nice_tcp_passive_socket_accept (nicesock);


But that seems to be out-of-band data or something according to the return
value?

But it seems like a new connectivity check never happens and the pair times
out. I also don't fully understand what the comment means.

When I run the linux-linux version it appears
conncheck.c conn_check_handle_inbound_stun->priv_reply_to_conn_check()
gets called, and everything works fine but on the iphone it does not.

I've removed STUN and TURN servers and have been running 2 phones off of
the same wifi just to simplify the connection paths, but I've also tried
adding in STUN servers.

This pull request problem (https://github.com/libnice/libnice/pull/6) seems
suspiciously like my issue except that particular code path never executes
for me. I've added it in anyways just to be safe.

Oh, the other thing that I've seen is the only call
to nice_tcp_active_socket_connect is to seemingly garbage src/dst ip:port
numbers like:

> [<unknown>]:903479824 -> [(null)]:1336121346

it's unclear to me right now when/where they turn into garbage .

Anyways, I'm a little lost and not sure what to investigate. But I'm happy
to add extra logging to figure this thing out. Any advice would be
appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nice/attachments/20160621/699149b3/attachment.html>