Question About NVRAM Keys/Values Stored in JFFS

[HarryMuscle]

I've read that the router stores some NVRAM keys/values in the JFFS partition in the /jffs/nvram directory. However, if you delete all the files in that directory and reboot the router they are recreated all with the same values that they had before they were deleted, so clearly the router also stores the exact same NVRAM keys/values somewhere else, most likely in NVRAM itself. So what is the purpose of having these keys/values in the /jffs/nvram directory if they are also stored in NVRAM itself?

Thanks,
Harry

 

[ColinTaylor]

However, if you delete all the files in that directory and reboot the router they are recreated all with the same values that they had before they were deleted, so clearly the router also stores the exact same NVRAM keys/values somewhere else, most likely in NVRAM itself.

No this is not normally the case. If you completely delete a variable, when the router boots up if any variables are missing it recreates them with the default values. There is another more complex scenario that only applies to the HND models. With those there is another file that also stores nvram data called /data/.kernel_nvram.setting.

 

[HarryMuscle]

No this is not normally the case. If you completely delete a variable, when the router boots up if any variables are missing it recreates them with the default values. There is another more complex scenario that only applies to the HND models. With those there is another file that also stores nvram data called /data/.kernel_nvram.setting.

The NVRAM keys/values stored in the /jffs/nvram directory aren't just defaults. For example the static DHCP lease list is stored there and I have over a dozen entries. I can delete that from the /jffs/nvram directory, reboot, and everything comes back, so clearly it's stored somewhere else too which seems strange.

 

[ColinTaylor]

It's probably using the old value from .kernel_nvram.setting or memory. That file acts as a sort of cache contains the committed nvram data. When you issue an nvram commit (which happens when you reboot) the variables that are cached are committed to disk, effectively undoing the change you made.

EDIT: Corrected description of .kernel_nvram.setting. Note that you should never attempt to modify this file directly as it will likely result in it getting corrupted.

 

[HarryMuscle]

It's probably using the old value from .kernel_nvram.setting or memory. That file acts as a sort of cache. When you issue an nvram commit (which happens when you reboot) the variables that are cached are committed to disk, effectively undoing the change you made.

Interesting. I just tried simply unplugging the router after deleting the nvram files and they still come back with their non default values. Assuming the .kernel_nvram.setting file is persistent then maybe they come back from there but definitely not from memory since that would be wiped by just pulling the power. Doesn't that file though only apply to HND routers? Is the RT-AX86U a HND router?

 

[ColinTaylor]

Yes the RT-AX86U is one of the HND routers. Other models may have slightly different filesystem layouts. You didn't mention a specific router so I was replying in general terms.

 

[Yota]

In fact there are 5 places where nvram variables are stored for 384/386/388 HND routers:


The first one is called misc1 partition, written by the manufacturer at the time of manufacture, where parameters cannot be modified directly, usually wireless power and MAC address are locked here. (usually we call it CFE parameters, although it is not responsible for bootloading at all)

The second is the modifiable nvram that everyone is talking about. It is stored in the misc2 partition. the corresponding partitions are different on different models. for AC86U, it becomes the mtd9 partition in the firmware. this partition has the same non-volatile memory as /jffs/. the difference is that the user cannot directly read and write the partition, it must be done through the nvram program.

The third and fourth are the backup and expansion of misc2, which are stored in the /jffs/ and /data/ partitions, (that is what the OP and ColinTaylor mentioned), both of which have non-volatile memory, but since they are usually direct backups of misc2, so modifying them does not make nvram changes take effect.

The fifth is the nvram stored in the memory. After each boot, the system will load the variables saved in misc1 and misc2 into the volatile memory, and change some of the variables, but some changes are only used in the current system, they will not be saved, and the original variables will be reloaded at the next boot. When you use the nvram set xxxx command, it is just saved to memory, the system can load the changes you committed, but after power off it will disappear, unless you use the nvram commit command to save it to misc2.

 

[HarryMuscle]

In fact there are 5 places where nvram variables are stored for 384/386/388 HND routers:


The first one is called misc1 partition, written by the manufacturer at the time of manufacture, where parameters cannot be modified directly, usually wireless power and MAC address are locked here. (usually we call it CFE parameters, although it is not responsible for bootloading at all)

The second is the modifiable nvram that everyone is talking about. It is stored in the misc2 partition. the corresponding partitions are different on different models. for AC86U, it becomes the mtd9 partition in the firmware. this partition has the same non-volatile memory as /jffs/. the difference is that the user cannot directly read and write the partition, it must be done through the nvram program.

The third and fourth are the backup and expansion of misc2, which are stored in the /jffs/ and /data/ partitions, (that is what the OP and ColinTaylor mentioned), both of which have non-volatile memory, but since they are usually direct backups of misc2, so modifying them does not make nvram changes take effect.

The fifth is the nvram stored in the memory. After each boot, the system will load the variables saved in misc1 and misc2 into the volatile memory, and change some of the variables, but some changes are only used in the current system, they will not be saved, and the original variables will be reloaded at the next boot. When you use the nvram set xxxx command, it is just saved to memory, the system can load the changes you committed, but after power off it will disappear, unless you use the nvram commit command to save it to misc2.

Thanks for the detailed explanation.

 

[ColinTaylor]

In fact there are 5 places where nvram variables are stored for 384/386/388 HND routers:


The first one is called misc1 partition, written by the manufacturer at the time of manufacture, where parameters cannot be modified directly, usually wireless power and MAC address are locked here. (usually we call it CFE parameters, although it is not responsible for bootloading at all)

The second is the modifiable nvram that everyone is talking about. It is stored in the misc2 partition. the corresponding partitions are different on different models. for AC86U, it becomes the mtd9 partition in the firmware. this partition has the same non-volatile memory as /jffs/. the difference is that the user cannot directly read and write the partition, it must be done through the nvram program.

The third and fourth are the backup and expansion of misc2, which are stored in the /jffs/ and /data/ partitions, (that is what the OP and ColinTaylor mentioned), both of which have non-volatile memory, but since they are usually direct backups of misc2, so modifying them does not make nvram changes take effect.

The fifth is the nvram stored in the memory. After each boot, the system will load the variables saved in misc1 and misc2 into the volatile memory, and change some of the variables, but some changes are only used in the current system, they will not be saved, and the original variables will be reloaded at the next boot. When you use the nvram set xxxx command, it is just saved to memory, the system can load the changes you committed, but after power off it will disappear, unless you use the nvram commit command to save it to misc2.

Thanks for the info. The partition and filesystem usage is slightly different for the RT-AX86U. mtd9 is a raw JFFS formatted partition that's mounted to /jffs and works just like a traditional filesystem. The other data we're talking about is contained in UBI volumes and there can be multiple volumes on each UBI device. Additionally there is a backup copy of the entire ubi0 device.

 

[Yota]

Thanks for the info. The partition and filesystem usage is slightly different for the RT-AX86U. mtd9 is a raw JFFS formatted partition that's mounted to /jffs and works just like a traditional filesystem. The other data we're talking about is contained in UBI volumes and there can be multiple volumes on each UBI device. Additionally there is a backup copy of the entire ubi0 device.

Thanks for your explanation, yes, you can use the cat /proc/mtd command to view the partition corresponding to misc2.

According to my observation, the function of nvram under /jffs/ is to back up misc2 in Asuswrt, and a new purpose is added in Asuswrt-Merlin - expansion, which is an effort to reduce the size of misc2.

The HND router adopts the A/B update method every time it is updated, that is, there are actually two systems saved on the nand, and only one of them is updated each time it is updated, so if there is a problem with the update, you can still boot to another non-updated system (to prevent accidental power failure during the flashing process and become a brick), and the nvram variable under /data/ plays a vital role when booting to another partition, because at that time /jffs/ may not be unavailable.

 

[ColinTaylor]

According to my observation, the function of nvram under /jffs/ is to back up misc2 in Asuswrt, and a new purpose is added in Asuswrt-Merlin - expansion, which is an effort to reduce the size of misc2.

This is different than on my router. On mine /jffs occupies the whole of the misc2 (mtd9) partition so it can't be a backup for itself. I don't know what you mean by "expansion".

The HND router adopts the A/B update method every time it is updated, that is, there are actually two systems saved on the nand, and only one of them is updated each time it is updated, so if there is a problem with the update, you can still boot to another non-updated system (to prevent accidental power failure during the flashing process and become a brick), and the nvram variable under /data/ plays a vital role when booting to another partition, because at that time /jffs/ may not be unavailable.

I have observed the same behaviour on my RT-AX86U.

 

[Yota]

This is different than on my router. On mine /jffs occupies the whole of the misc2 (mtd9) partition so it can't be a backup for itself. I don't know what you mean by "expansion".

Well, my experience only applies to the AC86U I own, hahaha.

The expansion I am talking about refers to the optimization made by RMerlin (maybe I should have used "extension" forgive my wording). For example, he saved some nvram variables in jffs to reduce the nvram occupancy.

These optimizations are absent in Asuswrt firmware