[Fwd: Multiple network interfaces under Linux]

Lauri Tischler (lauri.tischler@efore.fi)
Fri, 21 Aug 1998 11:22:32 +0300

This is a multi-part message in MIME format.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Interesting point. Is this something to worry about ??

Lauri Tischler, Network Admin             Tel: +358-9-47846331 
EFORE Oyj                                 Fax: +358-9-47846500
Piispanportti 12 (PL 61)               Mobile: +358-40-5569010
02211 Espoo FINLAND             EMail: lauri.tischler@efore.fi
* High Quality Custom Designed Power Supplies and Rectifiers *
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: <bouncer-dhcp-server@fugue.com> Received: from toccata.fugue.com (toccata.fugue.com [] (may be forged)) by mail.efore.fi (8.8.7/8.8.8) with ESMTP id JAA15201 for <lauri.tischler@efore.fi>; Fri, 21 Aug 1998 09:27:27 +0300 Received: from localhost (localhost [[UNIX: localhost]]) by toccata.fugue.com (8.8.8/8.6.11) id WAA03659 for dhcp-server-real; Thu, 20 Aug 1998 22:29:39 -0700 (PDT) Precedence: junk Sender: owner-dhcp-server@fugue.com Received: from andare.fugue.com (andare.fugue.com []) by toccata.fugue.com (8.8.8/8.6.11) with ESMTP id WAA03655; Thu, 20 Aug 1998 22:29:37 -0700 (PDT) Received: from andare.fugue.com (localhost []) by andare.fugue.com (8.8.8/8.6.11) with ESMTP id WAA13154; Thu, 20 Aug 1998 22:29:36 -0700 (PDT) Message-Id: <199808210529.WAA13154@andare.fugue.com> To: breu@cfu.net cc: "HICHENS, David" <DHICHENS@baea.com.au>, "'dhcp-server@fugue.com'" <dhcp-server@fugue.com> Subject: Re: Multiple network interfaces under Linux In-Reply-To: Your message of "Thu, 20 Aug 1998 11:40:29 CDT." <Pine.LNX.3.95.980820113921.22514C-100000@enterprise.cfu.net> Date: Thu, 20 Aug 1998 22:29:35 -0700 From: Ted Lemon <mellon@hoffman.vix.com>

*** From dhcp-server -- To unsubscribe, see the end of this message. ***

> Alan Cox of kernel hacking fame claims that the development > kernels (2.1.x series) contain everything needed to do it right including > the bpf, etc. 2.2.0, when released, will be stable and support it all.

No, unfortunately 2.1 (and therefor 2.2) actually breaks DHCP very badly. The server isn't too badly impacted, but the client is completely screwed. You see, BPF isn't the "right" way to do multiple interfaces - it's just a way that works consistently on a lot of platforms. Some platforms, including (at least) Linux, BSD/os and SCO Unix, provide a way to do multiple interfaces and still use the BSD sockets API. They do this by extending the API - in the Linux case, sockets are bound to hardware interfaces, and you only receive a packet if you have a socket bound to that interface (or an unbound socket), so it's easy to tell where packets come from. BSD/os and SCO put tags on packets that you can read from userland, so that you can tell where a packet came from without having multiple sockets.

Using the BSD sockets API is The Right Thing To Do. There's no excuse for meddling down at the low level with BPF, as we currently do, other than that we must, in order to make multiple interfaces work. When you meddle at the low level, you have to take into account the low-level details, like framing, which differ between different hardware types (e.g., Ethernet, Token Ring, FDDI). So platforms that use BPF or equivalents work really well if you happen to have an ethernet network, but fail miserably if you're using FDDI or Token Ring. Fortunately, this isn't a problem that most people run into.

So why is Linux 2.1 a problem? The Internet Software Consortium DHCP Distribution uses a common code base for the client and server. When you build them, you only get one copy of the common code. So the client and server are pretty much forced to use the same networking API. This could be worked around, but one wonders why - it makes a lot of sense to use a common API, and if you can't, I think there's something wrong.

Linux 2.1 does two things that break the client. The first is that it's no longer legal to configure an interface with an IP address of Of course, DHCP and BOOTP operate on the premise that this is possible, and that if you do it, the stack will do some fiddling for you to make things work. When this feature is taken away, you are pretty much forced to use BPF. On the BSDs, this isn't a bad thing, because you're using BPF anyway. On Linux, this is a really bad thing - Linux currently has the distinction of being the _only_ operating system on which the ISC DHCP networking glue works correctly, and it's about to lose this distinction because of this feature removal.

The other bug in 2.1 is that it used to be you could get a list of interfaces with the SIOCGIFCONF ioctl. In Linux 2.1, SIOCGIFCONF only returns the list of interfaces that already have IP addresses. When you're implementing a DHCP client, whose purpose in life is to acquire IP addresses for interfaces, this is an important and unfortunate change.

So, sorry to rain on your parade, but Linux 2.1 is a _disaster_ for DHCP support. :'(


------------------------------------------------------------------------------ To unsubscribe from this list, please visit http://www.fugue.com/dhcp/lists If you are without web access, or if you are having trouble with the web page, please send mail to dhcp-request@fugue.com. Please try to use the web page first - it will take a long time for your request to be processed by hand. ------------------------------------------------------------------------------


- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html