Date: Fri, 25 Aug 2006 08:21:12 +0200 From: Fredrik Lindberg <fli+freebsd-net@shapeshifter.se> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: freebsd-net@freebsd.org, Pat Lashley <patl+freebsd@volant.org>, Doug Barton <dougb@freebsd.org> Subject: Re: Zeroconfig and Multicast DNS Message-ID: <44EE96D8.3040806@shapeshifter.se> In-Reply-To: <20060824223756.GC40213@lor.one-eyed-alien.net> References: <AC7E9152833F0BCEA60635E7@garrett.local> <44EE1F7B.5000500@shapeshifter.se> <20060824220314.GB40213@lor.one-eyed-alien.net> <44EE22E7.6000700@shapeshifter.se> <20060824223756.GC40213@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis wrote: > On Fri, Aug 25, 2006 at 12:06:31AM +0200, Fredrik Lindberg wrote: >> Brooks Davis wrote: >>> It just occured to me that the daemon could handle this without any >>> interaction with dhclient or the static interface configuration. In the >>> mode where you only want an LLA if there isn't another address it's a >>> simple matter of watching the routing socket for messages and a) >>> removing the LLA if an IPv4 address other than 0.0.0.0 is configured on >>> the interface and b) (re)starting the process of obtaining an LLA when >>> all other addresses have been removed. The daemon should be listening >>> to the routing socket anyway because it should only run when the >>> interface has link which requires it to exit when the link goes down >>> similar to dhclient. I really need to go look at the code and see what >>> you're doing now. :) >> Well, I'm doing just that...except it's not the routing socket but the >> netdev filter of the kqueue system. Could be change to the routing >> socket. > > It looks like you'd need to switch to the routing socket to be able to > make decisions based on address changes, but the basic flow should be > the same. > It is doing decisions based on address changes... The difference is that instead of doing a read each time something arrives at the routing socket it just refreshes its data on whats on the interface when an address event takes place and then makes a descisions. Yes, you could see this as a potential race condition, but, it doesn't care if it was an address removal or address addition event that triggered it, it will do the same logic that should eliminate any race condition. However, I might change it to a routing socket anyway, haven't really decided yet. Fredrik Lindberg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44EE96D8.3040806>