From owner-freebsd-net@FreeBSD.ORG Mon Apr 28 14:42:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6CD137B401; Mon, 28 Apr 2003 14:42:48 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BFD843F3F; Mon, 28 Apr 2003 14:42:47 -0700 (PDT) (envelope-from mb@imp.ch) Received: from cvs.imp.ch (cvs.imp.ch [157.161.4.9]) by mail.imp.ch (8.12.6p2/8.12.3) with ESMTP id h3SLgiAf007951; Mon, 28 Apr 2003 23:42:45 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Date: Mon, 28 Apr 2003 23:42:44 +0200 (CEST) From: Martin Blapp To: Robert Watson In-Reply-To: Message-ID: <20030428173053.E52034@cvs.imp.ch> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Implementing SO_BINDTODEVICE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2003 21:42:49 -0000 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