[Dnsmasq-discuss] Make RA_INTERVAL configureable? Deprecate old prefixes?

Simon Kelley simon at thekelleys.org.uk
Mon Jul 29 16:00:25 BST 2013


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 at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>




More information about the Dnsmasq-discuss mailing list