casey@gauss.llnl.gov (Casey Leedom) (05/09/89)
I have no idea if the following problem has been discovered by anyone else, or if it's been described on Sun-Spots or TCP/IP since I no longer seem to have time to follow either. Sorry if it has ... Sun's PC NFS 3.0 now has support for ICMP (you can ping at it, etc.). It will even respond to broadcast ICMP packets (yes, I know this is a controversial practice). However, part of the algorithm it uses to respond to ICMP_ECHO packets is simply to swap the source and destination ethernet and IP addresses, respectively, of the packet. This means that when PC NFS 3.0 finds itself responding to a broadcast ICMP_ECHO (something that apparently never crossed the designers' minds), the ICMP_ECO_REPLY packet has a source ethernet address of ff:ff:ff:ff:ff:ff and a source IP address of your local IP broadcast address. [In fact, the reply packet has no identifying marks on it at all and you have to degenerate to partitioning methods to find the offending host. Fun, fun, fun.] An ethernet packet with a source ethernet address equal to the ethernet broadcast address is not only illegal (at least as far as I'm aware), but also tends to screw up a certain well known and widely used piece of hardware: DEC LanBridge 100s running version 2.0 of the PROM software. Other than that I don't know of any detrimental effects. Sun has been very good about helping us with this problem and we are running a BETA of PC NFS 3.0.1 that solves the problem. As I understand it, this will be an official product sometime in June or July. If you need the fix before then, the Sun problem reference number is 289928. Thanks again to Sun for being very helpful on this. Casey