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