Fw: Linux 2.0/2.1/2.2 -- Anyway to avoid different binaries??

Mike Black (mblack@csi.cc)
Fri, 5 Feb 1999 07:27:11 -0500


I'm forwarding this to the kernel list in the hopes that an intelligent
answer will be forthcoming (either a patch or a really good reason why not).

________________________________________
Michael D. Black Principal Engineer
mblack@csi.cc 407-676-2923,x203
http://www.csi.cc Computer Science Innovations
http://www.csi.cc/~mike My home page
FAX 407-676-2355
-----Original Message-----
From: Ted Lemon <mellon@hoffman.vix.com>
To: David T Hollis <dhollis@tampabay.rr.com>
Cc: 'DHCP Client Mailing List' <dhcp-client@fugue.com>
Date: Thursday, February 04, 1999 9:41 PM
Subject: Re: Linux 2.0/2.1/2.2 -- Anyway to avoid different binaries??

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

> Any way to avoid having to have different binaries for the various Linux
> kernels? On one or two boxes, it's no big deal to maintain, but in an
> enterprise it can be real pain.

Yes. Send email to the Linux kernel network people requesting that
they revisit the issue of whether or not to allow network interfaces
to be configured with IP addresses of 0.0.0.0.

The reason behind switching to lpf is that in 2.1.100 (or thereabouts)
somebody noticed that if you configured a network interface with an IP
address of 0.0.0.0 and some other machine arped for 0.0.0.0, it would
respond, which is incorrect. This bug was fixed by making it
impossible to configure an interface with that address. A preferable,
and equally effective fix would have been to hack the ARP code to
never reply to requests of this kind.

Since DHCP clients depend on being able to send requests from the
0.0.0.0 IP address, which is a perfectly legitimate thing to do, and
since this is no longer permitted in Linux, DHCP clients and servers
for 2.0 and 2.1/2.2 are not interchangeable. An additional
consequence is that it is not possible to run the DHCP server or
client on a Linux 2.1/2.2 box connected to a token ring network,
because the physical layer encapsulation protocol is different, and
with lpf the application has to do the physical layer encapsulation (I
kid you not!). This can be worked around by adding code to support
token ring - there's already similar code to support FDDI. But my
take on this is that it's really the O.S.'s job to do physical layer
encapsulation, and doing it in the application is just needless
duplication.

I've tried arguing this point with the Linux network gods, but for
some reason they concluded that my motivation was to avoid having to
do extra work, not that my concern was legitimate, so they refused to
back out the change. A sufficiently vocal response from real Linux
users like you might change their minds.

_MelloN_

----------------------------------------------------------------------------

--
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.tux.org/lkml/