From mboxrd@z Thu Jan 1 00:00:00 1970 From: ron minnich To: 9fans@cse.psu.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [9fans] my cpu-in-vmware problem: it's weird :-) Date: Tue, 22 Apr 2003 21:49:15 -0600 Topicbox-Message-UUID: 96458214-eacb-11e9-9e20-41e7f4b1d025 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