[Release] Asuswrt-Merlin 384.15 (and 384.13_4) are now available

[skeal]

Isn't the HW version indicated on the bottom of your router?

My router was replaced or re-manufactured, so the sticker you are referring to is over layed with a new sticker, without the version information.

 

[sanchez13]

My router was replaced or re-manufactured, so the sticker you are referring to is over layed with a new sticker, without the version information.

if you have RT-AX88U try:

nvram show |grep HwVer

S.

 

[skeal]

if you have RT-AX88U try:

nvram show |grep HwVer

S.

Thanks that worked!

 

[HorseCalledHorse]

My AC86U used to have the problem when rebooting, that it would hang and all of the LEDs go out (separate thread on this to suggest many others also experience this). I no longer seem to have this issue, after many reboots.

Be great if the firmware has sorted out this issue for the AC86U. I haven't had to reboot yet, but it'll be nice if my router doesn't turn itself off when I do

 

[wiz]

I know it is out of Merlins control, but ever since I upgraded my AC5300 all wireless devices keep loosing connection on a regular base. Syslog is flooded with disasoc and assoc messages. I've reverted back to 14_2 for now and all seems back to normal. I did tinker with the wireless settings, but I could not get it working like it should. I'll stick to 14_2 for now.

 

[telUK]

Be great if the firmware has sorted out this issue for the AC86U. I haven't had to reboot yet, but it'll be nice if my router doesn't turn itself off when I do

It still happens, I had it happen yesterday after updating from 384.13 to 384.15 after a reset I went to reboot and it hanged on GUI complete message, all lights on router were off.

 

[Sanna1967]

I know it is out of Merlins control, but ever since I upgraded my AC5300 all wireless devices keep loosing connection on a regular base. Syslog is flooded with disasoc and assoc messages. I've reverted back to 14_2 for now and all seems back to normal. I did tinker with the wireless settings, but I could not get it working like it should. I'll stick to 14_2 for now.

There are no differences with Wireless drivers between 14_2 and .15
Try to place the 2.4 and 5ghz band on fixed channels.

 

[Spyderboy]

I'm having the 2.4ghz connection dropping issues on my RT-AC3100. Can someone share how to manually force the channels in NVRAM?

 

[SteveyB]

Just wanted to say big thanks for all the work on the firmware.

Some feedback on recent builds as I noticed a few others reporting WiFi dropouts on recent firmware. I use the AC86U and have around 30 active devices on WiFi at a time (All types of devices u can probably think of and constantly being used by all the family for streaming, gaming, browsing etc). I separate 2.4/5 out and have been running a factory reset firmware 384.15 with no changes to default except WiFi config.

For me 384.13 was rock solid. Went weeks without a single blip on any device.

384.14 & 384.15 I see daily WiFi dropouts. Sometimes can go a day without an issue but have seen Chromecasts, PS4, Google Home and laptop all get dropped of WiFi. all these devices are a combination of 2.4ghz and 5ghz. This experience seems similar to other reports on the forum.

I have just changed to dedicated channels on both 2.4 and 5 to see if that makes any difference. I may have to go back to 384.13 if it doesn't.

To help out, is there anything to look out for in the logs ?

So have been running on locked channels on 2.4Ghz(9) and 5Ghz(100) and so far so good on 384.15. I have put 100Gb through the router - streaming, gaming, browsing, automation devices with no dropouts so far.

I too noticed that 384.14 & 384.15 put loads of of Disassoc, Deauth_ind, Auth & Assoc messages in the log which i didn't notice on 384.13. Will keep an eye on things over this weekend.

 

[wiz]

There are no differences with Wireless drivers between 14_2 and .15
Try to place the 2.4 and 5ghz band on fixed channels.

then you loose the smart connect feature as that does not allow you to choose channels. Like I said, I reverted back to 14_2 and all is well again. Could be there's no difference between the two versions but still 15 don't play nice here.

 

[neil0311]

I'm getting the same error too after a dirty upgrade.

kernel: CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set

Can someone please interpret for me what this error means? Sorry if I missed another post on it but doing a search turns up nothing but people asking what this means.

 

[Mutzli]

Can someone please interpret for me what this error means? Sorry if I missed another post on it but doing a search turns up nothing but people asking what this means.

Plenty of posts about it: https://www.snbforums.com/search/1291232/?q=wl_cfg80211_change_station&o=date&c[node]=42
Merlin says you can ignore this.

 

[RMerlin]

Hello,

After upgrade to 384.15 - VPN Shows connected , but no IPs present and VPN IPs are not on VPN - regular provider IP (kill switch not working) probably it thinks its on VPN

Will revert to 384.14 now and report


View attachment 21302

Works for me. Make sure you don't block access to STUN servers from Google or stunprotocol.org (they will be tried one after another).

The fact you also show a local IP of 0.0.0.0 would indicate that your tunnel failed to properly connect.

 

[neil0311]

Plenty of posts about it: https://www.snbforums.com/search/1291232/?q=wl_cfg80211_change_station&o=date&c[node]=42
Merlin says you can ignore this.

Thanks for the response but you do realize your search results were me and a few others asking the question.

If Merlin said to ignore it, then I will.

 

[XIII]

It's probably a user error rather than a bug in this release, so maybe someone can tell me what I do wrong?

When I ssh from my Mac (with $TERM=xterm-256color) I get $TERM=xterm-256color on a Raspberry Pi (as expected), but $TERM=xterm on my router (unexpected).

Pi:

❯ echo $TERM
xterm-256color
❯ ssh pi
Linux pi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l
pi@pi ~ > echo $TERM
xterm-256color

Router:

❯ echo $TERM
xterm-256color
❯ ssh ac86
ASUSWRT-Merlin RT-AC86U 384.15_0 Sat Feb  8 18:41:28 UTC 2020
admin@ac86u /tmp/home/root > echo $TERM
xterm

(I can set it manually on the router, so it seems supported)

EDIT: same behaviour when using Blink or Prompt on iOS

 

[Pirivan]

Dirty flash to 384.15 from 384.13_0 on RT-AC88U (have not yet fully reset router/settings). Terrible wireless performance (2.4Ghz in particular) with reduced range, streaming video constantly stopping or unable to playback at high resolutions (requiring a disconnect/reconnect to the wireless network or restart of streaming application). Lots of messages in the logs as others have noted:

Feb 16 11:17:04 syslog: WLCEVENTD wlceventd_proc_event(401): eth2: Disassoc MAC_ADDRESS, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 16 11:17:44 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)
Feb 16 11:17:44 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)
Feb 16 11:18:00 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind MAC_ADDRESS, status: 0, reason: Class 3 frame received from nonassociated station (7)
Feb 16 11:18:02 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)
Feb 16 11:18:02 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)

Similar to the thread here, https://www.snbforums.com/threads/3...cause-sending-station-is-leaving.61555/page-3 to get the wireless performance issues to go away (not the system log messages, not worried if they are just causing log chattiness) I had to statically set 2.4Ghz onto 20Mhz channel 11 (it was previously set to 20/40Mhz, auto channel select) and 5Ghz onto 80Mhz, channel 157 (it was also previously set to 20/40/80Mhz, auto channel select).

Anyone else on 384.15 with the RT-AC88U experience this issue?

 

[Phil Outram]

Dirty flash to 384.15 from 384.13_0 on RT-AC88U (have not yet fully reset router/settings). Terrible wireless performance (2.4Ghz in particular) with reduced range, streaming video constantly stopping or unable to playback at high resolutions (requiring a disconnect/reconnect to the wireless network or restart of streaming application). Lots of messages in the logs as others have noted:

Feb 16 11:17:04 syslog: WLCEVENTD wlceventd_proc_event(401): eth2: Disassoc MAC_ADDRESS, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 16 11:17:44 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)
Feb 16 11:17:44 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)
Feb 16 11:18:00 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind MAC_ADDRESS, status: 0, reason: Class 3 frame received from nonassociated station (7)
Feb 16 11:18:02 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)
Feb 16 11:18:02 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)

Similar to the thread here, https://www.snbforums.com/threads/3...cause-sending-station-is-leaving.61555/page-3 to get the wireless performance issues to go away (not the system log messages, not worried if they are just causing log chattiness) I had to statically set 2.4Ghz onto 20Mhz channel 11 (it was previously set to 20/40Mhz, auto channel select) and 5Ghz onto 80Mhz, channel 157 (it was also previously set to 20/40/80Mhz, auto channel select).

Anyone else on 384.15 with the RT-AC88U experience this issue?

Probably the same reason as the AX88U with this version, only a single antenna out of the 4 is now transmitting the 2.4ghz radio. On the AX88U it's only the antenna closest to switch port 8 that still transmits it. Try removing the aerial from this point and see if your 2.4ghz signal all but disappears.

 

[Pirivan]

Probably the same reason as the AX88U with this version, only a single antenna out of the 4 is now transmitting the 2.4ghz radio. On the AX88U it's only the antenna closest to switch port 8 that still transmits it. Try removing the aerial from this point and see if your 2.4ghz signal all but disappears.

Very interesting suggestion (much appreciated), tried removing the aerial and 2.4Ghz appeared to be about the same but perhaps it's another antenna with the RT-AC88U. I think I may just go back to 384.13_0 to avoid the issues I appear to have created.

 

[jackiechun]

Very interesting suggestion (much appreciated), tried removing the aerial and 2.4Ghz appeared to be about the same but perhaps it's another antenna with the RT-AC88U. I think I may just go back to 384.13_0 to avoid the issues I appear to have created.

I'm relatively new to the Asus world and these forums (I come from OpenWRT, which I run on my own home network) but I've done a lot of reading and from personal experience setting up my parents' home with an AC86U as the main and AC66U_B1 as a node, 384.13 is the most stable for me.

If you go through the Asus Merlin changelog you'll note that there are lines such as "UPDATED: RT-AC88U, RT-AC3100 to GPL 384_81351": https://www.asuswrt-merlin.net/changelog-382

GPL includes closed-source wireless drivers that RMerlin isn't able to modify. 384.12 and 384.13 use GPL 384_45717 for most router models. If you wander over to https://www.snbforums.com/forums/asuswrt-official.51/ you'll read that 45717 seems to be the most stable firmware. Of course this is anecdotal as other users report amazing uptimes with newer firmware: https://www.snbforums.com/threads/a...on-3-0-0-4-384_81351.60206/page-8#post-549258

So I've set up my parent's home as stated in my signature:

Main: Asus RT-AC86U | Asuswrt-Merlin 384.13 + Diversion 4.1.9
Node: Asus RT-AC66U B1 | Asus Stock 3.0.0.4.384.45717

(RMerlin recommended stock firmware for nodes and that they should be on the same codebase for compatibility reasons, which is why I went with 45717 for the node and 384.13 on the main, with Diversion set up for ad-blocking goodness).

If it were for my own home I would flash 384.15 right away on it (heck, even alpha builds). I've done M&M to try out different builds, my AC86U just likes 384.13 the most. The issue I run into on other versions are the Internet dropping and having to reboot the router for it to work again about once every day, not sure if this is related to DNS settings or something else. But it is rock-solid on 384.13.

RMerlin's work on this firmware is amazing and I will be throwing him some money soon.

 

[DarkKnight75]

Dirty flash to 384.15 from 384.13_0 on RT-AC88U (have not yet fully reset router/settings). Terrible wireless performance (2.4Ghz in particular) with reduced range, streaming video constantly stopping or unable to playback at high resolutions (requiring a disconnect/reconnect to the wireless network or restart of streaming application). Lots of messages in the logs as others have noted:

Feb 16 11:17:04 syslog: WLCEVENTD wlceventd_proc_event(401): eth2: Disassoc MAC_ADDRESS, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 16 11:17:44 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)
Feb 16 11:17:44 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)
Feb 16 11:18:00 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind MAC_ADDRESS, status: 0, reason: Class 3 frame received from nonassociated station (7)
Feb 16 11:18:02 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)
Feb 16 11:18:02 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc MAC_ADDRESS, status: 0, reason: d11 RC reserved (0)

Similar to the thread here, https://www.snbforums.com/threads/3...cause-sending-station-is-leaving.61555/page-3 to get the wireless performance issues to go away (not the system log messages, not worried if they are just causing log chattiness) I had to statically set 2.4Ghz onto 20Mhz channel 11 (it was previously set to 20/40Mhz, auto channel select) and 5Ghz onto 80Mhz, channel 157 (it was also previously set to 20/40/80Mhz, auto channel select).

Anyone else on 384.15 with the RT-AC88U experience this issue?

384.14 and 384.14.2 exhibited same behavior on my ac86u..so back to 384.12 and all is well again. Amazing that Asus would allow this crap firmware to be released without proper QC.

This is probably my last Asus router.