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