Alex <xela@MIT.EDU> writes:

> dhcpd replies with a DHCPOFFER with the bootfile-name option.  In
> conformance with rfc2132, dhcpd sets the byte after the last
> option in the options field, which is in this case necessarily the
> bootfile-name, to 255.  The PXE ROM incorrectly treats this as
> part of the filename, and tries to tftpboot pxeboot_ia32.bin0xff.
> My initial "0xff appended" was shorthand for all of this; there's
> no risk they'll append a different value in the next rev.

Is it guaranteed that bootfile-name will be the last option, or is
that an implementation detail of the dhcp server and this particular
configuration?

> Most sysadmins use tftp rarely.  They don't have its intricacies
> loaded into their forebrains, and they don't especially want to:
> the least surprising thing for a sysadmin who's trying to netboot
> a machine with one of these early-generation Intel PXE ROMs is 
> for it to just boot.  I got surprised a few months ago, and
> consequently became a lot more intimately acquainted with tftp
> than I ever wanted to be.  I don't see any point in any other
> sysadmin having to tread over that same ground.

I agree that they shouldn't have to debug it this thoroughly, but
improved error logging is suffient. I still think that "magically"
picking a file with a different name than requested by the client is a
very, very weird thing to do, and it needs to be justified with a
better rationale than "a sysadmin won't even have to look at a log to
see what is broken".

> IMHO Postel's language in RFC 791, where I believe he first stated
> the robustness principle, could hardly be more clear:

I have concluded that the robustness principle, when extended to the
degree of "accept obviously incorrect input, *even if the intent is
clear*", is wrong. It was a well-meaning idea, but it was concieved of
in a setting where such errors could be corrected by a friendly chat
with the implementor at the next get-together.

In practice today, it permits incorrect implementations to
interoperate, and even flourish. Social and economic forces have
proven insufficent to discourage incorrect implementations when they
work "well enough"; the only way to discourage them is to force them
to be fixed by denying interoperability in the first place.

        - Nathan