Patch for udhcpc hwtype

Denys Vlasenko vda.linux at googlemail.com
Wed Oct 20 14:18:24 UTC 2010


On Wed, Oct 20, 2010 at 4:03 PM, Sam Liddicott <sam at liddicott.com> wrote:
>
> On 20/10/10 14:39, Denys Vlasenko wrote:
>
> On Wed, Oct 20, 2010 at 2:18 PM, Sam Liddicott <sam at liddicott.com> wrote:
>
> So... if I fix the indenting, is the patch likely to be accepted?
>
> I proposed deleting -c altogether, and using -x 61:hexstring
> to specify client id.
>
> To make it easier for users to see how to use -x,
> help text can have examples added to it:
>
> # ./busybox udhcpc --help
> BusyBox v1.18.0.git (2010-10-20 13:29:07 CEST) multi-call binary.
>
> Usage: udhcpc [-fbnqvoCR] [-i IFACE] [-r IP] [-s PROG] [-p PIDFILE]
> 	[-H HOSTNAME] [-V VENDOR] [-x OPT:VAL]... [-O OPT]... [-P N]
>
> 	-i,--interface IFACE	Interface to use (default eth0)
> 	-p,--pidfile FILE	Create pidfile
> 	-r,--request IP		IP address to request
> 	-s,--script PROG	Run PROG at DHCP events (default
> /usr/share/udhcpc/default.script)
> 	-t,--retries N		Send up to N discover packets
> 	-T,--timeout N		Pause between packets (default 3 seconds)
> 	-A,--tryagain N		Wait N seconds after failure (default 20)
> 	-f,--foreground		Run in foreground
> 	-b,--background		Background if lease is not obtained
> 	-S,--syslog		Log to syslog too
> 	-n,--now		Exit if lease is not obtained
> 	-q,--quit		Exit after obtaining lease
> 	-R,--release		Release IP on exit
> 	-P,--client-port N	Use port N (default 68)
> 	-a,--arping		Use arping to validate offered address
> 	-O,--request-option OPT	Request option OPT from server (cumulative)
> 	-o,--no-default-options	Don't request any options (unless -O is given)
> 	-x OPT:VAL		Include option OPT in sent packets (cumulative)
> 				Examples: -x hostname:bbox -x 61:0100ffee11cc55
> 	-F,--fqdn NAME		Ask server to update DNS mapping for NAME
> 	-H,-h,--hostname NAME	Send NAME as client hostname (default none)
> 	-V,--vendorclass VENDOR	Vendor identifier (default 'udhcp VERSION')
> 	-C,--clientid-none	Don't send MAC as client identifier
> 	-v			Verbose
>
> Does this look ok? Is help text sufficiently clear?
>
> I don't fight your proposal but I don't offer a patch to implement it either. I don't know if anyone else does.

I already did it in git.

> I note that you don't propose getting rid of -V or -H.

I do think about getting rid of -V, -H and -r. -x covers them too.

> For me, -c is quite normal, I just needed to specify the hwtype of 0.
> The RFC you quoted stated "A hardware type of 0 (zero)
> should be used when the value field contains an identifier
> other than a hardware address (e.g. a fully qualified domain name)."

My read of the RFC is that client ID can be *any binary data*. An ASCIZ string
is not suited for that: for one, how would you include a zero byte in a string?
Therefore -c CLIENTID is a crippled format from the start, it allows only *some*
client IDs (namely, string ones), not any possible ID.

Adding *another* option to fix -c seems strange: it makes more sense
to just fix -c.

> The example seems real enough in the RFC an is real enough for me
that I don't see why we would want to make people convert an ASCII
string into hex.

If there is sufficient need for string client IDs, then it should be added
as a new option type (call it OPTION_0STRING because it's a string with
prepended zero), common.c should be taught to parse it, and then
DHCP_CLIENT_ID should be declared as such in dhcp_optflags[],
and given a name in dhcp_option_strings[].

After this, in addition to hex format -x 61:0062626f78 you will be
able to use more convenient -x clientid:bbox to achieve the same result.

-- 
vda


More information about the busybox mailing list