Give avahi some love
a project by e_bischoff
Updated almost 5 years ago. 6 hacker ♥️. 1 follower.

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:

Join this project

Looking for hackers with the skills:

avahi dns networking

This project is part of:

Hack Week 19

Activity

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


    • Comments

    • e_bischoff
      almost 5 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
      almost 5 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
      almost 5 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
      almost 5 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
      almost 5 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
      almost 5 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
      almost 5 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
      almost 5 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
      almost 5 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
      almost 5 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
      almost 5 years ago by e_bischoff | Reply

      For the moment, integrating my patched version with sumaform.

    • e_bischoff
      almost 5 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

    ddflare: (Dynamic)DNS management via Cloudflare API in Kubernetes by fgiudici

    Description

    ddflare is a project started a couple of weeks ago to provide DDNS management using v4 Cloudflare APIs: Cloudflare offers management via APIs and access tokens, so it is possible to register a domain and implement a DynDNS client without any other external service but their API.

    Since ddflare allows to set any IP to any domain name, one could manage multiple A and ALIAS domain records. Wouldn't be cool to allow full DNS control from the project and integrate it with your Kubernetes cluster?

    Goals

    Main goals are:

    1. add containerized image for ddflare
    2. extend ddflare to be able to add and remove DNS records (and not just update existing ones)
    3. add documentation, covering also a sample pod deployment for Kubernetes
    4. write a ddflare Kubernetes operator to enable domain management via Kubernetes resources (using kubebuilder)

    Available tasks and improvements tracked on ddflare github.

    Resources

    • https://github.com/fgiudici/ddflare
    • https://developers.cloudflare.com/api/
    • https://book.kubebuilder.io

    Learn enough Golang and hack on CoreDNS by jkuzilek

    Description

    I'm implementing a split-horizon DNS for my home Kubernetes cluster to be able to access my internal (and external) services over the local network through public domains. I managed to make a PoC with the k8s_gateway plugin for CoreDNS. However, I soon found out it responds with IPs for all Gateways assigned to HTTPRoutes, publishing public IPs as well as the internal Loadbalancer ones.

    To remedy this issue, a simple filtering mechanism has to be implemented.

    Goals

    • Learn an acceptable amount of Golang
    • Implement GatewayClass (and IngressClass) filtering for k8s_gateway
    • Deploy on homelab cluster
    • Profit?

    Resources

    EDIT: Feature mostly complete. An unfinished PR lies here. Successfully tested working on homelab cluster.

    Remote control for Adam Audio active monitor speakers by dmach

    Description

    I own a pair of Adam Audio A7V active studio monitor speakers. They have ethernet connectors that allow changing their settings remotely using the A Control software. From Windows :-( I couldn't find any open source alternative for Linux besides AES70.js library.

    Goals

    • Create a command-line tool for controlling the speakers.
    • Python is the language of choice.
    • Implement only a simple tool with the desired functionality rather than a full coverage of AES70 standard.

    TODO

    • ✅ discover the device
    • ❌ get device manufacturer and model
    • ✅ get serial number
    • ✅ get description
    • ✅ set description
    • ✅ set mute
    • ✅ set sleep
    • ✅ set input (XRL (balanced), RCA (unbalanced))
    • ✅ set room adaptation
      • bass (1, 0, -1, -2)
      • desk (0, -1, -2)
      • presence (1, 0, -1)
      • treble (1, 0, -1)
    • ✅ set voicing (Pure, UNR, Ext)
    • ❌ the Ext voicing enables the following extended functionality:
      • gain
      • equalizer bands
      • on/off
      • type
      • freq
      • q
      • gain
    • ❌ udev rules to sleep/wakeup the speakers together with the sound card

    Resources

    • https://www.adam-audio.com/en/a-series/a7v/
    • https://www.adam-audio.com/en/technology/a-control-remote-software/
    • https://github.com/DeutscheSoft/AES70.js
    • https://www.aes.org/publications/standards/search.cfm?docID=101 - paid
    • https://www.aes.org/standards/webinars/AESStandardsWebinarSC0212L20220531.pdf
    • https://ocaalliance.github.io/downloads/AES143%20Network%20track%20NA10%20-%20AES70%20Controller.pdf

    Result