diff options
author | Denys Vlasenko <vda.linux@googlemail.com> | 2017-03-27 22:22:09 +0200 |
---|---|---|
committer | Denys Vlasenko <vda.linux@googlemail.com> | 2017-03-27 22:41:59 +0200 |
commit | 64d58aa8061c7c848cf0fd37de3ccbb8582d0fc5 (patch) | |
tree | 8ff5d55d0e52a594957036268915c50a7c32a0cb /shell/ash_test/ash-signals/signal8.right | |
parent | e09f5e3045fc90547be9ec49c63b633d103cfc45 (diff) |
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 'shell/ash_test/ash-signals/signal8.right')
0 files changed, 0 insertions, 0 deletions