<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Hi,</div><div><br></div><div>We've seen the same thing with the libvirtd interface from KVM. And I spend some time looking into this and I know Fabrice also did and we couldn't find a great solution, so in commit b4abda09 he just added an option to ignore one specific prefix. But maybe we should extend that to a blacklist of prefixes (so we can ignore docker*, virbr*, br*. We currently explicitly ignore localhost in the code, maybe we should ignore more. I'm just worried that in some cases those may be legitimate interfaces and may actually be the right choice. For example if the peer is running inside docker!</div><div><br></div><div>Olivier</div><div><br></div><div>On Tue, 2017-08-29 at 16:19 +0200, Juan Navarro wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><pre>Good afternoon,
I have been studying a situation where libnice chooses the wrong network
interface for WebRTC connections in a public-facing server: an Amazon
Web Services instance, where all TCP and UDP ports are totally open,
hosting a WebRTC application. This machine also has Docker installed for
other unrelated purposes. This means that there are two network
interfaces: eth0 and docker0, and when ICE finishes, libnice always
selects the IP address of the docker0 interface as the local candidate!
A TURN server (coturn) is used for ICE. I guess that the STUN packets
are able to come out through the docker0 interface, during the
connectivity checks, which makes this a valid candidate; however later
the actual WebRTC stream doesn't work at all. And it is my understanding
that even if it worked, it would still be an error, because outbound
streams would be doing a totally unnecessary loop from the local
application to the docker0 interface, and out of Docker to the public
internet. Likewise for inbound streams.
Running "sudo ifconfig docker0 down" solves the issue: docker0 had been
brought down, so now libnice chooses the correct interface, eth0 (ie.
the local IP address of that interface) for the local candidate which
This happens with the latest libnice version available on Ubuntu 16.04
(Xenial): 0.1.13. It also happens with the latest release of libnice,
However, this does _not_ happen with the latest development version from
Git, which is commit dbaf8f5: libnice now chooses the IP address
corresponding to the interface eth0, and the WebRTC connections work
fine (the RTP streams are sent and received), even if a docker0
interface is present.
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 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?
nice mailing list
</pre></blockquote><div><span><pre>-- <br></pre><div>Olivier Crête</div><div><a href="mailto:email@example.com">firstname.lastname@example.org</a></div><div><br></div></span></div></body></html>