[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.
Cheers,
Simon,
Cheers,
Simon.
More information about the Dnsmasq-discuss
mailing list