[Dnsmasq-discuss] dnsmasq 2.61test7 & RA issues

[Simon Kelley]

On 25/03/12 14:21, Vladislav Grishenko wrote:
>> 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.

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.

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


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.

Cheers,

Simon.