From: David Presotto <presotto@closedmind.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] dhcpd and other CPU server fun.
Date: Mon, 21 Apr 2003 08:09:56 -0400 [thread overview]
Message-ID: <ff0c39a2fe01c7e8166d5b7245f7d764@plan9.bell-labs.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0304210003180.15159-100000@maxroach.lanl.gov>
> 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?
next prev parent reply other threads:[~2003-04-21 12:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-21 6:14 ron minnich
2003-04-21 6:34 ` nigel
2003-04-21 12:09 ` David Presotto [this message]
2003-04-21 16:02 ` ron minnich
2003-04-21 14:29 ` Russ Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ff0c39a2fe01c7e8166d5b7245f7d764@plan9.bell-labs.com \
--to=presotto@closedmind.org \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).