This commit is to fix a problem that any NVRAM variables that are not in the list of "shared/defaults.c" will not be restored from configuration file including custom variables. So far it’s in all ARM builds. Here’s the detail. For example, the following are not restored:
qos_inuse
rrule1
rrule2
Traced back to nvram_arm/main.c in the source code:
line 216:
if (issyspara(p))
nvram_set(p, v);
What it does is to perform a variable name check, if it either contains "wl", "wan", "lan", or it's in the list of "shared/defaults.c", the variable will be restored using nvram set equivalent command. If not found, then they are ignored. The perfect solution will be putting every single variable names in file "shared/defaults.c". However this is a tremendous and complex work to accomplish and requires highly orchestrated team effort. Before it’s done, the restore process is always flawed by missing some variables, potentially causing unexpected behavior of the router. The less perfect solution would be just skip the check. It seems restoring a complete list of variables in the configuration file is more important. To do this, just comment it out like the following:
// if (issyspara(p))
nvram_set(p, v);
There’s a flaw in the NVRAM encryption process which, by 20% of the chance, will cause the saved configuration file become corrupted. This commit is to fix this problem. Here’s the detail. Whenever NVRAM variables contain any control characters which ASCII values are less than 32(0x20), data corruption may occur when saving configuration file, either by using tomato GUI menu Administration/Backup Configuration or command line: nvram save filename.cfg. This problem will cause restoration failure either in GUI menu Restore Configuration or command line: nvram restore filename.cfg, WITHOUT showing any error messages. When this error occurs, only the NVRAM variables before the corrupted data are restored while any data after it is lost. The most common scenario that control characters are used in nvram is Line Feed(0x0A) and Carriage Return(0x0D), usually appears in custom scripts in firewall, init, etc. The root cause lies in nvram_arm/main.c in the following code:
Line 68:
rand = get_rand() % 30;
Line 88:
if (buf[i] == 0x0)
buf[i] = 0xfd + get_rand() % 3;
else
buf[i] = 0xff - buf[i] + rand;
Line 68 generate a random value from 0 to 29 and store it in “rand”. Starting from line 88, it uses this value to convert the original NVRAM value to the encrypted one. When it meets 0, which is a separator for NVRAM variables, random value of 0xfd, 0xfe, 0xff are used to represent it in the encrypted format. However, when NVRAM contains control characters such as 0x0A, and the random value happens to be 0, 1, or 2 less, in this case, “rand” = 0x08, 0x09 or 0x0A, the encrypted value will be 0xfd, 0xfe, 0xff, which is the same as “0” in the encrypted format. This results in decryption failure because the encrypted value of 0xfd, 0xfe, 0xff not only means 0, it also can be 0x0A, 0x0D, etc. The original values are lost and the data corruption occurs. While the perfect solution could be a complete makeover of this algorithm, the less perfect one is to walk around it. So far, only control characters of 0x0A and 0x0D are found to be used in NVRAM variables. By excluding the random value(in “rand”) from 8 to 13, value 0x0A and 0x0D will never to encrypted to 0xfd, 0xfe and 0xff, thus avoid the problem. The updated code contains a do…while loop to check if “rand” is between 8 to 13, if true, get the random number again until it’s not. This fix only works when the NVRAM contains no other control characters. If it does, corruption still occurs. However, this is quite uncommon. The up side of this fix is: it doesn’t interfere with the decryption algorithm by only use less number of random values in the encryption process. No change has to be made in the restore process for things to work. It’s totally compatible with any existing good configuration file. The fix has been tested in my ARM router and so far so good.
These fixes come directly from AsusWRT/Merlin.
nvram save -- would output every NVRAM key/value to stdout
due to #ifdef/#endif conditions being commented out
nvram restore -- depending on what characters were used in
NVRAM variables (keys or values), and the obfuscation method
involving random numbers implemented by Asus, it was possible
that certain values, ranges, or byte sequences of characters
may cause restoration problems.
nvram usage syntax -- restore showing the usage syntax if
there are no matching arguments, i.e. "nvram djdsjqd" should
now show usage syntax rather than nothing.
Reference: https://github.com/RMerl/asuswrt-merlin/blob/master/release/src/router/nvram_arm/main.c
Reference: http://www.linksysinfo.org/index.php?threads/tomato-arm-cfg-file.73093/#post-282981
- updated et, wl, ctf, emf, igs, bcm57xx drivers
- most binaries compiled from sources line libbcm, bcmcrypto, libbcmcrypto, nas, eapd, emf, igs
- fixed flash used space
- fixed wireless encryption problem (nas got Segmentation Fault)
- added ionice and taskset for Samba
- shared, include and router/shader code updated
- one fix in optware install script
- removed some mipsel stuff like iptables, iproute, et, nvram ...
- CFLAGS, LDFLAGS updated
- propably much more changes and fixes but i dont remember now ;)
pedro
Michał Obrembski
edrikk
iv7777
Jeremy Chadwick
Shibby