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

  • 4 months ago: a_faerber liked Give avahi some love
  • 4 months ago: moio liked Give avahi some love
  • 4 months ago: e_bischoff added keyword "networking" to Give avahi some love
  • 4 months ago: fcrozat liked Give avahi some love
  • 4 months ago: mcepl liked Give avahi some love
  • 4 months ago: mwilck liked Give avahi some love
  • 4 months ago: pgonin liked Give avahi some love
  • 4 months ago: e_bischoff started Give avahi some love
  • 4 months ago: e_bischoff added keyword "avahi" to Give avahi some love
  • 4 months ago: e_bischoff added keyword "dns" to Give avahi some love
  • All Activity

    Comments

    • e_bischoff
      4 months 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
      4 months 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
      4 months 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
      4 months 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
      4 months 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
      4 months 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
      4 months ago by e_bischoff | Reply

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

    • e_bischoff
      4 months 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
      4 months 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
      4 months 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
      4 months ago by e_bischoff | Reply

      For the moment, integrating my patched version with sumaform.

    • e_bischoff
      4 months 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

    Integrate Firecracker (microVMs) with a Cloud Foundry app runtime scheduler by tassis

    Description

    [Firecracker](https://firecrac...


    make "predictable network interface names" more predictable by mkubecek

    Since the so-called "predictable names" for net...


    ethtool ops for netdevsim by mkubecek

    This can be seen as a subproject of [ethtool ne...


    netlink interface for ethtool by mkubecek

    There seems to be an overall consensus that the...


    Hammer an Envoy service mesh onto a SAP S4/HANA landscape and watch everything explode. by STorresi

    Although CNCF projects are almost exclusively r...