PROBLEM(Sun PC NFS 3.0; broadcast pings; DEC LanBridge 100s) + FIX

[Casey Leedom]

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