[Release] Asuswrt-Merlin 384.14 (and 384.13_2) are now available

[podkaracz]

I was interested in using the Merlin firmware because of this very issue on my RT-AC5300. It started after I upgraded to the stock firmware 3.0.0.4.384.81219 that was released on the Asus site dated 2019/11/07. I would look at my Network Map and it would show one device yet have a superscript 2 or 3 on the icon. If I hovered over it, it indicated there were X amount of clients connecting through it. If Merlin 384.14 is based on that version of Asus firmware, I would stay stay away from it. My devices were constantly dropping off the network, poor signal strength, packet loss and even the WAN connection bugging out. I tried a factory reset and it looked like things were going ok until it started dropping clients again. I'm going to wait until Asus fixes this in their release before going with Merlin though. Just to be safe.

So far after downgrading to 3.0.0.4.384.45717, the log has been practically empty. With version 3.0.0.4.384.81219, it would have been full of those events already.

True

 

[Dion]

When Wireless mac address filtering is on for either 2.4ghz or 5ghz.. The site survey doesn't seem to work.. Anyone else see this bug?

 

[RMerlin]

When Wireless mac address filtering is on for either 2.4ghz or 5ghz.. The site survey doesn't seem to work.. Anyone else see this bug?

It's not a bug, it's a known limitation.

 

[Hammer73]

You should be using UPS to begin with

That is a reasonable idea in most cases. And I do have an UPS on all the computers, media room, whole house surge and brown-out filtering etc. Unfortunately when we're in a power out situation also my ISP is down too. I have a 'private leased WIFI' to the home. (Rural and the only viable option for a fraction of most forum readers' available bandwidth at a multiple of the price ). Those things aside... I would expect a router (3 working together) to reboot/recover on power restoration. Note that my observed aimesh issue is happening without a power outage involved.

 

[Hammer73]

I have different devices (RT-AC5300) but the Alpha that RMerlin has released is absolutely stabile. It solved a lot of small things that I encountered with 384.14. (Normally I keep on of my routers on the previous version but this Alpha version was a no brainer to be hesitant and I installed it after a while on the second as well. Both routers are faster, the signal strength is back and my LAN WAN performance is significantly better. A quick and dirty update should do the trick....

Just installed the .15 alpha version (dirty on all three nodes; 1 main, 2 mesh) Installed is: Diversion, Skynet, FreshJR QOS, scribe, ntpMerlin, scMerlin, uiDivStats, uiScribe

FWIW This is my log right before the AMAS_NODE_EVENT errors happen (sorry for image vs text. Cloudflare is blocking post because of 'code')

Since upgrading (clean) from version .13 the network won't recover till I
- switch all routers off
- boot main router and let it fully settle
- add nodes one by one

I'm up. All is working fine now but only after above steps. Suggestions are welcome!

 

[goRt]

Same FAILURE to connect to the internet with 384.14_2

I'm able to confirm that the 4g modem does get established but it takes upwards of a minute whereas previous releases were~10 seconds.

Thanks

 

[sanke1]

BTW @RMerlin
Your latest 384.14 firmware disables 5Ghz radio on RT-AX88U hardware revision A1.1 model. On A1 model, it’s fine.
5Ghz gets disabled after 2 mins after boot on both my A1.1 models. I double checked.

 

[a5m]

I've read through this entire thread and what I'm gathering is wait for 384.15?

 

[RMerlin]

I've read through this entire thread and what I'm gathering is wait for 384.15?

Nothing wrong with 384.14_2. 384.15 is mostly aimed at implementing a new addons API, and an upgrade to GPL 7756 for the RT-AX88U. And like with every single GPL update, some people claim that 7756 is completely broken for them, and some claim that 7756 resolved every single problems they had with the previous version.

Personally, both version have been working equally fine for my own RT-AX88U.

 

[CriticJay]

I've read through this entire thread and what I'm gathering is wait for 384.15?

Absolutely not. Firmware version 384.14_2 is working perfectly fine for me, on my AC86U with ~20 devices (mixed 2.4G/5G/wired) in my household.

 

[a5m]

Nothing wrong with 384.14_2. 384.15 is mostly aimed at implementing a new addons API, and an upgrade to GPL 7756 for the RT-AX88U. And like with every single GPL update, some people claim that 7756 is completely broken for them, and some claim that 7756 resolved every single problems they had with the previous version.

Personally, both version have been working equally fine for my own RT-AX88U.

Absolutely not. Firmware version 384.14_2 is working perfectly fine for me, on my AC86U with ~20 devices (mixed 2.4G/5G/wired) in my household.

Thanks for the vote of confidence guys. To be fair there was an equal number of people with and without issues, but of course, it's the former that had me concerned. May give it a shot on my RT-AC86U.

 

[Mrk26]

BTW @RMerlin
Your latest 384.14 firmware disables 5Ghz radio on RT-AX88U hardware revision A1.1 model. On A1 model, it’s fine.
5Ghz gets disabled after 2 mins after boot on both my A1.1 models. I double checked.

Didn't happened on mine A1.1 EU version when I tried 384.14.

 

[indark]

BTW @RMerlin
Your latest 384.14 firmware disables 5Ghz radio on RT-AX88U hardware revision A1.1 model. On A1 model, it’s fine.
5Ghz gets disabled after 2 mins after boot on both my A1.1 models. I double checked.

try setting the channel manually
that's the only way for me to be able to see 5Ghz channel even when I had exact same channel both auto and manual.

 

[RMerlin]

Thanks for the vote of confidence guys. To be fair there was an equal number of people with and without issues, but of course

The majority of complains were aimed at the internet monitoring issue that was resolved in 384.14_2.

 

[tarzan2000]

Hello!
What is it and how to get rid of it from the event log?

Jan 9 11:24:58 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 70:8B:CD:C8:52:90, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 9 11:25:01 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 70:8B:CD:C8:52:90, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 9 11:25:04 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 70:8B:CD:C8:52:90, status: 0, reason: d11 RC reserved (0)
Jan 9 11:25:04 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc 70:8B:CD:C8:52:90, status: 0, reason: d11 RC reserved (0)


AC86U + 384.14_2

PS: On version 14, there really was some kind of strange floating problem with Internet monitoring. I had active ping on google. So sometimes the router ceases to be allowed on the Internet, connections with the provider are established. A full reboot helped. As soon as I turn off Internet monitoring - everything is OK, well, or return to version 13. Paradox.

 

[Daniel G]

Unfortunately I had a number of problems with .14 and .14_2 on AC86U (with 2 AC68U in Mesh) - examples: Mesh stopped working, reboot of the 2 AC68U made them invisible, reboot of AC86U removed all settings. Even after proper factory reset of all devices and upgrade to.14_2 on all of them no stable Mesh connectivity.

I am back now on .13 for the hub and 3.0.0.4.384.81351 for the 2 AC68U - system is now as great and stable as before.

 

[goggleeyes]

Hello!
What is it and how to get rid of it from the event log?

Jan 9 11:24:58 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 70:8B:CD:C8:52:90, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 9 11:25:01 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 70:8B:CD:C8:52:90, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 9 11:25:04 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 70:8B:CD:C8:52:90, status: 0, reason: d11 RC reserved (0)
Jan 9 11:25:04 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc 70:8B:CD:C8:52:90, status: 0, reason: d11 RC reserved (0)


AC86U + 384.14_2

PS: On version 14, there really was some kind of strange floating problem with Internet monitoring. I had active ping on google. So sometimes the router ceases to be allowed on the Internet, connections with the provider are established. A full reboot helped. As soon as I turn off Internet monitoring - everything is OK, well, or return to version 13. Paradox.

I have the same messages in my log

 

[AndreiV]

Hello!
What is it and how to get rid of it from the event log?

Jan 9 11:24:58 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 70:8B:CD:C8:52:90, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

Use the forum search, it has been asked and answered too many times.

It's nothing to worry about , caused by ASUS changing logging levels.

 

[Petrica]

While trying to block IOT devices on home network found that some of the troubles connecting for the wifi clients might be due to blocking internet access feature.

Blocking internet access for too many devices in Time Scheduling or in Network Map can actually lead to blocking internet access for all devices: although hard limit is at 16 devices, starting from 10 devices blocked, most clients lose internet access and at 14 they're all disconnected from internet (clients can still connect to router and router itself has internet access but there is no internet access for any client, either wired or wireless).

 

[Butterfly Bones]

Hello!
What is it and how to get rid of it from the event log?

Jan 9 11:24:58 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 70:8B:CD:C8:52:90, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 9 11:25:01 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 70:8B:CD:C8:52:90, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 9 11:25:04 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 70:8B:CD:C8:52:90, status: 0, reason: d11 RC reserved (0)
Jan 9 11:25:04 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc 70:8B:CD:C8:52:90, status: 0, reason: d11 RC reserved (0)


AC86U + 384.14_2

PS: On version 14, there really was some kind of strange floating problem with Internet monitoring. I had active ping on google. So sometimes the router ceases to be allowed on the Internet, connections with the provider are established. A full reboot helped. As soon as I turn off Internet monitoring - everything is OK, well, or return to version 13. Paradox.

Here is the wlceventd debug info from RMerlin, started in 384.13 from Asus. Second paragraph of reply.
https://www.snbforums.com/threads/r...13-is-now-available.57860/page-35#post-515660