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

[Nehal J Wani]

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?

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