Not so interesting, however, there is the fact that I use a real wildcard certificate on the device, which itself is 12KB for the key and chain.
I looked through the code for httpd.c in dd-wrt, as I couldn’t modify /etc/cert.pem and /etc/key.pem, and /jffs/etc overlays didn’t work either. I created /tmp/https_cert and /tmp/https_key, but the server still didn’t read them. Looking at the code, the only avenue to putting the cert into httpd, for the GUI, was to insert it into NVRAM.
Now, I can probably get stunnel via entware and have it proxy the https tunnel with the certificate on /jffs, or as you say, cull the unused and empty NVRAM variables, as I did on an RT-N16 (by killing the second OpenVPN server config, as it was never going to be used). But, this workaround needs to be done at each boot, and with a scenario like on the 5300, there exists the possibility of NVRAM corruption due to truncation.
So, several bugs that led to this situation, but the most pressing is that the silent misbehavior of the system with regards to configuration is remedied.
It would appear that even the current system init service still references the K2.4 include for <bcmnvram.h>, and therefore still is based before 2012, with no router models supporting 128KiB of NVRAM.
However, this value is not likely current, although files including this file probably need to be verified for flash sizing.
I’m not going to detail the whole file, but the largest flash allocation in that header is 8Kx8, so another limit that should be checked.
As to why the full 128KiB is available, once booted: the later routines get their size from the chip ID directly. The system initialization NVRAM routines need to get their low-level chip information from newer sources.
Maintainers, please address.
I’m not going to put this in the ticket, just yet, because it’s still speculative in nature.
Last edited by Hapi12021 on Thu Jul 22, 2021 21:10; edited 1 time in total
I see the gotchas gotcha. There are pitfalls if you do not understand the layout on the public svn, and I can guarantee you that is not the files you should be looking at, most likely.
And that’s cool, I haven’t tried to build the whole system, so not familiar with the layout. I have built older versions of Tomato, however, so not entirely clueless on how these values get overridden at different points.
I’m still working my way through the code.
Do you know which module sets the NVRAM value probe_blacklist? That’s seems to be around where the trouble starts.
But, in general, since 128KiB flashes are still not that common, there probably exist a fair amount of #defines for older flash chips that need to have a second look, and the boot code may be misidentifying the AC5300’s size, or still think the largest flash is 64KiB.
A lot of routers have 128k nvram I have a Netgear R6400 which is broadcom and a Netgear R7800 which is atheros both having 128k
Would you be up for an experiment?
Assuming they run DD-WRT, inject an NVRAM variable that’s ~ 16-32K worth of random data, and ensuring that more than 64K total is used commit and reboot to verify if booting over 64K works on other platforms?
Ideally, dump the contents of NVRAM to a file before and after, and the only variable that should diff out would be the random data.
I do not have time to do that at the moment but specifying the amount of nvram is fairly simple, when I build for e.g. an R7000 which has 64k I have to specify that in the config file.
For the R6400 I specify 128k then building is done with DHAVE_128K.
I’m happy to provide any extra information I can. My browse through dmesg and messages yielded no significant debugging data. It was just if wl0 was unplugged from the system. No error messages at all. Likely it was never probed and never had the driver attached.
You really need to hear from the head honcho how he is building.
We have a router matrix but that is rather old and suggests builds are made with 64K NVRAM
I have made a build for your Asus RT5300 with 128K NVRAM specified but the chances that it will permanently brick your router I would estimate at about 80%
On the bright side I did not think it would build at all as the CPU is really different (Quadcore arm A53 at 1.8 GHz ?) so I actually thought I needed an Armv8 toolchain, but then again maybe I do and the build will brick your router
(I know/think that Armv8 should be backwards compatible with Armv7)
The RT-AC5300 is dual-core BCM4709C0 ARMv7 at 1.4GHz. It’s Northstar and not all that different than the RT-AC3200, but with a slightly uprev’d BCM4366 radio chipset for doing MU-MIMO @ 4:4. Physically, it’s a giant box with 8 antennas, but internally it’s pretty familiar territory.
Last edited by Hapi12021 on Fri Jul 23, 2021 17:23; edited 2 times in total