avahi: remove disallow-other-stacks=yes #3888
Conversation
This was originally added because SO_REUSEPORT was not available on older kernels With this setting, avahi-daemon does not use either SO_REUSEADDR or SO_REUSEPORT, which means that other mDNS applications cannot access the multicast udp port 5353 at the same time. This includes mDNS clients which are simply trying to discover other services on the network. One such client exists in a PVR add-on I am writing for Kodi which currently fails in network discovery when run on LibreELEC. See also grandcat/zeroconf#63
|
Let's test this for a while in nightlies and see if anything unusual is reported. Messing about with mDNS has tended to cause subtle (and unwanted) issues in the past.
|
|
You can see some discussion about this issue in https://avahi.freedesktop.narkive.com/r0mICasQ/re-avahi-commits-r646-in-trunk-avahi-core-core-h-avahi-core-server-c-avahi-core-socket-c-avahi-core- The mDNS spec explicitly states in https://tools.ietf.org/html/rfc6762#section-15.1:
While unicast packets may be affected by multiple listeners on port 5353, mDNS is designed as a multicast system first which means multiple listeners can exist and all cohabitate peacefully. The entire protocol is designed with multiple mDNS servers and clients in mind, and as outlined in the discussion above it is perfect valid to run multiple mDNS servers on the same machine. The unicast bits in the spec are only used as a fallback when multicast fails, so the concerns in the avahi man-page are frankly FUD. While it might not make sense to run multiple mDNS servers on a system (even though this is perfectly valid), the issue with I have a lot of experience with bonjour/zeroconf and am fairly certain that this change is both correct and harmless. (After all, it's not like there is a package manager on LibreELEC and users will try to install other mDNS servers). But testing it in the nightlies to confirm is a good idea. |
|
Yes, I'm not against the change, which sounds reasonable given your circumstances - hence the offer of testing in nightlies - I'm just saying that in the past we've been bitten by other mDNS changes (hence the testing in nightlies, etc.!) I'm willing to accept the Avahi man page may now be out of date - it looks like this option was added to Avahi over 14 years ago... 😄 |
|
👍👍. What do I need to do to get this into the nightlies? |
For my own builds, nothing - I've added it already. If you want to test the change, there are two threads on the Kodi forum for my own LibreELEC "10"/Kodi 19 test builds (released nightly, shortly after 9pm UK time, usually), which often include unmerged LibreELEC PRs (such as this one) and also Kodi PRs, for testing prior to merging. RPi/RPi2, and Generic (x86_64). I'll include this PR in tomorrows build ( You can upgrade to the test build of your choice using the available tar file. Downgrading back to official releases is possible, although any upgraded Kodi 19 databases will remain until you delete them (not an issue when returning to Kodi 18, but when you eventually upgrade to an official Kodi 19 release in 12+ months time, Kodi will start to use the already existing - and old - Kodi 19 databases, which may or may not work etc.). Configure the update channel for manual updating via the LibreELEC Settings addon (see note #7 in the first post of each thread). |
This was originally added because SO_REUSEPORT was not available on older kernels
With this setting, avahi-daemon does not use either SO_REUSEADDR or SO_REUSEPORT, which means that other mDNS applications cannot access the multicast udp port 5353 at the same time. This includes mDNS clients which are simply trying to discover other services on the network. One such client exists in a PVR add-on I am writing for Kodi which currently fails in network discovery when run on LibreELEC.
See also grandcat/zeroconf#63