unsolicited DHCP parameters [was: dhcpd and Vista]

[David W. Hankins]

On Thu, Nov 30, 2006 at 09:04:51PM -0600, Frank Bulk wrote:
> Microsoft Win2K DHCP server gives out responses for parameters the client
> does not even ask for.  I discovered this with a V-Brick product several
> years ago.  

I don't think they're the only ones.

> We were setting these up for non-static deployment across campus, and for
> the life of me I couldn't make it work.  So I connect to the serial
> interface and learn that the gateway and subnet mask aren't correct, they
> seem semi-random.  I then tried the V-Brick against a test Win2K box on a
> separate subnet and it works just fine!
> 
> Certain that ISC's DHCP server was in a good shape, I whipped out Ethereal
> to look at the packet exchanges of both Win2K's DHCP server and ISC.  The
> DHCP request from the V-Brick only asked for an IP address -- not even a
> subnet mask!  So ISC's DHCP server wasn't handing it out.  And Win2K was
> providing it, unannounced.

This happens with such frequency, I've considering making a config
scoped server configurable value that dumps DHCP packet contents (so
you can turn packet dumps on for one host record, say) to the log.

Or maybe dump "most recent entire packet contents" to the lease db,
in config language.  Some of you more paranoid types might even turn
that on globally.  That's a bit trickier because it would hold the
whole packet buffer (which is most-pessimally sized to 8KB I think)
from being reallocated.

But since you're unlikely to find such a tunable parameter on the
Windows server, you'd still have to use ethereal on one end.

And we have other features in higher demand of course.

> To resolve the problem I found an option in ISC's DHCP to give out the
> subnet mask and gateway anyways -- problem solved.

This is something we do in 3.1.0 now.  Specifically for the subnet
mask.  I didn't think to add the routers option, we hadn't had any
reports of clients that don't place that on the PRL (if they have
one).  I can add that the same way.


The thing is the PRL is not just "options I will use if you give them
to me", it's also "the order of priority".

There's a limited amount of space for options in DHCPv4 packets, only
guaranteed a few hundred bytes and many clients have problems with
UDP fragments (upper-limited to MTU), so it's quite possible to run
out.  By putting them on the packet in PRL order, we ensure that the
options most important to the client are present before we're out of
space.

The other thing is that DHCP's expected behaviour is different
depending on wether or not the client supplies a PRL at all.  If
they give us a PRL, that tells us what they can use.  If they don't,
then we have no way of differentiating, and they might be able to
use any and all options.


So we start out processing with a list of options we want to send (if
we have a value configured) no matter what...PRL or no...these are
"protocol mandatory", if you will:

        priority_len = 0;
        priority_list[priority_len++] = DHO_DHCP_MESSAGE_TYPE;
        priority_list[priority_len++] = DHO_DHCP_SERVER_IDENTIFIER;
        priority_list[priority_len++] = DHO_DHCP_LEASE_TIME;
        priority_list[priority_len++] = DHO_DHCP_MESSAGE;
        priority_list[priority_len++] = DHO_DHCP_REQUESTED_ADDRESS;
        priority_list[priority_len++] = DHO_ASSOCIATED_IP;

If there is a PRL, we concatenate it (minus disallowing the client's
request of the relay agent information option) to what we've got so
far above, and then add:

                /* If the client doesn't request this option explicitly,
                 * to indicate priority, consider it lowest priority.  Fit
                 * in the packet if there is space.
                 */
                if (priority_len < PRIORITY_COUNT)
                        priority_list[priority_len++] = DHO_FQDN;

                /* Some DHCP Servers will give the subnet-mask option if
                 * it is not on the parameter request list - so some client
                 * implementations have come to rely on this - so we will
                 * also make sure we supply this, at lowest priority.
                 */
                if (priority_len < PRIORITY_COUNT)
                        priority_list[priority_len++] = DHO_SUBNET_MASK;

Note that we do this in order to put these options at lowest priority.
As by providing the PRL, the client has indicated a priority.

Otherwise, if there is no PRL, we add at higher priority:

                priority_list[priority_len++] = DHO_SUBNET_MASK;
                priority_list[priority_len++] = DHO_ROUTERS;
                priority_list[priority_len++] = DHO_DOMAIN_NAME_SERVERS;
                priority_list[priority_len++] = DHO_HOST_NAME;
                priority_list[priority_len++] = DHO_FQDN;

And then codes for all configured options are appended (the config
hash table is searched).


Once that's done, the new combined PRL is filtered for unique
codes (later instances of a code we've already seen are removed),
and the final list is iterated in series to put options in the
packet.


> I filed a bug report with V-Brick, but it was not addressed for at least a
> year, after which I left the school.  

I'm sure because it works with Windows that they don't consider it
a bug.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins