Messages in this thread | | | Date | Mon, 8 Feb 1999 17:05:04 -0600 | From | Mitchell Blank Jr <> | Subject | Re: Fw: Linux 2.0/2.1/2.2 -- Anyway to avoid different binaries?? |
| |
Ah well, I guess this thread is back on the kernel list. For the record, my reply wasn't, I'm not sure why Ted replied back here. I replied to him not because I'm a deep Linux networking guru (i'm certainly not), but basically because: 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. 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.
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.
Anyway, hopefully that's enough of a disclaimer for everybody...
Ted Lemon wrote: > But you have to test against > INADDR_BROADCAST and the local subnet broadcast address in these cases > anyway, so what's the big deal adding one more test?
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.
> Sure, if you > engage in bad programming practice and dangerously overload > INADDR_ANY, you can run into trouble. Don't do that! The meaning of > 0.0.0.0 as an IP source address doesn't overlap with any other > meaningful use of INADDR_ANY,
It already does though - the binding of specific ethernet addresses.
Let me give a hypothetical example showing why this is enough to get you into trouble. Suppose I was writing a simple proxy server designed mainly for allowing a few hosts on a LAN to share a ppp dialin connection. Now obviously a major security concern is misconfigurations that would create an open proxy. Thus, by default I'll only bind my listening socket to ethernet ports (just by using a SIOCGIFCONF and looking for interfaces named "eth*", which is generally good enough for Linux). All seems fine.
Now suddenly someone installs this on a machine getting its ethernet address via dhcp. Oops, I just bound INADDR_ANY silently defeating the security.
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.
So I agree with your first two sentences in the above quoted segment entirely. We _shouldn't_ overload INADDR_ANY because yes it is dangerous.
> In order to have a complete TCP/IP implementation, according to the > Host Requirements Document (RFC1122), you _must_ be able to send > packets with a source address of 0.0.0.0 in order to configure your IP > stack.
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.
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.
> implementors, given that there's already a de facto API that works on > all Unix systems, including Linux prior to 2.1, but not on Linux 2.1 > or later.
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.
> Such applications already deal with this, and have had to deal with [...] > Trust me, the > Internet Software Consortium does not mind if you allow a 0.0.0.0 > source address, and we're maintaining bind.
Perhaps I should clarify my point. I wasn't trying to claim that any of the packages listed have a problem with such interface addresses - they clearly don't. I was just trying to say that there is the possibility for confusion about such interface addresses in userland programs (as I talked about above). I was merely listing things like named and gated as examples of userland programs that are sensitive to the interface list. They are examples of programs that could be confused by a 0.0.0.0 interface address, not examples of programs that are.
> How many people are going to have to create kludges like the > one you suggested to Mike?
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. If it can't be (i.e. there is no way to have a single dhcp-client executable that supports both 2.0 and 2.2; that seemed to be the nature of the thread that Mike forwarded) then that is quite unfortunate since admins are going to have to be forced into using a little script hack.
> How many man-days of effort do you think it would be for me to propose > and implement yet another API?
Well perhaps one of the local networking gurus has some ideas (anyone?) The problem as I see it is that when an OS wants to support dhcp they have the choice between two APIs
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. 2. lpf. This is non-optimal because it requires the application to know the link-layer encapsulation in use (which it doesn't)
It seems to me that the linux folks who opinions matter (which doesn't include me, BTW, so don't put this all on my shoulders just because I answered Mike's question) aren't too keen supporting the less-than-perfect 0.0.0.0 system. I think the only solution that can possibly make everybody happy is that if we had a way to get an packet socket that allowed sending arbitrary L3 frames allowing the kernel to do the L2 encaps as usual.
-Mitch
- 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/
| |