AC86U not retaining dhcp static list after reboots

[diyguy]

This is my third Asus with Merlin firmware, and this one is behaving oddly. I'm running the latest version of Asus Merlin and my dhcp static list will not persist after reboots. My previous 66U and 87U didn't have this issue. Any ideas ?

 

[L&LD]

Did you import settings to set it up?

 

[RMerlin]

How long is your list? The RT-AC86U and newer models have smaller size limitations than previous models.

 

[diyguy]

How long is your list? The RT-AC86U and newer models have smaller size limitations than previous models.

not long at all, 4 right now. I also notices that adding one entry from the GUI it doesn't retain it either. Odd ball issue with my router ?

 

[diyguy]

Did you import settings to set it up?

Nope, my old one died so I set this up from scratch.

 

[kernol]

@diyguy - not sure which road you travelled on the RT-AC86U from Stock firmware it was supplied with [version] through to Merlinware [version?]. I can see you have been around long enough to know the recommended path in getting there - so if you have followed L&LD's superb guides ... then I'm at a loss ... my RT-AC86U has never had this problem.

If not - then hop onto this link and see the guides he provides ...
https://www.snbforums.com/members/l-ld.24423/

 

[RMerlin]

not long at all, 4 right now. I also notices that adding one entry from the GUI it doesn't retain it either. Odd ball issue with my router ?

Check the content of the /jffs/ partition and make sure it's not full.

df -h /jffs

 

[brainosas]

not long at all, 4 right now. I also notices that adding one entry from the GUI it doesn't retain it either. Odd ball issue with my router ?

Which firmware you have installed? I have this same issue with latest Merlin beta installed, though I managed to solve it. Firstly, I assigned static addresses and rebooted router - all gone. Then I tried second time, but I only assigned one address instead of full list - wanted to make sure it works - rebooted and it worked - that single record was retained. Then I entered the rest addresses, saved, rebooted - all records were retained.
To me this issue is only with latest alphas or beta version, it is never a problem if I’d go back to 384.17 firmware. Clean install never helped, only second, third reboot.

 

[kernol]

Please excuse "dummy" question ... but I have never understood why static addresses are "reserved" within the DHCP range of the server?

I have always simply started the DHCP Server range at say . . . 50 through to 200 ... and then assigned static addresses on the client devices outside that range [...1 through to ...49 and ...201 through to 254].

 

[diyguy]

Please excuse "dummy" question ... but I have never understood why static addresses are "reserved" within the DHCP range of the server?

I have always simply started the DHCP Server range at say . . . 50 through to 200 ... and then assigned static addresses on the client devices outside that range [...1 through to ...49 and ...201 through to 254].

I use nordvpn and some devices need to be explicitly able to bypass it as well as be able to use DHCP. Also some smart switches I have only use DHCP and for automation needs I need the IP address to be the same so I don't have to reconfigure things constantly.

 

[diyguy]

Which firmware you have installed? I have this same issue with latest Merlin beta installed, though I managed to solve it. Firstly, I assigned static addresses and rebooted router - all gone. Then I tried second time, but I only assigned one address instead of full list - wanted to make sure it works - rebooted and it worked - that single record was retained. Then I entered the rest addresses, saved, rebooted - all records were retained.
To me this issue is only with latest alphas or beta version, it is never a problem if I’d go back to 384.17 firmware. Clean install never helped, only second, third reboot.

I was using 384.17. I have decided to return this one and go for an AX88U instead. I just don't know if I just got a dud.

 

[kernol]

I use nordvpn and some devices need to be explicitly able to bypass it as well as be able to use DHCP. Also some smart switches I have only use DHCP and for automation needs I need the IP address to be the same so I don't have to reconfigure things constantly.

Gotcha - makes sense - thanks

 

[elorimer]

Please excuse "dummy" question ... but I have never understood why static addresses are "reserved" within the DHCP range of the server?

I have always simply started the DHCP Server range at say . . . 50 through to 200 ... and then assigned static addresses on the client devices outside that range [...1 through to ...49 and ...201 through to 254].

I don't think this is a dumb question at all. The heading is "Manually assigned IP around the DHCP list", which implies, as you suggest, that the static addresses should not be in the DHCP range. But I don't think it matters whether the IP is in or out of the range.

It is more like "List of reserved IP address assignments".

 

[theirongiant]

Hi there. I'm having this issue on 384.17 with an AX88U and it's driving me crazy.

My /jffs/ partition is 99% full, and it's almost exclusively TrafficAnalyzer.

admin@RT-AX88U-27B8:/tmp/home/root# du -h /jffs
0    /jffs/scripts
3.5K    /jffs/.le/[REDACTED].asuscomm.com/backup
25.0K    /jffs/.le/[REDACTED].asuscomm.com
27.5K    /jffs/.le
17.0K    /jffs/addons/amtm/a_fw
17.5K    /jffs/addons/amtm
17.5K    /jffs/addons
997.0K    /jffs/signature
0    /jffs/configs
22.5K    /jffs/usericon
12.0K    /jffs/nvram
1.5K    /jffs/.sys/cfg_mnt
165.1M    /jffs/.sys/TrafficAnalyzer
14.8M    /jffs/.sys/nc
0    /jffs/.sys/diag_db
179.9M    /jffs/.sys
2.5K    /jffs/.cert
180.9M    /jffs

RMerlin, I honestly had no idea this was running the whole time and I wonder if many are in the same boat. Do you have suggestions for purging this periodically? If I turn off TrafficAnalyzer will it clear out automatically?

 

[RMerlin]

Please excuse "dummy" question ... but I have never understood why static addresses are "reserved" within the DHCP range of the server?

I have always simply started the DHCP Server range at say . . . 50 through to 200 ... and then assigned static addresses on the client devices outside that range [...1 through to ...49 and ...201 through to 254].

Because they are static leases, not real static IP addresses. They are still handled by the DHCP as a lease that will expire, you are merely telling the DHCP server to always provide that specific IP, hence it should be within the lease scope.

Only use an IP outside of the range if it's a real static address, i.e. one that you manually configured on the client's network interface.

I don't think this is a dumb question at all. The heading is "Manually assigned IP around the DHCP list", which implies, as you suggest, that the static addresses should not be in the DHCP range. But I don't think it matters whether the IP is in or out of the range.

This is just a bad Chinese -> English translation. It's not "around the DHCP list", it's "within the DHCP scope".

 

[RMerlin]

RMerlin, I honestly had no idea this was running the whole time and I wonder if many are in the same boat. Do you have suggestions for purging this periodically? If I turn off TrafficAnalyzer will it clear out automatically?

It's supposed to be monitored every hour, and automatically truncated at 30 MB. If it isn't, then it's a bug in Asus's monitoring/purging code, and is outside of my control.

You can manually do the purge process by running these two commands:

TrafficAnalyzer -d 30720
TrafficAnalyzer -e

 

[elorimer]

It's not "around the DHCP list", it's "within the DHCP scope".

Yes, "around", as in "see you around", not "around", as in "you've got to go around".

 

[theirongiant]

It's supposed to be monitored every hour, and automatically truncated at 30 MB. If it isn't, then it's a bug in Asus's monitoring/purging code, and is outside of my control.

You can manually do the purge process by running these two commands:

TrafficAnalyzer -d 30720
TrafficAnalyzer -e

admin@RT-AX88U-27B8:/tmp/home/root# TrafficAnalyzer -d 30720

table_main-1: over size 30720, timestamp=1590998400

start to delete some rules from /jffs/.sys/TrafficAnalyzer/TrafficAnalyzer.db because of over size

SQL error: disk I/O error

admin@RT-AX88U-27B8:/tmp/home/root# TrafficAnalyzer -e

It didn't work, so I deleted the whole database and flushed traffic data in RAM to disk.

rm /jffs/.sys/TrafficAnalyzer/*
/usr/sbin/TrafficAnalyzer -e
     [...router is busy for ~10 seconds...]
admin@RT-AX88U-27B8:/tmp/home/root#

 

[RMerlin]

It didn't work, so I deleted the whole database and flushed traffic data in RAM to disk.

Probably because the partition was already full.

 

[theirongiant]

Probably because the partition was already full.

Is this something that Asus would accept bug reports for?