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

Simon Kelley simon at thekelleys.org.uk
Tue Apr 25 09:42:14 BST 2006

[ Answering both your replies]

Fabio Muzzi wrote:

> Agreed.  Actually,  on  startup  you could also ignore the leases
> that are already  stored  in  the lease file. I mean, if the gateway
> reboots, every client will have to re-autenticate, but this is not a
> great issue, because the gateway MUST NOT reboot in normal operation.
> Or did I miss something?

That makes sense for your application, having "add" events for existing
leases when dnsmasq starts is a good thing to have in general. I can
imagine a firewall setup which sets a rule for each client: there's no
reason not to re-insert these rules after a reboot: the DHCP leases will
be in good shape.

For your application, you can do dhcp-leasefile=/dev/null and have all
leases completely evaporate when dnsmasq is restarted.

> SK> That  works  much  better,  but  it  needs  more work to use the
> lease SK> records  to  keep information about script execution. (You
> can't throw SK> away a lease record when it expires until you've run
> the script.)
> Well,  you  can  execute  the "expire" call to the script exactly
> when you delete the old record from the lease file, or am I wrong?

You could, if you blocked dnsmasq waiting the the script to terminate,
but that's a bit risky. No DNS or DHCP at all when the script is
running. What I've done is fork() and run the script asynchronously,
whilst it's running dnsmasq continues as normal. The complication is if
"running as normal" generates another lease event before the first
script finishes. Since the rule is "only one script at a time" the
second script invokation has to be queued. It turns out that using lease
datastructures allows this. In the current implementation, even if a 
script _never_ returns, dnsmasq will continue to run fine, but no new 
scripts will get run (obviously) and dnsmasq will not be able to free 
the memory associated with expired leases, so its memory usage will grow 
(but only slowly).
> SK> The old problem of userid still exists.
> Yes,  and  for  the  first test I will run as root. Then I'll see if
> I can find a better way.

I suspect that might be the best way.

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

Is this a problem only for the last client, because it hangs around for 
an indeterminate length of time, or do you need all lease ends signaled 
within a few minutes? There are a couple of approaches to doing this, 
I'll have a think about it.

 >I understand,  if  >I'm  not  wrong, that this could be achieved by 
 >compiling with >"have_broken_rtc", but maybe there is a better >solution.

That's not a solution on the latest releases, they no longer need to do 
periodic writes to the leasefile in broken_rtc mode.

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

This is easy, but the dhcp-leasefile=/dev/null solution to suppressing 
these events completely will probably work better in your case.





More information about the Dnsmasq-discuss mailing list