Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
On 27/07/13 19:11, Uwe Schindler wrote: I want to try and avoid making every parameter changable, like Radv does. Who can tell what the parameters should be. A flag which says stay in fast retransmit mode to fix buggy android seems much more sensible. That is perfectly fine! So a boolean option to work around the android bug (and for other power-saving devices, which ignore ICMPv6 messages in sleep mode) would be enough! Ideally we could detect android devices and automatically switch to that mode once an android device is in the WLAN, but that’s not really possible without a large database of MAC address prefixes of broken WIFI chips/manufacturers. :-) Maybe Broadcom fixes the bug at some time and later Samsung devices does not have this problem (the HTC Desire here is completely responsible - with the backside that the ongoing ICMP requests drain battery faster, because kernel has to wake up to process the RA). git repo now has --force-fast-ra. I'm currently hacking on a tiny netbook without access to my normal test harness, so this is untested. It's simple enough that I probably haven't broken it :) Finally I found one more small thing in addition to the deprecated prefixes: radvd sends shortly before exiting one or two last router advertisements to deprecate all prefixes it has given out before (this is also part of the DeprecatePrefix option of radvd). I found out that in the fact of a reboot of the router, when it comes back again there is no chance to deprecate the leases altogether. Another option would be to save the deprecated/used prefixes in the lease file, so it survives reboots of the router. In that case when somebody switches off the router by removing power coord or rebooting it through the web interface, it would announce the old prefixes as deprecated (for max 2 hours as we do currently). In my opinion, this would be nice to have, but its not urgent. At least it should send one or 2 RAs on shut down with preferred_lifetime=0 and maximum 2 hrs valid_ lifetime (but not greater than the current lifetime). Radvd does this if requested, so shutdown takes approx. 1 second. Hmm, deprecate prefixes when dnsmasq goes down but the router doesn't, but don't deprecate prefixes when the router goes down. That sounds exactly backwards. I know I probably restart dnsmasq more often than most (here at dnsmasq central, we eat our own dogfood) but the idea that stopping dnsmasq would kill all IPv6 connectivity on the network sounds like a bad one to me. Oone small thing with your new code - maybe a bug, because the comment says something else: Although the valid_lifetime of the prefix is now lower (30 mins on my machine), after deprecation it raises the valid_lifetime again up to 2 hrs. This is unneeded. It should use the lower of the current valid_lifetime or 2 hrs (this is what it explains in the RFC): then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time). BTW: The 2 hours are a special number: it is the minimum time a router can use to reannounce the valid lifetime if it is currently higher. Otherwise a client would ignore this message - this is to prevent malicious clients from spoofing a router. This is why it must use a minimum of the current lifetime but never more than 2 hours to deprecate the prefix. The code should look like: Once a prefix is deprecated, use the current lifetime in the last RA and decrement it from now on. Fixed now, see previous message. Cheers, Simon. Uwe ___ 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] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi Simon, I did a git pull yesterday evening and problem was already fixed. Many thanks! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Monday, July 29, 2013 4:55 PM To: Uwe Schindler Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 27/07/13 19:21, Uwe Schindler wrote: Hi, I found the reason for this bug: One small thing with your new code - maybe a bug, because the comment says something else: Although the configured (in my config) valid_lifetime of the prefix is now lower (30 mins on my machine), after deprecation it raises the valid_lifetime again up to 2 hrs. It misses to apply this code also to context-saved_lifetime in radv.c, approx. line 484: /* configured time is ceiling */ if (!constructed || valid time) valid = time; So this 3 lines should be moved up, before the part where valid is copied to saved_valid. Or the same code should also be applied to saved_lifetime, if set. Got it. That's fixed in the git repo now. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi Simon, I want to try and avoid making every parameter changable, like Radv does. Who can tell what the parameters should be. A flag which says stay in fast retransmit mode to fix buggy android seems much more sensible. That is perfectly fine! So a boolean option to work around the android bug (and for other power-saving devices, which ignore ICMPv6 messages in sleep mode) would be enough! Ideally we could detect android devices and automatically switch to that mode once an android device is in the WLAN, but that’s not really possible without a large database of MAC address prefixes of broken WIFI chips/manufacturers. :-) Maybe Broadcom fixes the bug at some time and later Samsung devices does not have this problem (the HTC Desire here is completely responsible - with the backside that the ongoing ICMP requests drain battery faster, because kernel has to wake up to process the RA). git repo now has --force-fast-ra. I'm currently hacking on a tiny netbook without access to my normal test harness, so this is untested. It's simple enough that I probably haven't broken it :) I did a git pull and rebuilt debian package. Works like a charm! Finally I found one more small thing in addition to the deprecated prefixes: radvd sends shortly before exiting one or two last router advertisements to deprecate all prefixes it has given out before (this is also part of the DeprecatePrefix option of radvd). I found out that in the fact of a reboot of the router, when it comes back again there is no chance to deprecate the leases altogether. Another option would be to save the deprecated/used prefixes in the lease file, so it survives reboots of the router. In that case when somebody switches off the router by removing power coord or rebooting it through the web interface, it would announce the old prefixes as deprecated (for max 2 hours as we do currently). In my opinion, this would be nice to have, but its not urgent. At least it should send one or 2 RAs on shut down with preferred_lifetime=0 and maximum 2 hrs valid_ lifetime (but not greater than the current lifetime). Radvd does this if requested, so shutdown takes approx. 1 second. Hmm, deprecate prefixes when dnsmasq goes down but the router doesn't, but don't deprecate prefixes when the router goes down. That sounds exactly backwards. I know I probably restart dnsmasq more often than most (here at dnsmasq central, we eat our own dogfood) but the idea that stopping dnsmasq would kill all IPv6 connectivity on the network sounds like a bad one to me. I think this is the reason why it is optional in radvd. You have to explicitely enable DeprecatePrefix: DeprecatePrefix on|off Upon shutdown, this option will cause radvd to deprecate the prefix by announcing it in the radvd shutdown RA with a zero preferred lifetime and a valid lifetime slightly greater than 2 hours. This will encourage end-nodes using this prefix to deprecate any associated addresses immediately. Note that this option should only be used when only one router is announcing the prefix onto the link, otherwise end-nodes will deprecate associated addresses despite the prefix still being valid for preferred use. See RFC4862, section 5.5.3., Router Advertisement Processing, part (e). Default: off I agree this has pros and cons. The problem with Linux machines is: On shutdown, dnsmasq is killed first and after that the network links are going down. When you shutdown/reboot your router, the old prefix of your ppp connection stays alive for very long time, because nothing deprecates it. So the deprecate on shutdown was just a easy to implement idea. I think the most correct impl would be: - dnsmasq writes all prefixes it announces to a file (at a similar persistent place like the dnsmasq.leases file). Maybe use the lease file for this. - After a restart it reads this file and for every prefix from this file which is no longer available it would do the same announcement like implemented before. Just make the list of prefixes persistent, on restart reload them and after restart do the same cleanup and mark for deprecation on them like implemented before if they disappeared. This is just a nice idea for future development, as I assume it's more complicated to do. As a workaround I will reorder the router's init.d scripts, so my PPP connection is shut down before dnsmasq, so dnsmasq has a short time to announce the deprecation. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
On 26/07/13 22:19, Uwe Schindler wrote: Hi, After some testing and reconnecting PPP connection several times: All works fine. It also recognizes multiple old prefixes and sends all of them as deprecated. Regarding the Android-Bug: I found out that I still have to enable the fast mode (which is only done in the first minute after a config change). The reason is: Although the prefix has a lifetime of 86400 on my dhcp-range, in contrast, the router itself gets a lifetime of 1800 secs (3 times RA_INTERVAL), the RDNS got a lifetime of 1200 secs (2 times RA_INTERVAL). To me this looks a bit inconsequent. The router itself is in my opinion the most stable thing of all, because its link-local-adress is used by clients. The DNS server should in my opinion have the same lifetime as the prefix / dhcp-range - or best would be to use this value: dhcp-option=option6:information-refresh-time (maybe you should send the dhcp's range's lease time as information-refresh-time on every dhcp request). The 3 times RA_INTERVAL comes from the default given in RFC 4861, section 6.2.1 which also specifies an absolute maximum value of 9000 seconds. I don't know if it's sensible to violate this RFC. I was able to fix the android bug again by reducing the re-transmit time by patcing the code, this time a bit more easy: I changed, as suggested by you, the if-statement in the function new_timeout(struct dhcp_context *context, time_t now), to always use the short interval of 5 - 20 secs. This solved the problem. I think if you add a config option to enable the fast retransmit if you have buggy android phones, we are fine. In addition, maybe have a separate config option to change the fast retransmit time (but different from RA_INTERVAL) and RA_INTERVAL itself (as you can do with radvd). I want to try and avoid making every parameter changable, like Radv does. Who can tell what the parameters should be. A flag which says stay in fast retransmit mode to fix buggy android seems much more sensible. Simon. Uwe P.S.: FYI, my DNS server address is a private IPv6 address which is assigned to the LAN interface in addition to the global prefix, see my other mail for explanation. So the DNS is stable here, stable as the link-local router address. I would recommend this setup also for router manufacturers. If the DNS server is not stable, the information-refresh-time in the DHCP packets should in any case be specified, otherwise the client never ever asks again for the DNS server. I checked this on windows computer. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, I send in my config: dhcp-option=option6:information-refresh-time,1h Otherwise, Windows Clients never try to renew information from DHCPv6 (it looks like that to me, in reality its 86400 secs, which is the default if not specified). http://www.6net.org/publications/standards/rfc4242.txt confirms this: This document describes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration. Further details: 3.1. Constants We define two constants for use by the protocol. How they are used is specified in the sections below. IRT_DEFAULT 86400 In some cases the client uses a default refresh time IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400 (24 hours). The client implementation SHOULD allow for this value to be configurable. IRT_MINIMUM 600 This defines a minimum value for the refresh time. 3.2. Client Behaviour A client MUST request this option in the Option Request Option (ORO) when sending Information-Request messages to the DHCPv6 server. A client MUST NOT request this option in the ORO in any other messages. If the Reply to an Information-Request message does not contain this option, the client MUST behave as if the option with value IRT_DEFAULT was provided. In my opinion, dnsmasq should by default (like for stateful IPv4 leases) use the lifetime specified in the dhcp-range to request the clients to refresh this information. If it is explicitely given, of course use the information from option6:information-refresh-time setting. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Saturday, July 27, 2013 3:04 PM To: Uwe Schindler Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 26/07/13 17:50, Uwe Schindler wrote: One thing I found in my investigations: The lifetime given in the dhcp-range for IPv6 oly affects the RAs, but not the time for refreshing the DHCP information request. I had to set it explicitely as dhcp-option6. What option are you sending? Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, Regarding the Android-Bug: I found out that I still have to enable the fast mode (which is only done in the first minute after a config change). The reason is: Although the prefix has a lifetime of 86400 on my dhcp-range, in contrast, the router itself gets a lifetime of 1800 secs (3 times RA_INTERVAL), the RDNS got a lifetime of 1200 secs (2 times RA_INTERVAL). To me this looks a bit inconsequent. The router itself is in my opinion the most stable thing of all, because its link-local-adress is used by clients. The DNS server should in my opinion have the same lifetime as the prefix / dhcp-range - or best would be to use this value: dhcp-option=option6:information-refresh-time (maybe you should send the dhcp's range's lease time as information-refresh-time on every dhcp request). The 3 times RA_INTERVAL comes from the default given in RFC 4861, section 6.2.1 which also specifies an absolute maximum value of 9000 seconds. I don't know if it's sensible to violate this RFC. OK that's fine. If the RFC says that, we should not violate! In general this means that the lifetime of the prefix does not need to be longer than that time, too. Because when the android phone does not get the RAs, its default gateway (router) will go away and so the IPv6 address is dead altogether. In my opinion, if the DNS server information is not limited, it should be set to the time of the prefix, too. I was able to fix the android bug again by reducing the re-transmit time by patcing the code, this time a bit more easy: I changed, as suggested by you, the if-statement in the function new_timeout(struct dhcp_context *context, time_t now), to always use the short interval of 5 - 20 secs. This solved the problem. I think if you add a config option to enable the fast retransmit if you have buggy android phones, we are fine. In addition, maybe have a separate config option to change the fast retransmit time (but different from RA_INTERVAL) and RA_INTERVAL itself (as you can do with radvd). I want to try and avoid making every parameter changable, like Radv does. Who can tell what the parameters should be. A flag which says stay in fast retransmit mode to fix buggy android seems much more sensible. That is perfectly fine! So a boolean option to work around the android bug (and for other power-saving devices, which ignore ICMPv6 messages in sleep mode) would be enough! Ideally we could detect android devices and automatically switch to that mode once an android device is in the WLAN, but that’s not really possible without a large database of MAC address prefixes of broken WIFI chips/manufacturers. :-) Maybe Broadcom fixes the bug at some time and later Samsung devices does not have this problem (the HTC Desire here is completely responsible - with the backside that the ongoing ICMP requests drain battery faster, because kernel has to wake up to process the RA). Finally I found one more small thing in addition to the deprecated prefixes: radvd sends shortly before exiting one or two last router advertisements to deprecate all prefixes it has given out before (this is also part of the DeprecatePrefix option of radvd). I found out that in the fact of a reboot of the router, when it comes back again there is no chance to deprecate the leases altogether. Another option would be to save the deprecated/used prefixes in the lease file, so it survives reboots of the router. In that case when somebody switches off the router by removing power coord or rebooting it through the web interface, it would announce the old prefixes as deprecated (for max 2 hours as we do currently). In my opinion, this would be nice to have, but its not urgent. At least it should send one or 2 RAs on shut down with preferred_lifetime=0 and maximum 2 hrs valid_ lifetime (but not greater than the current lifetime). Radvd does this if requested, so shutdown takes approx. 1 second. Oone small thing with your new code - maybe a bug, because the comment says something else: Although the valid_lifetime of the prefix is now lower (30 mins on my machine), after deprecation it raises the valid_lifetime again up to 2 hrs. This is unneeded. It should use the lower of the current valid_lifetime or 2 hrs (this is what it explains in the RFC): then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time). BTW: The 2 hours are a special number: it is the minimum time a router can use to reannounce the valid lifetime if it is currently higher. Otherwise a client would ignore this message - this is to prevent malicious clients from spoofing a router. This is why it must use a minimum of the current lifetime but never more than 2 hours to deprecate the prefix. The code should look like: Once a prefix is
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, I found the reason for this bug: One small thing with your new code - maybe a bug, because the comment says something else: Although the configured (in my config) valid_lifetime of the prefix is now lower (30 mins on my machine), after deprecation it raises the valid_lifetime again up to 2 hrs. It misses to apply this code also to context-saved_lifetime in radv.c, approx. line 484: /* configured time is ceiling */ if (!constructed || valid time) valid = time; So this 3 lines should be moved up, before the part where valid is copied to saved_valid. Or the same code should also be applied to saved_lifetime, if set. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
On 27/07/13 19:11, Uwe Schindler wrote: In my opinion, dnsmasq should by default (like for stateful IPv4 leases) use the lifetime specified in the dhcp-range to request the clients to refresh this information. If it is explicitely given, of course use the information from option6:information-refresh-time setting. I agree. My keyboard is clattering as we speak. There's a bit of a complication, which is that DHCPv6 information-requests don't include the IP address of the client, so if an information-request arrives on an interface which has more than one address and more than one corresponding dhcp-range, then it's ambiguous which one to use. I propose that in such a case, the range with the smallest time will be used. Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
On 25/07/13 22:32, Uwe Schindler wrote: Hi, reading https://datatracker.ietf.org/doc/rfc6204/?include_text=1, the requirements for home routers are listed here: L-13: If the delegated prefix changes, i.e., the current prefix is replaced with a new prefix without any overlapping time period, then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862]. This was my original proposal. I agree that this should be done by the PPP/WAN interface and the DHCPv6 cleint on the WAN interface, so the old prefix gets deprecated, but with current software available (ISC dhcpd does not work on PPP interfaces but would support that using a shell script applying the prefix delegation - and wide-dhcpc supports PPP interfaces, but it allows not to configure prefix delegation, so in deprecates addresses after PPP reconnect or a change of the prefix). So I would be very happy, if dnsmasq (as router advertisement daemon would provide support for this). Radvd does it - see DeprecatePrefix options in radvd. Uwe Good find. It's not clear to me if this is a one-off advertisement, or if the advertisements need to be repeated, though the 2 hours stuff implies that it should be repeated. I'll have a think about how to implement this withing the existing code. A one-off advertisement should be quite simple, but repeated ones are more difficult. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
On 25/07/13 22:32, Uwe Schindler wrote: Hi, reading https://datatracker.ietf.org/doc/rfc6204/?include_text=1, the requirements for home routers are listed here: L-13: If the delegated prefix changes, i.e., the current prefix is replaced with a new prefix without any overlapping time period, then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862]. This was my original proposal. I agree that this should be done by the PPP/WAN interface and the DHCPv6 cleint on the WAN interface, so the old prefix gets deprecated, but with current software available (ISC dhcpd does not work on PPP interfaces but would support that using a shell script applying the prefix delegation - and wide-dhcpc supports PPP interfaces, but it allows not to configure prefix delegation, so in deprecates addresses after PPP reconnect or a change of the prefix). So I would be very happy, if dnsmasq (as router advertisement daemon would provide support for this). Radvd does it - see DeprecatePrefix options in radvd. Try 2.67test8 - on the server now. No extra configuration needed. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi Simon, Perfect! I will rebuild the debian package from the snapshot and try out. As far as I see, you have not yet made the RA_INTERVAL configurable (only for the unsolicited advertisements), so I will patch this, too. But in any case, I can raise the lifetimes now, so the problem will appear later. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Friday, July 26, 2013 3:03 PM To: Uwe Schindler Cc: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 25/07/13 22:32, Uwe Schindler wrote: Hi, reading https://datatracker.ietf.org/doc/rfc6204/?include_text=1, the requirements for home routers are listed here: L-13: If the delegated prefix changes, i.e., the current prefix is replaced with a new prefix without any overlapping time period, then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862]. This was my original proposal. I agree that this should be done by the PPP/WAN interface and the DHCPv6 cleint on the WAN interface, so the old prefix gets deprecated, but with current software available (ISC dhcpd does not work on PPP interfaces but would support that using a shell script applying the prefix delegation - and wide-dhcpc supports PPP interfaces, but it allows not to configure prefix delegation, so in deprecates addresses after PPP reconnect or a change of the prefix). So I would be very happy, if dnsmasq (as router advertisement daemon would provide support for this). Radvd does it - see DeprecatePrefix options in radvd. Try 2.67test8 - on the server now. No extra configuration needed. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Have fun in Berlin! But the new code makes it possible to me to set the lifetime of the dhcp-lease to good old pre-IPv6 times (86400s) so it is very unlikely that the android problem reappears. I have tested it, all is fine now. The Android bug can be worked around by raising the lifetime/lease time in the DHCP/RA - I raised it now back to 86400 like my already existing IPv4 dhcp-range. It is very unlikely that the mobile phone is switched off to standby for longer than one day! So when it wakes up, the prefix is still valid. If the prefix changes from the provider, its correctly deprecated, so all is fine now. One thing I found in my investigations: The lifetime given in the dhcp-range for IPv6 oly affects the RAs, but not the time for refreshing the DHCP information request. I had to set it explicitely as dhcp-option6. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Friday, July 26, 2013 5:45 PM To: Uwe Schindler Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 26/07/13 16:24, Uwe Schindler wrote: Hi Simon, Perfect! I will rebuild the debian package from the snapshot and try out. As far as I see, you have not yet made the RA_INTERVAL configurable (only for the unsolicited advertisements), Not yet, but I did split the calculation out into its own function in preparation. Off to Berlin for IETF now. I should have some time to keep working on this during the conference. Cheers, Simon. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, After some testing and reconnecting PPP connection several times: All works fine. It also recognizes multiple old prefixes and sends all of them as deprecated. Regarding the Android-Bug: I found out that I still have to enable the fast mode (which is only done in the first minute after a config change). The reason is: Although the prefix has a lifetime of 86400 on my dhcp-range, in contrast, the router itself gets a lifetime of 1800 secs (3 times RA_INTERVAL), the RDNS got a lifetime of 1200 secs (2 times RA_INTERVAL). To me this looks a bit inconsequent. The router itself is in my opinion the most stable thing of all, because its link-local-adress is used by clients. The DNS server should in my opinion have the same lifetime as the prefix / dhcp-range - or best would be to use this value: dhcp-option=option6:information-refresh-time (maybe you should send the dhcp's range's lease time as information-refresh-time on every dhcp request). I was able to fix the android bug again by reducing the re-transmit time by patcing the code, this time a bit more easy: I changed, as suggested by you, the if-statement in the function new_timeout(struct dhcp_context *context, time_t now), to always use the short interval of 5 - 20 secs. This solved the problem. I think if you add a config option to enable the fast retransmit if you have buggy android phones, we are fine. In addition, maybe have a separate config option to change the fast retransmit time (but different from RA_INTERVAL) and RA_INTERVAL itself (as you can do with radvd). Uwe P.S.: FYI, my DNS server address is a private IPv6 address which is assigned to the LAN interface in addition to the global prefix, see my other mail for explanation. So the DNS is stable here, stable as the link-local router address. I would recommend this setup also for router manufacturers. If the DNS server is not stable, the information-refresh-time in the DHCP packets should in any case be specified, otherwise the client never ever asks again for the DNS server. I checked this on windows computer. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Uwe Schindler Sent: Friday, July 26, 2013 6:50 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? Have fun in Berlin! But the new code makes it possible to me to set the lifetime of the dhcp-lease to good old pre-IPv6 times (86400s) so it is very unlikely that the android problem reappears. I have tested it, all is fine now. The Android bug can be worked around by raising the lifetime/lease time in the DHCP/RA - I raised it now back to 86400 like my already existing IPv4 dhcp-range. It is very unlikely that the mobile phone is switched off to standby for longer than one day! So when it wakes up, the prefix is still valid. If the prefix changes from the provider, its correctly deprecated, so all is fine now. One thing I found in my investigations: The lifetime given in the dhcp-range for IPv6 oly affects the RAs, but not the time for refreshing the DHCP information request. I had to set it explicitely as dhcp-option6. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Simon Kelley [mailto:si...@thekelleys.org.uk] Sent: Friday, July 26, 2013 5:45 PM To: Uwe Schindler Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? On 26/07/13 16:24, Uwe Schindler wrote: Hi Simon, Perfect! I will rebuild the debian package from the snapshot and try out. As far as I see, you have not yet made the RA_INTERVAL configurable (only for the unsolicited advertisements), Not yet, but I did split the calculation out into its own function in preparation. Off to Berlin for IETF now. I should have some time to keep working on this during the conference. Cheers, Simon. ___ 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] Make RA_INTERVAL configureable? Deprecate old prefixes?
On 24/07/13 19:16, Uwe Schindler wrote: Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). My understanding of this is that it's something that should happen in the DHCP client and/or ISP DHCP server. Ie, when the prefix has to change, the ISP's DHCP server renews the existing prefix delegation, but with the preferred lifetime==0. It also offers a new prefix delegation. The old and new prefixes get installed in the network adaptor with the preferred lifetime values. Dnsmasq starts to advertise the new prefix and continues to advertise the old prefix, but with the pref- lifetime at zero taken from the value in the adaptor. The problem is different in most cases: When you have a dhcp client waiting on an PPPoE connection (e.g. wide-dhcpc, like most consumer routers use - ISC dhcp cannot listen on ppp interfaces unfortunately) and the PPPoE connection gets reconnected/disconnected, the ppp interface is disappears and is later recreated. When its disappearing, the whole set of IP addresses gets lost and they are not deprecated, so dnsmasq will not recognize any deprecation. I have seen your code that propagates the deprecation of existing interfaces in the RAs, but this only works if the prefix/IP address is still existing on the interface, just with preferred lifetime==0. With PPP interfaces disappearing and being recreated, this does not help, because the address is gone (it’s a new instance of the network interface, just with same name). As dnsmasq is mainly for consumer routers which are mostly working with PPP connections, it would be nice to have. Again, this is new territory, I'm not saying has to be done like that, but that's the process I was thinking of when I wrote the existing code. That's fine! See also: http://manpages.ubuntu.com/manpages/precise/man5/radvd.conf.5.html DeprecatePrefix on|off Upon shutdown, this option will cause radvd to deprecate the prefix by announcing it in the radvd shutdown RA with a zero preferred lifetime and a valid lifetime slightly greater than 2 hours. This will encourage end-nodes using this prefix to deprecate any associated addresses immediately. Note that this option should only be used when only one router is announcing the prefix onto the link, otherwise end-nodes will deprecate associated addresses despite the prefix still being valid for preferred use. See RFC4862, section 5.5.3., Router Advertisement Processing, part (e). Default: off Shutdown means in that case shutdown of interface, too. At least this is how it works for radvd. Uwe Cheers, Simon. ___ 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] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi again, In addition, I found a relic from the time when the RA_INTERVAL value was hardcoded into radv.c. There is still one: Line 294: put_opt6_long(1800); /* lifetime - twice RA retransmit */ Should be: put_opt6_long(RA_INTERVAL * 2); /* lifetime - twice RA retransmit */ I am currently looking into the code to find an easy way how to make the RA_INTERVAL configureable, maybe I can provide a patch. But if it's easy for you, it would be really nice to have this in future versions. So the deprecation of addresses no longer used on the network interface is not my primary concern, more I would prefer to work around the bugs in certain android phones not receiving ICMPv6 messages in standby mode, so the RA_INTERVAL should be configureable (I want to set it to much lower values than 600s, I have a patched version with 6s retransmit running on my debian testing box). Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Uwe Schindler Sent: Wednesday, July 24, 2013 8:17 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). Uwe ___ 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] Make RA_INTERVAL configureable? Deprecate old prefixes?
On 25/07/13 11:59, Uwe Schindler wrote: Hi again, In addition, I found a relic from the time when the RA_INTERVAL value was hardcoded into radv.c. There is still one: Line 294: put_opt6_long(1800); /* lifetime - twice RA retransmit */ Should be: put_opt6_long(RA_INTERVAL * 2); /* lifetime - twice RA retransmit */ Yes, that's a bug. I am currently looking into the code to find an easy way how to make the RA_INTERVAL configureable, maybe I can provide a patch. But if it's easy for you, it would be really nice to have this in future versions. So the deprecation of addresses no longer used on the network interface is not my primary concern, more I would prefer to work around the bugs in certain android phones not receiving ICMPv6 messages in standby mode, so the RA_INTERVAL should be configureable (I want to set it to much lower values than 600s, I have a patched version with 6s retransmit running on my debian testing box). Note that RA_INTERVAL is used in the code for two related things. 1) It sets the lifetime values for parameters being sent. At the moment, the router advertisement is set to three times RA_INTERVAL, the DNS server and domain-search params are twice RA_INTERVAL, and prefixes are set to (at least RA_INTERVAL) 2) It sets how often unsolicited RA's are sent. Clearly these are related, the lifetime of parameters must be at least until they can be renewed by another RA, and preferably longer, to allow for packet loss. You probably don't want to reduce the lifetimes, that would be counter-productive for the Android bug. you do want to send RAs more often. The relevant code for that is here: if (difftime(param-now, context-ra_short_period_start) 60.0) /* range 5 - 20 */ context-ra_time = param-now + 5 + (rand16()/4400); else /* range 3/4 - 1 times RA_INTERVAL */ context-ra_time = param-now + (3 * RA_INTERVAL)/4 + ((RA_INTERVAL * (unsigned int)rand16()) 18); Which says that for the first minute after an configuration change, we send RAs every 5- 20 seconds, the actual delay is random. Once the first minute is up, we wait 3/4 of RA_INTERVAL to RA_INTERVAL. It seems to me that the simplest solution might be lock the fast RA mode, and never drop back to the full RA_INTERVAL delay. on a config flag as Android workaround mode Another solution might be to derive the RA retransmit rate from the RA lifetimes, At the moment if you declare a RA prefix with a short lifetime, the lifetime gets extended to be as long as RA_INTERVAL, instead, we could reduce RA_INTERVAL to be the shortest configure lifetime (or actually half of that to allow for lost packets). Cheers, Simon. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Uwe Schindler Sent: Wednesday, July 24, 2013 8:17 PM To: dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). Uwe ___ 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] Make RA_INTERVAL configureable? Deprecate old prefixes?
On 25/07/13 12:36, Uwe Schindler wrote: Hi again, one addition, because its too hot here... The reality is again different (very complicated with IPv6): Hot there too? Reply at the end. On 24/07/13 19:16, Uwe Schindler wrote: Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). My understanding of this is that it's something that should happen in the DHCP client and/or ISP DHCP server. Ie, when the prefix has to change, the ISP's DHCP server renews the existing prefix delegation, but with the preferred lifetime==0. It also offers a new prefix delegation. The old and new prefixes get installed in the network adaptor with the preferred lifetime values. Dnsmasq starts to advertise the new prefix and continues to advertise the old prefix, but with the pref- lifetime at zero taken from the value in the adaptor. The problem is different in most cases: When you have a dhcp client waiting on an PPPoE connection (e.g. wide-dhcpc, like most consumer routers use - ISC dhcp cannot listen on ppp interfaces unfortunately) and the PPPoE connection gets reconnected/disconnected, the ppp interface is disappears and is later recreated. When its disappearing, the whole set of IP addresses gets lost and they are not deprecated, so dnsmasq will not recognize any deprecation. I have seen your code that propagates the deprecation of existing interfaces in the RAs, but this only works if the prefix/IP address is still existing on the interface, just with preferred lifetime==0. With PPP interfaces disappearing and being recreated, this does not help, because the address is gone (it’s a new instance of the network interface, just with same name). As dnsmasq is mainly for consumer routers which are mostly working with PPP connections, it would be nice to have. Indeed ist more complicated but effect ist he same: For DSL lines you ahev in most cases the following setup: - PPP connection (PPPoE), creating network adaptor ppp0 - this adaptor is coming on going when connections are created/released - LAN interface (on which dnsmasq is listening), eth0, with a static IPv4 address and a dynamic IPv6 address prefix - wide-dhcpc client listening on the ppp0 interface and requesting prefix delegation. The delegated prefix is assigned as new address with given suffix (::1 or from mac address) to the eth0 interface. In fact, as you say: When ppp0 disconnects or reconnects, the wide-dhcp client should not actually remove the delegated prefix from the eth0 interface, but unfortunately it does. The reason for this is the following: the dhcp client stops when the ppp0 interface disappears, so it is restarted in the ifup scripts after the ppp connection was reconnected. When the wide-dhcpc client exits, it will clean up so it removes all addresses assigned - that's the problem. I think this is even more broken than that. Surely, what should happen if the PPPoE link goes down and then comes up again is that the DHCP client should attempt to renew existing DHCP leases, including prefix delegations. Any sensible DHCP server at the ISP should give back the same prefix delegations, so not only should the prefixes not be removed from eth0 just because ppp0 goes down, they will probably not even be deprecated once the PPP link is back. Using dnsmasq to deprecate them once the PPP link goes is the last thing you should do. Maybe this is different with ISC dhcp (because you can script the whole prefix delegation), but ISC dhcp is never used, because current versions of isc-dhcp cannot listen on ppp interfaces (refuses to start). There is no reason for this, on the mailing list they say it’s a relic from earlier IPv4 days. There is nothing against listening for DHCP on a ppp interface. Because of this most consumer routers (like the Fritzbox) use wide-dhcpc as client for prefix delegation on
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, On 24/07/13 19:16, Uwe Schindler wrote: Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). My understanding of this is that it's something that should happen in the DHCP client and/or ISP DHCP server. Ie, when the prefix has to change, the ISP's DHCP server renews the existing prefix delegation, but with the preferred lifetime==0. It also offers a new prefix delegation. The old and new prefixes get installed in the network adaptor with the preferred lifetime values. Dnsmasq starts to advertise the new prefix and continues to advertise the old prefix, but with the pref- lifetime at zero taken from the value in the adaptor. The problem is different in most cases: When you have a dhcp client waiting on an PPPoE connection (e.g. wide-dhcpc, like most consumer routers use - ISC dhcp cannot listen on ppp interfaces unfortunately) and the PPPoE connection gets reconnected/disconnected, the ppp interface is disappears and is later recreated. When its disappearing, the whole set of IP addresses gets lost and they are not deprecated, so dnsmasq will not recognize any deprecation. I have seen your code that propagates the deprecation of existing interfaces in the RAs, but this only works if the prefix/IP address is still existing on the interface, just with preferred lifetime==0. With PPP interfaces disappearing and being recreated, this does not help, because the address is gone (it’s a new instance of the network interface, just with same name). As dnsmasq is mainly for consumer routers which are mostly working with PPP connections, it would be nice to have. Indeed ist more complicated but effect ist he same: For DSL lines you ahev in most cases the following setup: - PPP connection (PPPoE), creating network adaptor ppp0 - this adaptor is coming on going when connections are created/released - LAN interface (on which dnsmasq is listening), eth0, with a static IPv4 address and a dynamic IPv6 address prefix - wide-dhcpc client listening on the ppp0 interface and requesting prefix delegation. The delegated prefix is assigned as new address with given suffix (::1 or from mac address) to the eth0 interface. In fact, as you say: When ppp0 disconnects or reconnects, the wide-dhcp client should not actually remove the delegated prefix from the eth0 interface, but unfortunately it does. The reason for this is the following: the dhcp client stops when the ppp0 interface disappears, so it is restarted in the ifup scripts after the ppp connection was reconnected. When the wide-dhcpc client exits, it will clean up so it removes all addresses assigned - that's the problem. I think this is even more broken than that. Surely, what should happen if the PPPoE link goes down and then comes up again is that the DHCP client should attempt to renew existing DHCP leases, including prefix delegations. Any sensible DHCP server at the ISP should give back the same prefix delegations, so not only should the prefixes not be removed from eth0 just because ppp0 goes down, they will probably not even be deprecated once the PPP link is back. Using dnsmasq to deprecate them once the PPP link goes is the last thing you should do. Indeed! From my feeling the use of DHCP on a PPP interface is a horrible idea. Not even ISC's client supports it, but the providers seem to use it all, see https://datatracker.ietf.org/doc/rfc6204/ - So a fix in ISC's dhcp is long overdue to work with PPP - but e.g., https://bugzilla.redhat.com/show_bug.cgi?id=626514 is open since years! In contrast, wide-DHCP is dead, so no updates since 2008! To me this looks wrong altogether. The prefix should be assigned through the PPP protocol, like nameservers and addresses on IPv4.
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, On 25/07/13 11:59, Uwe Schindler wrote: Hi again, In addition, I found a relic from the time when the RA_INTERVAL value was hardcoded into radv.c. There is still one: Line 294: put_opt6_long(1800); /* lifetime - twice RA retransmit */ Should be: put_opt6_long(RA_INTERVAL * 2); /* lifetime - twice RA retransmit */ Yes, that's a bug. I am currently looking into the code to find an easy way how to make the RA_INTERVAL configureable, maybe I can provide a patch. But if it's easy for you, it would be really nice to have this in future versions. So the deprecation of addresses no longer used on the network interface is not my primary concern, more I would prefer to work around the bugs in certain android phones not receiving ICMPv6 messages in standby mode, so the RA_INTERVAL should be configureable (I want to set it to much lower values than 600s, I have a patched version with 6s retransmit running on my debian testing box). Note that RA_INTERVAL is used in the code for two related things. 1) It sets the lifetime values for parameters being sent. At the moment, the router advertisement is set to three times RA_INTERVAL, the DNS server and domain-search params are twice RA_INTERVAL, and prefixes are set to (at least RA_INTERVAL) 2) It sets how often unsolicited RA's are sent. Clearly these are related, the lifetime of parameters must be at least until they can be renewed by another RA, and preferably longer, to allow for packet loss. You probably don't want to reduce the lifetimes, that would be counter- productive for the Android bug. you do want to send RAs more often. The relevant code for that is here: if (difftime(param-now, context-ra_short_period_start) 60.0) /* range 5 - 20 */ context-ra_time = param-now + 5 + (rand16()/4400); else /* range 3/4 - 1 times RA_INTERVAL */ context-ra_time = param-now + (3 * RA_INTERVAL)/4 + ((RA_INTERVAL * (unsigned int)rand16()) 18); Which says that for the first minute after an configuration change, we send RAs every 5- 20 seconds, the actual delay is random. Once the first minute is up, we wait 3/4 of RA_INTERVAL to RA_INTERVAL. It seems to me that the simplest solution might be lock the fast RA mode, and never drop back to the full RA_INTERVAL delay. on a config flag as Android workaround mode This is a good idea, it is also easy to implement as a config flag? Another solution might be to derive the RA retransmit rate from the RA lifetimes, At the moment if you declare a RA prefix with a short lifetime, the lifetime gets extended to be as long as RA_INTERVAL, instead, we could reduce RA_INTERVAL to be the shortest configure lifetime (or actually half of that to allow for lost packets). In general I like the fast RA mode to be enabled with a config flag, but nevertheless, the constant RA_INTERVAL should be configureable, so you can customize it. I agree that lowering RA_INTERVAL currently also makes the lifetimes shorter, which is bad for the android bug. So I would decouple the RDNS, router and prefix lifetimes from RA_INTERVAL and make RA_INTERVAL configureable. In my opinion, the RDNS should have the dhcp--range's lease time as lifetime (minimum RA_INTERVAL). The prefix already has the lease time of the corresponding dhcp-range. The router itself could be in the same lifetime or even longer, especially as the router's link-local address is fixed and never changes. Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, reading https://datatracker.ietf.org/doc/rfc6204/?include_text=1, the requirements for home routers are listed here: L-13: If the delegated prefix changes, i.e., the current prefix is replaced with a new prefix without any overlapping time period, then the IPv6 CE router MUST immediately advertise the old prefix with a Preferred Lifetime of zero and a Valid Lifetime of the lower of the current Valid Lifetime and 2 hours (which must be decremented in real time) in a Router Advertisement message as described in Section 5.5.3, (e) of [RFC4862]. This was my original proposal. I agree that this should be done by the PPP/WAN interface and the DHCPv6 cleint on the WAN interface, so the old prefix gets deprecated, but with current software available (ISC dhcpd does not work on PPP interfaces but would support that using a shell script applying the prefix delegation - and wide-dhcpc supports PPP interfaces, but it allows not to configure prefix delegation, so in deprecates addresses after PPP reconnect or a change of the prefix). So I would be very happy, if dnsmasq (as router advertisement daemon would provide support for this). Radvd does it - see DeprecatePrefix options in radvd. Uwe On 24/07/13 19:16, Uwe Schindler wrote: Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). My understanding of this is that it's something that should happen in the DHCP client and/or ISP DHCP server. Ie, when the prefix has to change, the ISP's DHCP server renews the existing prefix delegation, but with the preferred lifetime==0. It also offers a new prefix delegation. The old and new prefixes get installed in the network adaptor with the preferred lifetime values. Dnsmasq starts to advertise the new prefix and continues to advertise the old prefix, but with the pref- lifetime at zero taken from the value in the adaptor. The problem is different in most cases: When you have a dhcp client waiting on an PPPoE connection (e.g. wide-dhcpc, like most consumer routers use - ISC dhcp cannot listen on ppp interfaces unfortunately) and the PPPoE connection gets reconnected/disconnected, the ppp interface is disappears and is later recreated. When its disappearing, the whole set of IP addresses gets lost and they are not deprecated, so dnsmasq will not recognize any deprecation. I have seen your code that propagates the deprecation of existing interfaces in the RAs, but this only works if the prefix/IP address is still existing on the interface, just with preferred lifetime==0. With PPP interfaces disappearing and being recreated, this does not help, because the address is gone (it’s a new instance of the network interface, just with same name). As dnsmasq is mainly for consumer routers which are mostly working with PPP connections, it would be nice to have. Indeed ist more complicated but effect ist he same: For DSL lines you ahev in most cases the following setup: - PPP connection (PPPoE), creating network adaptor ppp0 - this adaptor is coming on going when connections are created/released - LAN interface (on which dnsmasq is listening), eth0, with a static IPv4 address and a dynamic IPv6 address prefix - wide-dhcpc client listening on the ppp0 interface and requesting prefix delegation. The delegated prefix is assigned as new address with given suffix (::1 or from mac address) to the eth0 interface. In fact, as you say: When ppp0 disconnects or reconnects, the wide-dhcp client should not actually remove the delegated prefix from the eth0 interface, but unfortunately it does. The reason for this is the
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, RA's are not the same as DHCP, there's no such thing as a lease time. What there is, is preferred and valid lifetimes. What should happen is that when old address is about to go away, the address for that prefix on the network adaptor should have its preferred lifetime set to zero, and dnsmasq will then notice that and send RA's with the preferred lifetime also set to zero. I meant the life time, it was just a typo somehow :-) The idea here was to send preferred_lifetime=0 in RAs for prefixes that disappeared from the interface to inform the clients that they are no longer useable (my provider does not route old prefixes after a reconnect with PPP). Currently you have to set the lifetime very low (which produces more traffic on the wire) or manually delete or switch on/off the network adaptors once the router reconnects or the prefix changes for some reason. My proposal is to keep a list of previous prefixes from the constructor:ethX code and also send those prefixes, but with lifetime=0 to inform all client to no longer use that address. Those 0-lifetime RAs should be sent at least for the length of the original lifetime. Radvd has code to handle this (although it’s a bit buggy). Uwe ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
Hi, Le 16/07/2013 10:38, Uwe Schindler a écrit : Hi, I really like the dnsmasq implementation as replacement to my previous installation with radvd, because it closely integrates with DHCP. It also sends instant RA when a client requests DHCP, so it does not have to wait until the RA is sent out automatically. But I found a problem, especially happening with mobile phones (Android, Galaxy S3 in my case). When those go into sleep mode, they no longer listen to router advertisements, so after waking up, their address was already deprecated by the network stack and they have to wait for a new RA coming in. Unfortunately this happens too seldom (RA_INTERVAL is 600, means 10 minutes). They don't send any DHCP requests anymore, because the IPv4 DHCP lease is still fine (I have a lease time of 24 hrs for IPv4 leases, but 20 minutes for IPv6 lifetime - because those are not really static - see below). Would it be possible to make the RA_INTERVAL configureable so I can send RAs in a periodic manner like with radvd? I would like to send RAs every 3 or 10 seconds like I had with radvd configured. This is not possible without patching dnsmasq. Regardless of the interest of making the RA period configurable, why doesn't the mobile phone send out a Router Solicitation when it wakes up from sleep mode? A second thing related to RAs: I am living in Germany, where the assigned prefix to local networks is not really static (for privacy reasons), so it changes quite often (every 24hrs, enforced by DHCP prefix delegation on the PPPoE interface). When the prefix changes, dnsmasq should send (like radvd is doing) a zero lease time RA for the old prefix. I found out that dnsmasq.conf can set deprecated as life-time in the dhcp-range, but that would make all RAs going out have a time of 0s. It would be good if dnsmasq would send active prefixes with the given non-zero lifetime, but once a prefix disappears from the network adaptor, send extra RAs do deprecate the old prefix (using the old prefix with time=0) for a number of times. Uwe Amicalement, -- Albert. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?
I think this is related to this Android problem: https://code.google.com/p/android/issues/detail?id=32662 As you see, android devices sometimes ignore some packaets of the router advertisements, so if one is sent only once per 10 minutes, it hard for the phone to get them. This is why my previous radvd installation uses: MinRtrAdvInterval 3; MaxRtrAdvInterval 10; I just wanted to have a similar setup on dnsmasq, which was only possible by patching the header file and recompiling dnsmasq. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dnsmasq-discuss-boun...@lists.thekelleys.org.uk [mailto:dnsmasq- discuss-boun...@lists.thekelleys.org.uk] On Behalf Of Uwe Schindler Sent: Tuesday, July 16, 2013 11:15 AM To: 'Albert ARIBAUD'; dnsmasq-discuss@lists.thekelleys.org.uk Subject: Re: [Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes? Hi, But I found a problem, especially happening with mobile phones (Android, Galaxy S3 in my case). When those go into sleep mode, they no longer listen to router advertisements, so after waking up, their address was already deprecated by the network stack and they have to wait for a new RA coming in. Unfortunately this happens too seldom (RA_INTERVAL is 600, means 10 minutes). They don't send any DHCP requests anymore, because the IPv4 DHCP lease is still fine (I have a lease time of 24 hrs for IPv4 leases, but 20 minutes for IPv6 lifetime - because those are not really static - see below). Would it be possible to make the RA_INTERVAL configureable so I can send RAs in a periodic manner like with radvd? I would like to send RAs every 3 or 10 seconds like I had with radvd configured. This is not possible without patching dnsmasq. Regardless of the interest of making the RA period configurable, why doesn't the mobile phone send out a Router Solicitation when it wakes up from sleep mode? That is a good question but for actually 2 android phones this is not done: A Galaxy S3 (Android 4.1) and an older HTC Desire (Android 2.3) don't send Router Solicitations - those do not appear in logs. I think the reason why this happens has to do with the power management. I am not sure if this is 100% correct: When you switch off the screen of an Android phone, the WIFI goes to some kind of power saving mode so it only wakes up sometimes to listen for something going in. Most of the time it is sleeping. Maybe it does not get the Router Adverts in this state, because its just not awake when the router send adverts. When you wake it up, the timeout of the lease (which needs to be short on my networks, for the reasons of updated prefix delegations by the provider) is already reached, so the IPv6 address ist lost. The phone have to wait until a new advert comes in - I have no idea why it does not send router solicitations in this case, but I don't expect this to be fixed, so reconfiguring dnsmasq to send adverts every 6 seconds works perfectly fine here - it only floods the logs, but maybe this can be prevented by syslog to filter duplicate message. I patched the header file to have have RA_INTERVAL = 6 (was previously 600) and rebuilt the debian package. Now it works as expected. So my request here is just to make this configureable (maybe as param to enable-ra). Maybe also don't log *every* RA sent :-) If the following would be fixed, too, I could raise the DHCPv6 lease times to much larger values, because the automatic deprecation of prefix change would help here): A second thing related to RAs: I am living in Germany, where the assigned prefix to local networks is not really static (for privacy reasons), so it changes quite often (every 24hrs, enforced by DHCP prefix delegation on the PPPoE interface). When the prefix changes, dnsmasq should send (like radvd is doing) a zero lease time RA for the old prefix. I found out that dnsmasq.conf can set deprecated as life-time in the dhcp-range, but that would make all RAs going out have a time of 0s. It would be good if dnsmasq would send active prefixes with the given non-zero lifetime, but once a prefix disappears from the network adaptor, send extra RAs do deprecate the old prefix (using the old prefix with time=0) for a number of times. Uwe Amicalement, -- Albert. Thanks, Uwe ___ 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
