Bug 1723770

Summary: considering building libnice with --with-ignored-network-interface-prefix=virbr
Product: [Fedora] Fedora Reporter: Fabrice Bellet <fabrice>
Component: libniceAssignee: Stefan Becker <chemobejk>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 30CC: bdpepple, brian.murrell, chemobejk, kdudka, philip, svashisht, uraeus
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libnice-0.1.16-5.fc30 libnice-0.1.16-5.fc29 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-07-07 00:57:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Fabrice Bellet 2019-06-25 11:13:08 UTC
I think it would be beneficial to build libnice with this option. The rationale is to exclude all interfaces created by libvirtd to contribute to the connection checking algorithm used by libnice to determine a pair of local and remote address:port that can communicate together.

The virbrX interfaces created by libvirtd in Fedora define a local private network, only reachable from the local host, to give access to virtual machines with network translation address. This particularity makes it safe to exclude these interfaces in libnice : if the remote peer is *not* inside the network provided by virbrX, the removal of this interface has no effect, and if the remote peer is inside (ie *is* a virtual machine), a valid pair can nevertheless be discovered using the real network interface of the local host. A problem would occur if the local host has a virbrX interface, but no other real interface, which would be quite an unusual case.

The benefit is that the number of pairs (local address:port,remote address:port) to be tested is significantly reduced, and the pair of choice returned to the application is established faster (various timers increases according to the number of pairs).

Comment 1 Kamil Dudka 2019-06-25 12:50:35 UTC
Thanks for the proposal!  It makes sense to me.  Stefan, what is your opinion on this?

Comment 2 Stefan Becker 2019-06-25 13:05:18 UTC
On first look it does make sense.

I've forwarded the question to the SIPE media developer for comment. Stay tuned...

Comment 3 Kamil Dudka 2019-06-25 13:19:20 UTC
Perfect.  Thank you for taking care of it!

Comment 4 Stefan Becker 2019-06-25 13:20:25 UTC
... and let's hope no Fedora user is running a Lynx/SfB test installation in a virtual machine :-)

BTW: what about Docker & Podman interfaces? I see "docker0", "vethXXX" & "br-XXXX" on my work laptop.

I guess local interfaces, e.g. "lo", are automatically ignored by libnice.

Comment 5 Kamil Dudka 2019-06-25 14:05:13 UTC
As I understand it, the virbrX interface exists on the host only.  There is usually no such interface inside a virtual machine (unless we are using nested virtualization).  So this change should not affect users running libnice in a virtual machine.

Comment 6 Stefan Becker 2019-06-25 17:14:22 UTC
Unfortunately --with-ignored-network-interface-prefix= only works for one prefix:

agent/interfaces.c:

  } else if (g_str_has_prefix (ifa->ifa_name, IGNORED_IFACE_PREFIX)) {

i.e. setting it to "virbr" will address this issue only for libvirtd generated interfaces, but not for Docker/podman containers. I just verified on my work laptop that libnice picked up the docker0/br-XXX/vethXXX interfaces as candidates.

IMHO this option is kind of useless as it is implemented right now.

Comment 7 Kamil Dudka 2019-06-26 05:20:45 UTC
I agree it is not perfect but it is IMO better to address virbrX than nothing, given the fact that the option is still unused.

Comment 8 Stefan Becker 2019-06-26 06:42:59 UTC
I found more issues with the current implementation that should be addressed before updating the Fedora package. I have opened a ticket upstream.

Comment 9 Fabrice Bellet 2019-06-26 06:46:09 UTC
Since I'm also the author of this feature, I can comment on its goal :)

I agree that the way the ignored interface is hardcoded from the configure script is far from perfect, and the fact it does a simple substring matching has limitations compared to a regex or a list, so yes, it could be improved.

The idea behind this option is to provide a simple way for the package maintainer to counterbalance distro-wide the effect for libnice of another choice made distro-wide: running libvirt and its virbr0 interface in the case of Fedora. So in my mind, this possibility mainly targets the user of the default fedora workstation installation, that just want his videoconference/chat application to connect as fast as possible, without having to dig into the details of his default network setup. The user that has installed additional packages is not the intended audience, even if in his case, the discard of one interface among several others of the same kind cannot hurt.

Also, even when virbr0 is ignored on the host, when one peer is on the host and the other peer is in a virtual machine behind virbr0, a connection can still be established, with a pair made of the "real" interface of the host, and the network interface inside the VM. The only situation that will fail is when the host is disconnected from the network, and its "real" interface is not available.

Comment 10 Stefan Becker 2019-06-26 10:19:19 UTC
I already pushed the simple fixes to my fork on gitlab (https://gitlab.freedesktop.org/stefanb2/libnice/commits/topic-issue-87).

A package with those fixes included plus ignoring prefix "virbr" reduced the SDP candidate list in the initial INVITE message for "Show conference" on a conference call by half. I have the impression that the handshake is faster now, but that may be just my imagination.

It also seems that it now always succeeds to start remmina instead of occasionally timing out. But that may also be caused by a fix pushed to SIPE HEAD yesterday.

Comment 11 Stefan Becker 2019-06-27 11:03:02 UTC
I have submitted an upstream merge request for the improvements: https://gitlab.freedesktop.org/libnice/libnice/merge_requests/60

Fabrice: can you please review it? Thank you.

Comment 12 Fabrice Bellet 2019-06-28 12:21:57 UTC
It works fine for me!

Comment 13 Fedora Update System 2019-06-28 13:56:48 UTC
FEDORA-2019-75ac6d06f4 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-75ac6d06f4

Comment 14 Fedora Update System 2019-06-28 13:59:01 UTC
FEDORA-2019-f63e58a7d7 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f63e58a7d7

Comment 15 Fedora Update System 2019-06-28 18:25:52 UTC
libnice-0.1.16-5.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-75ac6d06f4

Comment 16 Fedora Update System 2019-06-28 21:44:31 UTC
libnice-0.1.16-5.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f63e58a7d7

Comment 17 Fedora Update System 2019-07-07 00:57:58 UTC
libnice-0.1.16-5.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2019-07-07 05:46:07 UTC
libnice-0.1.16-5.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.