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. >> 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? >> Second, we don't need to implement auth features, at least not at once >> - organizations paranoid enough to authenticate DHCPv6 traffic probably >> should not use dynamic IP addresses at all! > > Agreed. I can easy exclude this feature from applet. > >> Third, we might choose to support only the setup where there is only >> one DHCP server, not many - udhcpc currently simply uses the first >> server response (doesn't try to collect more responses and pick >> "best one"), and people aren't complaining. This means that the >> multi-server DHCP setups must be a very rare thing. > > Unfortunately, a few ISP's provide multi-server DHCP setups. Most of > them are buggy, but they are exists :( > For example - Beeline ISP, Ekaterinburg, Russia. If "always select very first received server reply" doesn't work for them, then their installation is broken IMO. >> Fourth, it should not set IPv6 addresses (ifaddrconf() func does that >> in current patch). It should just export data to environment and run >> a script, just like udhcpc does. > > i.e. like all others (ISC dchp client, for example). When I start > conversion of wide-dhcpv6, I don't think that it is simplifies code > too much. At this moment, I have to agree with you. Should we take ISC > dchp reasons list from starting point? > >> Do you want to work on it, or you don't find this to be a good idea? >> I probably can work on it this weekend... Here is a compilable code I just dropped into git: http://git.busybox.net/busybox/commit/?id=9ba75048c0099ed90b9a64cb7bb57bf12be93528 It's a moderately scary hack, but it builds and even sends dhcpv6-looking packets with correct UDP checksum! ;) d6_dhcpc.c file is basically a hacked copy of dhcpc.c - I retained the same logic we use in udhcpc. I deleted all logic which exports $envvars for now. I plan to add it back after I add code which parses dhcpv6 options returned by server. After the applet will reach the stage where it actually works in a simple setup (say, successfully sets IPv6 address + routing + DNS), then we can take a good look at possibilities to commonalize some bits in udhcpc and udhcpc6. Can you take a look at the code? Is basing future work on it ok with you? -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
