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

Uwe Schindler uwe at thetaphi.de
Mon Jul 29 16:57:23 BST 2013


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




More information about the Dnsmasq-discuss mailing list