DHCP clients getting different lease times
-
Hi,
I've been checking on my setup and noticed that clients seem to be getting different dhcp lease time durations.
Any ideas?
Version: 2.4.4 p3
Services > DHCP Server;
The default lease time is 41400
The maximum lease time is 43200
However under Status > DHCP leases;
-
Notice the wording for the default and maximum lease times. The default lease time is applied to "clients that do not ask for a specific expiration time" and the the maximum lease time is applied to "clients that ask for a specific expiration time." So you can set a ceiling on clients that ask for a specific expiration time, but not a floor. I haven't looked through all your leases, but none should be longer than 43200 seconds (12 hours). However, at the top you have a lease that only lasts 10 minutes. That must be because that Android device explicitly requested a lease that only lasts for 10 minutes. Requesting shorter leases by default is a reasonable thing for phones to do, for example, since they are often unlikely to remain in the same place for extended periods of time. It's probably a setting you could change on a per-device basis, but unless you have a very large number of devices on your network all requesting short leases, the traffic incurred for lease renewals is going to be negligible.
-
Afternoon,
Thank you, I was considering manually setting option 51, do you have any thoughts?
-
I'n not a DHCP expert by any means, but I took a look at option 51 and it sounds to me like it will do what you want. If I interpret it correctly, it will override both the default and maximum settings, and just give every client the lease length that you set for option 51 whether the client requests a specific time or not. I'd be inclined to try it and see whether it does what you expect. I don't think it should hurt anything, unless certain clients balk at not getting the lease time they request; but they shouldn't.
-
No need to set it in the Additional BOOTP/DHCP Options, its in the other options.
-
After some research, it turns out Android devices don't acknowledge option 51. My problem is users can get a new dhcp address before the captive portal max duration is exceeded. Which I believe is causing the end device to lose internet access until they accept the T&C's again.
-
I am looking also to decrease lease time of 3 Android phones. My Domoticz system has a plug-in which tracks the phones. The phones have a static ip address, but it takes about 20minutes before they are reported offline.
I already decreased the lease time to (3min. default and 5min. maximum) in the settings of one phone, but that doesn’t change anything -
An answer there is to make your pool bigger. The issue is not them renewing the lease before the portal session expires, it's them getting a different IP address before the portal session expires.
The DHCP server will try really hard to give the same MAC address the same IP address it had before. If someone else already has it, tough luck.
It's a matter of sizing your pool based on device churn during the session interval, not sizing it based on maximum connected devices at any one time.
-
But I gave them a static address...Doesn’t that prevent getting a different lease then?
-
If you gave them a fixed DHCP lease it should give them the same address regardless. Captive portal does not care as long as the MAC/IP address tuple does not change.
Maybe you can describe the problem you are looking to solve more clearly.
-
On my domoticz system I use a device presence detection plug-in. This keeps track of (in my case) 3 phones in my network. The plug-in creates switches in the Domoticz system which are are turned “ON” when a phone is active in the network and “OFF” when it is not not active. Based on this knowledge scripts can be made to turn on/off devices like lights, shutters, audio/video. The plug-in connects via ssh into a router and uses a variety of methods (depending on the type of router) to figure out the network presence of the specified devices.
For pfSense the plug-in uses “arp -a“ as an argument to scan the network. However it takes about 10-20 minutes (10min when the phones are in the dhcp pool, and 20min, when they have a static ip) before the plug-in reports a phone is offline.
I want to decrease that time to 3-5 minutes, because this may save some energy (e.g. a domoticz script does: turn off all lights if all 3 phones are not present in the network for 5 minutes).
PfSense can use different methods (including arping and nmap). Which one is best to use and which amount of polls and gracing time is enough to be sure a device is really offline?
-
I would argue that if you are looking at playing with ARP timeout values to accomplish something like that you are doing it wrong. Not sure what right is but that sounds like nothing but trouble to me.
ARP is probably the most positive method of determining if a device is or is not active on that segment. Mostly because you can generally get an ARP response even if the node is completely firewalling inbound connections.
If you do not require DNS resolution of the IP addresses,
arp -anwill probably return much faster. -
@gschmidt said in DHCP clients getting different lease times:
I want to decrease that time to 3-5 minutes, because this may save some energy
Ok this peaked my curiosity ;)
How many freaking lights do you have on exactly that a savings of lets say 17mins would be of any significance? I could see turning them off if nobody is home, ie they forget to turn them off when they left the house for day of work... But how much do you think that extra 17 minutes gets you?
Lets make the math easy... lets say you got every light in the house on - and your burning 1000watts.. You have some major floodlights ;)
For 1 hour, at .12 cents per kwh (average in the US).. that would be $0.12... So that extra 17 minutes of off time would be saving you a whole 3.4 cents... I can not image anyone using close to 1000 watts of "lights" especially these days of led lights.. So your talking talking what maybe a penny of savings, maybe ;)
