dhcpcd-discuss

On Fri, Mar 16, 2018 at 9:06 AM, Brenden Blanco <bblanco@xxxxxxxxx> wrote:
> On Sat, Mar 10, 2018 at 3:52 AM, Roy Marples <roy@xxxxxxxxxxxx> wrote:
>> On 09/03/2018 13:13, Roy Marples wrote:
>>>
>>> On 08/03/2018 22:31, Brenden Blanco wrote:
>>>>>
>>>>> I'm running dhcpcd on a single interface in dual stack and IPv6-PD.
>>>>> Archlinux recently updated to 7.0.1 which broke IPv6 for me.
>>>>>
>>>>> After doing git bisect I found that commit ef53a17 (DHCPv6: listen on
>>>>> all
>>>>> IPv6 addresses for active interface) responsible for this. Reverting it
>>>>> on
>>>>> master solves the issue for me.
>>>>>
>>>>> I'm running archlinux with systemd-networkd for everything else but the
>>>>> WAN
>>>>> interface.
>>>>> I can provide additional information if needed.
>>>>
>>>>
>>>> I came across this thread while googling, and I believe that I am
>>>> hitting it as well. Specifically, it seems that my ISP (wave-G
>>>> broadband) is ignoring any solicit requests that do not come from port
>>>> 546 (packets are blackholed).
>>>>
>>>> Besides reverting ef53a17, could we consider introducing a config
>>>> option to allow the source port to be overridden, as a buggy ISP
>>>> workaround?
>>>
>>>
>>> The problem here is simple, but hard to solve.
>>> dhcpcd is not running in master mode, which means you could have >1 dhcpcd
>>> instance handling dhcp6 on different interfaces. However, only one instance
>>> can actually bind the unspecified address to port 546. As we don't know
>>> which instance can win, we just don't bind it in non master mode, so the
>>> source port is random.
> Yup, understand that part, it's kinda ugly.
>>>
>>> We could bind to the LL address for the interface, but that in turn means
>>> we *may* not be able to unicast messages to the DHCPv6 server if it's asking
>>> for that.
>>> So a short term fix would be to ignore the unicast option in non master
>>> mode and bind to the LL address.
>>
>>
>> Fixed here hopefully:
>> https://roy.marples.name/git/dhcpcd.git/commit/?id=3715c0a1b3fbb92dd08d07d5f6e8f3afa833ff0d
>>
>> Can you both please test it and report back?
> I will give it a try this weekend, hopefully.

I can confirm that this works for my scenario.
>>
>> Roy