The determination of these lifetimes was changed in dnsmasq-2.67 to be based on the preferred lifetime of the prefix whose local address is being advertised, which is normally the prefix with the longest preferred lifetime on the interface. That seems to me to be a more sensible metric, and should address this problem.



On 05/11/13 18:05, Dan Williams wrote:
On Tue, 2013-11-05 at 09:21 +0100, Gui Iribarren wrote:
so, we started suffering frequent, periodic disconnects on clients since
upgrading dnsmasq 2.62 ->  2.66

tracking down the issue, it came down to a network-manager bug while
maintaining the RDNSS list, where an unhandled expiring RDNSS lifetime
results in a full reconnection

We've fixed a number of NM bugs in this area, specifically (a) adding
some elasticity before deciding the DNS servers have expired, and (b)
sending Router Solicitations before they have expired, to get updated

problem is, the kernel only understands the *router* lifetime, but
ignores everything about the RDNSS lifetime; and if the latter is
shorter than the former, then the RDNSS expires before the kernel sends
a RS to handle the *router* expiring lifetime.

RFC6106 says the lifetime SHOULD be bounded by "MaxRtrAdvInterval<=
Lifetime<= 2*MaxRtrAdvInterval", which allows at least one dropped RA,
and which NM should compensate for with the above mentioned fixes.

As you say below, the bug was fixed in NM 0.9.6 (released 2012-08-07, so
over a year ago) and I'd recommend that the distro just upgrade to get
the fixes instead of hacking around the issue in dnsmasq, which is
following the RFC.  It was clearly a NetworkManager bug.


in dnsmasq 2.62, router lifetime was equal to RDNSS lifetime, as shown

# rdisc6 wlan0
Soliciting ff02::2 (ff02::2) on wlan0...

Hop limit                 :           64 (      0x40)
Stateful address conf.    :           No
Stateful other conf.      :           No
Mobile home agent         :           No
Router preference         :       medium
Neighbor discovery proxy  :           No
Router lifetime           :         1800 (0x00000708) seconds
   Recursive DNS server     : fe80::fad1:11ff:fe54:3381
    DNS server lifetime     :         1800 (0x00000708) seconds
   from fe80::fad1:11ff:fe54:3381

this prevented the situation where the network-manager bug would happen:
as the kernel would issue a RS to renew the router lifetime, the RDNSS
was renewed as well, just in time

in network-manager 0.9.6 the bug is fixed (NM sends a RS by itself,
before RDNSS expires, independent of RtrAdvLifetime)
but notably debian squeeze still ships 0.9.4, which reconnects to the
network every 20 minutes when talking to a dnsmasq v2.66 (worked well
against v2.62)

Router lifetime           :         1800 (0x00000708) seconds
    DNS server lifetime     :         1200 (0x000004b0) seconds

then, even though it's the debian/etc maintainers who should fix their

can we anyway consider going back to the old behaviour in dnsmasq, to
help mitigation?
(RtrAdvLifetime = RDNSSLifetime)

i understand v2.66 follows RFC6106

       Lifetime      32-bit unsigned integer.  The maximum time, in
                     seconds (relative to the time the packet is sent),
                     over which this RDNSS address MAY be used for name
                     resolution.  Hosts MAY send a Router Solicitation to
                     ensure the RDNSS information is fresh before the
                     interval expires.  In order to provide fixed hosts
                     with stable DNS service and allow mobile hosts to
                     prefer local RDNSSes to remote RDNSSes, the value of
                     Lifetime SHOULD be bounded as
                     MaxRtrAdvInterval<= Lifetime<= 2*MaxRtrAdvInterval
                     where MaxRtrAdvInterval is the Maximum RA Interval
                     defined in [RFC4861].  A value of all one bits
                     (0xffffffff) represents infinity.  A value of zero
                     means that the RDNSS address MUST no longer be used.

but this RFC has been criticised already[1] (since it creates a fragile
situation, where a single or couple of RA packet losses - common in wifi
scenarios - are enough to lose the race condition)


and using RtrAdvLifetime = RDNSSLifetime only defies the "SHOULD"
keyword used in the RFC, strictly speaking.
in addition, dnsmasq (contrary to radvd) actually provides the RDNSS
service itself, so it's shouldn't be much of an issue to announce a
longer lifetime for that?

just a thought :)



Dnsmasq-discuss mailing list

Dnsmasq-discuss mailing list

Dnsmasq-discuss mailing list

Reply via email to