[PATCH] Added support for timezones on dhcp6-client (RFC 4833)

[Bernhard Reutner-Fischer]

On 20 June 2017 at 21:06, tiggersWelt.net (Support)
<support at tiggerswelt.net> 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!