YazDHCP - feature expansion of DHCP assignments (increasing limit on the number of DHCP reservations)

  • ATTENTION! You'll notice a Prefix dropdown when you create a thread. If your post applies to one of the topics listed, please use that Prefix for your post. When browsing the thread list you can use the Prefix to filter the view.
  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Jack Yaz

Part of the Furniture
If I wanted to be really clever I could make this dynamic and calculate the limit by taking the average length of a user's reservation (specifying dns obviously makes each entry longer, and not everyone uses that field, same as hostnames) and divide the total space by the average.

I'll do that
This is now available, no version update (hotfix)
 

dave14305

Part of the Furniture
This is now available, no version update (hotfix)
Updated via the CLI. Limit now 164. ;)

In terms of conserving space, I have been wondering why we bother (me included) storing 192.168.50. in precious settings space when the subnet should be known already. I contemplated removing it in FlexQoS iptables rules storage but haven’t gotten around to it yet. Just another thought during my morning coffee.
 

elorimer

Very Senior Member
Just out of curiosity, to revert back to "not" using this script, is there anything that needs to be done before/after uninstalling this script or safe to assume that the uninstall reverts back everything (assuming the assignments are less than the max)?
My way, not necessarily the best way: Before you install, save the configuration and the jffs. After you uninstall, restore the config (for the IPs) and jffs (for the hostnames).
 

Jack Yaz

Part of the Furniture
Updated via the CLI. Limit now 164. ;)

In terms of conserving space, I have been wondering why we bother (me included) storing 192.168.50. in precious settings space when the subnet should be known already. I contemplated removing it in FlexQoS iptables rules storage but haven’t gotten around to it yet. Just another thought during my morning coffee.
now that's a good idea. i could remove it for the API passing and add it back when dumping into DHCP_Clients so that file can be exported by users with no editing required
 

Jack Yaz

Part of the Furniture
now that's a good idea. i could remove it for the API passing and add it back when dumping into DHCP_Clients so that file can be exported by users with no editing required
since you love edge cases @dave14305 :D , i'd need to test what happens if you change the subnet at the same times as reservations, to make sure nvram gets the new plan subnet before my service call manipulates things
 

dave14305

Part of the Furniture
now that's a good idea.
There’s nothing coffee can’t do!
i'd need to test what happens if you change the subnet at the same times as reservations, to make sure nvram gets the new plan subnet before my service call manipulates things
In theory, nvram should already be written by httpd before the service events start firing.
 

Jack Yaz

Part of the Furniture
The other edge case is using a mask smaller than /24. That scenario could be ignored (255.255.254.0).
Given networkmap etc. assume a hardcoded /24 (unless that's changed) I have some wiggle room on ignoring that one
 

QuikSilver

Very Senior Member
@Jack Yaz I'm just reading thru this thread and I can't help but ask....Did you go to sleep at all??
 

Jack Yaz

Part of the Furniture
There’s nothing coffee can’t do!

In theory, nvram should already be written by httpd before the service events start firing.
As it turns out, the subnet can't be changed on the DHCP page. It's set on the LAN IP page. It raises the question as to what happens to reservations if one changes the LAN IP in an unmodded state

EDIT: I have tested and the reservations are untouched in stock, so no immediate concern to "fix" it. Perhaps a feature enhancement to come
 

Jack Yaz

Part of the Furniture
Not bad!
1610578776803.png
 

elorimer

Very Senior Member

heysoundude

Very Senior Member
Is there a benefit to moving the DHCP table to jffs from Nvram, or is this just to make for a larger number of static devices on a network centred around an asus router (running merlin?)?
 

JGrana

Senior Member
Is there a benefit to moving the DHCP table to jffs from Nvram, or is this just to make for a larger number of static devices on a network centred around an asus router (running merlin?)?
Nvram is quite small compared to jffs. On my AX88U, nvram is 128KB and jffs is 63MB. Huge difference!
As a result, as Asus has added more and more important values/settings/variables to nvram (so it survives reboots and resets) the need to find areas to "reduce" usage is expected. DHCP static is one area that has been reduced, I believe once before this time as well. Nvram is critical - jffs is the next spot to move things to.

The main problem (for us users) in using jffs is that, unlike nvram, it is not really permanent. A factory device reset and/or a "format jffs at next boot" will erase what you have in jffs.

As users of these fine addons, we should remember to backup jffs to USB once in a while.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top