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

[Fabio Muzzi]

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.

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.

When  the  last  client  disconnects,  I  get no "del" event, which is not
acceptable.



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

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.




-- 

  Fabio "Kurgan" Muzzi