In the DHCP Configuration page, it would be nice if the page showed us how many Leases are in use out of how many available. I have one firewall that has a lot of leases in use and it would be nice to see at a glance if I am getting close to using up all available leases. Right now, I copy all the leases to a spreadsheet and use the rows filled to determine how many leases are in use.
3 Likes
For the DHCP server all IPs handed out sometimes are ‘in use’.
Even if the lease time has expired, the relation IP <—> MAC is retained. If a device, identified by the MAC, without an IP sends a request it gets the IP defined by this ‘old’ lease relation.
It is possible to count the defined dynamic leases and give an information
<#of possible IPs>,<#of expired leases>,<#of active leases>
Is this the feature you think of?
Yes. Something like:
Total Addresses: 150
In Use: 104 (69%)
Available: 46 (31%)
2 Likes
Looking at the sources ( dhcp.cgi ) shows it isn’t such easy as it sounds.
dhcp.cgi is one of the ‘odd’ programs of IPFire. The printing of the dynamic leases is a separate function in /var/ipfire/header.pl which just reads the info from dhcpd’s leases file, without knowing the configuration.
Your feature would request a reorganisation of these sources.
Okay, thank you for checking. I do believe it could be a useful feature in environments where DHCP usage is high. Perhaps the feature could be put on a list for future consideration.
1 Like
Searching on the internet, I found a cgi/perl program called dhcpstatus, however, it was written in 2000 and would most like have to be re-written, because dhcpd.conf and dhcpd.leases files probably have a different format.
But it shouldn’t be that hard to take the difference between the end and start address of the dhcp to get the total, then count how many current leases and generate all the numbers from there (% available, how many IPs available, etc)
1 Like
I remember an add-on called “Who’s online?”
Can this be of any help?
Not really. It just shows what DHCP server shows, but adds a button that says whether that system is offline or online. What I’m looking for is similar to what I’ve seen in other consumer routers and in Windows Server’s DHCP page:
Total DHCP Leases
Used DHCP Leases
Unused DHCP Leases
When dealing with 200+ leases, this is very valuable to see at a glance whether you are approaching capacity. Right now IPFire just shows a long list of leases in use. It may look like all or most leases are in use, but until you actually count them, you won’t know. This is where I have to copy the leases, paste them into a spreadsheet, and use the rows field to see how many are in use.
1 Like
I’ll touch back on this, as I have to go on an service call and be out for much of the day, but it shouldn’t be that hard considering 80% of the info is already called to the page.
One thing I don’t understand is the leases with the strike through mark and we should be able to control this behaviour as maybe 48 hrs after a lease expired might be handy for some while others wouldn’t care about past expired leases.
1 Like
The basic behaviour of the DHCP server is ( ignoring the fixed leases, which have a set of IPS outside the dynamic set { start_addr … end_addr } ):
- start: free_set={start_addr, …, end_addr}, old_leases={}, active_leases{}
- loop:
- request for IP by device(MAC)
- search for MAC in active_leases, if found select IP from tuple, update element to (MAC, IP, new lease_time), goto send
- search in old_lease for MAC, if found select IP from (MAC,IP,last_request_time) tuple and delete the tuple in old_leases, goto send
- chose an element of free_leases; if free_leases=={}, chose oldest element of old_leases; delete element IP from free_leases or old_leases.
- send: answer with (IP, lease_time), add (IP, MAC, lease_time) to active_leases
- goto loop
- timer tasks:
-
- if lease_time of (IP,MAC) is expired move (MAC, IP, lease_time) from active_leases to old_leases
Okay, a bit complicated.
But this means there are three sets
- dynamic_pool={ IP | start_addr<=IP<=end_addr}
- active_pool={ IP | current_time < expiration_time(IP) }
- expired_pool={ IP | current_time >= expiration_time(IP) }
The numbers are
- Total leases = || dynamic_pool ||
- Used leases = || active_pool ||
- Unused leases = || dynamic_pool - active_pool - expired_pool ||
- Available leases = || dynamic_pool - active_pool ||
So far the theory, which can be easily implemented. But as stated before the source isn’t prepared for such analysis. It demands some reorganisation of the subroutines. Eeach change bears the danger of unwanted side-effects.
IMHO, the effort ( including checks of dependencies ) is much higher than the gain.
If there are no IPs available anymore there are error messages.
If your dynamic pool has a size of 200 IPs there is not much room in a usual /24 net. A /24 net includes 254 addresses, 256 numbers - network IP - broadcast IP.
A change in the network definition demands much more than just some DHCP settings.
This page just needs just need refinements, even though half of the issue of the Current Lease section is the expired leases not getting deleted in the .leases file so you end up with this big grey blob area with a bunch of ip addresses with a strike through. Which I find that to be a broken part of the page.
current dynamic leases should only list the current dynamic leases and why is the .leases file not auto deleting when it expires but instead is deactivated and no controls to delete the entry in the file. So, how long does it take to reach 4GB since it doesn’t purge old records?
Ok, Its not hard to write this page guys. Even if it wasn’t using any perl::ip tools.
1 Like
Thank you, for doing it. 
1 Like
Well I guess, since that is part of open source community.
In Perl, just like C++. to calculate the difference between two 32 bit words in 8 bit BCD value segments (the structure of ip adresses), one just simply converts the ip number into its integer value, then subtract the two, leaving how many addresses or numbers between the two.
The green and blue DHCP parameters are rendered by the same subroutine. So you would just use what they already loaded into variables for filling the blanks in the start and end address part of the form.
There are several ways to convert the ip number to an integer, I use the bit shift operation as that is much faster than most other methods.
my ($start_bytes, $end_bytes)= map { [split /\./, $_] }($dhcpsettings{"START_ADDR_${itf}"},$dhcpsettings{"END_ADDR_${itf}"});
my $dhcp_pool_int= ( ($end_bytes->[0] << 24) + ($end_bytes->[1] << 16) + ($end_bytes->[2] << 8) + $end_bytes->[3] ) - ( ($start_bytes->[0] << 24) + ($start_bytes->[1] << 16) + ($start_bytes->[2] << 8) + $start_bytes->[3] );
print $dhcp_pool_int;
Other stuff is just as easy. But I have no time this morning to elaborate.
1 Like
@bloater99
indeed a good question 
once upon a time this was raised already but
no solution/interest was found/raised 
i am also a fan of a good dhcp server
as it is a crucial and essential network component
but it seems we are just ~three 
and this:
was already said back then.
one can see ipfire is a firewall not a dhcp-server
and as dhcp.cgi=odd it is not for production environments
it seems that there is a lot of work and
do not forget the other maybe odd dhcp-lease-bridge 
so if one touches the dhcp it could be
way more than just a dashboard that makes sense 
maybe you can add a poll to the topic
to get a view about the interest in
your request 
and do not forget the devmailinglist 
I think this is a bit pointless. It is not a poll that is needed but users to step forward and say
Yes, I will pick that issue up and do the coding and submit a patch to the IPFire dev mailing list
or more donations to fund the work required overall on IPFire.
That issue is on my list of things to get around to but it is there with a whole bunch of other things and any problematic bug or needing to work on a critical package update or to support work on IPFire3.x will always jump the queue.
Anyone else is welcome to step up and work on that issue.
3 Likes
@bonnietwin
i understand that the focus is firewall
this helps to get a more relaxed view at
odd things besides …
that reads beautifully but not everyone has the ability
just because @dr_techno points out some valid odd points
does not mean he is able to fix them
i also hope that more skilled devs would join 
btw:
without users and feedback
from users a dev can do what 
1 Like
Well I’ve been preoccupied and focusing on replacing my ipfire machine before it totally dies. I have to turn it off and reboot it now every once in a while. So once I sort my hardware issues I will revisit this offically since no one has stepped up.
But it would be nice to know all of the variables that are rendered into memory for that page instead of having to sift through the remote called pages to see what is rendered in variables and arrays. Even though I could spin up new code from scratch, if some of the data is rendered already, it would be redundant code.
But I do wonder why its not deleting old leases, unless that part of it needs to be fixed because someone left out the auto cleanup statement.
1 Like
i am so glad that i am not the only one
not able to see the advantage of this feature 
for ages
If you mean expired leases with ‘old leases’, it is quite easy to explain.
dhcpd just tries to implement semi-fixed leases. Each device, identified by it’s MAC, will get the same IP at a reconnect.
Listing these expired leases in the IPFire WUI gives some sort of history.
A big dynamic pool with many different clients, which connect not very often, includes a big set of these expired leases.
Devices with changing MAC enlarge this set. A device with three different MACs produces two expired entries and one ( active or expired ) entry.
1 Like
@bbitsch
i appreciate your efforts to explain 
and as already mentioned here, it seems to be sufficient
for networks with only a handful of devices 
roger roger 