YazDHCP YazDHCP floods with dnsmasq errors

[gjf]

Hi all.

I am using YazDHCP and it constantly floods in logs:

Apr 29 23:07:39 dnsmasq[7433]: duplicate dhcp-host IP address 192.168.111.10 at line 1 of /jffs/addons/YazDHCP.d/.staticlist
Apr 29 23:07:39 dnsmasq[7433]: duplicate dhcp-host IP address 192.168.111.11 at line 2 of /jffs/addons/YazDHCP.d/.staticlist
Apr 29 23:07:39 dnsmasq[7433]: duplicate dhcp-host IP address 192.168.111.12 at line 3 of /jffs/addons/YazDHCP.d/.staticlist

At the same time I don't see anything incorrect in .staticlist:

7C:ED:8D:78:00:00,set:7C:ED:8D:78:00:00,192.168.1.10
00:1A:79:09:00:00,set:00:1A:79:09:00:00,192.168.1.11
80:1F:02:87:00:00,set:80:1F:02:87:00:00,192.168.1.12

So what is wrong?

 

[bennor]

Hi all.

I am using YazDHCP and it constantly floods in logs:

At the same time I don't see anything incorrect in .staticlist:

So what is wrong?

It may help if you post your router model and what firmware version along with any additional scripts you are running.
Edit to add: Have you tried the standard troubleshooting steps of rebooting the router. And (exporting the YazDHCP CVS file) uninstalling YazDHCP (rebooting the router) then reinstalling YazDHCP (and importing the YazDHCP CVS file)?

 

[dave14305]

So what is wrong?

Something is duplicated. Check /etc/dnsmasq.conf to see if the same entries are present.

 

[gjf]

Something is duplicated. Check /etc/dnsmasq.conf to see if the same entries are present.

Of course these entries are present as YazDHCP initially took them from there:

...
dhcp-host=80:1F:02:87:00:00,set:80:1F:02:87:00:00,MAG-2,192.168.1.12
dhcp-host=00:1A:79:09:00:00,set:00:1A:79:09:00:00,MAG-1,192.168.1.11
dhcp-host=7C:ED:8D:78:00:00,set:7C:ED:8D:78:00:00,XBox,192.168.1.10

It looks like the script itself adds new entries from .staticlist but does not check are they already present in dnsmasq.conf.

So what is the solution? Cleaning entries in dnsmasq.conf cleans the table in LAN - DHCP Server - Manually Assigned IP addresses in the DHCP scope - and even if YazDHCP adds them in a background it is not obvious for the user they were added.

 

[gjf]

@bennor Asus RT-AX86U, Merlin 386.7, but I am pretty sure the problem is in script itself, not firmware or other scripts.
And of course rebooting etc was tested, this problem exists for ages since RT-AC86U, I did not pay attention actually because everything works. However flooding in logs is annoying.

 

[dave14305]

Of course these entries are present as YazDHCP initially took them from there

They shouldn’t still be there now. YazDHCP entries are included in a dhcp-hostsfile entry in dnsmasq.conf.

 

[gjf]

They shouldn’t still be there now. YazDHCP entries are included in a dhcp-hostsfile entry in dnsmasq.conf.

Yup I've got it. Put # sign at the end of each entry and after restart of dnsmasq looks like the problem gets solved.
However I still wonder why YazDHCP didn't removed them automatically during installation.

 

[dave14305]

Yup I've got it. Put # sign at the end of each entry and after restart of dnsmasq looks like the problem gets solved.
However I still wonder why YazDHCP didn't removed them automatically during installation.

Where were they located that you could just comment them out? dnsmasq.conf.add? Or are they still in nvram also?

 

[gjf]

Where were they located that you could just comment them out? dnsmasq.conf.add? Or are they still in nvram also?

/etc/dnsmasq.conf
And yes: I know it is regenerated with every reboot.
Looks like I need to write some script that will changes entries after reboot every time. However the source of problem was indicated.

The solution is quite easy by the way: adding the following into dnsmasq.postconf:

CONFIG=$1
source /usr/sbin/helper.sh

pc_delete "dhcp-host=80:1F:02:87:00:00,set:80:1F:02:87:00:00,MAG-2,192.168.1.12" $CONFIG
pc_delete "dhcp-host=00:1A:79:09:00:00,set:00:1A:79:09:00:00,MAG-1,192.168.1.11" $CONFIG
pc_delete "dhcp-host=7C:ED:8D:78:00:00,set:7C:ED:8D:78:00:00,XBox,192.168.1.10" $CONFIG

And as I stated above: the problem is inside YazDHCP script that ignores nvram DHCP entries. These entries come into dnsmasq.conf automatically and cause errors in log. And I cannot remove them from nvram as they are necessary for correct information at router settings page.

 

[Dezzo]

I'm having this same issue.
Will the YazDHCP script be updated to correct this?

 

[Jack Yaz]

YazDHCP should be clearing nvram on install, assuming you select it to do so. If that's no longer working, a firmware update has changed something to break it

 

[Martinski]

YazDHCP should be clearing nvram on install, assuming you select it to do so. If that's no longer working, a firmware update has changed something to break it

This being a 3-day weekend here in the US (Memorial Day), I had some free time to look into a problem a friend of mine reported with the latest YazDHCP versions "1.0.5" & "1.0.6" (develop branch).

When the "DHCP Lease" in the WebGUI is set to a value greater than 7 days *and* later you un-install YazDHCP, the Lease Time is left as is in the NVRAM "dhcp_lease" variable. This is OK with dnsmasq as the value is definitely valid & everything continues to work without issues, except that if you go to the now-stock "LAN --> DHCP Server" WebGUI page, the "Lease Time" is the greater-than-7-days value which is "invalid" for the standard WebGUI page, and if you click on the "Apply" button you get an error message. The fix is to manually change the value to anything <= 7 days (in seconds).

I have now modified the YazDHCP shell script to reset the NVRAM value during uninstallation when the Lease Time is greater than 7 days (I'll submit a GitHub PR later this evening).

While testing the above fix, I found that the option to export "DHCP assignments and hostnames from NVRAM" is available *only* during installation, so if you happen to answer "NO" at that time (thinking that you could do it later), you are left stuck with the NVRAM settings (e.g. "dhcp_staticlist"), unable to export, make a backup of & clean the NVRAM variables *after* installation is completed.

You have the option to un-install & then re-install YazDHCP to have another chance to export the NVRAM settings. Or, you could manually find the places in the WebGUI where the "MAC & IP address bindings" are set (usually in the "Client Status" list from "Network Map") and remove them *before* setting them up in YazDHCP.

If you leave the settings in NVRAM and decide to add them manually to YazDHCP, you will find yourself in the situation where dnsmasq will output the "duplicate dhcp-host IP address" messages because there are indeed 2 sources for the dnsmasq settings: NVRAM vars & YazDHCP client files (".staticlist" & ".hostnames").

I believe the above scenario is probably what's causing the "flooding of messages" reported in this thread.

@Jack Yaz, is there a specific reason for not allowing the "Export settings from NVRAM" process *after* the installation is completed?

I've reviewed the code and so far I haven't found a technical reason. It seems to me that it's just a bug and, from what I can see, it shouldn't be difficult to fix it. Any objections?

I think I'll go ahead and make the fix after dinner. I'll submit a PR and you can review & comment on the changes as you see fit.

 

[Martinski]

...
And as I stated above: the problem is inside YazDHCP script that ignores nvram DHCP entries. These entries come into dnsmasq.conf automatically and cause errors in log.

During YazDHCP installation, did you answer YES to the following question?
"Do you want to export DHCP assignments and hostnames from NVRAM to YazDHCP DHCP client files?"

Do you currently see the following backup files on your router?
/jffs/addons/YazDHCP.d/.nvram_dhcp_staticlist
/jffs/addons/YazDHCP.d/.nvram_jffs_dhcp_staticlist

And I cannot remove them from nvram as they are necessary for correct information at router settings page.

I don't understand what you mean exactly by the above statement.
Which "correct information at router settings page" are you referring to?
Can you elaborate on why you need to have the specific NVRAM settings and not have them available *only* in YazDHCP?

Further details might be useful to understand how your router got into the situation you reported.

 

[Jack Yaz]

I thought I had left in a check that if nvram was populated the export option would be available in the menu. Perhaps not

 

[SomeWhereOverTheRainBow]

This being a 3-day weekend here in the US (Memorial Day), I had some free time to look into a problem a friend of mine reported with the latest YazDHCP versions "1.0.5" & "1.0.6" (develop branch).

So essentially, when @Martinski gets a three day weekend, Martinski comes out to play? Awesome work man! Glad you are still behind the scenes catching things. If you and @Jack Yaz were to team up indefinitely, you two would be the dynamic duo, and no one would be able to keep up! Again, Great work!

 

[Martinski]

I thought I had left in a check that if nvram was populated the export option would be available in the menu. Perhaps not

Yes, there is indeed a check like so:

    ...
    showexport="true"
    if [ "$(nvram get dhcp_staticlist | wc -m)" -le 1 ]; then
        showexport="false"
    fi
    if [ -f /jffs/nvram/dhcp_hostnames ]; then
        if [ "$(wc -m < /jffs/nvram/dhcp_hostnames)" -le 1 ]; then
            showexport="false"
        fi
    elif [ "$(nvram get dhcp_hostnames | wc -m)" -le 1 ]; then
        showexport="false"
    fi
    if [ "$showexport" = "true" ]; then
        printf "x.    Export nvram to %s\\n\\n" "$SCRIPT_NAME"
    fi
    ...

But the code requires *both* NVRAM vars "dhcp_staticlist" & "dhcp_hostnames" to have a non-NULL (non-empty) value, so this check fails with F/W 386.4 & later versions because "dhcp_hostnames" is no longer used/set at all (it's always empty, at least on the AC & AX router models I have access to - and all running recent F/W versions).

Perhaps the need for *both* NVRAM vars to be set was a requirement for F/W versions before 386.4?

If that's the case, I'll need to check for the F/W version as well within the above check.
Does that sound reasonable?
I don't have another ASUS router with such an old F/W version to test & verify.

 

[SomeWhereOverTheRainBow]

Yes, there is indeed a check like so:

    ...
    showexport="true"
    if [ "$(nvram get dhcp_staticlist | wc -m)" -le 1 ]; then
        showexport="false"
    fi
    if [ -f /jffs/nvram/dhcp_hostnames ]; then
        if [ "$(wc -m < /jffs/nvram/dhcp_hostnames)" -le 1 ]; then
            showexport="false"
        fi
    elif [ "$(nvram get dhcp_hostnames | wc -m)" -le 1 ]; then
        showexport="false"
    fi
    if [ "$showexport" = "true" ]; then
        printf "x.    Export nvram to %s\\n\\n" "$SCRIPT_NAME"
    fi
    ...

But the code requires *both* NVRAM vars "dhcp_staticlist" & "dhcp_hostnames" to have a non-NULL (non-empty) value, so this check fails with F/W 386.4 & later versions because "dhcp_hostnames" is no longer used/set at all (it's always empty, at least on the AC & AX router models I have access to - and all running recent F/W versions).

Perhaps the need for *both* NVRAM vars to be set was a requirement for F/W versions before 386.4?

If that's the case, I'll need to check for the F/W version as well within the above check.
Does that sound reasonable?
I don't have another ASUS router with such an old F/W version to test & verify.

What variables are you curious about? I have a RTAC87 running 384.13 if you want me to check the nvram I can.

nvram show | grep dhcp
dhcpd_querylog=1
dhcp1_gateway_x=
wan1_vpndhcp=1
dhcp1_enable_x=0
wan0_proto=dhcp
wan_dhcpenable_x=1
dhcp1_dns1_x=
dhcp_dns1_x=
wan1_dhcpenable_x=1
dhcp_start=192.168.2.2
ipv61_dhcp_start=
dhcp_end=192.168.2.254
dhcp_lease=86400
ipv6_dhcp6s_enable=1
dhcpd_send_wpad=1
dhcp_hostnames=
dhcpd_dns_router=1
wan0_dhcpenable_x=1
vpn_server_dhcp=1
wan_vpndhcp=1
wan_proto=dhcp
vpn_server2_dhcp=1
ipv6_dhcp_end=
ipv61_dhcp_end=
ipv61_dhcp_lifetime=86400
ipv6_dhcp_pd=1
ipv61_dhcp_pd=1
dhcp1_staticlist=
dhcp_gateway_x=
dhcpd_lmax=253
dhcp_staticlist=
wan1_proto=dhcp
ipv61_dhcp6c_release=1
wan0_vpndhcp=1
dhcp_static_x=0
ipv6_dhcp_start=
dhcp_dns2_x=
dhcp1_start=192.168.2.2
ipv6_dhcp_lifetime=86400
dhcp1_lease=86400
dhcp1_static_x=0
ipv6_6rd_dhcp=1
dhcp1_end=192.168.2.254
ipv61_6rd_dhcp=1
dhcpc_mode=1
dhcp_enable_x=1
dhcp1_wins_x=
dhcp_wins_x=
ipv6_dhcp6c_release=1
vpn_server1_dhcp=1

Does that help? obviously this is not running in router mode though.

 

[Martinski]

What variables are you curious about? I have a RTAC87 running 384.13 if you want me to check the nvram I can.

But the code requires *both* NVRAM vars "dhcp_staticlist" & "dhcp_hostnames" to have a non-NULL (non-empty) value, ...

In your output, both NVRAM vars are set to empty string.

Does that help? obviously this is not running in router mode though.

I don't think you can install & run YazDHCP successfully unless it's in "Router Mode." Thanks for trying though.

 

[Martinski]

Perhaps the need for *both* NVRAM vars to be set was a requirement for F/W versions before 386.4?

If that's the case, I'll need to check for the F/W version as well within the above check.

OK, I have fixed the code & added a check in the export function to validate that the NVRAM entries being exported do not conflict with any existing DHCP IP address assignments that were added *after* the initial installation but *before* starting the "Export from NVRAM." This was necessary to avoid ending up with entries having the same MAC and/or IP addresses in the mix. However, this check is only for F/W 386.4 & later versions.

I've also added code to check that there are no conflicts between any NVRAM "dhcp_staticlist" entries (if set) and the DHCP client files data sent from the WebGUI page.

I'll submit a GitHub PR within the next ~20 minutes after I run a few more tests.

 

[thelonelycoder]

I don't think you can install & run YazDHCP successfully unless it's in "Router Mode." Thanks for trying though.

Only a house has all features a human expects of a building to live in.
A shed, garage or extension have their own purposes and generally don’t come with a front porch, doorbell, bathroom and kitchen.