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.
