[9fans] Missing ARP reply in 9load

[Lucio De Re <lucio@proxima.alt.za>]

I had been wondering why the 2ed CPU server managed to load its
kernel over the wire when I ran the modified CMU BOOTPd, but not
when using ISC's DHCPd.

Ted Lemon evidently does not enter the ethernet information from the
DHCP requester in the ARP tables, as CMU BOOTPd does (and promptly
deletes, which I always thought a little suspicious).

Of course, I'm not running the most recent version of the DHCP server,
perhaps things have changed in the recent past, but I wonder if 9load
should not address this problem, and respond to ARP requests for its
freshly acquired IP address, irrespective.

I guess standards should be followed here, although I have never
really faced this problem, or seen an RFC addressing it.  I believe
one must allow for the possibility that the TFTP server is running
on a different host from the DHCP server, and could not conceivably
be expected to know the ethernet address of the TFTP client.

Russ?  I don't think I am as confortable with Plan 9 sources as to
undertake to fix this.

This for Rob Presotto, whom I remember frequenting the ISC DHCP
mailing list when I still did: I have

	option option-128 c0:60:20:86;
	option option-129 c0:60:20:85;

in dhcpd.conf and ISC DHCPd seems happy, but I still get prompted for
the address of the authenticator and file server once I've net booted
9pcdisk.gz and selected IL.

I think this ties up with Forsyth's comments about bootargs=, but I
thought one would avoid distributing information in plan9.ini files
wherever possible.  While asking, what maginc incantantion will
persuade a 3ed AUTH server to use itself rather than a third party?

++L