RT-N66R = RT-N66U (But . . .)

After narrowing down the replacement router that I wanted to either a Netgear WNDR 4500 or an Asus RT-N66U, I bought an RT-N66R from Best Buy last Saturday. It really wasn't until I got it home that I noticed it wasn't a "U". Since I couldn't find a reference to that model on the Asus website, I called Asus tech spt/product information and was told by an Asus rep (who didn't hesitate in his answer) that the only difference between the "R" and the "U" models is that the "R" is sold by retailers such as Best Buy.

That sounded great. However, the firmware version that the R came with is 3.0.0.4.176, and doing an update check with the router's web administration GUI states that "The router's current firmware is the latest version." Yet, we know that the latest U firmware is version 3.0.0.4.220. When I went to the Asus download website today, I found that both the R and U were listed. For the RT-N66R, no firmware updates are listed as available, and the utility software is shown as: ASUS RT-N66R Utility version 4.2.6.4, The first version of utility for ASUS RT-N66R. (For the RT-N66U (VER.B1), the utility software is ASUS RT-N66U B1 Utility version 4.2.3.9, The first version of utility for ASUS RT-N66U B1.)

Since it's evident that I need to upgrade the firmware to fix these issues, I might as well try the Merlin ASUS RT-N66U 3.0.0.4.220.18b while I've still got store return privileges. I'll let you know the results.

If it's fully compatible, I think that the R should maybe be rolled up into the U subforum. I suspect the R could outrun the U in sales from big box stores.

I have a feeling they are the exact same hardware, but it's indeed a marketing difference (either in bundling or packaging). In fact that model does not even exist in the firmware source code, so I suspect it's the exact same firmware.

Could you do me a favor and post the output from the "dmesg" command (run it over telnet)? That will allow me to at least see if most of the hardware is the same.

Normally I would suggest trying to flash my firmware just to see what happens (those routers are near impossible to brick), however the lack of an official RT-N66R firmware to flash it back in case of trouble could be a problem.

EDIT: 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.

I'm glad to provide the attached dmesg output (after boning up on telnet, having never used it, but really quite simple). I hope I did it right and that you can conclude that the hardware is the same. I also attached a screen shot of the RT-N66R web GUI. Aside from the version number difference from what Asus has been making available for the RT-N66U, they've embedded "R" in it, but maybe there aren't any substantive differences to complicate things.

It's heartening to think about this router being near brick proof. I've been living with an otherwise great Linksys WRT350N for about 5 years that often couldn't make a power cycle without a blinking power LED endstate. It worked much better the last 3 years with DD-WRT, but I've come to become intimate with the 30-30-30 reset method. And finally, the true brick.

I've scanned the 32K/64K issue in the DD-WRT forum and recognize that the 64K firmware upgrade method for the RT-N66U hasn't filled the technical bill. But my WRT350N only had 32K of memory and I was running the mega version of DD-WRT v24-sp2 on it and still had 15K free, according to the System Info page. So I don't yet understand why the RT-N66 memory is handicapping it. I guess I'd have been disappointed by the WRT350N if I'd tried using very many other features in the mega DD-WRT.

So at this stage, without a posted official firmware to flash back to, you think it's too risky to change it? I wonder why they bother to provide an RT-N66R labeled CD with the "Firmware Restoration" program which wants you to browse for a firmware file that's not available. Perhaps making the original firmware available is an oversight or still to come; I thought that was standard practice. (The RT-N66U B1 has the first version of firmware posted for download.)

The RT-N66U needs more nvram because it's a true dual band router, and it also has USB ports, DownloadMaster, optware, etc... All those features require additional space to store both settings and temporary values.

A brand new RT-N66U with only a basic configuration would have less than 3 KB of free nvram with its original 32 KB nvram.

Interesting - I just noticed that the firmware has AiCloud enabled, while being based on a much older version (176). AiCloud was only officially launched with build 220, and went through a lot of code changes between these two versions.

Hello, new here. Thought I would chime in on this since I just got my shiny new Black Knight in the mail from Amazon today. Pretty much same thing as the OP, but didn't get from a BB (obviously). Grepped the dmesg output for nvram and it's showing the updated 64k as well as AiCloud even though I have the .176 FW.

The RT-N66U needs more nvram because it's a true dual band router, and it also has USB ports, DownloadMaster, optware, etc... All those features require additional space to store both settings and temporary values.

A brand new RT-N66U with only a basic configuration would have less than 3 KB of free nvram with its original 32 KB nvram.

Click to expand...

Thanks for the good explanation in a nutshell.

Interesting - I just noticed that the firmware has AiCloud enabled, while being based on a much older version (176). AiCloud was only officially launched with build 220, and went through a lot of code changes between these two versions.

Click to expand...

Yes, the AiCloud tab has the Google Play logo link, but AiCloud isn't working right. I suppose it's been fixed for build 220? I've been able to set up the AiDisk USB HDD and access the media server, network share, FTP server, and Download Manager. But the Cloud Disk can't be connected through either the Google app or the URL with a browser. (The Google app recognizes the existence of the router's AiCloud, because it starts with the nickname prefilled with the host name, and that changes if I change the DDNS service. And for IE connection, Windows Network Diagnostics says that the remote device or resource won't accept the connection.)

The AiCloud hard-coded 443 port conflicts with the standard SSL port that many users will want forwarded to a server, so I had to remove that port forward for WHS 2011 to test. I think that routers should be able to have any of their administrative ports changeable -- and that includes added functions like FTP server and AiCloud -- so that the router can be transparent to applications and roles that one wants to assign to connected computers. The only port I can find that's selectable is the HTTPS LAN port for the web GUI. I reckon I've been spoiled by DD-WRT.

I noticed that the FTP security (for Share with Account) seems weak: FTP access on the LAN goes directly to a log-on screen, but Internet FTP access through DDNS doesn't trigger a log-on screen until you drill down into the folders. (Although the folders appeared to be empty in the latter case, it's not a warm and fuzzy feeling that anyone is allowed to be connected and see the folder structure.)

Normally I would suggest trying to flash my firmware just to see what happens (those routers are near impossible to brick), however the lack of an official RT-N66R firmware to flash it back in case of trouble could be a problem.

Click to expand...

I just talked with an Asus wireless router tech support rep (Ron), who confirmed -- as I was told before -- that R is simply the "retail" version of U. Asus provides the routers to Best Buy and they market them. But this time, I specifically asked about the firmware. He said that the U firmware is for the R. That's why there's no firmware listed under downloads for RT-N66R. He said that the latest 220 build is also for the R (and you can't get into trouble with Asus for flashing it). That's probably true for the AC66 router as well. Perhaps with enough queries, they'll consolidate the download options on the Asus support web page to cover the models under one selection as "U/R" or "U or R". I think that would provide the needed clarification to customers. Edit: On second thought, that might not work because separate manuals for the R and U models were published. Instead, just replicate the U firmware under the R model selection, starting with build 220. And include the current shipping R firmware, build 176, for download to enable a customer to flash back to it.

So, for me, that opens the door to official firmware upgrade for the R.

Overall, Build 220 (and also the Merlin build) is a definite improvement for the RT-N66R. Build 220 fixes these problems that I found in build 176 which was on the router out of the box:

1. The Save Setting selection no longer goes to an HTTP 404 Not Found page.

2. AiCloud works great and does a good job of streaming video to Android from LAN shares. (Be sure your phone or tablet has good security because the AiCloud app caches the username and password for immediate connection. So anyone who has access to your lost phone can be in your LAN.)

3. FTP access is more secure by starting with a log-on screen before showing the file structure.

However, I have these issues, although they may also exist in the "U" version (or maybe it's just my router or cockpit error):

1. Download Master goes to a blank page at port 8081.

2. HTTPS access to the web GUI works on the LAN IP address and from Android, but IE9 results in res://ieframe.dll/invalidcert.htm?SSLError=50331648 when using a DDNS address after clicking continue on the problem-with-security-certificate screen.

3. After logging on to FTP and clicking on the root folder, IE cannot display the webpage.

If these issues aren't unique to the "R" model, then indeed "R" = "U".

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?

2. HTTPS access to the web GUI works on the LAN IP address and from Android, but IE9 results in res://ieframe.dll/invalidcert.htm?SSLError=50331648 when using a DDNS address after clicking continue on the problem-with-security-certificate screen.

Click to expand...

Accessing the router using the DDNS from inside your network can cause the router to crash and reboot itself if you are running Asus's firmware. I have fixed that issue in my builds (it's related to the GRO setting). Asus are aware of the issue and will have a solution in a future firmware update.

Accessing the router using the DDNS from inside your network can cause the router to crash and reboot itself if you are running Asus's firmware. I have fixed that issue in my builds (it's related to the GRO setting). Asus are aware of the issue and will have a solution in a future firmware update.

Click to expand...

I'm sorry to say that IE9 chokes in HTTPS access using DDNS within the LAN even with your 220.18 build. While I can get past the log-in window to see the GUI, the screen freezes either right away or after a few clicks. Although the router doesn't crash, that HTTPS access isn't reliable on my system. However, Google Chrome does successfully access the GUI under the same HTTPS scenario. In fact, it's very speedy operation of the GUI. Plain HTTP access using DDNS inside the network does work okay with IE9.

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?

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?

Click to expand...

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.

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:

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.

Flashing an older firmware won't help you determine if the CFE addresses 32 KB or 64 KB. The RT-AC66U requires the NVRAM_64K switch to be enabled when the firmware is compiled. The only way to truly determine if the CFE can access the whole 64 KB is through a serial cable.

Restoring settings meant for a different nvram size is not supported. You HAVE to clear your settings and manually reconfigure when switching nvram size, otherwise you will run into issues.

The multiple login issue usually occurs if you log from one IP, change your PC's IP without logging out - the router will still think you are logged in on the first IP.

To be clear, I followed cautions about using settings from mismatched firmware. I never tried to restore any settings to the earlier 32KB firmware. I tried to restore the backup from the 220.18 back to the 220.18 after flashing back to that current version. That's when I had the problems. Shouldn't the 220.18 have set the NVRAM back up to 64KB after experimentation with 32KB firmware and accepted the settings without error? Now that I have it working right but with minimum custom configuration settings, I guess I'd better bite the bullet and clear brNVRAM and test the settings restore so I can rely on the backup and restore function.

Why do you suppose there's still a multiple login problem when only one computer is being used after the router's memory is erased and the browser is restarted? That's the issue I had.