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: > >>> dhclient doesn't provide IPv4LL but has hooks to call avahi-autoipd as > >>> needed. Meanwhile dhcpcd provides IPv4LL out of the box, along the > >>> same fallback connectivity logic as avahi-autoipd. Having both > >>> installed is not only redundant, it concurrently tries to control the > >>> same interfaces. > >> > >> Ok, let's drill down here a bit. I assume you mean the following two hooks: > >> > >> avahi-autoipd: /etc/dhcp/dhclient-enter-hooks.d/avahi-autoipd > >> avahi-autoipd: /etc/dhcp/dhclient-exit-hooks.d/zzz_avahi-autoipd > >> > >> Are those hooks executed by dhpcd? My understanding is, that those hooks > >> are only executed by isc-dhcp-client and dhcpd ignores them. > > > > Those are indeed ignored by dhcpcd. > > Ok, thanks for confirming. > > > However, those are triggered on any host running ifupdown: > > > > 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. Martin-Éric
