Date: Fri, 15 Jul 2005 01:22:14 -0400 From: Chuck Swiger <cswiger@mac.com> To: Andrea Campi <andrea+freebsd_current@webcom.it> Cc: freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient Message-ID: <42D74806.5040204@mac.com> In-Reply-To: <20050714202820.GE1064@webcom.it> References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> <1121368125.83653.12.camel@realtime.exit.com> <20050714193037.GF19351@odin.ac.hmc.edu> <42D6C686.4070407@centtech.com> <20050714202820.GE1064@webcom.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrea Campi wrote: > picking one random message to answer to... Agreed. :-) > let's not forget Zeroconf (169.254.x.x) address assignment. I have > (admittedly outdated now) patches to howl to make it work that are > waiting on someone to help me finalize them AND most integrate with > appropriate scripts so that things work as expected. This means > removing the autoconfigured address when obtaining a proper address > via DHCP, and vice versa. > > A full solution should IMHO take this into account, too. For the wired case, it's entirely reasonable to respond to a link down/link up combination by doing an ARPOP_REQUEST to the IP address of a router (which quite probably provides the default route) on that interface's associated network, and/or the IP address of the DHCP server which assigned your machine it's IP. If your router/DHCP server still thinks that your MAC address belongs to that IP address, well, the system ought to rely on TCP retransmissions or the design of higher levels to handle a timeperiod of no traffic without needlessly dropping connections by dropping routes, closing open TCP sockets before their time, etc. In other words, an interface link down event should *not* blindly remove or change the assigned IP address on an interface, only a link up event might, and only then after checking via ARP (or a DHCP query, or similar variants). In the meantime, and in the absense of having "multiple default routes" (routes have metrics, can't one use them to prioritize and choose an alternate path if the packets get routed through a link which is down?), it might be nice to pick an alternate default route upon a link-down event. I don't understand the layer-2 aspects of 802.11 wireless stuff modulo the various flavors of WEP and WPA encryption to know whether there is an exact equivalent to ARP, but I'd imagine something could be used to check whether the AP you were just connected to still thinks your machine is what it saw a minute or two ago, before your signal dropped off for a bit... -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42D74806.5040204>