[Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues
themiron at mail.ru
Sun Mar 25 16:15:12 BST 2012
> From: Simon Kelley
> Sent: Sunday, March 25, 2012 7:48 PM
> >>>>> 3.Periodic RA isn't working, because alarm code goes into (dhcp ||
> >>>>> dhcp6) path and don't trigger RA alarms
> >>>> This code does that, I think.
> >>>> #ifdef HAVE_DHCP6
> >>>> else if (daemon->ra_contexts)
> >>>> /* Not doing DHCP, so no lease system, manage alarms for
> >>>> ra
> >>> only */
> >>>> send_alarm(periodic_ra(now), now); #endif
> >>> Yes, but it "else" condition of (damon->dhcp || daemon->dhcp6).
> >>> In my case and example, damon->dhcp is enabled, so periodic_ra will
> >>> not be executed as expected several times while first minute.
> >> In the damon->dhcp || daemon->dhcp6 case, send_alarm is called from
> >> lease_update_file, since the first event in the future might be a
> >> lease
> > expiry,
> >> or it might be an RA multicast.
> > Got it, unfortunately under some circumstances there'll be neither
> > incoming router solicitations nor immediate dhcp leases expiration to
> trigger RA.
> > Example: big dhcpv4 leases ~ week to not stress network, dnsmasq
> > restart due reboot/etc, clients connected via 3 network switches
> > dnsmasq - [switch1] - [switch2] - [switch3] - IPV6 only clients.
> > If switch 2 is temporary off, dnsmasq and clients see the links up and
> > therefore take no action, so RA packets could be either not
> > originated/ or just lost.
> > That means RA timers should work independent to other dhcp/dhcp6
> > events, especially if the last ones are quite long.
> They do. Check the code at the end of lease_update_file()
> It find the shortest of
> time to next RA
> time to next ICMP6 for SLAAC-confirm
> time to next lease expiry
> LEASE_RETRY - if the leasefile write failed.
> and sets the alarm to the time to first event.
> >>>>> Only other netlink/dhcpv4 events could trigger it. Also, even if
> >>>>> fixed event logic leads to DHCP leases rewrite on every RA event
> >>>>> by
> >> design.
> >> It shouldn't. There'd a check in lease_update_file of the file_dirty
> > Yep, really. Thanks for pointing out.
> >> The 6to4 case, maybe more useful.
> >> But is 6to4 going to be used much in the real world?
> > I'd say 6to4 is the only easy solution for end-users at the moment
> > whose ISP doesn't allow any IPv6.
> > If they uses some kind of CPE in router mode with dnsmasq on-board and
> > want to use IPv6 too, it makes sense.
> > Frankly speaking, in Russia/UA the majority ISP doesn't offer IPv6
> > connectivity at all.
> That's true in most places. Very few UK ISPs offer IPv6. Most people I
> what want it use a 6in4 tunnel via a tunnel broker. I'm using Sixxs and it
> very well. 6to4 has a bad reputation, partly because it comes with
> asymmetric routing.
> I think most people will not get IPv6 until their ISP offers it.
Asymmetric routing can't be treated as bad-only, it has dual effect that
makes lower RTT also possible, comparing to 6in4/gogo6/etc tunnels per
countries. I'd say it's geo-dependent.
Anyway, 6to4 pro and cons discussing is out of the subject, the fact is it's
still more than widely used and will be used tomorrow and even the day after
Personally I can't force users avoid to use tunnels just because it's
theoretically worse than native IPv6 connections, which are just not
available. Not a perfect world, yeah.
> > But, there's no other easy way to get runtime clients stats including
> > expiration (actually, preferred remaining) time with HAVE_BROKEN_RTC.
> > With udpcpd it can be done via dumpleases or just to read & parse
> > udhcpd's lease file and I was hoping for the same approach for dnsmasq.
> > Leases get read by request, so triggering actual lease file write
> > isn't the problem (used signal), the problem is no expiration/remaining
> Use a dhcp-script. That has the the information you need in the
> variable DNSMASQ_TIME_REMAINING.
> If you don't want to store the data persistently, then send SIGHUP to
> dnsmasq and it will call the script on all existing leases with an "old"
Thanks, that was the documented way,
Script support gives +10Kb to dnsmasq size, corresponding script binding and
asymmetric of per-lease recording add more complexity.
So, I was thinking just about to add another one parameter to dnsmasq
leases file with remaining time. Code is shared for RTC and BROKEN_RTC,
costs almost nothing to size, and for second case it would fix lease
prolongation issue as well. Of course, I can use it for my purposes only,
just let you know about.
More information about the Dnsmasq-discuss