[Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues

Vladislav Grishenko 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
flag.
> >
> > 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
know
> what want it use a 6in4 tunnel via a tunnel broker. I'm using Sixxs and it
works
> 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
tomorrow.
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
> time.
> 
> Use a dhcp-script. That has the the information you need in the
environment
> 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"
> event.

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 mailing list