<html><head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body><div>Hi,</div><div><br></div><div>Looking through the "webrtc" code that his shared between chrome and firefox, it seems they implement may different things, but my guess is that they may only select one "host" address based on the default route. Maybe we should add an option to do that for the normal use-case. They also seem to have hardcoded things to ignore some types of interfaces like VirtualBox ones:</div><div><a href="https://chromium.googlesource.com/external/webrtc/+/master/webrtc/rtc_base/network.cc#680">https://chromium.googlesource.com/external/webrtc/+/master/webrtc/rtc_base/network.cc#680</a></div><div><br></div><div><br></div><div>See also:</div><div><a href="https://chromium.googlesource.com/external/webrtc/+/master/webrtc/rtc_base/network.cc">https://chromium.googlesource.com/external/webrtc/+/master/webrtc/rtc_base/network.cc</a></div><div><a href="https://chromium.googlesource.com/external/webrtc/+/master/webrtc/p2p/base/stunport.cc">https://chromium.googlesource.com/external/webrtc/+/master/webrtc/p2p/base/stunport.cc</a></div><div><br></div><div>Olivier</div><div><br></div><div>On Tue, 2017-08-29 at 17:28 +0200, Juan Navarro wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
    Thanks for the pointer!<br>
    <br>
    it happened that I was just reading the commit logs when your email
    arrived, and reading the additions of commit b4abda09, where the
    compilation option "--with-ignored-network-interface-prefix" was
    introduced. I don't really understand how this change was able to
    improve my situation with the "docker0" interface, as I didn't know
    about this option until now (ie. I compiled the latest libnice
    without using this option, and it indeed fixed the situation with
    the docker0 interface).<br>
    <br>
    I've also read that the option
    "--with-ignored-network-interface-prefix" is provided mainly to
    allow the distribution maintainers to specify a network interface
    which they know is special in their distribution and as such should
    be ignored. I think that you're right and maybe it would make more
    sense if it was the _user_ of the library the one who could decide
    which network interfaces are idiosyncratic to their specific
    platform in use, and so a way to specify a list of interfaces to
    ignore at runtime would be more useful for her.<br>
    <br>
    I guess this problem must have also affected Chrome and Firefox at
    some point in their development; do you have any knowledge of this?
    As it seems that they work correctly for all cases, doesn't matter
    if there are any virtual interfaces in the system, they always
    choose the correct local candidates. Checking their solutions to
    this problem could clarify a lot, so I'd like to also study those.<br>
    <br>
    Regards,<br>
    Juan<br>
    <style type="text/css"> p, li { white-space: pre-wrap; }
</style><br>
    <br>
    <div class="moz-cite-prefix">On 29/08/17 16:50, Olivier Crête wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:1504018206.4195.29.camel@collabora.com" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
      <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 
gets selected.

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, 
0.1.14.

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?

Kind regards,
Juan


_______________________________________________
nice mailing list
<a href="mailto:nice@lists.freedesktop.org" moz-do-not-send="true">nice@lists.freedesktop.org</a>
<a href="https://lists.freedesktop.org/mailman/listinfo/nice" moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/nice</a>
</pre>
      </blockquote>
      <div><span>
          <pre>-- 
</pre>
          <div>Olivier Crête</div>
          <div><a href="mailto:olivier.crete@collabora.com" moz-do-not-send="true">olivier.crete@collabora.com</a></div>
          <div><br>
          </div>
        </span></div>
    </blockquote>
    <br>
  

</blockquote><div><span><pre>-- <br></pre><div>Olivier Crête</div><div><a href="mailto:olivier.crete@collabora.com">olivier.crete@collabora.com</a></div><div><br></div></span></div></body></html>