DHCP host status update time

[CloudNode]

Would anyone happen to know the default time a client online status takes to update in the dhcp lease screen? When a client goes offline, I notice it takes around 20 mins for that host to show the actual status change to offline.

[johnpoz]

@CloudNode yeah 20 minutes is how long things stay in the arp cache.. So that would be the max it could take..

But if the device goes offline when there is 30 seconds left in the cache, then it would update in 30 seconds..

Just look at your arp table

arp -a

or via the gui, look in the arp table under diagnostics menu

If you want to change it, setting net.link.ether.inet.max_age should work.. Not 100% because never really had a need/desire to change the 20 min default

[CloudNode]

@johnpoz thanks.. my use case is that I am running the following command from a Debian container

snmpwalk -v 2c -OXsq  -c public 192.168.2.1 .1.3.6.1.2.1.4.22.1.2

That picks up the active Macs and provides their MAC address and ip address and from there I use that data to tell me of a new device (Mac) shows up and alerts me. I have it running every 6 mins

And if a device connects and then disconnects before the 20 mins cycle, then I want my script to still be able to see the device as it would still be active in the arp cache.

But I was not aware of the device connects and disconnects, there is still a chance for it not to pickup within my script that runs every 6 mins as that cache cycle may be towards the end. Hmmm, not too sure how to handle that one..

[johnpoz]

@CloudNode if cache is 20 min which it is unless you changed it and your script runs every 6 minutes, I don't see how you would miss one..

if cache expired just after you checked, you wouldn't know the device is gone until the next run in another 6 minutes, that sort of thing..

But lets say a device connected, even for 1 second and sent any traffic on the wire at all to pfsense that pfsense had to answer, then the item would be in the cache for 20 minutes.. so you would catch it on the next run..

Off the top of my head I can't think of a scenario where you would miss a device.. Only a delay for 6 minutes in knowing it went a way.. But that could be longer.. So say a client got on 1 second after you just checked and then left.. You wouldn't know it was gone for 4 cycles of your check..

Prob the most accurate way to know if something on or off your network would be to run an arpscan at the specific interval.. Say every 5 minutes.. But in that scenario you could miss something that got on only for 4 minutes.. You would prob have to combine arpscan and looking in arp cache of pfsense to know precise details..

[CloudNode]

@johnpoz So if a device connects and then disconnects and the cache cycle like you said has let’s say 30 seconds left and my script lets say still has 3 mins before I runs then it will not see that devices as the arp table will clear. (If I read your statement correct)?

Unless… there is a way when a device is online/active I can get pfsense to kick a script off. Then I don’t need to even poll every 6 mins.

[johnpoz]

@CloudNode read my edit.. think I covered most of the scenarios

[CloudNode]

@johnpoz thanks.. is a way when a device is online/active I can get pfsense to kick a script off? The same way arp watch functions where it kicks off an alert as soon as a devices comes comes online. Then I don’t need to even poll every 6 mins.

Or I need to time the exact 20 min cycle start on pfsense and start my crontab to every 5 mins and that way I will always be within the cycle.

[johnpoz]

@CloudNode you can look at the arpwatch package - it can alert you when something new is detected.. But not sure it will alert if once that devices comes back a 2nd time, etc.

It has its own flakiness to it, can be noisy alerting on stuff you don't want like dhcp discovers, etc

But maybe it will work for you.. Can't hurt to play with it for a bit ;)

[CloudNode]

@johnpoz oh I have played with it already. Not a fan of it.

I made a really nice script that performs snmpwalk for dhcp clients and stores the Mac and IP to a know device file and when you runs another cycle it performs a walk, compares the Mac’s to the known device file and will only alert via telegram if there is something new and then also log that entry into a client log file. If nothing new is found, then nothing happens. New items will be sent to telegram (Mac, IP and host name).

I ran a test now where I connected 2 different devices and can see them on the arp table. I connected then 5 mins from each other. 1st device fell off in 20 mins but the 2nd device did not fall off at that time. 5 to 6 mins later it fell off. So it seems like the cycle count may be per device

[johnpoz]

@CloudNode said in DHCP host status update time:

cycle count may be per device

yeah why would you think it clears its whole cache every 20 minutes?

Look at your arp table and you can see exactly how long each device has left.

[CloudNode]

@johnpoz ah man, I thought from your first post that the arp cache cycle was for all devices and if one is offline during the next cycle it will perform an update and show the actual device status.

Per device cycle will be 100% fine for me with a script pull every 5 to 8 mins. (Most likely will stick to 5 mins)