Messages in this thread | | | Date | Sat, 22 Aug 1998 11:26:35 +0300 | From | Lauri Tischler <> | Subject | 2.2 breaks DHCP, FUD or not ?? |
| |
I found this on 'dhcp-server' list. Plse tell me it's not true and that I'm just an ignorant victim of FUD.
[QUOTE] > > 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 > 0.0.0.0. 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. :'(
[/QUOTE]
Cheers.. -- 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 *
- 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
| |