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 add-emoji ).

I have contacted avahi's maintainer (Trent Lloyd).

Links:

Looking for hackers with the skills:

avahi dns networking

This project is part of:

Hack Week 19

Activity

  • about 4 years ago: a_faerber liked this project.
  • about 4 years ago: moio liked this project.
  • about 4 years ago: e_bischoff added keyword "networking" to this project.
  • about 4 years ago: fcrozat liked this project.
  • about 4 years ago: mcepl liked this project.
  • about 4 years ago: mwilck liked this project.
  • about 4 years ago: pgonin liked this project.
  • about 4 years ago: e_bischoff started this project.
  • about 4 years ago: e_bischoff added keyword "avahi" to this project.
  • about 4 years ago: e_bischoff added keyword "dns" to this project.
  • about 4 years ago: e_bischoff originated this project.

  • Comments

    • e_bischoff
      about 4 years ago by e_bischoff | Reply

      Possible ways to solve spurious name conflicts:

      1. 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."

      1. 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.

      1. Find a way to identify the origin of probes, and discard a machine's own probes

      ... but does such a way even exist?

    • e_bischoff
      about 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.

    • e_bischoff
      about 4 years ago by e_bischoff | Reply

      A fourth possible way to solve the spurious name conflicts issue:

      1. 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.

    • e_bischoff
      about 4 years ago by e_bischoff | Reply

      Yet another possible approach:

      1. 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...

    • e_bischoff
      about 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...

    • e_bischoff
      about 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 address 2620:

    • e_bischoff
      about 4 years ago by e_bischoff | Reply

      the information about the (outdated) address 2620: comes from the other machine, the one with the reflector.

    • e_bischoff
      about 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.

    • e_bischoff
      about 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 .

    • e_bischoff
      about 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.

    • e_bischoff
      about 4 years ago by e_bischoff | Reply

      For the moment, integrating my patched version with sumaform.

    • e_bischoff
      about 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

    Avahi Integration and Network Connection by vojha

    Avahi Integration and Network Connection

    ...


    Exploring DPDK within containers by paolodepa

    Project Description

    Containerization is h...