Subject: Re: README: changes to config, to support dump device configuration
To: Matthias Drochner <firstname.lastname@example.org>
From: Ted Lemon <email@example.com>
Date: 06/18/1997 11:39:59
> It was actually a bit more: In my environment, he client gets a different
> configuration depending on which subnet it is physically located in.
> The bootptab can hold any number of entries for one hardware
> address, the server scans for matching ones (using the requested filename
> too) and sends the reply to the right subnet.
This is how dhcpd works as well. In fact, it's incapable of working
any other way.
> -Is this scenario acceptable?:
> ROM issues DISCOVER, takes first OFFER, sends
> REQUEST, gets ACK.
> Kernel sends REQEST with same server ID and uses address from ACK.
If the BOOT proms provided this sort of support, this would be a
reasonable thing to do. Although I would prefer that the boot PROM
be a little more picky about which address it takes. Ideally, the
address acquired at the previous boot would be retained in EEPROM so
that the PROM could do an INIT-REBOOT (just a DHCPREQUEST) if
possible. Right now this is a pipe dream, though.
> -Can the filename field in requests be used by the DHCP server?
> (I like the semantics to look up first <filename>.<hostname> and
> fall back to <filename>.)
If you can document how this is supposed to work, and convince me that
it's reasonable, then I can implement it. From what you've said so
far, I'm not sure what you mean.
> -How would you manage to have different TFTP and NFS servers
> (TFTP for kernel, NFS for root file system) - there is only one
> "siaddr" field.
How about passing as the root filesystem name ``froboz:/roots/myclient''?
> -Are there still user defined tags (ala T144)?
Yes. Actually, the protocol expands this somewhat, although
currently I don't support this as well as I'd like.