Glenn.Satchell at uniq.com.au
Fri Jun 8 14:21:58 UTC 2007
>Subject: RE: Vendor Options
>Date: Thu, 7 Jun 2007 10:56:33 -0400
>From: "Michael Melia Jr." <mjm at petrocelli.com>
>Thanks Glenn. That worked for me except I made the following change:
>match if option dhcp-vendor-identifier = "wyse-1000";
>match if option vendor-class-identifier = "wyse-1000";
>which is what you probably meant anyway.
Yes it was.
>However, everything I previously tried involved creating a option name
>space, defining options in that space, creating a "vendor-classes" class
>and creating a subclass for wyse. Pretty much everything out of the man
>pages for dhcp-options under vendor encapsulation. However, I could not
>get it to work. Is there a benefit to using that over the way you
>described. Could someone rework this examples into that form so I can
>understand what I was doing wrong?
The dhcp options are defined in the RFCs and specify "standard" things
that many different clients might need to know. In dhcpd you can see
them by looking in the source distribution at the table in the file
common/tables.c at the section that begins after "/* DHCP Option names,
formats and codes, from RFC1533."
vendor-option-space encodes things into one of these dhcp options, the
so-called "vendor encapsulated options", option number 43. The format
of option 43 is decided by the vendor of that piece of hardware. It's a
way of sending any pieces of information in an arbitrary format that
only that device will understand.
So in this case, if the device expects the settings to be in the
standard dhcp options then that is completely different to the vendor
More information about the dhcp-users