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

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

[ron minnich]

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

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

[David Presotto]

Doing a ping before giving out an address is a suggestion from
an RFC, don't remember which.   It solves a world of problems;
systems that have grabbed an unused address without using dhcp,
dhcp servers that have lost their database, systems that overrun
their lease (lots of these amongst dumb clients)...

Our dhcpd does it too.  If we don't have a
static binding for a system AND the system has never gotten a
dhcp address from us before we look for the oldest (we think unused)
binding and then do a quick ping to make sure it really is unused.
If noone answers the ping, we hand the address out.

Vmware is being reasonable there.

The random

	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]

packet that you see might be 172.16.189.254 sending a dhcp request
to refresh its dhcp lease.  Are you giving our really short leases?
I don't know the output of tcpdump that well.  Having a client address
(C:172.16.189.254) in a request is a sure sign of a renewal.  However,
there should also be DHCP options in the packet.  Does tcpdump not
print them?

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

[Russ Cox]

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

you said before that you were setting sysname=p9 in your
termrc or cpurc.  that might have something to do with it.

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

[ron minnich]

On Wed, 23 Apr 2003, Russ Cox wrote:

> you said before that you were setting sysname=p9 in your
> termrc or cpurc.  that might have something to do with it.

I yanked that out, but I'll make good and sure I yanked it out.

Dave was right, that .254 DHCP was from the auth server.

It was rather funny to think about, as .254 was getting .254 DHCPs and
ignoring them. If you know Jackie Chan movies and The Prisoner, it went
like this:

Jackie Chan: WHO AM I?
Number .254: That would be telling

I fixed the auth thing with the ndb/query hack that Dan (I think it was
Dan) recommended. Life is getting better now as the DHCP is all run from
Plan 9, not linux dhcp.

BTW snoopy gives much more useful output than tcpdump ...

ron

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

[Micah Stetson]

Presotto said:
> 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]
...
> I don't know the output of tcpdump that well.  Having a client address
> (C:172.16.189.254) in a request is a sure sign of a renewal.  However,
> there should also be DHCP options in the packet.  Does tcpdump not
> print them?

Then Ron Minnich said:
> BTW snoopy gives much more useful output than tcpdump ...

I have no doubt that snoopy is more straightforward and possibly
more flexible than tcpdump, though I haven't had a chance to play
with it, yet.  But tcpdump can give better output than the above.
By default, however, it only captures the first 68 bytes of every
packet -- the [|bootp] at the end of the message means that the
packet was truncated in the middle of the bootp information.  If
you add '-s 0' to the command line, it will capture whole packets
and give you better output.

Micah

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

[David Presotto]

Of course, I never did quite understand why it was called tcpdump...

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

[Boyd Roberts]

> Of course, I never did quite understand why it was called tcpdump...

ask mogul

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

[Boyd Roberts]

> > I don't know the output of tcpdump that well.

tcpdump = find(1)