[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [PATCH] udhcpc6 ll-address-, options- and release-/renew-fix
From:       Denys Vlasenko <vda.linux () googlemail ! com>
Date:       2017-03-27 20:47:51
Message-ID: CAK1hOcN6GrX=wH+5PvajiQPkOYxD+EhT1jnG+gT2k6B8_2pswQ () mail ! gmail ! com
[Download RAW message or body]

On Wed, Mar 8, 2017 at 12:15 PM, tiggersWelt.net (Support)
<support@tiggerswelt.net> wrote:
> this is my first post on the list and my first set of patches I wrote
> for busybox, so please forgive me if I'm missing something.
>
> We are currently trying to build an IPv6-only-environment with statefull
> autoconfiguration using busybox-udhcpc6 on client-side. During
> development I was wondering if anyone out there might be using udhcpc6
> as well es we encountered some severe bugs.
>
> This weekend I shared an initial patch on bugzilla [0], but had to find
> out some time later that someone already has done it years ago here on
> the mailinglist [1] - although the patch didn't make it into any release.
>
> At the moment the vanilla udhcpc6 uses a null-source-address when asking
> for dhcp6-autoconfiguration. As already said on the ticket and on the
> referenced mailinglist-post, this behaviour is wrong as the
> link-local-address of the interface should be used and any interface is
> supposed to have one.
> You'll find our patch attached to this e-mail (udhcpc-read-ipv6.patch)
> that has evolved since the post on bugzilla and is similar to the patch
> by Mathias Krüger - it also utilizes getifaddrs() but instead of using a
> new additional function, we had rewritten udhcp_read_interface().
>
> Using this patch it was no problem to acquire an IPv6-Address via DHCPv6
> using ISC DHCPD6 on server-side.
>
> But when we tried to use dnsmasq on server-side, udhcpc6 was unable to
> forward the acquired address to its setup-script although the
> IPv6-Address had been assigned by the server as we could see via
> tcpdump. We traced this issue down to a problem on how udhcpc6 parses
> DHCPv6-Options: When moving to next option, a pointer-address is
> increased and a length buffer is decreased by the length of the option.
> The problem is that it is done in this order:
>
>   option += 4 + option[3];
>   len_m4 -= 4 + option[3];
>
> But this has to be switched as the length is decreased by the length of
> the *next* option, not the current one. This affected both - internal
> checks if a required option is present and the function to expose
> options to the environment of the setup-script.
> There was also a bug parsing D6_OPT_STATUS_CODE Options, that made
> dnsmasq not work as udhcpc6 thought it is receiving a non-positive
> status-code (because it did not parse the status-code as required in RFC
> 3315).
> In addition we introduced basic support for RFC 3646 (OPTION_DNS_SERVERS
> and OPTION_DOMAIN_LIST) and RFC 4704 (OPTION_CLIENT_FQDN). All this
> option-related patches are located in the attached udhcpc-v6-options.patch.
>
> Last but not least: We wanted udhcpc6 to release it's IPv6-Addresses on
> quit (-R-commandline-option) which turned out to generate once again
> kind of garbage on the network-link.
> We tracked this down to two issues:
>
>  - udhcpc6 uses a variable called "srv6_buf" to send packets to
>    the dhcp6-server, but this variable gets never initialized correctly
>    and contained kind of a garbage-address
>
>  - The address of the dhcp6-server is usually a link-local-address,
>    that requires an interface-index when using connect() on an AF_INET6-
>    socket
>
> In the attached patch "udhcpc-fix-kernel-send.patch" we added an
> additional parameter for ifindex to d6_send_kernel_packet() and made
> d6_recv_raw_packet() to capture the address of the dhcp6-server and
> forward it to its callee.
>
> With these three patches applied busybox just worked like a charme in
> our IPv6-only-environment. The patches may required some review, but I
> would be very happy if you find them useful, too.

Applied with some edits, thanks!

Please pull latest git and confirm that it indeed builds and works for you.

I'm actually surprised that you needed so few changes to actually
make it work: you are the very first real user :)
Expect a few more bugs here and there...
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]