aboutsummaryrefslogtreecommitdiff
path: root/networking/libiproute/ll_proto.c
diff options
context:
space:
mode:
authorDenys Vlasenko <vda.linux@googlemail.com>2017-03-27 22:22:09 +0200
committerDenys Vlasenko <vda.linux@googlemail.com>2017-03-27 22:41:59 +0200
commit64d58aa8061c7c848cf0fd37de3ccbb8582d0fc5 (patch)
tree8ff5d55d0e52a594957036268915c50a7c32a0cb /networking/libiproute/ll_proto.c
parente09f5e3045fc90547be9ec49c63b633d103cfc45 (diff)
downloadbusybox-64d58aa8061c7c848cf0fd37de3ccbb8582d0fc5.tar.gz
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>
Diffstat (limited to 'networking/libiproute/ll_proto.c')
0 files changed, 0 insertions, 0 deletions