[libnice] Issues with candidate selection through wrong network interface

[Fabrice Bellet]

Hi Juan,

On 08/29/17 at 04:19pm, Juan Navarro wrote:
> Now here comes the problem: I have some other machines where there is no
> docker0, but there are some other kind of virtual interfaces, such as br-*
> (eg. a machine with 8 interfaces named like "br-1adb6aca2ec6", which are
> bridged interfaces if I'm not mistaken). In those cases, the latest libnice
> still behaves like the previous versions: one of those br-* interfaces gets
> selected as local candidate, which makes the following streams to fail
> reaching its destination. This even happens for localhost connections!
> (where the Chrome browser and the libnice application are running in the
> same machine). However bringing all of the virtual interfaces down -with
> ifconfig- makes it work (leaving only the actual network interface which has
> a more direct connection to the app).

I guess that each br-xxxx interface _is_ a bridge, with its own ip
address? I ask this precision, because libnice gathers ip addresses, and
not network interfaces. 

What may happen here could be that these 8 bridges cause an unusual high
number of local candidates to be created (one distinct ip address with
each bridge, one ip adress for the real network interface, one ip for
the turn relayed candidate, maybe more if the host is behind a nat for
its Internet access).

This multiplicity of candidates will have an impact on the ICE
algorithm, because it contributes to the number of candidates pairs to
be tested, and indirectly to the definition of some timeout values used
when testing each pair. The consequence is that the number of local ip
addresses on one peer can influence exponentially the time it takes for
the connection check algorithm to move from state CONNECTED to state
READY, on both peers. However, if it should have a minimal impact on the
time to reach state CONNECTED, which is the important state there,
because the media can start flowing from this state. And more important,
it should not change the result of the connection check itself.

This is the idea with this option
"ignored-network-interface-prefix" to deliberately discard some
interfaces that are known to not contribute to useful local candidates,
to make the connection algorithm complete faster. 

> I would like to gain a deeper knowledge of how all this works in libnice,
> and how should I act in order to solve this problem. I guess there must be
> lots of people out there running into the same issue, just by having Docker
> installed, or any other software which creates virtual network interfaces.
> So, how do you deal with this issue?

It would be interesting to have a debugging log of both peers with this
environnement variable set:

G_MESSAGES_DEBUG=libnice,libnice-stun,libnice-verbose

Best wishes,
-- 
fabrice