PC NFS 3.0, broadcast pings, and DEC LanBridge 100s [+ FIX]

[Casey Leedom]

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