[Dnsmasq-discuss] Execute external commands on DHCP lease allocation / deallocation

Simon Kelley simon at thekelleys.org.uk
Tue Apr 25 12:35:49 BST 2006


Fabio Muzzi wrote:
> Hello Simon,
> 
> Tuesday, April 25, 2006, 10:42:14 AM, you wrote:
> 
> 
> 
> 
>  >>Important: "del" events happen only when some other dhcp event triggers
>  >>a  pruning  of  the  lease  file.  This means that when the last client
>  >>leaves  the  network  its lease will expire, but no "del" event will be
>  >>triggered until a new client connects and asks for a lease. This should
>  >>be  corrected,  since  I  rely  on  "del"  events to "logically logoff"
>  >>clients that switch off without logging off from the captive portal web
>  >>page  (that  is,  100%  of  the clients). Ideally, delete events should
>  >>happen  as soon as a lease expires, but a little delay (5 minutes?) can
>  >>be acceptable in my set-up.
> 
> SK> Is this a problem only for the last client, because it hangs around for 
> SK> an indeterminate length of time, or do you need all lease ends signaled 
> SK> within a few minutes? There are a couple of approaches to doing this, 
> SK> I'll have a think about it.
> 
> The  best solution at all should be that every "del" event is triggered at
> actual  lease  expiry,  or at least a few minutes after it. Ideally, there
> should  be  no delay, and all "del" events should be triggered immediately
> at lease expiry. This allows me for the maximum control over what happens,
> removing all of the time uncertainties.

OK, I'll aim for that.
> 
> I am currently running with a lease time of 2 minutes (the minimum allowed
> by  dnsmasq)  so  when  there are connected clients these generate "renew"
> dhcp  events  every  minute  (windows  renews  at  half  the expiry time),
> triggering  "del"  events  for  expired  leases,  which  is an accepptable
> situiation,  because  I  get "del" events with a delay of no more than a 2
> minutes.

Don't be tempted to reduce it below two minutes. There are clients out 
there (Apple's, I think) which will break.
> 
> When  the  last  client  disconnects,  I  get no "del" event, which is not
> acceptable.

Understood.
> 
> 
> 
>  >>Not-so-important:  Maybe  you  should differentiate, if it's not too
>  >>hard, between  "add"  events  triggered  by dhcp lease allocations and 
>  >>the "add" events  triggered by leases file being read at startup. This 
>  >>will allow me to  distinguish  between  "restart-triggered"  events 
>  >>and  normal  client connection  events. It's not necessary to 
>  >>distinguish between "del" events that happen during normal execution 
>  >>and "del" events that are triggered at startup, at least for my set-up.
> 
> 
> SK> This is easy, but the dhcp-leasefile=/dev/null solution to suppressing 
> SK> these events completely will probably work better in your case.
> 
> If  it's  easy,  please differentiate between "start-up" deletes and adds,
> and  "normal" deletes and adds. This allows for maximum flexibility in any
> set-up, and it should be worth the time spent doing it.

Will do.
> 
> I have thought about it and found that if I reboot, I can live with a null
> leasefile,  but  I  could have better control over firewall rules (and not
> disrupt  service)  if  I'm aware of start-up time deletions and additions,
> provided I can distinguish between start-up and normal events.

OK. expect some more code this evening (UTC).


Cheers,

Simon.


> 
> 
> 
> 




More information about the Dnsmasq-discuss mailing list