submit patch for udhcpc - addition of Option 43

Denys Vlasenko vda.linux at googlemail.com
Mon Mar 22 16:13:54 UTC 2010


On Mon, Mar 22, 2010 at 3:47 PM, Krebs, Steven <steven.krebs at intel.com> wrote:
> On Sunday 21 March 2010 17:01, Denys Vlasenko wrote:
>
>> You are using a config file specifically for option 43?
>> What will happen when users will eventually want other options?
>> 256 config files?
>
> I don't think there are 255 options left to implement, quite a few are already implemented (option 1 is the sub mask, option 6 is the list of ip addresses of DNS servers, option 51 is lease time etc...),

Implemented options are:

option 0x3c: -V,--vendorclass=CLASSID	Vendor class identifier
option 0x0c: -H,-h,--hostname=HOSTNAME	Client hostname
option 0x3d: -c,--clientid=CLIENTID	Client identifier
option 0x32: -r,--request=IP		IP address to request
option 0x51: -F,--fqdn=NAME             Ask server to update DNS
mapping for NAME

Not many if you ask me.

> and very few of those are vendor defined multiple-strings (see reference below).   I agree most of these can be handled by simple command line parameters, but I think this vendor_specific option is a little more difficult.   That being said, I need to further clarify you idea for how the command line syntax would look:
>
>>  Then create a new option for udhcpc, say -x OPT, which allows
>> udhcpc to add _any_ supported_ option_ (not only yours)
>> to the emitted packet.
>
> So for my OCAP use case would you expect the command line to look something like (example 1):
>
> udhcpc -i eth1 -s etc/udhcpc.script -V "OpenCable2.1" -x "OPT 43 SUB 2 ESTB SUB 3 ECM:ESTB SUB 4 $SERIAL_NO SUB 5 HW_VER1.0.0 SUB 6 FW_VER1.0.0 SUB 7 Boot_ROM25.008 SUB 8 001320 SUB 9 MODEL_NO_3100 SUB 10 'VENDOR NAME' SUB 54 0A859B428"

Something like -x "vendorinfo:suboption=value" might work.
Here "vendorinfo" is the DHCP option name.
Several -x options should accumulate.
In the future, other DHCP options might be supported this way
without changing the syntax, and old options can be specified
using it too: -x "hostname:string", -x "fqdn:string" etc.

> And you think read_opt() will handle the above syntax (specifically one of the first three examples).

It needs to be taught to do it.

> Then once the code reads the options and understands how many, I will dynamically allocate an array of options, with a dynamic array of sub strings and values, then  based on a new type OPTION_VENDOR_SPECIFIC finally concat the final option 43 string (of 256 or less bytes).

Basically yes. udhcpd already does something like that
in order to handle udhcpd.conf which can contain
directives like:

opt     dns     192.168.10.2 192.168.10.10
option  subnet  255.255.255.0
opt     router  192.168.10.2
opt     wins    192.168.10.10
option  dns     129.219.13.81   # appended to above DNS servers for a total of 3
option  domain  local
option  lease   864000          # default: 10 days

> One thing I need help with, I used statically allocated arrays
> in my previous prototype because I was not clear
> as to where/when to de-allocate, can you help me with that?

You never need to deallocate them. You create them once and then
reuse them for the life of the udhcpc instance.

-- 
vda


More information about the busybox mailing list