matt@oddjob.UChicago.UUCP (Matt Crawford) (06/21/84)
I understand that NIC is recommending the use of all 1 bits in the host portion of an internet address to denote a broadcast datagram. (That is the low order 24, 16 or 8 bits depending on whether the network is class A, B, or C.) Unix 4.2bsd uses all zero instead of all one bits for that purpose, and to convert would take more than a simple redefinition of the constant INADDR_ANY because of the variable length of the hosts field. Has anybody had a clash of software incompatibilty over this point? I am expecting to run into the problem soon at this university. ___________________________________________________________ Matt University ARPA: crawford@anl-mcs.arpa Crawford of Chicago UUCP: ihnp4!oddjob!matt
joe@fluke.UUCP (Joe Kelsey) (06/22/84)
Yes - I have found Berkeley's choice to be quite annoying. Their use of this blatantly non-standard bug can cause problems if you are trying to connect heterogenous machines on the same network. We have 5 VAXen running 4.2, 4 SUN-2s running 4.2, a VMS VAX and an IBM 3083 sharing the same Ethernet and trying to send mail, files, etc., back and forth. In addition, the UNIX VAXen each send out the rwho packets once every minute. So, that is 5 broadcast packets per minute, each with the internet destination address of 192.9.200.0 (we use net number 192.9.200), or approximately one packet every 12 seconds. These packets go out over the Ether with Ethernet addresses of all one's, so everyone HAS to receive them and then decide if they are important or not. The SUNs don't participate in the rwho junk, so they ignore the packets. Similarly, the IBM seems to safely ignore the packets. On VMS, we are running Compion's Access-I software. This is a very well thought out package, with perhaps the only major problem being that it was *modularly designed*. No, modularity is great and wonderful, but if you stick too closely to modularity in network design, especially in the interface between layers, you may lose big. When Access receives the packet, the network interface module strips the Ethernet cruft off the packet before passing it to IP. IP says "who is this host 192.9.200.0? I never heard of them before!" and proceeds to send out two response packets: one is an ICMP message to the sending host saying "I don't know who this 192.9.200.0 is" and a retransmission of the packet it just received. Well, the NIM can easily send out the ICMP message because it already knows the ethernet address of the sender, but it can't retransmit the rwho packet since it doesn't know what the ethernet address is. So, the NIM blithely sends out an ARP trying to find out who 192.9.200.0 is! I found out about this behavior when we first booted the IBM software. We had console tracing turned on and noticed a message about ARP adding a translation for the VMS machine several times ber minute. At first I thought that the VMS ARP implementation was screwed up and just sending out constant ARP packets, but then I looked at some detailed traces from the Access software (you can get INCREDIBLE levels of tracing from Access - more than you EVER wanted to know!) and discovered this side-effect of modularity! The real problem is that IP doesn't know that the packet came in as a broadcast packet, and the NIM doesn't realize that IP is retransmitting a packet that it received as a broadcast as a specific address packet. If IP *knew* that the packet with the 0 address was a broadcast packet, it could just throw it away and all would be fine. If the NIM *knew* that the only broadcast packets it wants to see are. Sigh. Aren't non-standards fun! At least it all works! /Joe
mogul@SU-SHASTA.ARPA (06/26/84)
From: Jeff Mogul <mogul@SU-SHASTA.ARPA>
I understand that NIC is recommending the use of all 1 bits in the host
portion of an internet address to denote a broadcast datagram. (That is
the low order 24, 16 or 8 bits depending on whether the network is class
A, B, or C.) Unix 4.2bsd uses all zero instead of all one bits for that
purpose, and to convert would take more than a simple redefinition of the
constant INADDR_ANY because of the variable length of the hosts field.
There was an IEN (out of BBN) issued a few years ago, on an unrelated
topic, that specified this form for a broadcast address. I discussed
this with Jon Postel when I decided to write an RFC on broadcasting, and
he more or less declared "all ones" to be the standard. My RFC has not
yet been issued, but I am fairly sure that any "standard" for IP
broadcasting willl be all 1's rather than all 0's.
This is yet another case where Berkeley disregarded informal standards,
to the detriment of all 4.2BSD users (Another case is the infamous "trailer
protocols", but at least you can turn those off.)
Has anybody had a clash of software incompatibilty over this point? I am
expecting to run into the problem soon at this university.
I'm about to test some code that should solve the problem. When I get
it working, I'll announce it over various lists. The fixes involve
minor changes to all device drivers, larger changes to a few other kernel
modules, and probably large changes to programs such as rwhod that
use broadcasts.
-Jeff