another request-options question

Denys Vlasenko vda.linux at googlemail.com
Thu Oct 22 09:17:33 UTC 2009


On Thu, Oct 22, 2009 at 2:28 AM, Christopher Barry
<christopher.barry at rackwareinc.com> wrote:
>> > I'm defining an option in ISC dhcpd to send a non-standard server IP to
>> > clients. I'm planning on using -O to have the client ask for it.
>> >
>> > Will this option appear as a variable in my environment as the name of
>> > the option I define?
>>
>> Looking at the code, no, it won't. Only those in dhcp_option_strings[]
>> will.
>>
>> BTW, any "-O option" is also checked against dhcp_option_strings[]
>> and won't be accepted if it is not found there. You can't request
>> options which udhcpc doesn't know. Understandably, because udhcpc
>> needs to know their *format* - is it an IP? String? Integer?
>> Pair of IPs? etc.
>
> So, when I define the option in ISC dhcpd, and give it a type of
> ip-address, this format specification data is not sent to the client?
> How can any dhcp client understand new options defined on the server? Is
> this limitation particular to udhcpc?

No, this is a limitation of DHCP protocol. Every option has this format:

<OPTION CODE (1 byte)>  <OPTION LENGTH (1 byte)> <OPTION DATA>

You can skip options you do not know, but you cannot use them.
There is no type information in them.
For example, you see an unknown option 0xEE:

0xEE 0x04 0x41 0x42 0x43 0x00

It's 4 bytes long, but is its value an IP address or a string "ABC"?

> Should I be looking at using another dhcp client to solve this? Or, is
> adding this option to udhcpc source fairly simple? How have others
> tackled this problem?

Teaching udhcpc a new option is not hard. Yust pick a similar existing
option, grep for it:

# grep DNS_SERVER *
options.c:	{ OPTION_IP | OPTION_LIST     | OPTION_REQ, 0x06 }, /*
DHCP_DNS_SERVER    */
options.c:	"dns" "\0"         /* DHCP_DNS_SERVER     */
options.h:#define DHCP_DNS_SERVER         0x06

and add your option similarly.


>> > Assuming so, will this variable be in the environment of the script that
>> > fires off udhcpc, or will it be available in a script run by an event?
>>
>> I don't understand this question. There is only one script which
>> is run by udhcpc, the question assumes there are two kinds of scripts.
>
> I was assuming - yes. I made the leap that each even could run a
> separate script. Are these simply handled in a single script?

Yes. The same script is run on every state change.
It can differentiate by looking at $1 and environment.

See examples/udhcp/simple.script
and examples/udhcp/sample.script

--
vda


More information about the busybox mailing list