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

[cc biggs]

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.

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 pulled my antennae and didn't see a difference either.

However, I am also having the same 2.4 weak signal/disconnects in .15 as others have mentioned. I've done the M&M about 10 times, I did the power cycle kabuki dance several times, used ASUS default settings, set things manually in many different configurations, even with 5 mhz off - still made no difference. With the AX88 sitting next to my laptops I was getting between 38% and 60% signal strength (using wifiinfofiew and air rader for mac), when I rolled back to .14 I get 100% (did this about 10 times also).

so I'll be rocking the .14 for a while.

 

[Allan Marcus]

Hello. I'm on a Mac.
When I download RT-AC68U_384.15_0.zip from SourceForge, I don't get the right files. The MD5 matches, but the firmware file after unzipping is:
RT-AC86U_384.15_0_cferom_ubi.w

When I download from OneDrive (mirror 2), I get the correct .trx file.

 

[Sanna1967]

RT-AC86U_384.15_0_cferom_ubi.w

According to your signature, you downloaded the wrong model

 

[JaimeZX]

So to everyone who has done this so far - will we have to re-install the other scripts, or will everything just work even though AMTM is part of the code now? Thanks!!

 

[L&LD]

@JaimeZX, it should just work.

 

[Phil Outram]

I pulled my antennae and didn't see a difference either.

However, I am also having the same 2.4 weak signal/disconnects in .15 as others have mentioned. I've done the M&M about 10 times, I did the power cycle kabuki dance several times, used ASUS default settings, set things manually in many different configurations, even with 5 mhz off - still made no difference. With the AX88 sitting next to my laptops I was getting between 38% and 60% signal strength (using wifiinfofiew and air rader for mac), when I rolled back to .14 I get 100% (did this about 10 times also).

so I'll be rocking the .14 for a while.

Is yours the AX88U and if so did you pull the correct antenna? It's the one closest to switch port 8 (rear left). I've verified this fault on 3 seperate AX88U routers, one of which had a full reset. This only effects the 2.4ghz band.

 

[Allan Marcus]

According to your signature, you downloaded the wrong model

Doh!

let me tell you, getting old sucks.

 

[oso2276]

Upgraded RT-AC68U. All working fine

Enviado desde mi moto g(8) plus mediante Tapatalk

 

[Dabombber]

Two things I have noticed with upgrading from 384.14 to .15:

• Reboots are much faster (placebo?)
• 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.

This was a 'dirty' upgrade also. I'm certainly happy with that outcome!

I don't think it's placebo. Before I'd quite often get events skipped by the rc_service on a reboot, after upgrading I've yet to see one skipped, so the startup stuff must have seen some love.

For the new addons stuff, rather than namespacing settings, wouldn't it make more sense to have per addon settings (/jffs/addons/my_addon/custom_settings.txt for example) and load just your own stuff. i.e.

var custom_settings = <% get_custom_settings("my_addon"); %>;

Bit of an edge case but it'd be possible for an addon to get two pages if a previous one was removed, maybe the md5s should be iterated through completely before returning the page number.

I also noticed a bug which prevents page updates for system logs if "*/" is in one of the lines, caused by /www/ajax_log_data.asp. It might be possible to fix by escaping the log, but that'd require a custom nvram_dump function. It might be easiest to dump <% nvram_dump("syslog.log","syslog.sh"); %> to a page (or just symlink the log(s) to /www) and read it using XMLHttpRequests.

 

[AntonK]

Somehow, pulling our antennas off to successfully complete firmware updates seems a little odd.

 

[ika]

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.

I also have this since a few fw versions earlier, but (for me) it only happens with devices on the guest wifi (happens continuously 24/7).

Feb 17 06:22:34 wlceventd: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind XX:XX:XX:XX:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 17 06:22:34 wlceventd: WLCEVENTD wlceventd_proc_event(401): wl0.1: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 17 06:22:34 wlceventd: WLCEVENTD wlceventd_proc_event(420): wl0.1: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Feb 17 06:22:34 wlceventd: WLCEVENTD wlceventd_proc_event(449): wl0.1: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Feb 17 06:25:56 wlceventd: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind XX:XX:XX:XX:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 17 06:25:56 wlceventd: WLCEVENTD wlceventd_proc_event(401): wl0.1: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 17 06:25:56 wlceventd: WLCEVENTD wlceventd_proc_event(420): wl0.1: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Feb 17 06:25:56 wlceventd: WLCEVENTD wlceventd_proc_event(449): wl0.1: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Feb 17 06:28:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind XX:XX:XX:XX:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 17 06:28:30 wlceventd: WLCEVENTD wlceventd_proc_event(401): wl0.1: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 17 06:28:30 wlceventd: WLCEVENTD wlceventd_proc_event(420): wl0.1: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Feb 17 06:28:30 wlceventd: WLCEVENTD wlceventd_proc_event(420): wl0.1: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Feb 17 06:28:30 wlceventd: WLCEVENTD wlceventd_proc_event(449): wl0.1: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Feb 17 06:48:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind XX:XX:XX:XX:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 17 06:48:30 wlceventd: WLCEVENTD wlceventd_proc_event(401): wl0.1: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 17 06:48:30 wlceventd: WLCEVENTD wlceventd_proc_event(420): wl0.1: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Feb 17 06:48:30 wlceventd: WLCEVENTD wlceventd_proc_event(449): wl0.1: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)

Devices recover themselves on their own. It's annoying but hardly enough for me to downgrade, since these are (MAC filtered) IOT devices which are completely fine with minor disconnections.

It's just a bug in the fw and you can always go back to the fw version you found to be stable for you, if you are so concerned.
Hope it will get sorted out soon tho.

 

[Chris_J]

Are you using YazFi? I also see this happen whenever YazFi starts/restarts. It kicks off all clients and forces them to re-authenticate as part of the script. I assumed this was normal behaviour.

 

[SteveyB]

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.

So after a weekend of intense use I have had no issues experienced,so far, on 384.15 on the RT-AC86U once I locked the WiFI channels.

 

[Phil Outram]

Somehow, pulling our antennas off to successfully complete firmware updates seems a little odd.

This isn't what was stated. You don't need to pull the antenna off to perform the update. Pulling the antenna off that is closest to switch port 8 is to verify that after the update only a single antenna now transmits the 2.4ghz radio. In the case of the AX88U before this update all 4 antennas transmitted the signal, now only a single one does, which can be verified by removing this antenna and watching the signal vanish completely (or almost completely). This is why the 2.4ghz signal strength and performance of the AX88U on this build is poor.

 

[RMerlin]

For the new addons stuff, rather than namespacing settings, wouldn't it make more sense to have per addon settings (/jffs/addons/my_addon/custom_settings.txt for example) and load just your own stuff. i.e.

Having one single file makes it much more easier for the web server to handle, as it will be one single hardcoded file to process. Dealing with a user-specified filename would be difficult, and would also introduce more issues related to the size limit imposed by the server buffers.

 

[nzwayne]

384.15 is the first firmware level on the RT-AX88U that I've been able to get my Garmin Index Smart Scale to establish a 2.4GHz wireless connection too. Was unable with earlier levels of 384.13 & 384.14 even with the assistance of Garmin support (they even shipped a replacement scale to try). I had to use an older RT-N56U instead.
384.15 & it's earlier Alpha/Betas rock solid with my 35 odd clients at home, in a AiMesh backhaul with 2x RT-AC86U's. Thanks Merlin & the others who assist in the Merlin project!

 

[XIII]

I can no longer access my router over VPN via <name>.asuscomm.com (or router.<mydomainname>.<tld>) over VPN, but 192.168.1.1 does work over VPN.

What would cause domain names to fail suddenly?

 

[Mrk26]

Have you got error in log related to ssl certificate failed to update?

 

[gotdade]

I keep having the mysterious client isolation on ASUSWRT-Merlin RT-AC3200 384.13_4

As you can see my network is configured using Tri-Band Smart Connect.

On 5G-1 is my Raspberry Pi "Pi-Hole" DNS server.

The Asus Router is configured to send the IP of this RPi as the primary DNS for DHCP clients, so they benefit from the Pi-Hole filtering.

However, randomly in time but eventually for sure, the RPi becomes isolated by the router. From the point of view of the RPi client, it is still connected and there is no change. From the RPi I can "ping" the router. From the router, I can "ping" the RPi client. However, it suddenly behaves as if client isolation was enabled. No other clients can talk to it.

If I change any parameter in the Asus router and force a reset of the network, then everything is back to normal.

Feb 19 20:11:19 rc_service: httpds 296:notify_rc restart_wireless
Feb 19 20:11:19 custom_script: Running /jffs/scripts/service-event (args: restart wireless)

What can I do about this? It first started with 384.13_2 which I needed due to the Let's Encrypt fix. With 384.13 everything was solid.

 

[mlippold]

I keep having the mysterious client isolation on ASUSWRT-Merlin RT-AC3200 384.13_4
What can I do about this? It first started with 384.13_2 which I needed due to the Let's Encrypt fix. With 384.13 everything was solid.

If you/others can't figure it out you may want to just consider connecting it via Ethernet. You'd benefit by it always being available during wireless restarts, channel changes, lower latency (not by much, but it is something) etc...

I can't say enough good things about setting up Unbound on your Pihole as well - I just recently added it to both of mine and it is great.

If you are interested used a mix of these two urls to set it up on mine:
https://docs.pi-hole.net/guides/unbound/

Some tweaks (I did all but the RAM based logging since it didn't work on my flavor of OS):
https://www.reddit.com/r/pihole/comments/dezyvy/into_the_pihole_you_should_go_8_months_later/

and then to benchmark: https://github.com/cleanbrowsing/dnsperftest