[Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6 address range are not notified on address range change

[Simon Kelley]

On 18/09/18 23:03, line wrap clean up wrote:
> On Tue, Sep 18, 2018 at 11:13:27PM +0200, Andrey Vakhitov wrote:
> Hi Simon,
> 
>>> I've set it up as you suggested, initially name resolution seems
>>> to work fine. But after some days of operation (and some nightly
>>> reconnects) dnsmasq seems to loose associated IPv6 adresses: DNS
>>> request reports only IPv6 address assigned via DHCP. The SLAAC-based
>>> IPv6 addresses on hosts are present and correct. How can I investigate
>>> and fix this issue?
> 
>> Look in the log for lines that look like
>>
>> DHCPv4-derived IPv6 names on ........
>>
>> which should occur after a reconnect with a different address which
>> causes new DHCP address ranges to be constructed.
>>
>> After that happens, dnsmasq will take a guess at the IPv6 addresses
>> that hosts will assign themselves, based on the network address and
>> the MAC address of the host (transformed into EUI-64) It then starts
>> to ping those addresses, and when it gets a reply, it will log
>>
>> SLAAC_CONFIRM(interface) <address> <hostname>
>>
>> and start using the address/name in the DNS.
>>
>> Once confirmed, the addresses remain valid until the DHCPv4 lease it's
>> based on expires or goes though init-reboot state or the MAC address
>> or interface it's accessible by changes.
>>
>> The only other thing that will delete these addresses in a new address
>> appearing and a new dhcp range being created, hence it's interesting
>> to look at what happens in the logs after each of those events.
> 
> Strange thing: sometimes after reconnect I can observe expected behaviour
> (like you described it, see log 1), sometimes not (SLAAC-CONFIRM is missing,
> see log 2)
> 

Is it possible that those hosts are sometimes down or disconnected?

FWIW the strategy in the code is to continue trying to ping putative
addresses more-or-less forever, with increasing backoff, _except_ when a
call to sendto() returns EHOSTUNREACH (no route to host) which causes
the code to give up.

I confess I have no idea why it's like that,  and the git commit
messages don't really give much clue. Even more annoying, the original
code logged when giving up, but  that was subsequently removed, with
equally unsatisfactory commits.

Cheers,

Simon.