I've read Merlin's NVRAM FAQ posting, and have a few derived conclusions that I think I've arrived at, and would appreciate a comment as to how accurate they are (apologies if they're blindingly obvious to some, or laughably simplistic etc). And then a couple of follow up questions if I may (and who knows, some of this may be deemed worthy of inclusion or addressing in his FAQ).
#1 - There are in essence 3 things built into the router that persist across reboots: the current firmware image including the kernel and base filesystem (binaries etc); the nvram variables; and the jffs partition (if any). At runtime the firmware image reads the nvram variables and configures itself accordingly. This includes reading nvram and then executing commands to set up network interfaces etc, and also using those settings as a basis for dynamically generating config files (for apps such as dnsmasq etc) which are then mounted in a RAM backed tmpfs. If this "as directed by nvram variables" config then indicates that the jffs partition is enabled, Merlin's firmware then mounts that partition and runs scripts and further amends the tmpfs config files according to the files it finds in the jffs partition. Scripts could notionally then load settings from a USB stick or a remote machine etc and further re-configure the router (execute commands directly and/or change config files), and the firmware actually checks newly plugged in USB devices for an executable /asusware/.asusrouter file to execute (is this a hotplug rule?), but in essence it is just these 3 areas that define the behaviour of the router that can be changed across reboots.
Is this broadly correct?
#2 - The web UI displays information based on values it reads from these nvram settings (and settings read from the tmpfs config files as potentially further modified by jffs files?) in a more-easily-understood manner, together with transient state info (active devices, IP addresses etc). But any "permanent" changes made by the UI are only ever persisted by writing back to nvram. A single user interaction may of course result in multiple nvram variables being updated, which may in turn lead to config files being regenerated in tmpfs, but that's the idea of a nice UI, to wrap up such complexity.
Anything that can be configured by the web UI could be done by raw writes to the nvram, not to say that this is a great idea due to the complexity of certain operations and knowing which files should be regenerated and services restarted etc to take effect without a reboot, but in principal it could be done.
Or is it the case that, for example, a web UI may be displaying information that it reads from the output of certain commands (eg ifconfig) and makes its changes purely by running other commands, and if so, is it delegating the responsibility for persisting changes to those other commands?
Or do some changes in the UI get persisted by updating the firmware file image itself (eg a config file or script in the base filesystem) - I think this is very unlikely for any number of reasons, and that the raw firmware image is only ever modified by explicit firmware updates, but would be interested to know if, for example, there's an equivalent of the jffs filesystem reserved for system use.
#3 - The nvram settings are essentially name-value pairs - they have no magical/automatic effect in themselves (eg by memory mapped I/O etc), but only have effect by applications from the firmware image knowing to read them and act accordingly (similar to how an INI file only has significance when an application reads it and reacts accordingly). Any nvram vars that the firmware does not know to read ("SchmergsConfusionLevel=4") will have no effect as the kernel/running apps won't have any code to read this, but some code will enumerate some keys to determine what to read (eg "wl_vifnames" defines a list of wireless interfaces, for each of these some component will know to work out further keys to look up for SSID names, MAC addresses etc) according to convention rules encoded in the firmware software.
#4 - On the first boot with a new firmware image, the firmware knows to write some default settings into nvram, but any subsequent boots with the same firmware image will not repeat this action.
How does it know what's the first boot - does the firmware upgrade process set an nvram symbol or does the firmware record its version number in nvram when booted or similar?
#5 - The "Save Settings" in the web GUI returns a CFG file that, I assume, is a collection of purely nvram settings, obscured or encrypted or compressed to hide certain values (wifi passwords and the like).
Does this represent all nvram symbols, or just the "known to the firmware" items (see "SchmergsConfusionLevel=4" above)?
#6 - The factory-reset option effectively wipes nvram completely (all keys, not just the "known keys") before rebooting, having set whatever flag is required to indicate to the firmware on next reboot that it should re-initialise the now-empty nvram area with its defaults (as in #4 above).
#7 - Depending on the accuracy of the above, and the answer to #5, if I take a backup of current settings, reset to factory defaults, and then restore those settings (ie all under the same version of the firmware), will the net effect be nothing (backup backed up all settings which are then restored) or will this have the effect of undoing any nvram vars that were set manually (at a shell prompt etc) which can't be configured by the web UI, or is it all a bit more complicated than that?
The above sort of makes sense to me in that I think I can see how I would build such a system, how this would guide decisions about what actions do what, how it separates user config from system defaults, and the like, but if I've got the wrong end of the stick, I'd appreciate any illumination.
And to any future readers - don't take any of the above as accurate without further confirmation from Merlin etc. By itself, it's only my best guess of how it all hangs together.
#1 - There are in essence 3 things built into the router that persist across reboots: the current firmware image including the kernel and base filesystem (binaries etc); the nvram variables; and the jffs partition (if any). At runtime the firmware image reads the nvram variables and configures itself accordingly. This includes reading nvram and then executing commands to set up network interfaces etc, and also using those settings as a basis for dynamically generating config files (for apps such as dnsmasq etc) which are then mounted in a RAM backed tmpfs. If this "as directed by nvram variables" config then indicates that the jffs partition is enabled, Merlin's firmware then mounts that partition and runs scripts and further amends the tmpfs config files according to the files it finds in the jffs partition. Scripts could notionally then load settings from a USB stick or a remote machine etc and further re-configure the router (execute commands directly and/or change config files), and the firmware actually checks newly plugged in USB devices for an executable /asusware/.asusrouter file to execute (is this a hotplug rule?), but in essence it is just these 3 areas that define the behaviour of the router that can be changed across reboots.
Is this broadly correct?
#2 - The web UI displays information based on values it reads from these nvram settings (and settings read from the tmpfs config files as potentially further modified by jffs files?) in a more-easily-understood manner, together with transient state info (active devices, IP addresses etc). But any "permanent" changes made by the UI are only ever persisted by writing back to nvram. A single user interaction may of course result in multiple nvram variables being updated, which may in turn lead to config files being regenerated in tmpfs, but that's the idea of a nice UI, to wrap up such complexity.
Anything that can be configured by the web UI could be done by raw writes to the nvram, not to say that this is a great idea due to the complexity of certain operations and knowing which files should be regenerated and services restarted etc to take effect without a reboot, but in principal it could be done.
Or is it the case that, for example, a web UI may be displaying information that it reads from the output of certain commands (eg ifconfig) and makes its changes purely by running other commands, and if so, is it delegating the responsibility for persisting changes to those other commands?
Or do some changes in the UI get persisted by updating the firmware file image itself (eg a config file or script in the base filesystem) - I think this is very unlikely for any number of reasons, and that the raw firmware image is only ever modified by explicit firmware updates, but would be interested to know if, for example, there's an equivalent of the jffs filesystem reserved for system use.
#3 - The nvram settings are essentially name-value pairs - they have no magical/automatic effect in themselves (eg by memory mapped I/O etc), but only have effect by applications from the firmware image knowing to read them and act accordingly (similar to how an INI file only has significance when an application reads it and reacts accordingly). Any nvram vars that the firmware does not know to read ("SchmergsConfusionLevel=4") will have no effect as the kernel/running apps won't have any code to read this, but some code will enumerate some keys to determine what to read (eg "wl_vifnames" defines a list of wireless interfaces, for each of these some component will know to work out further keys to look up for SSID names, MAC addresses etc) according to convention rules encoded in the firmware software.
#4 - On the first boot with a new firmware image, the firmware knows to write some default settings into nvram, but any subsequent boots with the same firmware image will not repeat this action.
How does it know what's the first boot - does the firmware upgrade process set an nvram symbol or does the firmware record its version number in nvram when booted or similar?
#5 - The "Save Settings" in the web GUI returns a CFG file that, I assume, is a collection of purely nvram settings, obscured or encrypted or compressed to hide certain values (wifi passwords and the like).
Does this represent all nvram symbols, or just the "known to the firmware" items (see "SchmergsConfusionLevel=4" above)?
#6 - The factory-reset option effectively wipes nvram completely (all keys, not just the "known keys") before rebooting, having set whatever flag is required to indicate to the firmware on next reboot that it should re-initialise the now-empty nvram area with its defaults (as in #4 above).
#7 - Depending on the accuracy of the above, and the answer to #5, if I take a backup of current settings, reset to factory defaults, and then restore those settings (ie all under the same version of the firmware), will the net effect be nothing (backup backed up all settings which are then restored) or will this have the effect of undoing any nvram vars that were set manually (at a shell prompt etc) which can't be configured by the web UI, or is it all a bit more complicated than that?
The above sort of makes sense to me in that I think I can see how I would build such a system, how this would guide decisions about what actions do what, how it separates user config from system defaults, and the like, but if I've got the wrong end of the stick, I'd appreciate any illumination.
And to any future readers - don't take any of the above as accurate without further confirmation from Merlin etc. By itself, it's only my best guess of how it all hangs together.
