What's new

nmp_client_list eating up all NVRAM space

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

nurv2600

Occasional Visitor
Recently, maybe around the same time we updated our router to version .45, the router will randomly crash or start acting funny after a few weeks. After some investigation, I found it's because all the NVRAM is being eaten up, often to the point where "nvram show" indicates a negative value as being free. When scrolling through an "nvram show" output via SSH, there's one value, "nmp_client_list" which looks like it's a DHCP client list. The problem is that it's HUGE, and takes up thousands of KB of NVRAM. This is not a problem on my personal router at home, were I rarely have more than 20 devices connected, but with the work router, we easily have 50-75 clients connected all the time, and countless others walking through the store and connecting. I've tried reducing the DHCP lease time as low as 12 hours, and it still occurs.

What I don't get is that this variable wasn't part of the system in earlier versions, as best I can remember. While I don't remember it not being there explicitly, we've always had the same (large) number of customers connecting, so there's nothing new there. Any idea what this variable is for, and how I might be able to stop the router from using it? The router seemed fine before the .45 update. Thanks to anybody who can help me out on this one!
 
Recently, maybe around the same time we updated our router to version .45, the router will randomly crash or start acting funny after a few weeks. After some investigation, I found it's because all the NVRAM is being eaten up, often to the point where "nvram show" indicates a negative value as being free. When scrolling through an "nvram show" output via SSH, there's one value, "nmp_client_list" which looks like it's a DHCP client list. The problem is that it's HUGE, and takes up thousands of KB of NVRAM. This is not a problem on my personal router at home, were I rarely have more than 20 devices connected, but with the work router, we easily have 50-75 clients connected all the time, and countless others walking through the store and connecting. I've tried reducing the DHCP lease time as low as 12 hours, and it still occurs.

What I don't get is that this variable wasn't part of the system in earlier versions, as best I can remember. While I don't remember it not being there explicitly, we've always had the same (large) number of customers connecting, so there's nothing new there. Any idea what this variable is for, and how I might be able to stop the router from using it? The router seemed fine before the .45 update. Thanks to anybody who can help me out on this one!

That was added by Asus when they added the new Networkmap, with firmware 376.xxx.
 
I'd be tempted to create a cron job that runs at 6am every morning that issues the following commands:
Code:
nvram set nmp_client_list=
nvram commit
 
That was added by Asus when they added the new Networkmap, with firmware 376.xxx.

shirt, that seems like a useless option; why would I ever want to save my DHCP lease table on restart?? The cron job might not be a bad idea...do you guys have any other suggestions for working around this issue (and it IS an issue for people with lots of clients, 64k just isn't enough)?
 
shirt, that seems like a useless option; why would I ever want to save my DHCP lease table on restart?? The cron job might not be a bad idea...do you guys have any other suggestions for working around this issue (and it IS an issue for people with lots of clients, 64k just isn't enough)?

It's not to save your leases, it's to save any customizations you might do to the Networkmap. Since 376, Asus lets you edit the name of your devices, and change their icons.

I could look into possibly adding a hidden setting to disable the feature, but that will have to wait for a future release as 376.48 development is complete, only bugfixes will be done to that version before its final release.
 
That would be fantastic, as I cant imagine I'm the only one who's running into this issue. Anybody running a business or any establishment with many clients is going to run into this issue.
 
That would be fantastic, as I cant imagine I'm the only one who's running into this issue. Anybody running a business or any establishment with many clients is going to run into this issue.

As a potential workaround, you could try manually terminating the networkmap service. Through SSH:

Code:
killall networkmap

Note that changing settings on some of the router pages might cause it to get restarted. It will also completely disable the Client List on the router's main page, but for now it should at least resolve your stability issues.
 
As a potential workaround, you could try manually terminating the networkmap service. Through SSH:

Code:
killall networkmap

Note that changing settings on some of the router pages might cause it to get restarted. It will also completely disable the Client List on the router's main page, but for now it should at least resolve your stability issues.

Great, thank you for posting this, I'll give it a try and let you know!
 
Am posting this here as something that worked for me.

After a couple of days running the script to clean up the NVRAM I am satisfied with the results for my application. Should note that this is on two RT-AC68Us and an RT-N66R.

Enable SSH and allow scripts in JFFS.

Created a script in jffs I logged in with Putty and used the following commands:

Note: (Enter) is not a command you type in but when you should press the Enter key. Sometimes the long lines wrap in the forum and are confusing. If you do not like the term CleanNVRAM use what you like.

cat << EOF > /jffs/scripts/services-start (Enter)
#!/bin/sh (Enter)
/usr/sbin/cru a CleanNVRAM "0 1 * * * nvram set nmp_client_list= && nvram set client_info_tmp= && nvram set webdav_smb_pc= && nvram commit" (Enter)
EOF (Enter)

Next:

chmod a+rx /jffs/scripts/services-start (Enter)

Start your script:
/jffs/scripts/services-start (Enter)

To see if your cron is running:
cru l (Enter)

You should see: 0 1 * * * nvram set nmp_client_list= && nvram set client_info_tmp= && nvram set webdav_smb_pc= && nvram commit followed by the name of the job, in my case CleanNVRAM


This will give you a cron job that will run at 0100 every day and clean your routers NVRAM in three areas. My experience is that the values are rebuilt in NVRAM as SMB (Windows or Samba) devices become active and talk with each other and enabling devices to show up on AiCloud. Cleaning out the webdav_smb_pc= area may not be necessary for you and likely will mess up some things like traffic analysis. Your call to use this. As for me it is more important to keep the router running than to see who is surfing where.
 

Latest threads

Sign Up For SNBForums Daily Digest

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