On Tue, Nov 8, 2011 at 8:03 AM, Vladislav Grishenko <[email protected]> wrote:
>> From: Denys Vlasenko [mailto:[email protected]]
>> On Fri, Nov 4, 2011 at 8:04 AM, Leonid Lisovskiy <[email protected]>
> wrote:
>> > On Fri, Nov 4, 2011 at 4:54 AM, Denys Vlasenko
>> <[email protected]> wrote:
>> >>
>> >> I think that maybe emulating existing dhcp6c tool with its config
>> >> file and command line is not a good idea. This will make DHCP and
>> >> DHCPv6 clients in busybox to be very different.
>> >
>> > Agree, but redesign of applet I was postpone for the future. Seems to
>> > be, this time is come...
>> > But I don't see any way to simplify dhcp6c config file like udhcpc
>> > since we can have several IA/PD.
>>
>> I prefer to follow the model of udhcpc, where one instance of client
> daemon
>> configures one interface.
>
> This will completely break rfc3633 support.
[...reading rfc3633...]
I don't think so. See option -x below:
$ busybox udhcpc6 --help
BusyBox v1.20.0.git (2011-11-07 15:35:32 CET) multi-call binary.
Usage: udhcpc6 [-fbnqvoRB] [-i IFACE] [-r IP] [-s PROG] [-p PIDFILE]
[-x OPT:VAL]... [-O OPT]... [-P N]
-i,--interface IFACE Interface to use (default eth0)
-p,--pidfile FILE Create pidfile
-s,--script PROG Run PROG at DHCP events (default
/usr/share/udhcpc/default.script)
-B,--broadcast Request broadcast replies
-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
-n,--now Exit if lease is not obtained
-q,--quit Exit after obtaining lease
-R,--release Release IP on exit
-S,--syslog Log to syslog too
-P,--client-port N Use port N (default 68)
-O,--request-option OPT Request option OPT from server (cumulative)
-o,--no-default-options Don't request any options (unless -O is given)
-r,--request IP Request this IP address
-x OPT:VAL Include option OPT in sent packets (cumulative)
Examples of string, numeric, and hex byte opts:
-x hostname:bbox - option 12
-x lease:3600 - option 51 (lease time)
-x 0x3d:0100BEEFC0FFEE - option 61 (client id)
-v Verbose
Signals:
USR1 Renew lease
USR2 Release lease
Option -x can be extended to support options with arbitrary format.
Thus, with some coding, IA_PD can be requested via -x.
Then, the second half of work is to export values (in this case, prefix(es),
their lifetime) from server reply to $envvars so that script can use them.
>> >> Maybe we need a udhcpc6 applet which is similar to udhcpc.
>> >>
>> >> For one, it should handle one interface. This simplifies many things.
>> >
>> > One upstream(listen) interface - yes. But simplification to single
>> > downstream (IA, PD) interface seems to be bad idea.
>>
>> Can you elaborate why is it a bad idea?
>
> This is bad idea, because it should be only one and same dhcpv6 client (id)
> which is responsible for:
> 1) receiving/assigning address to interface it running on
> 2) receiving/assigning prefix(es) to sub-interface(s) as per rfs3633
udhcpc handles all configurational tasks by running a script. This is
a VERY generic mechanism. The script certainly can "assign prefix(es)
to sub-interface(s) as per rfs3633". It can do much more than that.
For example, on my machines the script (re)starts ntpd if needed.
Imagine the awkwardness of hard-coding *that* into C code.
--
vda
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
