On 7/5/19, Gene Heskett <ghesk...@shentel.net> wrote: > On Friday 05 July 2019 05:13:48 Brian wrote: > >> On Fri 05 Jul 2019 at 09:56:39 +0300, Reco wrote: >> >> > Third, whatever good avahi does is limited to a single L2 network >> > segment by the very definition of how it works. This particular >> > problem shows it BTW. >> > > And does it very well both for avahi-daemon, and the dhcpd's that invent > avahi like addresses out of thin air, and then giving that BS priority > over the admins attempts to setup his network to his liking by giving > them a metric of 202 when the default priority/metric is 1024. > > So his (and my) only recourse is to rip that stuff out, with a root rm -f > if that what it takes to get rid of them. IMO, bug reports should be > filed against the dhcpd's both 4 and 6 to get rid of their reporting > bogus data if there are no servers responding to their requests.
Hi Gene, Please understand that assigning a 169.254.0.0/16 address to an interface that doesn't get a reply from a dhcp server is 'standards compliant' behavior. So if you do file a bug report, rants about 'bogus data' won't help your case; quoting RFC 3927 section 1.9.2 might. RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses 1.9. When to configure an IPv4 Link-Local address 2. If a host finds that an interface that was previously configured with an IPv4 Link-Local address now has an operable routable address available, the host MUST use the routable address when initiating new communications, and MUST cease advertising the availability of the IPv4 Link-Local address through whatever mechanisms that address had been made known to others. Regards, Lee