What's new

[Release 384/NG] Asuswrt-Merlin 384.5 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Tried Rescue Mode (slow flashing Power light) and the Firmware Restoration tool...about 38% into the upload of the trx file, get a Connection between computer and router issue message. Router reboots to previous 384.5 beta2 fw. Thanks again.

Did you try with a different copy of firmware file? There are two sources from where you can download them Sourceforge and OneDrive, try the one you didn't yet tried. Also try with a firmware download on a different machine.
 
Tried from different computers; trx file successfully uploaded to another AC68U. Very intriguing that this router's firmware does not seem to be updated by using any of the above suggestions. Thanks
 
Tried from different computers; trx file successfully uploaded to another AC68U. Very intriguing that this router's firmware does not seem to be updated by using any of the above suggestions. Thanks

Do a factory reset using the hardware buttons TWICE and see if that changes anything.
 
Are you sure your RT-AC68U is not a rebranded T-Mobile? That router is not supported with RMerlin's firmware, nor the official firmware.
 
I'm presently on version 3.80.69_2 on a RT-AC1900P. I like to keep things current, but I have apparently missed a couple of versions. It seems like updating to 3.84 is potentially dicey at the moment. An internet outage or having to buy a new router would be a day-wrecker for most, but I especially don't want to screw things up with my wife working from home a couple of days a week.

I know these things can be model specific. So, I would love some feedback on what the best version to be on at the moment is, and whether the 3.84 build is problematic on the RT-AC1900P specifically. Thanks.

Edit: I should note that I use the router for WiFi. I need both bands to work reliably. I use an EdgeRouter-X as my primary internet gateway/router. The RT-AC1900P is used as an access point.
 
I'm presently on version 3.80.69_2 on a RT-AC1900P. I like to keep things current, but I have apparently missed a couple of versions. It seems like updating to 3.84 is potentially dicey at the moment. An internet outage or having to buy a new router would be a day-wrecker for most, but I especially don't want to screw things up with my wife working from home a couple of days a week.

I know these things can be model specific. So, I would love some feedback on what the best version to be on at the moment is, and whether the 3.84 build is problematic on the RT-AC1900P specifically. Thanks.

Edit: I should note that I use the router for WiFi. I need both bands to work reliably. I use an EdgeRouter-X as my primary internet gateway/router. The RT-AC1900P is used as an access point.

I'm not an ac1900 expert or user, but if you're happy with the ways things are working at the moment, I would do nothing at all.

Since you're using the ac1900 just as a access point I don't think an upgrade will give you much benefit either, since these fw updates are first and foremost security enchancements for boxes running in router mode.

So for the moment I would have kept my Egderouter updated, and let the ac1900 be as it is... But that's just my opinion.
 
Tried from different computers; trx file successfully uploaded to another AC68U. Very intriguing that this router's firmware does not seem to be updated by using any of the above suggestions. Thanks
Then you must be using a T-Mobile TM-AC1900 that has been converted over to an AC68U. Either that or you have a hardware issue with that particular AC68U. If you have a T-Mobile unit then you are on your own as no support is offered here. They are very troublesome.
 
I'm presently on version 3.80.69_2 on a RT-AC1900P. I like to keep things current, but I have apparently missed a couple of versions. It seems like updating to 3.84 is potentially dicey at the moment. An internet outage or having to buy a new router would be a day-wrecker for most, but I especially don't want to screw things up with my wife working from home a couple of days a week.

I know these things can be model specific. So, I would love some feedback on what the best version to be on at the moment is, and whether the 3.84 build is problematic on the RT-AC1900P specifically. Thanks.

Edit: I should note that I use the router for WiFi. I need both bands to work reliably. I use an EdgeRouter-X as my primary internet gateway/router. The RT-AC1900P is used as an access point.
Then best you can do is last 380.70 from merlin, stable and updated and no problems at all.
 
Thanks again. Tried it from another Mac and still no change. Was able to upgrade another AC68U to 384.5 with no issues. Not sure if there's a brute force method to upgrade the FW.
For me, normally unable to update due to memory issue. Try temporary disable memory hungry module like aiprotection, dnscrypt-proxy, take out usb hdd/drive.

Do a clear cache with following command right before you flash the firmware
sync; echo 3 > /proc/sys/vm/drop_caches
 
Tried from different computers; trx file successfully uploaded to another AC68U. Very intriguing that this router's firmware does not seem to be updated by using any of the above suggestions. Thanks
try in recovery mode with a very old firmware, maybe it can upload only smaller trx below 32MB, newer are too large.
Older 3.0.0.4.378 should be fine either stock or merlin: dlcdnet.asus.com/pub/ASUS/wireless/RT-AC68U/FW_RT_AC68U_30043783873.zip
Or even smaller 376: dlcdnet.asus.com/pub/ASUS/wireless/RT-AC68U/FW_RT_AC68U_30043763626.zip
Then you should be able do update again what I can remember from other posts.

At least worth a try!
 
Last edited:
RT-AC88U switched from 384.4beta1 to 384.5 today.

For those messing with VLANs: BEWARE of the RoboSwitch configuration! The "CPU" port went from 8 (380.x), to 7 (384.4beta1), back to 8 (384.5).

@skeal: about you TQoS<->VPN issue (as the developer of the TQoS patch):
I don't see how to fix that issue without needing significant additions to the code base (incl. the UI).
"Blindly" including the tun* interface(s) in the TQoS (iptables) classifying rules may not be what people expect, at least anymore that the current mis-classification issue.
Should all VPN traffic be considered one type of traffic ? Should the tunneled traffic answer to the same classification rules than the existing upload/download configuration ? Should this be split by VPN (when people have more than one VPN active) ? etc.
In order to cover the issue properly, we'd need additional (UI+NVRAM) configuration settings, allowing users a finer-grained control of their QoS<->VPN configuration.
Also, without hands-on testing, I have no idea how QoS implemented on the tun* interfaces would interact with the existing eth0/br0 QoS configuration. It may be as simple as adding a 'iptables -t mangle -I POSTROUTING -o tunX -j QOS' (you could try it in your firewall-start script). But maybe it will just not work or break the entire setup (again, I can't tell without hands-on testing, which I wouldn't be able to do since I don't use VPN).
 
RT-AC88U switched from 384.4beta1 to 384.5 today.

For those messing with VLANs: BEWARE of the RoboSwitch configuration! The "CPU" port went from 8 (380.x), to 7 (384.4beta1), back to 8 (384.5).

@skeal: about you TQoS<->VPN issue (as the developer of the TQoS patch):
I don't see how to fix that issue without needing significant additions to the code base (incl. the UI).
"Blindly" including the tun* interface(s) in the TQoS (iptables) classifying rules may not be what people expect, at least anymore that the current mis-classification issue.
Should all VPN traffic be considered one type of traffic ? Should the tunneled traffic answer to the same classification rules than the existing upload/download configuration ? Should this be split by VPN (when people have more than one VPN active) ? etc.
In order to cover the issue properly, we'd need additional (UI+NVRAM) configuration settings, allowing users a finer-grained control of their QoS<->VPN configuration.
Also, without hands-on testing, I have no idea how QoS implemented on the tun* interfaces would interact with the existing eth0/br0 QoS configuration. It may be as simple as adding a 'iptables -t mangle -I POSTROUTING -o tunX -j QOS' (you could try it in your firewall-start script). But maybe it will just not work or break the entire setup (again, I can't tell without hands-on testing, which I wouldn't be able to do since I don't use VPN).
Thank you for your time looking into this! I tried the command you gave me in the previous post and it doesn't work.
Code:
iptables v1.4.15: Couldn't load target `QOS':No such file or directory
 
Tried Rescue Mode (slow flashing Power light) and the Firmware Restoration tool...about 38% into the upload of the trx file, get a Connection between computer and router issue message. Router reboots to previous 384.5 beta2 fw. Thanks again.

I got the same problem until i manually configured the IP address and mask as instructed información Asus web-site
 
Hola Merlin, as always thanks for your hard work.

I'm wondering what are the chances of a _1 version getting released.
 
I got the same problem until i manually configured the IP address and mask as instructed información Asus web-site
Thanks again for all suggestions. My solution was to winscp the trx file over to router and use mtd-write2 to update the firmware. Will see during the next upgrade.
 
Hola Merlin, as always thanks for your hard work.

I'm wondering what are the chances of a _1 version getting released.

Doubt it, unless there's a security release required before I'm ready for the next release.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top