On Mon, Nov 7, 2011 at 7:10 PM, Denys Vlasenko <[email protected]> wrote: > >> 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?
Of course, yes. For a example, take linux(busybox)-based CPE - router/gateway/access point. It has at least two interfaces - WAN & LAN. In case of DHCPv6 used by ISP to provide IPv6 access, we have to: 1) assign address(IA) on WAN interface 2) assing prefix(PD) on LAN interface Thus, we must support two interfaces, at least. >> 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. Yes, you are absolutely right, but in some places it is monopoly ISP :( And customers claims go to trash can - "windows works" it is typical answer. > 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? Will do this ASAP. Will write you after I done it. Regards, Leonid _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
