pwl@tc.fluke.COM (Paul Lutt) (07/08/88)
We recently purchased an Excelan LANalyzer board and Compaq PC for
analyzing our local ethernet. While familiarizing myself with this
test instrument, I decided to watch my Sun workstation (a diskless
Sun-3/60) boot single user. I'm seeing some interesting behavior that
I hope someone out in netland can explain. Here is the scenario:
======================================================================
1) The client workstation uses TFTP to boot the "boot" program.
(Everything looks reasonable so far.)
2) The boot program loads in vmunix through "nd" calls to the
server. (Still looks reasonable.)
3) Vmunix starts up. One of the first things it does is send out
a very strange looking ARP request:
Packet #1172: client -> ether-broadcast
ARP request (0.0.38.80 -> 0.0.38.80)
The source and destination internet addresses are totally bogus.
As expected, no ARP reply is ever received for this bogus request.
4) The client then sends a reverse ARP request to find out its own
internet address. The server replies with the correct information.
5) Now another funny packet. The client sends out a strange ARP
request:
Packet #1175 client -> ether-broadcast
ARP request (client -> client)
The client has just asked what its own ethernet address is! This
same request appears at least twice during the booting process.
======================================================================
Note that the workstation boots normally. I'm just curious why such
strange requests are being made.
As a side note, there was a recent posting in comp.sys.sun stating that
some nd error messages seen during booting are due to net mask traffic
directed at the booting workstation. I can confirm that this is
probably true.
During the booting sequence, the client sends a ICMP request for the
local net mask. In our case, all the systems on the network using
TCP/IP try to respond. Most systems start out by sending an ARP
request to the client to get its ethernet address so that they can then
send the mask. During the trace I ran, upwards of sixty systems sent
ARP requests, followed by ICMP replies containing the net mask. It
seems likely that such volumes of traffic directed at a workstation
might indeed exhaust the buffer pool.
Thanks to anyone who can shed some light on this. I sometimes think we
were better off NOT knowing what was going on deep in the bowels of the
network. :-)
--
Paul Lutt
Domain: pwl@tc.fluke.COM
Voice: +1 206 356 5059
UUCP: {uw-beaver,microsof,sun}!fluke!pwl
Snail: John Fluke Mfg. Co. / P.O. Box C9090 / Everett WA 98206hedrick@athos.rutgers.edu (Charles Hedrick) (07/08/88)
In at least some versions of the Sun software, the systems ended up using an Internet address that was their system serial number. This was done during early stages of kernel operation, before the system knew its Internet address. Typically the serial numbers were small, so you'd get an address that looked like 0.0.x.y. In some releases, this entry was never removed from the routing table. Once the system came up, it was interpreted as a default route. I'm not sure whether these things are still happening under current releases. This is a moderately dangerous practice. 0.0.x.y should be interepreted as meaning "this net, host x.y". It is certainly possible that there could already be an x.y on the current network. I'd be very surprised if this practice continued into release 4.0
swb@TCGOULD.TN.CORNELL.EDU (Scott Brim) (07/09/88)
I've been told that the client's ARP request for its own address is to make sure nobody else is using it, and that if someone actually responds the client will refuse to network. If true, that's a nice sanity check. Scott