> This time, I tail'ed -f my syslog file to see when the 3/50 talked to
> the DEC.

> The first time it asked for an IP number (before it run tftp and get
> the netboot program), all works fine:

> Jan  5 15:43:53 localhost: 227 rarpd: Received IP address request for ->08:00:20:00:1d:35:
> Jan  5 15:43:53 localhost: 227 rarpd: The IP address is ->128.227.42.13.
> Jan  5 15:43:53 localhost: 227 rarpd: Sent out response
> Jan  5 15:43:57 localhost: 227 rarpd: Received 60 bytes:

> However, even though it says on the Sun's screen

> Requesting Internet address for 8:0:20:0:1D:35

> It never actually sends a request!  Doesn't this sound as if netboot
> is a little bit peculiar?

Personally, I am inclined to suspect the DEC box.

Why?  Let me delve a bit into my personal history....

Years ago, the lab I worked for at the time had a MicroVAX-II and some
Suns.  We were having an extremely frustrating time with NFS between
the uVAX and the Suns - reading certain files would consistently hang,
when the VAX was reading a file that resided on a Sun, but there was no
visible pattern to _which_ files.

I eventually tracked it down.  The uVAX Ethernet interface was unable
to receive very short packets, close to the Ethernet limit.  But the
Sun was perfectly willing to send such short packets.  Normally, this
did not cause trouble, because Ethernet plus IP plus next protocol
headers were enough to push the packet over the limit.  But when a
large NFS packet was fragmented, the last fragment could be tiny enough
to be consistently dropped.  Mounting with rsize=1024,wsize=1024 fixed
the problem, because then it didn't use fragmented mobygrams: every
packet had at least Ethernet + IP + UDP + RPC + NFS headers, which put
it well over the critical size.  (The files that failed were those
whose sizes, modulo the default 8K packet size, fell into a certain
small window.)

Now, I don't know how big a RARP query is, but it ain't big.  If the
PROM driver pads the packet to a larger size than netboot's Ethernet
code does, and your DEC box is using an Ethernet interface suffering
from the same bug I saw, this is exactly what I'd expect.

Maybe go hack on netboot to pad the packet out to 70 bytes or
something.  The limit I saw was, I think, 64 bytes; I'm sure it was
under 70 bytes.  (I _think_ the Ethernet spec limit is 60 bytes.)

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu