Asuswrt-Merlin 376.49 is out

[NomadTech]

This is because the latest firmware is now doing a device model check against the NVRAM.

To flash this latest firmare, do the following (confirmed working on my TM-AC1900):

1. Flash the Asus 1.0.21 CFE from here using the mtd-write v3 tool (put both files on a USB stick, change to /tmp/mnt/usbstickvolumename and do "./mtd-write cfefile.bin boot" via SSH).

2. Clear your NVRAM ("mtd-erase2 nvram" via SSH or do a hard-reset).

3. Power-off the router, then power it back on after 10 seconds.

4. Connect to the router and complete the setup wizard.

5. Confirm in the "System Info" page that your router model is now RT-AC68U and not TM-AC1900, and that your CFE version is 1.0.21.

6. Upgrade to the latest Merlin firmware via the GUI as usual - no more error message.

I already took care of my router. Info is perfect and usefull for anyone else having this problem. Thank you.

 

[siraltus]

I already took care of my router. Info is perfect and usefull for anyone else having this problem. Thank you.

I know you did. I posted this procedure for anyone else who can't update to the latest firmware.

 

[siraltus]

I uploaded two (unsupported) builds, labeled as 376.49_6:

The AC68 cfeupd build will take care of updating the CFE, and also be ready to accept any FW > 32 MB (such as Asus's recent 378_xxxx builds).

Thank you. What CFE version does the cfeupd build install? 1.0.21?

 

[SylCoca]

Not sure what option you are using, because there's no such option in the firmware.

On my router, using 49_5.

Advanced settings/administration/system/Miscellaneous

Below authentication method.

There is a prompt for

"Enable WAN access from wifi"

I have this option set to"no"

Shouldn't this block access to logging onto the router through WiFi connected devices, or am I reading this setting incorrectly.

Thanks

 

[JockC]

All 378_xxxx firmwares on the AC68U require an upgraded bootloader. Flash 376_3626 first to upgrade it, after that you can flash the 378_xxxx releases.

Thank you for the response. I had already managed to get the Asus 3813 firmware to upgrade by using the rescue utility although, having done that, there's nothing in it for me (I'm only using the RT as a WAP) so I'll be reverting back to Merlin. Can you please confirm that, having successfully upgraded to the latest 3813 Asus firmware using the rescue utility, that the boot loader size will be no longer an issue for any subsequent versions (either Asus or your own) or do I need to go back and redo the 3626 upgrade?

Edit. I installed the "_6" version and then reinstalled the supported "_5" version so I believe I'm now good for any future firmware upgrades (Asus or Merlin). Thanks again, Merlin, for your prompt action in resolving the conflicting boot loader sizes issue.

 

[jmantn]

I uploaded two (unsupported) builds, labeled as 376.49_6:

The AC68 cfeupd build will take care of updating the CFE, and also be ready to accept any FW > 32 MB (such as Asus's recent 378_xxxx builds). Most likely I will be including the CFE updater in future builds as well, seeing how much confusion it creates to require users to first flash with an intermediary release such as 3626. People with downgraded/modified CFE will just have to deal with it, as older CFE are not officially supported in any way.

The AC87 newqtn update replaces the previous test build, only this time with the infosvr security fixes included. This build includes the latest Quantenna driver as used by Asus's recent 378_3754 release.


Treat these as being unsupported test releases.

Files can be found in the Misc folder:

https://www.mediafire.com/folder/ftf9kjixr1a5f//Misc

I flashed the 68U version from the Misc folder and used this command from my terminal cat /dev/mtd0ro | grep bl_version and it shows version 1.0.2.0. I seen someone mention 1.0.2.1 so not sure if I messed something up or if either is good.

Gonna try and flash the ASUS 1.0.21 CFE but don't know the commands in terminal to change directory (doing this on a Mac) in the following:
"put both files on a USB stick, change to /tmp/mnt/usbstickvolumename and do "./mtd-write cfefile.bin boot" via SSH"

Edit: I think it's the same as Dos as in cd.. so gonna try that and google at this point

 

[RussellInCincinnati]

Tmobile TMAC1900 (modded with 1.0.2.0 US CFE) upgrades nicely to newer CFE

I uploaded two (unsupported) builds, labeled as 376.49_6:

The AC68 cfeupd build will take care of updating the CFE, and also be ready to accept any FW > 32 MB (such as Asus's recent 378_xxxx builds)...Treat these as being unsupported test releases.

Take the case of one of my Tmobile routers. Have changed these TMAC1900 routers to more generic RT-AC68u devices. Did this by uploading the 1.0.2.0 US CFE throught the Linux prompt with mtd-write V2. Then after resetting them, loading Merlin firmware (376.49_4) into the now-generic RT-AC68u using standard menu options.

Anyway, can report that upgraded the RT-AC68u to the 376.49_6 firmware, that RMerlin says will handle larger-than-32-megabyte CFE bootloaders in the future, has proceeded without incident.

Thanks as usual, RMerlin.

 

[RussellInCincinnati]

Tmobile TMAC1900 (modded with 1.0.2.0 US CFE) upgrades nicely to newer CFE

I uploaded two (unsupported) builds, labeled as 376.49_6:

The AC68 cfeupd build will take care of updating the CFE, and also be ready to accept any FW > 32 MB (such as Asus's recent 378_xxxx builds)...Treat these as being unsupported test releases.

Take the case of one of my Tmobile routers. Have changed these TMAC1900 routers to more generic RT-AC68u devices. Did this by uploading the 1.0.2.0 US CFE throught the Linus prompt. Then after resetting them, loading Merlin firmware (376.49_4) into the now-generic RT-AC68u using standard menu options.

Anyway, can report that upgraded the RT-AC68u to the 376.49_6 firmware, that RMerlin says will handle larger-than-32-megabyte CFE bootloaders in the future, has proceeded without incident. Hmm, is that because the "new" bootloader I just installed is 1.0.2.0 anyway? Well in any case the _6 firmware certainly hasn't hurt anything.

Thanks as usual, RMerlin.

Hey, how can we tell from the Linux prompt or whatever, that the machines can now handle >32megabyte bootloaders?

 

[jmantn]

This is because the latest firmware is now doing a device model check against the NVRAM.

To flash this latest firmare, do the following (confirmed working on my TM-AC1900):

1. Flash the Asus 1.0.21 CFE from here using the mtd-write v3 tool (put both files on a USB stick, change to /tmp/mnt/usbstickvolumename and do "./mtd-write cfefile.bin boot" via SSH).

Note: You will need to replace the secret code (WPS PIN) and MAC address in the 1.0.21 CFE using a HEX editor before flashing. They are on the sticker on the back of your router.

2. Clear your NVRAM ("mtd-erase2 nvram" via SSH or do a hard-reset).

3. Power-off the router, then power it back on after 10 seconds.

4. Connect to the router and complete the setup wizard.

5. Confirm in the "System Info" page that your router model is now RT-AC68U and not TM-AC1900, and that your CFE version is 1.0.21.

6. Upgrade to the latest Merlin firmware via the GUI as usual - no more error message.

Using a Hex editor and doing a search I found three different Mac addresses listed in the CFE. Do I change the first one or all three?

Edit: I entered in my WPS Pin and Entered in my Mac address in all three places and it doesn't seem to flash correctly as it still shows 1.0.2.0 for my 68U
2nd Edit: I didn't realize I had to rename the bin from the instructions provided....been a long day what can I say..... It's working now.

 

[scajjr]

Tried to flash 376_49_6 to my TM-AC1900 via the GUI but it still fails. Do I have to do it through recovery?

Sam

 

[jmantn]

I just posted this in the Official Firmware thread however since tonight I just converted all Routers over to Merlin's firmware I'm wondering if maybe this is a better place (both may be preferred since the issue started on official firmware)..

Originally Posted by jmantn View Post
Running latest firmware from this thread for my 87R and installed the day it came out and did two factory resets on New Year's Day and as of today experiencing intermittent issues all day for the first time.. I have charter (DHCP is normal not aggressive) and contacted charter twice where each time they confirmed no issues with Modem or neighborhood regarding speed. I have two iMac's hard wired one is used for work and seen in my logs an unholy amount of miniupnpd closed Unexpectantly (I shutdown my non work computer and cleared logs without thinking so don't have full transcript) issues. Most of the issue in the logs were resulting from the non work iMac but also a few from the work iMac.

Will edit post when I see the error again.

Issue just happened today for over three hours as of 325 est where on my 60download connection I've seening as high as 4,000MS and a DL speed of .029 it's progressively getting better after a restart of modem and router however still intermittent. Charter is convinced it's on my end and I disagreed until I seen my log firing off miniupnpd errors almost every two minutes or so.

This also affected two iPhone 6 Pluses, an iPad Air 2, and the two mentioned iMac's. I will also note about a week after latest beta came out I started experiencing the issue where 5ghz would stop and I'd have to throw my devices into airplane mode temporarily to fix but I've been dealing with that however the other issue is job impacting.

Here's the error that was spamming my logs like crazy:
Jan 11 15:16:27 miniupnpd[733]: HTTP Connection from 192.XXX.X.XXX closed unexpectedly

This is happening every 15 minutes on Work computer, non work computer is remaining offline until work shift is over.

Jan 11 15:16:27 miniupnpd[733]: HTTP Connection from 192.XXX.X.XXX closed unexpectedly
Jan 11 15:31:27 miniupnpd[733]: HTTP Connection from 192.XXX.X.XXX closed unexpectedly
Jan 11 15:46:27 miniupnpd[733]: HTTP Connection from 192.XXX.X.XXX closed unexpectedly


Router firmware: 378.3754


Edit at 1630-ish started noticeably going down again on wifi and hard wired devices:

Jan 11 15:16:27 miniupnpd[733]: HTTP Connection from 192.XXX.X.XXX closed unexpectedly
Jan 11 15:31:27 miniupnpd[733]: HTTP Connection from 192.XXX.X.XXX closed unexpectedly
Jan 11 15:46:27 miniupnpd[733]: HTTP Connection from 192.XXX.X.XXX closed unexpectedly
Jan 11 15:49:37 miniupnpd[733]: Expired NAT-PMP mapping port 37370 UDP removed
Jan 11 15:49:37 miniupnpd[733]: Expired NAT-PMP mapping port 37370 TCP removed
Jan 11 15:56:14 kernel: br0: received packet on vlan1 with own address as source address
Jan 11 15:59:57 ntp: start NTP update
Jan 11 16:01:27 miniupnpd[733]: HTTP Connection from 192.XXX.X.XXX closed unexpectedly
Jan 11 16:18:28 kernel: br0: received packet on vlan1 with own address as source address
Jan 11 16:59:59 ntp: start NTP update
Jan 11 17:00:11 ntp: start NTP update
Jan 11 17:00:41 ntp: start NTP update
Jan 11 17:00:45 ntp: start NTP update
Jan 11 17:00:48 ntp: start NTP update
Jan 11 17:00:52 ntp: start NTP update
Jan 11 17:00:59 ntp: start NTP update
Jan 11 17:01:28 miniupnpd[733]: HTTP Connection from 192.XXX.X.XXX closed unexpectedly
Jan 11 17:06:32 miniupnpd[733]: Expired NAT-PMP mapping port 16403 UDP removed
Jan 11 17:06:34 miniupnpd[733]: Expired NAT-PMP mapping port 5900 TCP removed
Jan 11 17:06:36 miniupnpd[733]: Expired NAT-PMP mapping port 4500 UDP removed

All 192.XXX.X.XXX reflects the same IP above

One final note I have three routers total, the 87R, 68U running the just released ASUS firmware and N66U with latest Merlin Release.

87R is directly connected to my Modem and the 87R connects a wired bridge to my N66U and another wired bridge to my 68U.

The work computer is connected via cat6e to my Wired N66U which is cat6e wired to my 87R.

My 87R and 68U both share the same SSID's and WPA2 pass keys but each band is on a separate channel (87R's 2.4 is on different channel then my 68U's 2.4 band and etc..)

The reasons for my layout shouldn't matter as much as how they are laid out so being detailed and also wanted to note all cabling in my setup is utilizing cat6e cable.

Just to follow up tonight I have done the following to try and fix this:

ASUS RT-AC87R:
Created a backup of my settings via:
http://forums.smallnetbuilder.com/sh...ad.php?t=19521

Then flashed Merlin's RT-AC87U_3.0.0.4_376.49_6_newqtn and erased NVRAM via "mtd-erase2 nvram", did a Factory reset via the web and by the WPS button by holding the WPS button on back of router, while turning the router off, and back on, continue to hold the wps button till the power light starts blinking. Then restored previously backed up settings

ASUS RT-N66U:
Flashed Merlin's RT-N66U_3.0.0.4_376.49_5 however since I was on _4 no Factory reset was done.

ASUS RT-AC68U:
Flashed over to Merlin's RT-AC68U_3.0.0.4_376.49_6_cfeupd

Updated CFE Bootloader from 1.0.2.0 to 1.0.2.1 using info here:
http://forums.smallnetbuilder.com/sh...087#post159087
and
http://forums.smallnetbuilder.com/sh...ad.php?t=17793

erased NVRAM and did a factory restore.


Still seeing same logs and still having intermittent internet issues and dropouts and Charter is sending someone tomorrow and still telling me it's on my end.

 

[RMerlin]

Thank you. What CFE version does the cfeupd build install? 1.0.21?

Version 1.0.2.0.

 

[RMerlin]

On my router, using 49_5.

Advanced settings/administration/system/Miscellaneous

Below authentication method.

There is a prompt for

"Enable WAN access from wifi"

Re-read it again, cause there's no such setting.

 

[RMerlin]

Hey, how can we tell from the Linux prompt or whatever, that the machines can now handle >32megabyte bootloaders?

You can probably check the size of the "linux" partition:

cat /proc/mtd

3e00000 = 64 MB, 2000000 = 32 MB. My AC68U is upgraded, so I can't tell for sure the exact value it preveiously had, but my AC66 shows 2000000. Those value are in hexadecimal.

That shows the size of the partition, but keep in mind you also need the bootloader that goes with it, not just a firmware with a 64 MB partition.

 

[GoNz0]

Version 1.0.2.0.

will this force the cfe update if we run the 1.0.1.8 cfe?

 

[burtal]

new official build

ASUS RT-AC68U Firmware version 3.0.0.4.378.3873

-Fixed infosvr security issue.
-Fixed Cross-site request forgery security issue

 

[octopus]

You can probably check the size of the "linux" partition:

cat /proc/mtd

3e00000 = 64 MB, 2000000 = 32 MB. My AC68U is upgraded, so I can't tell for sure the exact value it preveiously had, but my AC66 shows 2000000. Those value are in hexadecimal.

That shows the size of the partition, but keep in mind you also need the bootloader that goes with it, not just a firmware with a 64 MB partition.

Mine show this:

octopus@OCTOPUS:/tmp/home/root# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 "boot"
mtd1: 00180000 00020000 "nvram"
mtd2: 01e00000 00020000 "linux"
mtd3: 01c676ec 00020000 "rootfs"
mtd4: 05ec0000 00020000 "brcmnand"
mtd5: 00140000 00020000 "asus"

 

[RMerlin]

will this force the cfe update if we run the 1.0.1.8 cfe?

Yes, anything below 1.0.2.0 will be upgraded.

 

[RMerlin]

Mine show this:

That's a 32 MB partition (30 MB, I suspect the missing 2 MB is allocated to nvram and boot).

 

[octopus]

That's a 32 MB partition (30 MB, I suspect the missing 2 MB is allocated to nvram and boot).

Yepp, just tested to run 376.49_6_cfeupd and I can se larger linux but no CFE update.
After I returned to 376.49_5 and Linux is back to small size.
I did a nvram reset after but then still show old cfe1018EU.

I did not reconfigured by hand this time used my old config file, maby that was a mistake!

Octopus