[Dnsmasq-discuss] old event to dhcp-script on lease expiry

[Simon Kelley]

On 27/06/14 21:43, Nehal J Wani wrote:
> On Sat, Jun 28, 2014 at 12:58 AM, Simon Kelley <simon at thekelleys.org.uk> wrote:
>> On 27/06/14 19:40, Nehal J Wani wrote:
>>>> An "old" event is not generated when a lease is _renewed_ (ie when the
>>>> only thing that changes is the expiration time) unless the option
>>>> leasefile-ro is set. Note that setting leasefile-ro has a bunch of other
>>>> effects too.
>>>>
>>>> When a lease _expires_ (ie the end time of the lease is reached without
>>>> it being renewed) then a a "del" event is generated.
>>>
>>> So, if I understand correctly, there is no way to maintain the leases
>>> file database *and* have my own script catch all events? Why does
>>> dnsmasq put such restrictions?
>>
>> That's correct. The reason for the behaviour is mainly historical. At
>> first, the script received just the events needed to log the existance
>> of leases.      Later, the ability to use the script to maintain the lease
>> database was added, and for that, changes to the expiration time had to
>> be noted. THe old behaviour (when leasefile-ro is not set) stayed for
>> backwards compatibility.
>>
>>> It would be cool to have both
>>> concurrently.
>>
>> As a pragmatic approach, the patch to get the behaviour you want is very
>> small.
>>
> 
> Recently, an API for querying leases info guest machines was pushed in
> libvirt and will most likely be available in 1.2.6. Since this library
> is used by many people around the world, and we have our custom lease
> file helper, which maintains a separate database for leases in JSON
> format, if we just enable leasefile-ro, then we will loose the lease
> file generated by dnsmasq, and we don't want that. Hence, sending a
> patch is fine by me, but will you be willing to have this option
> available in dnsmasq?

Yes. For that application, you clearly don't want a third-party patch.
At very least I'd be willing to add a boolean option to dnsmasq which
enables "old" events when the lease expiry time changes, independent of
leasefile-ro.

> 
>>>
>>> Another question, not very much related to dnsmasq, is that when a
>>> machine receives a lease for a particular period, when should it query
>>> the DHCP again for a new lease? Is it bound to do so, by some RFC? Or
>>> is a matter of choice by the developer?
>>
>> The server can include the information in the lease. There are three
>> options which it can include. The length of the lease is mandatory, and
>> there are two options called T1 and T2. T1 is the time after which the
>> client should renew the lease by doing unicast to the server which gave
>> it the lease. T2 is the time after which the client should try
>> broadcasting if it fails to renew the lease, to give the other half of a
>> failover pair a chance to reply. T1 defaults to half of the lease time,
>> and T2 to 7/8ths of the leasetime. In practise it's very rare to use
>> other values for these. Dnsmasq always send T1 as half lease time and T2
>> as 7/8th the lease time. It doesn't allow them to be configured
>> differently. The RFC the details this is RFC 2131.
>>
> 
> Thanks for all this info.
> Query1: If the lease time is say, 10 minutes, then T1 will be 5
> minutes. Then according to the RFC, the machine should ask for a
> renewal of the lease from the DHCP server using the unicast method? In
> this case, no event will be generated?

The primary key of the lease database is the IP address. Everything else
about a lease can change as long as the IP address remains. Think of an
"old" event as saying "The lease for this IP address has changed in some
way". The change could be to the associated hostname, or client-ID or
MAC address. "old" events are generated for all existing leases when
dnsmasq starts, just to synchronise things. Or it could be that new
information about the lease has become available* When leasefile-ro is
set then the expiry time of the lease is included in this. When the
expiry time changes because the client renewed the lease, then the "old"
method gets called. Without leasefile-ro, them changes _just_ to the
expiry time don't count as changes to the lease.

* There are lots of things supplied to the script that aren't stored in
the lease database, for instance vendor-class and user-class, and relay
options such at circuit-id. When dnsmasq starts, these aren't known, so
the "old" method is invoked without them. Once the client makes a DHCP
transaction, they become known and the "old" method could be invoked
again with the extra information.

>  But you said that, "The old
> behaviour (when leasefile-ro is not set) stayed for backwards
> compatibility."

> Query2: What does dnsmasq do if the machine sends no request for
> renewal at all? Will it just delete the lease?

Once the lease reaches its expiry time, it will be deleted, and a "del"
event sent to the script.

Cheers,

Simon.

>