Am 24.01.25 um 18:20 schrieb Martin-Éric Racine:
pe 24.1.2025 klo 19.04 Michael Biebl (bi...@debian.org) kirjoitti:Am 24.01.25 um 17:39 schrieb Martin-Éric Racine:pe 24.1.2025 klo 18.20 Michael Biebl (bi...@debian.org) kirjoitti:Am 27.12.24 um 10:42 schrieb Martin-Éric Racine:avahi-autoipd: /etc/network/if-down.d/avahi-autoipd avahi-autoipd: /etc/network/if-up.d/avahi-autoipd That is what overlaps with dhcpcd's built-in IPv4LL fallback.What exactly is problematic in those hooks? Those add a 169.254.0.0 route if not already existent. How does this clash with dhcpcd?It has been ages since I resorted to purging avahi-autoipd as a solution, but of what I recall a 169.254.0.0 route kept on appearing regardless of whether we had acquired an outside IP or not. As soon as I purged it, dhcpcd handled the whole process itself without interference.
Could you elaborate how this route entry interferes with dhcpcd or what exactly you mean by interference?
I'd first like to understand, why adding this route entry is problematic in case dhcpcd handles an interface.
Second, if adding such a route entry is indeed problematic and should be skipped if dhcpcd handles an interface (via /e/n/i), then we have different options:
a/ ifupdown tells the avahi-autoipd hook, it should skipb/ the avahi-autoipd hook can query ifupdown whether a certain interface should be handled or not
For a/, ifupdown could export an environment variable available to all hooks, which dhcp client it uses. The avahi-autoipd hook could check this env var and exit early if DHCP_CLIENT==dhcpd.
For b/, ifupdown would need to provide an interface which would allow one to query this information.
OpenPGP_signature.asc
Description: OpenPGP digital signature
