On Mon, Mar 22, 2010 at 3:47 PM, Krebs, Steven <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
