Avahi is (among others) a domain names auto-configuration system for Linux compatible with Bonjour.
The project is to dig into avahi source code to modernize it if possible and fix bugs.
I'm in particular interested in fixing the spurious name conflicts bug that makes a lot of people's life painful (including me ).
I have contacted avahi's maintainer (Trent Lloyd).
Links:
- home page: www.avahi.org
- Freenode: #avahi
- RFC 6762 (Multicast DNS)
- Source code: github/lathiat/avahi
Looking for hackers with the skills:
This project is part of:
Hack Week 19
Activity
Comments
-
over 4 years ago by e_bischoff | Reply
Possible ways to solve spurious name conflicts:
- give the user the ability to disable the renaming mechanism
While simple and efficient, this would directly offend RFC 6762 that says: "Having named their computer this way, the user has the authority to continue utilizing that name until such time as a name conflict occurs on the link that is not resolved in the user's favor. If this happens, the computer (or its human user) MUST cease using the name, and SHOULD attempt to allocate a new unique name for use on that link."
- Don't recognize duplicate names before N seconds after bringing an interface up
This is less bad, but also slightly against the RFC sentence quoted above. Also, it brings a performance-dependent factor to the behaviour, which therefore becomes non-deterministic.
- Find a way to identify the origin of probes, and discard a machine's own probes
... but does such a way even exist?
-
over 4 years ago by e_bischoff | Reply
About the uniqueness of names: the RFC states
"It is required that the protocol have the ability to detect and handle name conflicts, but it is not required that this ability be used for every record.".
Said otherwise, it could be considered as legit to NOT use the uniqueness mechanism. However, the RFC gives examples of where it could make sense, for example for load balancing or fault tolerance. That implies "identical" hosts in terms of functionality, which is not what we are considering here.
Still, it would mean that providing a way to disable the uniqueness mechanism could be welcomed.
-
over 4 years ago by e_bischoff | Reply
A fourth possible way to solve the spurious name conflicts issue:
- use the "known answers mechanism"
This mechanism (https://tools.ietf.org/html/rfc6762#section-7.1) allows to specify hosts for which we DO NOT want to have answers. We could use it for our own name + IP association, admitting it could work so.
-
over 4 years ago by e_bischoff | Reply
Yet another possible approach:
- Remove the origin for the conflicts
For example, the RFC states "A Multicast DNS responder MUST NOT place records from its cache, which have been learned from other responders on the network, in the Resource Record Sections of outgoing response messages. Only an authoritative source for a given record is allowed to issue responses containing that record."
If avahi does not respect this, it could be the explanation for the conflicts.
Reflectors seem to break this by their very concept...
-
over 4 years ago by e_bischoff | Reply
As of day 2, stil tracing the code to see what's happening. It looks like
avahi_record_equal_no_ttl()
returns 0 despite equal records... -
over 4 years ago by e_bischoff | Reply
cause found: the machine enters in collision with itself because it is once identified by its lik-local address,
fe80:
, and once with its global address2620:
-
over 4 years ago by e_bischoff | Reply
the information about the (outdated) address
2620:
comes from the other machine, the one with the reflector. -
over 4 years ago by e_bischoff | Reply
If I comment out function
reflect_cache_walk_callback()
, then no more collision.Investigating why we need this function and whether it could be removed.
-
over 4 years ago by e_bischoff | Reply
We cannot remove this function. But I understood why it sends back information about our machine but on the other interface.
The fix is here: https://github.com/lathiat/avahi/pull/263 .
-
over 4 years ago by e_bischoff | Reply
Fix got merged upstream. Let's see if I have the time and opportunity to give avahi some more love before the end of the week.
-
over 4 years ago by e_bischoff | Reply
For the moment, integrating my patched version with sumaform.
-
over 4 years ago by e_bischoff | Reply
Integration with sumaform drafted: https://github.com/uyuni-project/sumaform/pull/684
I have run during the night SUSE manager container tests with reflectors and the fix, everything worked as expected.
Similar Projects
This project is one of its kind!