What's new

Release Asuswrt-Merlin 386.1 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!

Status
Not open for further replies.
I upgraded from 384.18 to 386.1, I skipped 384.19 entirely.

I done a reset as well.

Have you got or tried setting 2.4ghz to 20mhz only, and turning off all the universal beamforming stuff?
It's always 20mhz. I've always run the advanced settings at default.. it always worked just fine. The thing is it's not like it's always doing that every time. It's only after a few hours . And it lasts minutes .... And when it's happening every clients in 2.4ghz is affected. . Which is weird. If it's beam forming atleast this should just affect the IoT items. Not all devices on 2.4ghz.. weird bug
 
Has the software update notification always worked on Merlin? Today was the first time I noticed it actually alert me.
It has worked for me on the 386 releases. Never saw it work prior to that either.
 
Are you sure you downloaded the Correct Version of firmware?

yes. I put the router in rescue mode and updated to the official ASUS Version 9.0.0.4.386.41994 beta for the RT-AC88U.

After doing so I still can’t flash 386.1_2. I can flash the official ASUS firmware though.

Edit:

I can't flash 386.1 either and that was working. Something is really weird. I seem to only be able to flash the same firmware that's already installed.
 
Last edited:
I powered off my RT-AC88U, removed the USB flash drive, powered the router back on and am still getting an error flashing. The error is that the firmware is not compatible.
The error appears after about 15 seconds of "Please wait, Applying Settings...".



I even tried doing a factory reset and initialize again and then immediately tried to update to 386.1_2 and got the same error.

Again I'm not sure what else to do. The only thing unusual I did recently was perform a factory reset and initialized all config and set everything up by hand.


Edit:

I tried to update to the official ASUS Version 9.0.0.4.386.41994 and am getting the same error message.
Turn off
a. Adaptive QOS
b. AIProtection
c. Widraw from Privacy
d. Reboot

If the following steps did not help use ASUS restore utility.
 
yes. I put the router in rescue mode and updated to the official ASUS Version 9.0.0.4.386.41994 beta for the RT-AC88U.

After doing so I still can’t flash 386.1_2. I can flash the official ASUS firmware though.

Edit:

I can't flash 386.1 either and that was working. Something is really weird. I seem to only be able to flash the same firmware that's already installed.
RT-AC88U_386.1_2 hash is:
SHA256: 3464460D95950F01BB5BCEB0825D04BA087C477768E29736283F9F806BD0CEA6

Do you have same ?
 
It's always 20mhz. I've always run the advanced settings at default.. it always worked just fine. The thing is it's not like it's always doing that every time. It's only after a few hours . And it lasts minutes .... And when it's happening every clients in 2.4ghz is affected. . Which is weird. If it's beam forming atleast this should just affect the IoT items. Not all devices on 2.4ghz.. weird bug
Yeah strange, hope you get it sorted.
 
Turn off
a. Adaptive QOS
b. AIProtection
c. Widraw from Privacy
d. Reboot

If the following steps did not help use ASUS restore utility.

None of those were enabled.

At this point something very odd is happening. I can't use the UI to upgrade to any 386.x based firmware. I did use the rescue tool to install the latest official ASUS firmware for my RT-AC88U, but even after doing so I can't upgrade to either 386.1 or 386.1_2, even though I had previously upgraded to 386.1

I was able to flash 384.19 from the UI. After I did that I could upgrade to 386.1_2 via the firmware.

So I can go from 384.19 to any 386 code base firmware and I can go from any 386 to 384 firmware, but not from 386 to 386, including ASUS ones (unless I use the rescue tool) I have no idea why.
 
It's always 20mhz. I've always run the advanced settings at default.. it always worked just fine. The thing is it's not like it's always doing that every time. It's only after a few hours . And it lasts minutes .... And when it's happening every clients in 2.4ghz is affected. . Which is weird. If it's beam forming atleast this should just affect the IoT items. Not all devices on 2.4ghz.. weird bug
So I’m not crazy.

I’m having the exact same problem. Upgraded last weekend and have been having an issue with my guest wireless ever since

2.4GHz guest Wi-Fi network #2. Network seems to drop all clients and refuses to let anyone join every few hours. Requires a router reboot to fix.

ive tried everything I can think of.

Hard reset
Reconfigure from scratch.
Fixed to 20MHz and a specific channel
Turned off beam forming and MUMIMO
Turned off AiProtect
 
Dirty upgrade to 386.1_2 on my RT-AC88U. If I hadn't done it myself I wouldn't have known it had happened. Smooth as Tennessee whiskey!
 
Dirty upgrade to 386.1_2 on my RT-AC88U. If I hadn't done it myself I wouldn't have known it had happened. Smooth as Tennessee whiskey!

Are there different revisions of the RT-AC88U?

It seems like mine doesn’t have enough memory to verify a 386 version is valid when it’s already running a 386 version. I can only downgrade to 384 and then upgrade to 386. This includes with ASUS’s firmware.

I even did a factory reset set with initialization prior to trying to upgrade, so everything should have been off and nothing was plugged into the USB.
 
Are there different revisions of the RT-AC88U?

It seems like mine doesn’t have enough memory to verify a 386 version is valid when it’s already running a 386 version. I can only downgrade to 384 and then upgrade to 386. This includes with ASUS’s firmware.

I even did a factory reset set with initialization prior to trying to upgrade, so everything should have been off and nothing was plugged into the USB.
That's a good question, and there often are different hardware versions of routers from what I understand. I'm guessing the version (or revision) number of the router is on some plate or sticker underneath it somewhere, but I can't get there easily with my setup and, even if I did, with my eyes I wouldn't be able to read it. Is there some software way of discovering a router's version or revision number?

And would a hardware revision even make a difference in the context we're talking about?
 
Last edited:
And would a hardware revision even make a difference in the context we're talking about?

I’m not sure, but there must be some reason your AC88U could upgrade and mine couldn’t, even after clearing NVRAM and JFFS.

I have 377 MB RAM free, which seems like it should be good enough.

Rather than continue the discussion here, I created a new thread.
 
Last edited:
DNSOmatic was broken in alpha1 on the RT-AC86U but fixed on the AX86U - reported this in the alpha thread today so be interesting if its broken still.

Just applied to one AX86U (386.1_2) locally and was fine, tried a remote AX86U that had alpha1 v2 and the firmware update stays on "applying settings" dialogue. It never actually applies, have rebooted remote AX86U and tried again on a different machine (both have fast cable broadband) and still stuck. In the past been fine doing remote upgrades (albeit alpha 1 v1 did a strange partial reset to network wizard but kept all the settings).

EDIT: OK the AX86U upgraded remotely is fine now. There were no internet connection issues, but the flaming thing just sat on Applying Settings, even after rebooting it several times, trying another up to date browser, and even different computer. Have no idea why it wouldn't take the upgrade this afternoon, but a few hours later it took it first time!!!

DNSOmatic IS fixed on AX86U and AC86U and will register. The first reboot of the Ac86U router didn't update the DNSomatic for some hours, but did anther remote reboot and it registered that time. Can only think it was a DNSomatic issue refusing update after the reboot when the update was completed. Another reboot and all is well again on that front.
 
Last edited:
So I’m not crazy.

I’m having the exact same problem. Upgraded last weekend and have been having an issue with my guest wireless ever since

2.4GHz guest Wi-Fi network #2. Network seems to drop all clients and refuses to let anyone join every few hours. Requires a router reboot to fix.

ive tried everything I can think of.

Hard reset
Reconfigure from scratch.
Fixed to 20MHz and a specific channel
Turned off beam forming and MUMIMO
Turned off AiProtect
And it's not even just GN2 . It happens on GN3 too!! And when it does that thing. It'll just freeze the clients on main 2.4ghz radio. It won't be able to reach the internet or local network. Usually it calms down after 10 mins or more. Sometimes it doesn't. And to fix it well u need to reboot . Or in ssh just do "radio off 0" then do "radio on 0" . It'll restart the 2.4ghz and it'll work again.

Although I haven't tried running 2.4ghz without guest networks enabled. Since i need my IoT devices to be connected to the internet.. so I don't know if it's just a guest network problem or the whole 2.4ghz . It's been stable here just fine on 384.19 ... Just for info, what's your bootloader ver? Mine is 1.0.1.0 . New late 2020 unit i guess.. what's yours?
 
Just flashed 386.1_2 AX58U. No problems flashing did a factory reset and reconfigured all working as expected so far. :)
 
386.1_2 breaks OpenVPN completely for me on the RT-AX88U. Downgrading it to 386.1 restored it with the same config. I didn't see anything in the changelog that would be an obvious culprit.

To attempt to troubleshoot, I tried to enable OVPN server 2, which I don't use, in its default configuration to see if that worked, but it also failed to start with the same errors in the logs.

Here are the startup errors in the log for 386.1_2 (same erros for ovpn-server1):
Code:
Feb 13 10:23:27 ovpn-server2[12157]: --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Feb 13 10:23:27 ovpn-server2[12157]: Options error: --dh fails with 'dh.pem': No such file or directory (errno=2)
Feb 13 10:23:27 ovpn-server2[12157]: Options error: Please correct these errors.
Feb 13 10:23:27 ovpn-server2[12157]: Use --help for more information.
Feb 13 10:23:27 openvpn: Starting OpenVPN server 2 failed!

Here is a successful startup of OpenVPN on 386.1 after downgrade:
Code:
Feb 13 10:33:35 ovpn-server1[2432]: --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Feb 13 10:33:35 ovpn-server1[2432]: OpenVPN 2.5.0 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 30 2021
Feb 13 10:33:35 ovpn-server1[2432]: library versions: OpenSSL 1.1.1i  8 Dec 2020, LZO 2.08
Feb 13 10:33:36 ovpn-server1[2444]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Feb 13 10:33:36 ovpn-server1[2444]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Feb 13 10:33:36 ovpn-server1[2444]: Diffie-Hellman initialized with 2048 bit key
Feb 13 10:33:36 ovpn-server1[2444]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Feb 13 10:33:36 ovpn-server1[2444]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Feb 13 10:33:36 ovpn-server1[2444]: TUN/TAP device tun21 opened
Feb 13 10:33:36 ovpn-server1[2444]: TUN/TAP TX queue length set to 1000
Feb 13 10:33:36 ovpn-server1[2444]: /usr/sbin/ip link set dev tun21 up mtu 1500
Feb 13 10:33:36 ovpn-server1[2444]: /usr/sbin/ip link set dev tun21 up
Feb 13 10:33:36 ovpn-server1[2444]: /usr/sbin/ip addr add dev tun21 10.8.0.1/24
Feb 13 10:33:36 ovpn-server1[2444]: ovpn-up 1 server tun21 1500 1621 10.8.0.1 255.255.255.0 init
Feb 13 10:33:36 ovpn-server1[2444]: /usr/sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Feb 13 10:33:36 ovpn-server1[2444]: ERROR: Linux route add command failed: external program exited with error status: 2
Feb 13 10:33:36 ovpn-server1[2444]: Could not determine IPv4/IPv6 protocol. Using AF_INET
Feb 13 10:33:36 ovpn-server1[2444]: Socket Buffers: R=[524288->524288] S=[524288->524288]
Feb 13 10:33:36 ovpn-server1[2444]: UDPv4 link local (bound): [AF_INET][undef]:61194
Feb 13 10:33:36 ovpn-server1[2444]: UDPv4 link remote: [AF_UNSPEC]
Feb 13 10:33:36 ovpn-server1[2444]: MULTI: multi_init called, r=256 v=256
Feb 13 10:33:36 ovpn-server1[2444]: IFCONFIG POOL IPv4: base=10.8.0.2 size=252
Feb 13 10:33:36 ovpn-server1[2444]: Initialization Sequence Completed

Is anyone else having this issue? Any suggestions to fix it other than wait for the next release?
 
Run this and then upgrade to 386.1 and reset after the upgrade. Do it before @L&LD wakes up.
I want to dispel this commonly held notion that @L&LD EVER sleeps in the first place. :D

BTW: updated to 386.1_2. Smooth sailing so far.
 
Last edited:
You are manually opening required ports, UPNP does this or tries to automatically for you, but UPNP is not something you want to leave on. Also when done playing you should turn open nat off again, so as not to advertise open ports when not gaming.
I believe this is outdated advice as stated previously here. The firmware version of UPNP is secure and it is unnecessary to turn it on and off. Of course, it's up to each individual how they want to deal with it.
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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