Messages in this thread | | | Subject | Re: Fw: Linux 2.0/2.1/2.2 -- Anyway to avoid different binaries?? | Date | Mon, 08 Feb 1999 18:46:55 -0500 | From | Ted Lemon <> |
| |
> 1. Mike's question had been hashed out on the list before, and I felt > I could give a reasonably accurate recap of the last time it came up.
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/
| |