Documentation for nvram variables?

[Thw0rted]

Is there a documentation page, or perhaps community wiki, that lists notable nvram variables for the official firmware? I've got SSH access set up for my routers and would like to be able to automate some changes by writing a small script to trigger via SSH.

My current task is about MAC filtering, which I think I can figure out based on this older post. I'd rather "learn how to fish", though, so I was hoping somebody had already done the legwork of explaining what commonly-used variables do, how they're formatted, that sort of thing.

 

[ColinTaylor]

There's no specific documentation for nvram variables. If there isn't already a post describing something you'll have to look at the source code and work it out, with the proviso that the nvram existence/format may change between firmware releases.

 

[Thw0rted]

I'm not afraid to poke around in the source code, I just didn't expect to have it available for the commercial FW. Is there just not a big enough / interested-enough community to keep a wiki updated?

Is there more support for this sort of "power user" stuff in Merlin vs the official FW? I'm very comfortable in a linux environment, I just don't want to run custom firmware for the home network my family uses -- can't afford the downtime if/when I break something fiddling with it. (With only AX92U, I don't think Merlin is an option anyway?)

 

[ColinTaylor]

I'm not afraid to poke around in the source code, I just didn't expect to have it available for the commercial FW. Is there just not a big enough / interested-enough community to keep a wiki updated?

The GPL source code is available in the downloads section of the Asus support site.

Is there more support for this sort of "power user" stuff in Merlin vs the official FW? I'm very comfortable in a linux environment, I just don't want to run custom firmware for the home network my family uses -- can't afford the downtime if/when I break something fiddling with it. (With only AX92U, I don't think Merlin is an option anyway?)

As stock Asus firmware doesn't support custom user scripts or configs (without hackish workarounds) there would be almost zero interest in trying to document and keep up to date the thousands of nvram variables IMHO.

 

[Thw0rted]

I'm happy to write a script on my laptop (or phone, for that matter) that runs

ssh meshrouter "nvram set foo=bar && nvram commit && service restart_wireless"

and watch the console output to make sure it worked. I thought it would be easier than trying to reverse-engineer their web API, work out authentication, and script REST calls via `curl`. I guess that's not a popular option though?

 

[ColinTaylor]

I thought it would be easier than trying to reverse-engineer their web API, work out authentication, and script REST calls via `curl`. I guess that's not a popular option though?

Indeed. The router doesn't run a normal web server. RMerlin has said on a few occasions that it's not worth trying to interact with it in this way (although... link).

 

[Thw0rted]

Thanks for the link. I dug through the sources a bit, and I strongly suspect that e.g. this template call to a function provided by the environment are the bread and butter of the extension. On stock firmware, I'm not going to be able to hook and run custom ASP like that, I have to work with whatever (undocumented) AJAX/REST API they expose for their own frontend to use. I'm actually really comfortable doing that -- I've been writing Greasemonkey scripts since Firefox versions were in the single digits -- but I strongly suspect that if I can simply find the *right* SSH commands to run, I can accomplish the same thing, much more easily, and it will work much more reliably.

(Did you know that a bunch of the built-in web UI uses synchronous XHR, and that's why it goes totally unresponsive for seconds at a time whenever you save changes? Asus, if y'all are looking for somebody who understands modern web development, I can give you some pointers...)

 

[Thw0rted]

Just as a brief follow up, I think I fully understand the scmerlin addon in the context of this extension documentation which was linked from the first post of the thread you showed me. Basically, it's a textbook example of using the Merlin extension API to get system information, hook your custom web content into existing pages, then call router-side scripts using the "service event script" feature. Really neat if you're running Merlin, not applicable for stock firmware at all.

I'd still welcome anybody who can give me even an out-of-date and partial breakdown of useful nvram settings. Worst case I guess I could just make a new post here and edit it to add my own findings when I feel inclined to mess with it, but crowdsourcing would be really great if possible.

 

[ColinTaylor]

I'd still welcome anybody who can give me even an out-of-date and partial breakdown of useful nvram settings. Worst case I guess I could just make a new post here and edit it to add my own findings when I feel inclined to mess with it, but crowdsourcing would be really great if possible.

I suppose it depends on what you class as useful. I'd start by extracting release/src/router/shared/defaults.c from the source code of the firmware you're using and looking for hints in there.

 

[toaruScar]

I usually do this the dumb way:
First do I a nvram dump, and save the output to a file
Then I fiddle with settings on webGUI
Then I do another dump, and use diff to compare two dumps.
From the result I can more or less figure out which variables are related to what function.

 

[Thw0rted]

Thanks toaru, since making the OP I found a couple of posts that use a pattern like `nvram show | grep {interesting thing}` which has definitely been helpful. It would still be helpful to have some kind of notes or observations about these values, though -- I don't want to have to factory-reset the router because I guessed wrong when trying to reverse engineer however the hell a "greater-than-sign delimited list" works, just to grab an example off the top of my head.

 

[toaruScar]

I don't want to have to factory-reset the router

You can at least ameliorate the reset experience if you use dd to image the block device of the router to an external drive beforehand.
If you screw up, just factory reset the route, enable SSH, and restore the image to the block device and restart the router.
In this way the cost of misconfigured value is almost negligible IMO.

 

[ColinTaylor]

You can at least ameliorate the reset experience if you use dd to image the block device of the router to an external drive beforehand.
If you screw up, just factory reset the route, enable SSH, and restore the image to the block device and restart the router.
In this way the cost of misconfigured value is almost negligible IMO.

I generally don't like this technique because you're ignoring any changes made to nvram that are currently cached in memory but not yet written. While the risk might be very low I still prefer to use the user-space tools to restore nvram, e.g. the GUI or nvram restore. It's also worth remembering that some of the "nvram" variables are now stored in the /jffs filesystem so that needs to be restored as well. dd'ing /jffs would be even more risky because not only is it cached it is also dynamically compressed.

 

[toaruScar]

dd'ing /jffs would be even more risky because not only is it cached it is also dynamically compressed.

Will unmounting /jffs before doing a dd address this concern?

 

[ColinTaylor]

Will unmounting /jffs before doing a dd address this concern?

It would, except it can't be unmounted while the OS is running. That's why Merlin has the option to "Format JFFS partition at next boot" so that it can be formatted before the OS is loaded.

 

[toaruScar]

it can't be unmounted while the OS is running

I tried it on my XT8.

umount /jffs

and /jffs is gone. A reboot and it’s back.

 

[ColinTaylor]

I tried it on my XT8.

umount /jffs

and /jffs is gone. A reboot and it’s back.

Ah, OK. I didn't realise you were using an XT8. It sounds like they are different than the "RT-" models.

admin@RT-AX86U:/# umount /jffs
umount: can't unmount /jffs: Device or resource busy

 

[Thw0rted]

OK, so, bottom line do *not* try to `dd` my way to a painless backup/restore, yes? (RT-AX92U)

I did see several backup utilities over in the Merlin forums, but a) I don't have it and b) I don't think it's supported on the AX92U. GUI backup is a thing but I reflexively avoid it, probably because everybody on here complains about "dirty upgrades" and how restoring settings from a previous firmware version brings the devil in to the house or something. If I had a complete understanding of nvram variables, maybe I could selectively restore them (via `nvram set`) by hand....

 

[ColinTaylor]

OK, so, bottom line do *not* try to `dd` my way to a painless backup/restore, yes? (RT-AX92U)

Personally I don't see any reason not to use the GUI save/restore feature. It's designed exactly for the situation you're describing.

I did see several backup utilities over in the Merlin forums, but a) I don't have it and b) I don't think it's supported on the AX92U. GUI backup is a thing but I reflexively avoid it, probably because everybody on here complains about "dirty upgrades" and how restoring settings from a previous firmware version brings the devil in to the house or something. If I had a complete understanding of nvram variables, maybe I could selectively restore them (via `nvram set`) by hand....

I forgot you weren't using Merlin so that's even more reason to just use the GUI options because you won't have a complicated setup involving user scripts.

The "dirty upgrade" just refers to updating the firmware version without following it with a factory reset and manual setup. In other words a "normal update" that 99.9% of users would/should be doing (especially when using stock firmware). The problems only come when trying to reload settings taken from a different version of the firmware, but that's not what you're doing (AFAICT).

Side note: Like @toaruScar in post #10 I also have an automatic process (automatic because I'm running Merlin) that performs an nvram show every time the router boots up and stores the output in a timestamped file. So if I make any changes it's easy to diff the most recent file with an older one to determine what has changed (assuming a reboot has happened since the change). Sometimes it's easier/quicker to just identify a rogue variable this way and correct it rather than having to go through the "restore settings" procedure.