[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