udhcp6: fix problems found running against dnsmasq
authorDenys Vlasenko <vda.linux@googlemail.com>
Mon, 27 Mar 2017 20:22:09 +0000 (22:22 +0200)
committerDenys Vlasenko <vda.linux@googlemail.com>
Mon, 27 Mar 2017 20:41:59 +0000 (22:41 +0200)
commit64d58aa8061c7c848cf0fd37de3ccbb8582d0fc5
tree8ff5d55d0e52a594957036268915c50a7c32a0cb
parente09f5e3045fc90547be9ec49c63b633d103cfc45
udhcp6: fix problems found running against dnsmasq

Patch is based on work by tiggerswelt.net. They say:
"
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).
"

Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
networking/udhcp/d6_common.h
networking/udhcp/d6_dhcpc.c