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] PATCH: Address some FQDN issues
On 24/07/13 16:04, Roy Marples wrote: On 24/07/2013 14:29, Simon Kelley wrote: I think this should happen already: for IPv4 calls to do_options have the domain argument which is set to the result of get_domain(address) which will be domain-suffix unless there's a more specific example. This is for INFOREQ where there is no address, but is assigned DHCP values via matching clientid/hwadddr. Thus get_domain(address) is never called. OK, that makes sense. I've just pushed changes for IPv6 which set the domain for INFOREQ 1) From dhcp-host if a FQDN is given there. 2) otherwise from --domain. Does that make more sense. I think the patches to DHCPv4 don't make sense, since DHCPINFORM does always have an address, though for consistency with DHCPv6, we could make the FQDN in --dhcp-host take priority. 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, 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] Decouple enable-tftp and no-dhcp-interface
On Jul 25, 2013, at 4:44 PM, Lonnie Abelbeck wrote: On Jul 25, 2013, at 4:06 PM, Simon Kelley wrote: On 23/06/13 20:34, Lonnie Abelbeck wrote: Hi, I'd like to suggest that enable-tftp and no-dhcp-interface should be decoupled. Not only is it confusing that no-dhcp-interface also disables enable-tftp for that interface, but it is sometimes desirable to allow DNS and TFTP on an interface without DHCP. Looking at src/tftp.c is seems there is no dependance on DHCP except to walk the no-dhcp-interface args when HAVE_DHCP is defined. Ideally, IMHO, enable-tftp should be independent from HAVE_DHCP and add a new no-tftp-interface config that would be tested for interface exceptions instead of no-dhcp-interface. Reasonable ? The rationale for the current state-of-the-world is that the TFTP server in dnsmasq is provided for the express purpose of doing netbooting, so it makes sense to do TFTP on the same interfaces/addresses as DHCP. I'd like to keep that as-is, for backwards compatibility if no other reason, so I suggest that we could add new option --tftp-interface that would have a higher priority than no-dhcp-interface. SO, to do TFTP but NOT DHCP on eth0 you'd do no-dhcp-interface=eth0 tftp-interface=eth0 No existing configs would change meaning, and the common case wouldn't need to use the new option. Comments? Simon. To be clear, if in the above example eth1 had DHCP enabled, then TFTP would be served on both eth0 and eth1 ? If so, would this be more clear ? -- tftp-no-dhcp-interface=eth0 -- which would be a synonym for no-dhcp-interface but would mark that interface to allow TFTP. I agree no change to existing configs is best. Lonnie Replying to myself, another idea... Allow enable-tftp to work the same as currently, but then add enable-tftp= with options: # Limit TFTP server to a list of interfaces --enable-tftp=eth1,eth2 # Allow TFTP server for all interfaces --enable-tftp=* Then enable-tftp and enable-tftp= can't both be specified. Lonnie ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
