[9fans] my cpu-in-vmware problem: it's weird :-)

[ron minnich <rminnich@lanl.gov>]

The scenario is that I have two vmware machines, an auth server which I
run a rio on. It is 172.16.189.254(0:50:56:cc:31:ba). I have a cpu server
running as 172.16.189.135(0:50:56:dd:b1:e3) via DHCP. The host-only
network is via vmnet1@172.16.189.1( 00:50:56:C0:00:01)

I know I should do 3 machines, but my poor laptop can do just so much, 3
machines are beyond its capacity.

I bring up the auth server and start up dhcpd (manually for now).  So the
cpu server should boot, dhcp, and come up all happy. The auth server
should respond to it.

here is a tpcdump (use a wide window)

06:20:07.054322 0:50:56:dd:b1:e3 Broadcast ip 590: 0.0.0.0.bootpc >
255.255.255.255.bootps:  xid:0x71704e46 file ""[|bootp]

06:20:07.065400 0:50:56:0:0:0 Broadcast ip 62: 172.16.189.254 >
172.16.189.128: icmp: echo request [tos 0x10]

06:20:07.280984 0:50:56:cc:31:ba 0:50:56:dd:b1:e3 ip 334:
172.16.189.254.bootps > 172.16.189.135.bootpc:  xid:0x71704e46
Y:172.16.189.135 S:172.16.189.254 sname "p9"
 file ""[|bootp]

catch that crazy second packet: somebody at 0:50:56:0:0:0 is responding
with an ICMP ECHO(?) The problem is, there is no such interface anywhere
on this machine, virtual or real, although 0:50:56 is a vmware net
interface standard. It also claims to be the .254. is this
the plan9 dhcpd doing something odd?

There are several of them ...

06:20:07.293552 0:50:56:0:0:0 0:50:56:dd:b1:e3 ip 342:
172.16.189.254.bootps > 172.16.189.135.bootpc:  xid:0x71704e46
Y:172.16.189.135 S:172.16.189.254 file ""[|boot
p] [tos 0x10]


If I kill the Plan 9 dhcpd, well:
06:32:26.550754 0:50:56:cc:31:ba Broadcast ip 590: 172.16.189.254.bootpc >
255.255.255.255.bootps:  xid:0x5f5809a0 secs:8 C:172.16.189.254 file
""[|bootp]

06:32:42.333038 0:50:56:dd:b1:e3 Broadcast ip 590: 0.0.0.0.bootpc >
255.255.255.255.bootps:  xid:0xb36676b file ""[|bootp]

06:32:42.333280 0:50:56:0:0:0 Broadcast ip 62: 172.16.189.254 >
172.16.189.135: icmp: echo request [tos 0x10]

06:32:43.329998 0:50:56:0:0:0 0:50:56:dd:b1:e3 ip 342:
172.16.189.254.bootps > 172.16.189.135.bootpc:  xid:0xb36676b
Y:172.16.189.135 S:172.16.189.254 file ""[|bootp
] [tos 0x10]

gag.

Kill the vmware dhcpd on vmnet1.

Yep, it's that damned vmware daemon. But now that it's off:

06:34:10.653276 0:50:56:dd:b1:e3 Broadcast ip 590: 0.0.0.0.bootpc >
255.255.255.255.bootps:  xid:0x8f551a1 file ""[|bootp]

06:34:12.096343 0:50:56:cc:31:ba Broadcast ip 590: 172.16.189.254.bootpc >
255.255.255.255.bootps:  xid:0x7a2b9449 secs:8 C:172.16.189.254 file
""[|bootp]

OK, I've seen these too: .254 sends out these bootpc requests every once
in a while. The dhcpd on .254 gives an error message every time it gets
one. Hmm. Who would be doing this? Anything magic about having a .254
address?

Anyway, with that vmware vmnet1 dhcpd out of the say, things on the cpu
server work better, except it still comes up with the wrong sysname -- p9
instead of cpu2. Right IP address, I can cpu -h cpu2, but the cpu server
has the wrong sysname.

And the auth server has no way to get its own ip address, since I was
using the vmware vmnet1 dhcpd for the auth server to get an ip.

I'm going to try some of Dan's ideas for this one.

I really need these CPU servers to come up with no interaction, since
they're going to be sealed in a little box.

BTW cwlinux.com sells 1 Ghz. (!) C3 cards for ca. $100, and we're going to
make these into CPU servers. yeah, the C3 is a dog, but gee -- $100!

ron