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 deprecated, use the current lifetime in the last RA and decrement it from now on. Uwe _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
