From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: David Presotto To: 9fans@cse.psu.edu Subject: Re: [9fans] dhcpd and other CPU server fun. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Mon, 21 Apr 2003 08:09:56 -0400 Topicbox-Message-UUID: 93b0acc2-eacb-11e9-9e20-41e7f4b1d025 > 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?