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

2018-10-06 Thread Andrey Vakhitov 
Hello Simon,

>> I've reactivated the patch locally and observing it since 4 days. Todays 
>> night associated 
>> IPv6 names got lost again directly during IP prefix change process, the log 
>> shows it clearly
>> (see log 1). So I would vote again for retrying during some extended 
>> timeframe even if the
>> host isn't reachable.

> OK, done. Patch is here:
>
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=ee1df06aabaa8f212eaa7102f6d62cb25bfb35e9

Thanks a lot for your great support! I've applied the patch and will monitor 
the behaviour.

Best Regards,
--
Andrey Vakhitov

E-Mail:  and...@vakhitov.netStuttgart, Germany





___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2018-10-03 Thread Andrey Vakhitov 
Hello Simon,

>>> 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.
>> 
>> Is it possible that it collides with route changes happening during 
>> renumbering? Is it possible to keep pinging for some prolonged period 
>> (may be configurable, let's say 10 minutes) ?
>> 
>>> 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.
>> 
>> Do you have a reference to appropriate changesets? Maybe I could make 
>> local patches and collect more information on this issue... Well, I'm 
>> leaving for a week right now, so I have to put it on hold for a week, 
>> but I'd continue investigation after that if I'd know there to put the 
>> traces ...

> Reversing this patch
> ...
> Will give you logging for the event of giving up on "no route to host"
> error. If we can establish that's what's happening, it should be possible to 
> tweak the strategy to fix the problem.

I've reactivated thepatch locally and observing it since 4 days. Todays night 
associated IPv6 names got lost again directly during IP prefix change process, 
the log shows it clearly (see log 1). So I would vote again for retrying during 
some extended timeframe even if the host isn't reachable.
Renumbering during previous 3 nights went smooth, see log 2 for example

- log 1 -
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: unauthenticated RECONFIGURE6 from 
fe80::7eff:4dff:fe03:2c18
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: RECONFIGURE6 from 
fe80::7eff:4dff:fe03:2c18
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: broadcasting RENEW6 (xid 0x4a0693), 
next in 10.5 seconds
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: DHCPv6 REPLY: prefix mismatch
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: deleting address 
2001:16b8:224c:d2fc::1/64
Okt 03 04:50:57 rtr dhcpcd[6467]: lo: deleting reject route to 
2001:16b8:224c:d2fc::/62
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: deleting route to 
2001:16b8:224c:d2fc::/64
Okt 03 04:50:57 rtr dhcpcd[6467]: dmz0: deleting address 
2001:16b8:224c:d2fd::1/64
Okt 03 04:50:57 rtr dhcpcd[6467]: dmz0: deleting route to 
2001:16b8:224c:d2fd::/64
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: soliciting a DHCPv6 lease
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: delaying SOLICIT6 (xid 0x88553e), next 
in 0.3 seconds
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 
2001:16b8:224c:d2fd::, old prefix for dmz0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 
2001:16b8:224c:d2fc::, old prefix for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: no address range available for DHCPv6 
request via lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: no address range available for DHCPv6 
request via lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: no address range available for DHCPv6 
request via dmz0
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: broadcasting SOLICIT6 (xid 0x88553e), 
next in 0.9 seconds
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: SOL_MAX_RT 3600 -> 3600
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: INF_MAX_RT 3600 -> 3600
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: ADV 2001:16b8:2284:b9fc::/62 from 
fe80::7eff:4dff:fe03:2c18
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: broadcasting REQUEST6 (xid 0x3b716e), 
next in 1.0 seconds
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: REPLY6 received from 
fe80::7eff:4dff:fe03:2c18
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: 2001:16b8:224c:d2fc::/62: became stale
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: renew in 1800, rebind in 2880, expire 
in 7200 seconds
Okt 03 04:50:57 rtr dhcpcd[6467]: lo: adding reject route to 
2001:16b8:2284:b9fc::/62
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: writing lease 
`/var/db/dhcpcd/wan0.lease6'
Okt 03 04:50:57 rtr dhcpcd[6467]: wan0: delegated prefix 
2001:16b8:2284:b9fc::/62
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: adding address 2001:16b8:2284:b9fc::1/64
Okt 03 04:50:57 rtr dhcpcd[6467]: lan0: pltime 3600 seconds, vltime 7200 seconds
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 
2001:16b8:2284:b9fc::, old prefix for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: DHCPv6 stateless on 
2001:16b8:2284:b9fc::, constructed for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: DHCPv4-derived IPv6 names on 
2001:16b8:2284:b9fc::, constructed for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: router advertisement on 
2001:16b8:2284:b9fc::, constructed for lan0
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: SLAAC-HOSTUNREACH 
a00:3a::2001:16b8:2284:b9fc
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: SLAAC-HOSTUNREACH 
a00:3a::2001:16b8:2284:b9fc
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]: SLAAC-HOSTUNREACH 
a00:3a::2001:16b8:2284:b9fc
Okt 03 04:50:57 rtr dnsmasq-dhcp[11540]:

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

2018-09-19 Thread Andrey Vakhitov 
Hello Simon,

> If you look, lots of things are different between the two logs. In the
second one, 
> dhcpcd is doing routing table changes, for instance. That could explain
why dnsmasq 
> gives up trying to confirm SLAAC addresses because it gets transient "no
route to host" 
> returns. (see previous reply to make sense of this.)

Ok, change of the routing is actually the "normal case" for me in this
scenario. Once again: My ISP requires nightly reconnect. After the reconnect
IPv6 address range assigned by IPS changes normally. Delegated prefixes
allocated by upstream router are changing also. Addresses of internal
interfaces there dnsmasq provides DHCP & DNS services are changing as well
(new prefix). And this is exactly the reason why I want to utilize
"ra-names" option: IPv6 prefixes are changing every day and I need name
resolution to reach hosts via IPv6.

Best Regards,
--
Andrey Vakhitov

E-Mail:  and...@vakhitov.net    Stuttgart, Germany




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2018-09-18 Thread 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)  
>>
>> 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.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2018-09-18 Thread Simon Kelley 
On 18/09/18 23:03, line wrap clean up wrote:

> 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)
> 
> -- log1 
> Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 
> 2001:16b8:2284:f5fc::, constructed for lan0
> Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 
> 2001:16b8:2284:f5fc::, constructed for lan0
> Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 
> 2001:16b8:2284:f5fc::, constructed for lan0
> Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 
> 2001:16b8:2284:f5fd::, constructed for dmz0
> Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 
> 2001:16b8:2284:f5fd::, constructed for dmz0
> Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 
> 2001:16b8:2284:f5fd::, constructed for dmz0
> Sep 17 20:22:45 rtr dnsmasq[7855]: reading /etc/dnsmasq-resolv.conf

> -- log2 
> Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 
> 2001:16b8:22c4:83fc::, constructed for lan0
> Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 
> 2001:16b8:22c4:83fc::, constructed for lan0
> Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on 
> 2001:16b8:22c4:83fc::, constructed for lan0
> Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: waiting for DHCPv6 DAD to complete
> Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding address 
> 2001:16b8:22c4:83fd::1/64
> Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: pltime 3600 seconds, vltime 7200 
> seconds
> Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 
> 2001:16b8:22c4:83fd::, constructed for dmz0
> Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 
> 2001:16b8:22c4:83fd::, constructed for dmz0
> Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: router advertisement on 
> 2001:16b8:22c4:83fd::, constructed for dmz0
> Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: waiting for DHCPv6 DAD to complete
> Sep 18 04:35:20 rtr dhcpcd[15081]: lan0: adding route to 
> 2001:16b8:22c4:83fc::/64
> Sep 18 04:35:20 rtr dhcpcd[15081]: dmz0: adding route to 
> 2001:16b8:22c4:83fd::/64
> Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing 
> `/usr/lib/dhcpcd/dhcpcd-run-hooks' BOUND6
> Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 
> 00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
> Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 
> 00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
> Sep 18 04:35:20 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 
> 00:02:00:00:ab:11:ee:62:d8:4d:ca:9f:9d:d5
> Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: Router Advertisement DAD completed
> Sep 18 04:35:20 rtr dhcpcd[15081]: wan0: executing 
> `/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
> Sep 18 04:35:21 rtr ddclient[1597]: SUCCESS:  updating rtrhomevak.spdns.de: 
> good: IP address set to 2001:16b8:22c4:8300>
> Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed
> Sep 18 04:35:21 rtr dhcpcd[15081]: dmz0: executing 
> `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
> Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed
> Sep 18 04:35:21 rtr dhcpcd[15081]: lan0: executing 
> `/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
> Sep 18 04:35:29 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:22c4:83fc::



If you look, lots of things are different between the two logs. In the
second one, dhcpcd is doing routing table changes, for instance. That
could explain why dnsmasq gives up trying to confirm SLAAC addresses
because it gets transient "no route to host" returns. (see previous
reply to make sense of this.)


Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2018-09-18 Thread line wrap clean up 
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)  
>
> 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)

-- log1 
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 
2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 
2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 
2001:16b8:2284:f5fc::, constructed for lan0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv6 stateless on 
2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: DHCPv4-derived IPv6 names on 
2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq-dhcp[7855]: router advertisement on 
2001:16b8:2284:f5fd::, constructed for dmz0
Sep 17 20:22:45 rtr dnsmasq[7855]: reading /etc/dnsmasq-resolv.conf
Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain homenet
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53
Sep 17 20:22:45 rtr dnsmasq[7855]: ignoring nameserver 
fd00::7eff:4dff:fe03:2c18 - cannot make/bind socket: Address alr>
Sep 17 20:22:45 rtr dnsmasq[7855]: setting upstream servers from DBus
Sep 17 20:22:45 rtr dnsmasq[7855]: using local addresses only for domain homenet
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.4.4#53
Sep 17 20:22:45 rtr dnsmasq[7855]: using nameserver 8.8.8.8#53
Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: DHCPv6 DAD completed
Sep 17 20:22:47 rtr dhcpcd[15081]: lan0: executing 
`/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: DHCPv6 DAD completed
Sep 17 20:22:47 rtr dhcpcd[15081]: dmz0: executing 
`/usr/lib/dhcpcd/dhcpcd-run-hooks' DELEGATED6
Sep 17 20:22:49 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(dmz0) 
00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18
Sep 17 20:22:55 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is 
unreachable, expiring it
Sep 17 20:22:56 rtr dhcpcd[15081]: wan0: executing 
`/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2284:f5fc::
Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(lan0) 2001:16b8:2250:65f8:: 
old prefix
Sep 17 20:22:58 rtr dnsmasq-dhcp[7855]: DHCPINFORMATION-REQUEST(lan0) 
00:02:00:00:ab:11:d5:97:98:17:01:41:27:3e
Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2284:f5fd::
Sep 17 20:22:59 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2250:65f9:: 
old prefix
Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 
2001:16b8:2284:f5fc:d250:99ff:fe84:93d0 vdrmain
Sep 17 20:23:03 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(dmz0) 
2001:16b8:2284:f5fd:5054:ff:fe12:3456 dmzhost
Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: fe80::7eff:4dff:fe03:2c18 is reachable 
again
Sep 17 20:23:03 rtr dhcpcd[15081]: wan0: executing 
`/usr/lib/dhcpcd/dhcpcd-run-hooks' ROUTERADVERT
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2284:f5fd::
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: RTR-ADVERT(dmz0) 2001:16b8:2250:65f9:: 
old prefix
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 
2001:16b8:2284:f5fc:222:4dff:fea7:dcdc vdrkit
Sep 17 20:23:05 rtr dnsmasq-dhcp[7855]: SLAAC-CONFIRM(lan0) 
2001:16b8:2284:f5fc:fca1:42ff:fed2:a2bd xenhost
-

-- log2 
Sep 18 04:35:20 rtr

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

2018-09-17 Thread Simon Kelley 
On 10/09/18 19:51, Andrey Vakhitov wrote:
> Hello Simon & Uwe,
> 
>> unfortunately that problem is seen often with providers in Germany, although 
>> the large ones no longer
>> do it (or allow to disable the disconnect). The problem is that German 
>> providers automatically 
>> disconnect the PPPoE connection every 24 hrs. After reconnecting you get a 
>> new address (IPv4) and 
>> prefix (IPv6). Since the changes we did (deprecating prefixes) this works 
>> fine  for standard router 
>> advertisements. But won't help for DHCPv6.
> 
> This is exactly my case, my ISP is o2.
> 
>>> Dnsmasq doesn't implement RECONFIGURE. It probably should. The main 
>>> problem, from a quick look at the RFC, is that RECONFIGURE mandates 
>>> use of security mechanism, and dnsmasq doesn't implement that either!
> 
> I know that it's against RFC but some routers (like the fritzbox I'm using, 
> very popular choice in Germany) actually send RECONFIGURE without 
> authentication. This is BTW the reason for introduction of "noauthrequired" 
> config option in dhcpcd ;-)


I wonder if a very simple RECONFIGURE implementation would work here:
Just send a non-specific RECONFIGURE message to all clients when a new
IPV6 network turns up? Without security. That would be fairly simple to
implement and to configure.



Cheers,

Simon.

> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2018-09-10 Thread Andrey Vakhitov 
Hello Simon & Uwe,

> unfortunately that problem is seen often with providers in Germany, although 
> the large ones no longer
> do it (or allow to disable the disconnect). The problem is that German 
> providers automatically 
> disconnect the PPPoE connection every 24 hrs. After reconnecting you get a 
> new address (IPv4) and 
> prefix (IPv6). Since the changes we did (deprecating prefixes) this works 
> fine  for standard router 
> advertisements. But won't help for DHCPv6.

This is exactly my case, my ISP is o2.

>> Dnsmasq doesn't implement RECONFIGURE. It probably should. The main 
>> problem, from a quick look at the RFC, is that RECONFIGURE mandates 
>> use of security mechanism, and dnsmasq doesn't implement that either!

I know that it's against RFC but some routers (like the fritzbox I'm using, 
very popular choice in Germany) actually send RECONFIGURE without 
authentication. This is BTW the reason for introduction of "noauthrequired" 
config option in dhcpcd ;-)

> My recommendation to the reporter:
> - Don't use stateful DHCPv6 in Germany, that does not work well. You clients 
> should get the addresses 
> using router advertisements. For static hosts assign static names in your own 
> domain. The "ra-names" 
> assigns both the IPv4 and IPv6 address to the SLAAC name, so lookup works 
> fine. With router 
> advertisements, DNSmasq will send "deprecated" prefixes for some time when it 
> figures out that the 
> prefix changed and sends the new prefix at the same time. This allows to have 
> no interruption (except 
> the forced PPP disconnect). In general, in IPv6 world you should forget about 
> static addresses, it's also 
> better for privacy.

As you correctly recognized, the reason for usage of stateful DHCPv6 was to get 
correct dynamic name resolution for IPv6. My IPv4 setup utilizes static 
addresses, I didn't used DHCPv4 for hosts acting as servers. I also see the 
combination of DHCPv4 with SLAAC as possible workaround, I've to try it. My 
problem with this setup is the lack of fallback address in networkd DHCP 
client: If DHCPv4 fails due to any reason the host get some "weird" address. 
Static IPv4 setup is free from this drawback and wanted to keep it as is and 
complement it with IPv6 solution...

Best regards,
--
Andrey Vakhitov

E-Mail:  and...@vakhitov.netStuttgart, Germany




___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2018-09-10 Thread Uwe Schindler 
Hi Simon,

unfortunately that problem is seen often with providers in Germany, although 
the large ones no longer do it (or allow to disable the disconnect). The 
problem is that German providers automatically disconnect the PPPoE connection 
every 24 hrs. After reconnecting you get a new address (IPv4) and prefix 
(IPv6). Since the changes we did (deprecating prefixes) this works fine  for 
standard router advertisements. But won't help for DHCPv6.

My recommendation to the reporter:
- Don't use stateful DHCPv6 in Germany, that does not work well. You clients 
should get the addresses using router advertisements. For static hosts assign 
static names in your own domain. The "ra-names" assigns both the IPv4 and IPv6 
address to the SLAAC name, so lookup works fine. With router advertisements, 
DNSmasq will send "deprecated" prefixes for some time when it figures out that 
the prefix changed and sends the new prefix at the same time. This allows to 
have no interruption (except the forced PPP disconnect). In general, in IPv6 
world you should forget about static addresses, it's also better for privacy.
- Alternatively use a very short DHCPv6 lease time. E.g., if router 
advertisements last a maximum time of 30 minutes, also set the lease time to 30 
minutes for IPv6. This requires clients to renew more often, but the change 
gots faster. If you force the router to disconnect during nights at a fixed 
time, the effect won't be so large.

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Dnsmasq-discuss 
> On Behalf Of Simon Kelley
> Sent: Sunday, September 9, 2018 11:49 PM
> To: dnsmasq-discuss@lists.thekelleys.org.uk
> Subject: Re: [Dnsmasq-discuss] clients of DHCPv6 with constructed IPv6
> address range are not notified on address range change
> 
> Dnsmasq doesn't implement RECONFIGURE. It probably should. The main
> problem, from a quick look at the RFC, is that RECONFIGURE mandates use
> of security mechanism, and dnsmasq doesn't implement that either!
> 
> The intention is that address change is a gradual process. The old
> address gets deprecated whilst the new one is added, and after a while
> the old address disappears. DHCP lease times are shorter than the time
> taken for an address to disappear. This gives time for hosts to move to
> the new address.
> 
> What's happening in your case seems a bit brutal. Even if you can push
> the change to all the clients fast, you're still going to break every
> on-going connection at address-change time.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> On 09/09/18 22:07, Andrey Vakhitov wrote:
> > Thanks for a great dnsmasq software.
> >
> >
> >
> > I’m using dnsmasq 2.79 in combination with IPv6 prefix delegation. The
> > prefixes are changing daily due to daily reconnect of upstream router.
> > Dhcpcd is used to handle prefix delegation on external interface and
> > apply new address to internal interface (dmz0). Dnsmasq picks up the
> > prefix assigned to the internal interface by dhcpcd and server RA and
> > DHCPv6 server.
> >
> >
> >
> > dhcp-range=set:dmz6,::,constructor:dmz0,ra-stateless,ra-names
> >
> > dhcp-
> host=id:00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18,set:dmzfix6,[::56],dmzhos
> t
> >
> >
> >
> > Initially the host gets IPv6 address via DHCPv6 correctly, DNS
> > resolution works as expected, everything seems to be ok. But after
> > reconnect (and according prefix change) the client stays with the IPv6
> > address from old prefix and doesn’t update it. I’ve used tcpdump to
> > monitor DHCP-related traffic and could not see DHCPv6 RECONFIGURE
> > message sent by dnsmasq to clients on prefix change. I assume that this
> > is the cause of the problem: DHCP clients are not aware of changed
> > prefix and can’t act without corresponding notification from server.
> >
> > As dhcp client I use build-in DHCP client from system-networkd, just for
> > info, maybe it matters…
> >
> >
> >
> > If I’m wrong with my assumption I’d appreciate any explanation helping
> > me to configure dnsmasq and DHCP client properly.
> >
> >
> >
> > Best regards,
> >
> > --
> >
> > Andrey Vakhitov
> >
> >
> >
> > E-Mail:  and...@vakhitov.net 
> > Stuttgart, Germany
> >
> >
> >
> >
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2018-09-09 Thread Simon Kelley 
Dnsmasq doesn't implement RECONFIGURE. It probably should. The main
problem, from a quick look at the RFC, is that RECONFIGURE mandates use
of security mechanism, and dnsmasq doesn't implement that either!

The intention is that address change is a gradual process. The old
address gets deprecated whilst the new one is added, and after a while
the old address disappears. DHCP lease times are shorter than the time
taken for an address to disappear. This gives time for hosts to move to
the new address.

What's happening in your case seems a bit brutal. Even if you can push
the change to all the clients fast, you're still going to break every
on-going connection at address-change time.


Cheers,

Simon.



On 09/09/18 22:07, Andrey Vakhitov wrote:
> Thanks for a great dnsmasq software.
> 
>  
> 
> I’m using dnsmasq 2.79 in combination with IPv6 prefix delegation. The
> prefixes are changing daily due to daily reconnect of upstream router.
> Dhcpcd is used to handle prefix delegation on external interface and
> apply new address to internal interface (dmz0). Dnsmasq picks up the
> prefix assigned to the internal interface by dhcpcd and server RA and
> DHCPv6 server.
> 
>  
> 
> dhcp-range=set:dmz6,::,constructor:dmz0,ra-stateless,ra-names
> 
> dhcp-host=id:00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18,set:dmzfix6,[::56],dmzhost
> 
>  
> 
> Initially the host gets IPv6 address via DHCPv6 correctly, DNS
> resolution works as expected, everything seems to be ok. But after
> reconnect (and according prefix change) the client stays with the IPv6
> address from old prefix and doesn’t update it. I’ve used tcpdump to
> monitor DHCP-related traffic and could not see DHCPv6 RECONFIGURE
> message sent by dnsmasq to clients on prefix change. I assume that this
> is the cause of the problem: DHCP clients are not aware of changed
> prefix and can’t act without corresponding notification from server.
> 
> As dhcp client I use build-in DHCP client from system-networkd, just for
> info, maybe it matters…
> 
>  
> 
> If I’m wrong with my assumption I’d appreciate any explanation helping
> me to configure dnsmasq and DHCP client properly.
> 
>  
> 
> Best regards,
> 
> --
> 
> Andrey Vakhitov
> 
>  
> 
> E-Mail:  and...@vakhitov.net    
> Stuttgart, Germany
> 
>  
> 
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

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

2018-09-09 Thread Andrey Vakhitov 
Thanks for a great dnsmasq software.

 

I'm using dnsmasq 2.79 in combination with IPv6 prefix delegation. The
prefixes are changing daily due to daily reconnect of upstream router.
Dhcpcd is used to handle prefix delegation on external interface and apply
new address to internal interface (dmz0). Dnsmasq picks up the prefix
assigned to the internal interface by dhcpcd and server RA and DHCPv6
server.

 

dhcp-range=set:dmz6,::,constructor:dmz0,ra-stateless,ra-names

dhcp-host=id:00:02:00:00:ab:11:9b:74:21:c0:e9:5d:1c:18,set:dmzfix6,[::56],dm
zhost

 

Initially the host gets IPv6 address via DHCPv6 correctly, DNS resolution
works as expected, everything seems to be ok. But after reconnect (and
according prefix change) the client stays with the IPv6 address from old
prefix and doesn't update it. I've used tcpdump to monitor DHCP-related
traffic and could not see DHCPv6 RECONFIGURE message sent by dnsmasq to
clients on prefix change. I assume that this is the cause of the problem:
DHCP clients are not aware of changed prefix and can't act without
corresponding notification from server.

As dhcp client I use build-in DHCP client from system-networkd, just for
info, maybe it matters.

 

If I'm wrong with my assumption I'd appreciate any explanation helping me to
configure dnsmasq and DHCP client properly.

 

Best regards,

--

Andrey Vakhitov

 

E-Mail:    and...@vakhitov.net
Stuttgart, Germany

 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss