[libnice] Issues with candidate selection through wrong network interface
Olivier Crête
olivier.crete at collabora.com
Tue Aug 29 15:45:59 UTC 2017
Hi,
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:https://chromium.googlesource.com/exter
nal/webrtc/+/master/webrtc/rtc_base/network.cc#680
See also:https://chromium.googlesource.com/external/webrtc/+/master/web
rtc/rtc_base/network.cchttps://chromium.googlesource.com/external/webrt
c/+/master/webrtc/p2p/base/stunport.cc
Olivier
On Tue, 2017-08-29 at 17:28 +0200, Juan Navarro wrote:
> Thanks for the pointer!
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> Regards,
>
> Juan
>
> p, li { white-space: pre-wrap; }
>
>
>
>
> On 29/08/17 16:50, Olivier Crête wrote:
>
>
>
> > Hi,
> >
> >
> >
> > 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!
> >
> >
> >
> > Olivier
> >
> >
> >
> > On Tue, 2017-08-29 at 16:19 +0200, Juan Navarro wrote:
> >
> > > 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
> > > nice at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/nice
> > >
> > >
> >
> >
> > --
> >
> > Olivier Crête
> > olivier.crete at collabora.com
> >
> >
> >
> >
> >
>
>
>
>
>
--
Olivier Crête
olivier.crete at collabora.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nice/attachments/20170829/4c80526f/attachment.html>
More information about the nice
mailing list