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
-
almost 5 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?
-
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.
-
almost 5 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.
-
almost 5 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...
-
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... -
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 address2620:
-
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. -
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.
-
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 .
-
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.
-
almost 5 years ago by e_bischoff | Reply
For the moment, integrating my patched version with sumaform.
-
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
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
- https://github.com/ori-edge/k8s_gateway/issues/36
- https://github.com/coredns/coredns/issues/2465#issuecomment-593910983
EDIT: Feature mostly complete. An unfinished PR lies here. Successfully tested working on homelab cluster.
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:
- add containerized image for ddflare
- extend ddflare to be able to add and remove DNS records (and not just update existing ones)
- add documentation, covering also a sample pod deployment for Kubernetes
- 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
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
- The code is available on GitHub: https://github.com/dmach/pacontrol