Your recap was fine. The reason I responded to the Linux mailing
list rather than to you is that responding to you didn't seem like it
might be productive. I guess you think that this is a dead issue now
that the decision has been made, but the transition from Linux 2.0 to
2.2 is going to be really painful for a lot of people if you don't fix
this _soon_, and Mike is not going to be the last person you're going
to hear from, nor, I suspect, are most of the people you hear from
going to have been sent by me (or even know who I am). There are a
_lot_ of people using DHCP on Linux, and the forced switch to LPF
makes the ISC product and dhcpcd (whose ancestry I do not know) much
more of a pain to set up.
> 2. I think Ted's tactics were a bit over the line. It seemed that
> rather than just disagreeing with the change, he was implying that
> it might have been an oversight and that people should report it
> as such.
No, sorry. I said it was a deliberate decision, stated that I
disagreed with it, and why, and told one of your customers that if it
is a problem for him, he should complain to you about it, not me,
because I have no power to make his life better and you (collectively)
do. I don't think that's unfair at all.
> I don't have a particularly rigid stance one way or the other on the
> issue, I was mainly attempting to privately recap the points of
> view I had seen expressed by people who matter more than me.
A laudable goal.
> Well, Linux won't let you set the IP address to INADDR_BROADCAST either.
> It does let you set the IP address to the subnet broadcast address...
> I personally suspect that's a bug.
Right, but on the way into the IP stack, a packet is examined to see
if it's for the host receiving it, and it's discarded if not.
Broadcast packets are always for the host receiving it, if they're on
a broadcast address the host recognizes. But while it's entirely
appropriate to respond to a UDP packet to port 67 and your IP address
with an ICMP port unreachable message, it is _not_ appropriate to so
respond if the packet was send to a broadcast address, so a conforming
IP implementation already has a test for this, and that test is in
exactly the same place where the equivalent test for 0.0.0.0 would
need to be made.
> Now suddenly someone installs this on a machine getting its ethernet
> address via dhcp. Oops, I just bound INADDR_ANY silently defeating
> the security.
No, you didn't. The 0.0.0.0 address is *required* to be unconfigured
once a real address has been obtained, and AFAIK Linux used to do the
right thing in that case. The client script unconfigures the 0.0.0.0
address itself before configuring the new IP address. So unless you
set up the server before you have an IP address, this shouldn't be a
problem. Also, it seems inadvisable to set up any server to
configure its address with DHCP - what if the DHCP server goes down?
Do you stop providing whatever service you are providing?
> Now one can just say "the programmer should have checked for it" and
> would be right. But having an API that can confuse a program silently
> in an edge case should make people scared.
No, the program should never need to check for this.
> Please cite chapter and verse. As far as I can tell, the only requirement
> regarding 0.0.0.0 (3.2.1.3.(a)) is that IF you send such a packet it must
> be from a "part of an initialization procedure by which the host learns
> its own IP address". It doesn't specify how the OS interfaces with
> userland to facilitate sending such packets, nor does it even state that
> you "_must_ be able to send" them.
I suppose that's true. RFC951 and RFC2131 do say that you must be
able to send such packets, though, and I feel the language you quoted
in RFC 1122 strongly implies that this should be supported, although
it does not directly require it.
> Ted, I have no problem with your dissenting opinion on this issue. In
> fact, I regard your opinion quite highly in this matter. However,
> claiming that Linux is in violation of RFC1122 (which you did 3 times in
> your message) is a rather grave charge... I hope you can back it up.
It's my opinion that the Linux 2.1/2.2 kernel is in violation of the
spirit if not the letter of RFC1122. You can certainly read the RFC
the other way, but I think that reading would be wrong, particularly
in the context of RFC951 and RFC2131.
> If that is really the case (and I assume it is, because you of all
> people should know) then MAYBE we should support it for no other
> reason than UNIX-standardiztion. I thought I remembered some people
> lamenting that there was now "another OS" that had to use the lpf
> hack, so I thought there were other unicies doing the same. I
> guess I was wrong on this count, sorry.
No, it's more sad and depressing than that. Until Linux 2.1 came
out, Linux had the distinction of being the _only_ operating system
on which the Internet Software Consortium DHCP Distribution had a
fully-functional network API (BSD/os and SCO both have mechanisms that
are equivalent to what Linux provided, but support for them hadn't
been contributed, and I haven't had time to do it myself yet).
On NetBSD, FreeBSD, Ultrix, Digital Unix, SunOS, Solaris and
NextStep/Rhapsody, we do indeed use the Berkeley Packet Filter or
something very much like it, not because of the absence of support for
using 0.0.0.0 as a source address (they all have this) but because
their BSD socket implementations do not provide a mechanism whereby I
can tell on what interface a packet arrived, or dictate on what
interface a packet should be sent.
On Linux, the SO_BINDTODEVICE socket option allows me to do this, and
it's a *tremendous* win. Unfortunately, as of Linux 2.1, it's no
longer usable. I'm hoping to have time to do an equivalent hack for
NetBSD before the NetBSD 1.4 release, but even though I'm a NetBSD
hacker, I still think it's sad that this fine Linux API has lost its
value (it was added specifically to support DHCP) because the DHCP
client forces me to use lpf.
> I don't know. Is there any deep reason that lpf could not be made
> to work under 2.0? (or does it?) In that case it's not an end-user
> issue - it's merely another program that needs to be updated prior to
> running a 2.2 kernel.
It's not a program - it's a kernel facility. Requiring that people
upgrade their kernels in order to avoid having to install a different
DHCP implementation doesn't seem like an advantageous choice.
> 1. Allowing an interface address of 0.0.0.0. I think we can both
> agree this is non-optimal since it conflicts with the use of
> INADDR_ANY in bind(). Obviously we disagree on the severity
> of this problem.
No, we disagree on the existance of a problem. If your network
interface has not yet been configured with a nonzero IP address, then
your source address is going to be 0.0.0.0. If your interface _has_
been configured, then your source address is going to be the
interface's address. There's nothing complicated about this. You
probably don't even have to write any special-case code to deal with
this, if your code currently picks the first address off the interface
address list. Actually, Linux uses pseudo-interfaces for aliases, so
it's even easier - INADDR_ANY means the sole address the interface
has. I speak of interfaces here because an application that's
configuring network interfaces needs to use SO_BINDTODEVICE to get
correct behaviour anyway.
> It seems to me that the linux folks who opinions matter aren't too
> keen supporting the less-than-perfect 0.0.0.0 system.
So I'd like to humbly suggest that they implement a perfect 0.0.0.0
system like the ones in all the other free unices and all the
commercial ones too.
_MelloN_
-
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/