[Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues

[Vladislav Grishenko]

> From: Simon Kelley
> Sent: Sunday, March 25, 2012 6:17 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.

> >>> 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.

> > Don't you find this trade-off between totally inaccurate lease time
> > and almost accurate with expections - as acceptable?
> 
> Yes. It would be unacceptable if the leases turned out shorter than
> promised, but this can only  make the leases longer. When a client gets a
> lease, it gets a promise that the address ins available for x hours.
> Increasing the time before the lease expires can only be a problem if
there's
> a shortage of addresses, so that addresses cannot be reused. In most
cases,
> the DHCP server will be up much longer than the lease time, so the effect
is
> small. If the DHCP server goes down often, the solution is to reduce the
lease
> time. Reducing the frequency of writes to flash is important.

Ok, that's true, it doesn't harm.
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.

Best Regards, Vladislav Grishenko