[9fans] dhcpd and other CPU server fun.

[ron minnich <rminnich@lanl.gov>]

I am fooling around with a vmware auth/kfs/etc. server (hostname p9) and a
vmware virtual-floppy-booting CPU server (hostname cpu2) until I get my
little battery-powered CPU server done.

The CPU server has an entry in ndb/local on the auth/kfs/etc. server.  In
that entry it has fs=p9 and auth=p9 entires, as well as the usual dom=
etc. entries. There is an empty plan9.ini on the virtual floppy. When boot
comes up I get the [il] prompt and hit return.

The behaviour of the CPU server at that point is not repeatable in this
sense: sometimes, the CPU server just proceeds to boot, without prompting
for the IP address of the fs or auth server. Other times, it asks for the
IP addresses.

Now I'm curious. There is no entry in the standard DHCP packet for custom
entries like auth and fs, right? I've read the DHCP RFCs and it seems not
flexible enough for arbitrary named parameters, but maybe I misread it.

How does the auth= and fs= stuff get communicated to a CPU server in this
case? Is there a secondary il-based set of packets that passes that info
on? How solid is the dhcp server on Plan 9 anyway? It seems to not always
respond correctly. Anyone out there using it on a reasonably frequent (as
in booting) basis?

The other thing I'm seeing is that the CPU server will get completely hung
on the way up. The CPU server and auth server send packets out to each
other, to no avail. Is this (I'm guessing) a VMWare thing, or is there
something else going on? Anyone else seen this either with vmware or real
hardware?

Finally, sometimes when the CPU server comes up, it has the right IP
address, and you can even cpu -h to it by its right hostname, but ndb/cs
has set the wrong sysname in /dev/sysname. Again, this is pretty random.
 From one boot to the next it happens or it doesn't.  Any idea why this
would happen?

Thanks

ron