casey@lll-crg.llnl.gov (Casey Leedom) (05/22/89)
I know that the subject of broadcast pings (ICMP_ECHO packets sent to the broadcast address) is controversial: whether to respond or not to respond? Nevertheless, it's at least known what the general form of an ICMP_ECHOREPLY packet should be if one is sent. Sun's PC NFS 3.0 now implements ICMP and responds to broadcast pings, but does so with an illegal [I think] ethernet packet. In the process of creating the reply packet, PC NFS 3.0 simply swaps the source and destination ethernet and IP addresses. Apparently it never occurred to the engineers that their code might find itself responding to an ICMP packet that wasn't explicitly directed at themselves. The reply packet to a broadcast ping has a source ethernet address of ff:ff:ff:ff:ff:ff and a source IP address of the local IP broadcast address. [I.e. the packet has absolutely no identifying marks on it whatsoever. You can't tell where it came from. We had to resort to binary search, physically partitioning one of our ethernets ...] [As far as I'm aware, an ethernet packet with a source address equal to the ethernet broadcast address is illegal. (I think that's true about any multicast address, but I'll wait for someone to respond to Dave Wiltzius message on that issue.)] These packets cause DEC LanBridge 100s with revision 2.0 PROMs to ``learn the broadcast address'' which eventually partitions your network as ARPs start failing, etc. As far as I know these packets don't cause any other problems. A fix is available from Sun for this problem. Sun worked with us to come up with the fix and has been very helpful. The fix will be released as part of a general upgrade called PC NFS 3.0.1 (or was it 3.1?) sometime in the June/July time frame (from what I've been told). If you can't wait for that, you should contact Sun and ask about the 3.0.0.8 BETA version. The bug fix for this particular problem is associated with problem number 289928. Casey