[9fans] dhcpd and other CPU server fun.

[9fans] dhcpd and other CPU server fun.

[ron minnich]

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

Re: [9fans] dhcpd and other CPU server fun.

[nigel]

> 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.
>
There is indeed a vendor extensions section in bootp (which dhcp is an
extension of) which Plan 9 uses for this purpose. Right click on this:

/sys/src/cmd/ip/dhcpd/dhcpd.c:/add plan9 specific options/

Re: [9fans] dhcpd and other CPU server fun.

[David Presotto]

> 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.

As nigel said, yes there is.

> 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?

However, unless you set up the non plan 9
server with a hex entry for the vendor extension field corresponding
to our fs/auth entry, it won't answer with that stuff.  However, if you
have a plan 9 system serving dhcp/bootp for you then will get them
returned in the dhcp/bootp packets.  We use our CPU server to serve
about 100 plan 9,  Windows, and Unix systems and printers and have been doing
it for years.  Its pretty solid.  For the first few years, every year or so,
I'ld see a system that we didn't answer correctly and have to change dhcpd to
talk to it.  Hasn't happened for a while now.

> 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.

Sounds like you have two bootp/dhcp servers answering, one with the info
and one without.  Snoop the network and look.
	snoopy -f dhcp
Of course, only part of the dhcp conversation is boradcast...

> 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?

Rsc is the vmware king.  He would know.  Do you ever manage to boot the
kernel successfully through vmware?

Re: [9fans] dhcpd and other CPU server fun.

[ron minnich]

On Mon, 21 Apr 2003, David Presotto wrote:

> Rsc is the vmware king.  He would know.  Do you ever manage to boot the
> kernel successfully through vmware?

yes indeed,but it is intermittent. I will do one more search-and-destroy
for other dhcpd's but have not found them yet :-)

ron

Re: [9fans] dhcpd and other CPU server fun.

[Russ Cox]

> 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?

This fits with your other DHCP problems, which presotto answered.
If the rogue non-Plan 9 DHCP server answered, it might give out
the wrong sysname.  I'm not sure how to turn off the VMware DHCP
server, but I bet it's in the documentation.

Ndb/cs sets the sysname using, in order:

	an environment variable $sysname
	the contents of /net/ndb (set during dhcp)
	the current ip address, looked up in the network db
	the current ether address, looked up in the network db

> 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?

I've had no such problems with VMware, but it's been a while
since I did a boot over a virtual network.

Which network mode are you using?
Are they on the same virtual network?
Which packets are they sending to no avail?

Russ