On Sunday 21 March 2010 13:53, Denys Vlasenko wrote: > On Wednesday 17 March 2010 18:40, Krebs, Steven wrote: > > Hi, you seem to be the main developer for the udhcpc functionality. > > Have you had a chance to take a look at this patch yet? > > Thanks for pinging me, I somehow missed it. > > > All, > > > > Sorry if this is a little rough, this is my first submission for busybox. > > > > On some networks (in my case for a cable modem) the dhcp server requires > > dhcp option 60 and option 43. dhcp option 60 is already supported > > with the -V command line option in udhcpc. It looks to me like > > option 43 is not supported. I have implemented a prototype for option 43.
Aha, understand what you want to achieve. You want udhcpc to have more options in its DISCOVER and/or REQUEST packets. > > dhcp option 43 is known as the vendor specific option. I have chosen > > the command line option -x (as -v was already taken). > > I have made -x an optional argument with an optional value. > > By default when -x is used, udhcpc will read the file > > /etc/udhcpc.vendor_specific and parse the suboptions within > > to create option 43. One may also optionally specify a path > > and filename after -x. In my version of busybox (older) getopts32 > > does not allow a space after the -x when the value is optional. > > So one could specific a different path for the file as so: > > > > udhcpc -x/tmp/udhcpc.vendor_specific > > > > Dhcp option 43 is a concatenation of substrings. > > For my purposes I needed to implement it for (OpenCable) > > OC-SP-HOST2.1-CFR-I10-091211 which requires suboptions > > 2,3,4,5,6,7,8,9,10 and 54. > > http://www.cablelabs.com/specifications/OC-SP-HOST2.1-CFR-I10-091211.pdf > > So that is what is currently supported, but I tried to make > > the implementation generic and it can be expanded fairly easily. > > > > The udhcpc.vendor_specific config file is KEY value string pairs > > separated by whitespace. Example: > > > > SUBOPTION2 ESTB > > SUBOPTION3 ECM:ESTB You are using a config file specifically for option 43? What will happen when users will eventually want other options? 256 config files? I think at the very least the config file should be generic enough to be extensible to more options. Or maybe we can avoid having a file just yet - so far udhcpc was managing with command line options. udhcp already has machinery for converting binary option representation into string - it is used when udhcpc needs to export server's options into environment variables And it has machinery for converting strings into options - this code is responsible for implementing "opt OPTION VALUE" directive in udhcpd.conf file. You need to extend this code - teach it to handle a new type of option (since option 43 is neither a string nor an IP address), and then hook this code up to a new udhcpc option. To this end, add new #define DHCP_VENDOR_INFO to options.h, and add the new _type_ of option, OPTION_VENDOR_INFO, in the same file. Add it to dhcp_options[], dhcp_option_strings[], dhcp_option_lengths[]. Then teach read_opt() function to how to convert a string into a binary representation of OPTION_VENDOR_INFO option, and teach xmalloc_optname_optval() to do the opposite conversion. 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. This should be not so hard - use read_opt(). -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
