If we're lucky, Asus might have also taken the occasion to fix the CFE to properly handle 64K
NVRAM, which would open the door to full DD-WRT support. But that would require someone with such a router and a
serial cable to validate whether Asus did change the CFE or not.
Is what I provided below relevant to the CFE issue?
If the 66r does use the 66u firmware, would it be possible to flash it to a firmware version
that does not have the 64k nvram fixed in the kernel, then telnet and run the nvram show command to see if it still
is 64k?
That way it wouldn't need to be opened up? Or am I off base?
OK, I checked it out, since I had the confidence from already easily upgrading the firmware (see below) and having store return privileges. I put the RT-N66R back to an earlier firmware and got the readings by Telnet. I also discovered some significant problems that may be applicable to other than the "R" model.
UPDATE: I think I resolved the issues below. Please see the post at http://forums.smallnetbuilder.com/showpost.php?p=49667&postcount=25 for an explanation. In retrospect, any difficulties that I experienced were not show stoppers (more likely user errors) and shouldn't overshadow the impressive performance of this router.
Flashing and Backup Issues. Upfront, these are remaining issues for me, listed by importance (see Problems Experienced below):
a. Reliability of settings configuration file is questionable. (I don't like to think of having to manually re-enter all of the settings that make my network flow correctly.)
b. Reliability of Firmware Restoration utility operation is questionable. (Assuming the router is bullet proof -- here's hoping -- other flashing methods might work.)
c. Duplicate web GUI login-blocking enigma ("You cannot Login unless logout another user first") complicates and frustrates resolution of problems. (When router is fully functioning, I've been able to log in simultaneously from different computers, both HTTP and HTTPS -- maybe that's just the Merlin build? -- and I haven't had that problem with Linksys or DD-WRT GUIs. Duplicate login restrictions should be removed. Remote access might be needed but wouldn't be available if the web GUI was left open on the LAN.)
NVRAM Size. Here's the result of flashing the RT-N66R to the pre-64KB NVRAM firmware 3.0.0.3.178. If I correctly understand how to read the outputs of dmesg and "nvram show," I think it went back to 32KB like one would expect if it's just a clone of the "U" model, different in branding only. I've attached the Telnet logs for the output of both dmesg and "nvram show" (excerpt because of attachment size limit here) if anyone wants to glean further information or if I didn't provide the right summary:
dmesg --
dev_nvram_init: _nvram_init
_nvram_init: allocat header: 2280980480,
size= 32768
nvram show --
size: 29689 bytes (3079 left)
Pre-64KB Firmware. I started with the out-of-the-box firmware of 4.176 (which is already 64KB NVRAM) and several days ago upgraded to Asus 4.220 then Merlin 4.220.18, all smoothly without a hitch. So, I thought it would be a piece of cake to go back to 3.178, and it was. While at the 3.178 firmware and having read a number of threads here on clearing NVRAM, resetting, and upgrading these Asus routers, I decided to try some of the methods: Holding the reset button, using "mtd-erase -d nvram" both with Telnet and at
http://192.168.1.1/Main_AdmStatus_Content.asp, and even putting router into "rescue mode" and using Firmware Restoration utility to reload 3.178 (failed - see below). (I didn't try the method of holding the WPS button while powering the router back on to clear NVRAM, which I assume will work
http://forums.smallnetbuilder.com/showpost.php?p=47627&postcount=19.) Of course, Telnet had to be re-enabled for any Telnet access after successful resets. At various times I was greeted with the "You cannot Login unless logout another user first" webpage while trying to access the web GUI. Generally,
http://192.168.1.1/Main_AdmStatus_Content.asp was always available as long as the power LED wasn't blinking. And there were several times when the configuration did survive the "mtd-erase -d nvram." I ended these experiments with the router in a seemingly stable 3.178 state with minimum configuration.
Problems Experienced. Getting back to the 4.220.18 build and restoring my configuration settings was a saga lasting hours. (I didn't keep track of the times I reset the router and flashed the firmware.) Each time I restored the settings with the backup file, I could see that only the 2.4GHz SSID had been restored, but the 5GHZ SSID was still "ASUS_5" and I couldn't log in to the web GUI with my username and password after I closed the browser window. I also couldn't access the Administration page to enable Telnet. Apparently the .cfg settings file that I had backed up to was corrupted. Frustratingly, I was continually met with "You cannot Login unless logout another user first." I often ended Internet Explorer between NVRAM clearings and firmware flashing, including ending the iexplorer processes in Task Manager to hopefully eliminate any caching that may have been contributing to these problems. But I was always able to get to
http://192.168.1.1/Main_AdmStatus_Content.asp. That webpage also presented a login window that, curiously, would accept my username and password when the main web GUI page would not. I tried the Firmware Recovery utility at least five times and found that if I tried to upload the firmware and was unsuccessful, I would later only get the response of "not in rescue mode" unless I exited and restarted the program. When the program did start to upload the firmware, the power LED stopped its slow blinking, which indicated it was in the rescue mode, and I had these errors (never successfully completing the recovery process): Either the program aborted the upload part way through, resulting in the status that the router is not in rescue mode, or after completing the upload and after a fairly lengthy recovery process, I received a warning that the recovery was unsuccessful.
Resolution. To finally restore workability, I cleared NVRAM via the Main_AdmStatus_Content webpage referenced above. I then closed all IE processes, restarted the browser, and accessed 192.168.1.1 after waiting out the "You cannot Login unless logout another user first" error (it seemed to go away on it's own after 5-10 minutes, but I was never really sure of what was going on there -- apparent restricted simultaneous logins seem to persist beyond complete router resets), sprinted through the Quick Setup, did the firmware upgrade again to be sure there wasn't any corrupted code in the router (maybe that wasn't necessary), and re-entered all of my "production" configuration information. (Fortunately, with this being a brand new router, I haven't gotten around to entering all the MAC address filters, static IP addresses, and port forwards that I normally use.) I saved the settings into a backup file that has the same size (36,872 bytes) as the one that wouldn't restore correctly, so I still don't know if it's any good or how to test it -- not the best comfort level.