On 20 June 2017 at 21:06, tiggersWelt.net (Support) <[email protected]> wrote: > Am 20.06.2017 um 20:32 schrieb Bernhard Reutner-Fischer: > [...] >>> @@ -261,17 +263,21 @@ static void option_to_env(uint8_t *option, uint8_t >>> *option_end) >>> *new_env() = dlist; >>> break; >>> case D6_OPT_CLIENT_FQDN: >>> - // Work around broken ISC DHCPD6 >>> + /* Work around broken ISC DHCPD6 >>> + * ISC DHCPD6 does not implement RFC 4704 >>> correctly: It says the first >>> + * byte of option-payload should contain flags >>> where the bits 4-8 are >>> + * reserved for future use and MUST be zero. >>> Instead ISC DHCPD6 just >>> + * writes the entire FQDN as string to >>> option-payload. We assume a >>> + * broken server here if any of the reserved bits >>> is set. >> >> you mean as literal string or as (DNS-)encoded domain name? > > Literal String. If otherwise I would have used udhcp's functions for this.
Did you tell them? They should really fix this on their end.. > > Haven't used ISC DHCPD6 for a while. If you wish to see some samples, I could > generate new ones. I would at least ask them if they are aware that they use this option in a way not conforming to RFC 4704. > Last time I touched the code, I was not sure what's required here. Thinking > about it twice it would make sense the make sure that option + olen + 4 does > not > exceed option_end. Am I right or am I missing something? right > > If I understood the "cap"-argument right, I would move the olen-calculation > to a > more general place and check it accordingly. I'll also rename it to something > more catchy. please do. TIA! _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
