YazDHCP YazDHCP v1.2.6 [2026-Apr-12] - Feature expansion of DHCP assignments (increasing limit on the number of DHCP reservations)

[Seth Harman]

Are you using custom icons? (not sure it would play a roll but more information may help narrow things down)

Personally, when using YazDHCP on a RT-AX86U Pro, I haven't see your issue (YazDHCP disappearing) over the past few YazDHCP update, before I moved to the latest stock Asus firmware while waiting for newer GPL's in Asus-Merlin. But I also don't have a USB device attached and don't use custom icons or the like.

PS: May want to also check the system log and browser console to see if any errors are listed in either one. Don't remember off hand if YazDHCP had an error log option in the CLI (doesn't appear so).

I'm not using any custom icons. I just now swapped the USB Key out and used BACKUPMON to put everything back onto a USB hard drive that's now plugged in. Doing a restore forces a router reboot and, sure enough, YazDHCP vanished from the DHCP Server tab again. So I did a force update and now it's back. I attempted to delete one of the entries and it's not working, so this doesn't appear to be related to whatever I'm using as a USB storage medium.

Edit: I just checked the system log, there's a few entries for YazDHCP but I don't see anything throwing up an error.

 

[bennor]

Edit: I just checked the system log, there's a few entries for YazDHCP but I don't see anything throwing up an error.

If you haven't tried already, see if a different web browser including a different web browser on another computer/device exhibits the same issue. Check the browser console for errors when the YazDHCP disappears to see if the browser lists any errors. Temporarily disable any browser addons in case one of them is interfering.

 

[Seth Harman]

If you haven't tried already, see if a different web browser including a different web browser on another computer/device exhibits the same issue. Check the browser console for errors when the YazDHCP disappears to see if the browser lists any errors. Temporarily disable any browser addons in case one of them is interfering.

Multiple machines, multiple browsers (Chrome, Edge, Firefox) all exhibiting the same behavior. Edge and Firefox have no addons, Chrome in Incognito Mode also the same result.

 

[bennor]

Multiple machines, multiple browsers (Chrome, Edge, Firefox) all exhibiting the same behavior. Edge and Firefox have no addons, Chrome in Incognito Mode also the same result.

Are you running any other addon scripts or Entware in addition to YazDHCP? Or have you made any other modifications to the router using SSH?

 

[Seth Harman]

Are you running any other addon scripts or Entware in addition to YazDHCP? Or have you made any other modifications to the router using SSH?

I am currently running Entware and FlexQOS, vnStat, BACKUPMON, and spdMerlin in addition to YazDHCP. When I've removed YazDHCP completely as a test the other scripts continue to operate as normal. Unless someone is specifically aware of any of those scripts conflicting with YazDHCP I don't think it's useful to spend time disabling/uninstalling them to see what happens with YazDHCP since there really shouldn't be any interaction between them (although anything is possible, I guess). For now it's more an annoyance than anything serious: when it drops out of existence I just SSH in, force a reinstall, and go on my way. And when I need to add clients I just edit the list manually. If anyone really wants to dig into what's going on I can provide additional information or logs.

One interesting thing I forgot to mention is even on a completely fresh install (uninstall/reboot/reinstall) the same behavior manifests, starting with not being able to use the UI to turn on support for guest networks; I have to SSH in, fire up AMTM, run YazDHCP, and tell it to enable it.

 

[dave14305]

If anyone really wants to dig into what's going on I can provide additional information or logs.

When it's "missing" in the GUI, login over ssh and run:

mount | grep Advanced_DHCP_Content
ls -l /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp
md5sum /jffs/addons/YazDHCP.d/Advanced_DHCP_Content.asp
df -k /jffs

The file shouldn't really be disappearing unless something is unmounting it, or your /jffs is flaky.

 

[jksmurf]

It was either two or three revisions ago.

Just a data point really, I don’t see any of these issues.

I’ve been keeping up with YazDHCP updates, and even the recent entware install does not seem to have affected it, albeit with a different set of addons to yours.

Just wondering if there could be a single entry it doesn’t like, whether it would be worth uninstalling but rather than reimporting all your reservations, just add in 5 to 10 manually, across your main and GNP networks, and see if the behaviour persists?

 

[Martinski]

I am currently running Entware and FlexQOS, vnStat, BACKUPMON, and spdMerlin in addition to YazDHCP. When I've removed YazDHCP completely as a test the other scripts continue to operate as normal. Unless someone is specifically aware of any of those scripts conflicting with YazDHCP I don't think it's useful to spend time disabling/uninstalling them to see what happens with YazDHCP since there really shouldn't be any interaction between them (although anything is possible, I guess). For now it's more an annoyance than anything serious: when it drops out of existence I just SSH in, force a reinstall, and go on my way. And when I need to add clients I just edit the list manually. If anyone really wants to dig into what's going on I can provide additional information or logs.

One interesting thing I forgot to mention is even on a completely fresh install (uninstall/reboot/reinstall) the same behavior manifests, starting with not being able to use the UI to turn on support for guest networks; I have to SSH in, fire up AMTM, run YazDHCP, and tell it to enable it.

I can take a look at the problem later this evening, but for context, please provide clear and readable screenshots of the messages generated during a completely fresh installation, and the corresponding syslog file covering that installation (please indicate the time of the install). This is in addition to the information that @dave14305 requested.

Also, after the installation is completed, run YazDHCP again and provide a screenshot of any messages generated at that point. I may request further data after I have reviewed the initial information.

Thanks.

P.S. I got to get back to my day job...

 

[Ripshod]

I'm not using any custom icons. I just now swapped the USB Key out and used BACKUPMON to put everything back onto a USB hard drive that's now plugged in. Doing a restore forces a router reboot and, sure enough, YazDHCP vanished from the DHCP Server tab again. So I did a force update and now it's back. I attempted to delete one of the entries and it's not working, so this doesn't appear to be related to whatever I'm using as a USB storage medium.

You've possibly copied any damaged files to the hard drive so it's possible you'll just get the same errors.
Whilst it's not on the cards yet get yourself used to the idea of a full reset/rebuild.

 

[Martinski]

You've possibly copied any damaged files to the hard drive so it's possible you'll just get the same errors.
Whilst it's not on the cards yet get yourself used to the idea of a full reset/rebuild.

@Seth Harman sent me some info via DM, and his syslog file showed entries indicating that the "/jffs/scripts/service-event" file does not have executable permissions, which means that any command placed inside does not run at all. Therefore, the WebUI page becomes "non-functional" when the user attempts to make any changes. I suspect the /jffs/scripts/services-start script is not executable either, which would explain why the WebUI page is not mounted during startup following a reboot.

I gave him instructions to set the required executable permissions; however, it remains unclear how and why those files keep being reset to non-executable. Perhaps, he's got a custom script doing it accidentally. Anyway, that's where we are at the moment.

FYI.

 

[Seth Harman]

@Seth Harman sent me some info via DM, and his syslog file showed entries indicating that the "/jffs/scripts/service-event" file does not have executable permissions, which means that any command placed inside does not run at all. Therefore, the WebUI page becomes "non-functional" when the user attempts to make any changes. I suspect the /jffs/scripts/services-start script is not executable either, which would explain why the WebUI page is not mounted during startup following a reboot.

I gave him instructions to set the required executable permissions; however, it remains unclear how and why those files keep being reset to non-executable. Perhaps, he's got a custom script doing it accidentally. Anyway, that's where we are at the moment.

FYI.

He was right on the money. No idea how the permissions on those files got borked but I'm going to keep an eye on them going forward.