Date: Mon, 28 Apr 2003 23:42:44 +0200 (CEST) From: Martin Blapp <mb@imp.ch> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-net@freebsd.org Subject: Re: Implementing SO_BINDTODEVICE Message-ID: <20030428173053.E52034@cvs.imp.ch> In-Reply-To: <Pine.NEB.3.96L.1030428112253.21738L-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1030428112253.21738L-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > Hmm. My impression was that dhclient used solely BPF descriptors on > FreeBSD to perform interface-specific DHCP client communications, and that > SO_BINDTODEVICE was used only in the DHCP server? BPF requires you to > specifically identify an interface to bind to, as it's an interface-layer > communications primitive. Hmm. I'll have to look at this again. > Last time I tried, the only real issue in using dhclient on multiple > interfaces was making sure that pid files didn't collide, but that was > several years ago, things could easily have changed. I guess one can work around with binding just to another port within dhclient. > What semantics does SO_BINDTODEVICE offer? Normally, IP sockets make IP > address binding and routing decisions based on the process optionally > specifying IP addresses for local binding, and based on the destination of > a connection/transmission. In the meantime I have found out that omsshell does provide the functionality to remove and add dhclient supported devices. What's missing is a uncomplicated access method via af_unix socket. I'm currently implementing this one. Then the way dhclient is used will change. You only call dhclient once at startup. For each device you add you call omshell which tells dhclient to poll for link activity. If you remove the card, omshell can be called again to invalidate the device. Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030428173053.E52034>