On Wed, Oct 20, 2010 at 4:03 PM, Sam Liddicott <[email protected]> wrote: > > On 20/10/10 14:39, Denys Vlasenko wrote: > > On Wed, Oct 20, 2010 at 2:18 PM, Sam Liddicott <[email protected]> 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
