[Beta] Asuswrt-Merlin 384.15 Beta and 384.13_3 are now available

[Asad Ali]

The only thing left in my repair kit bag is if you can also try changing your router's IP subnet series. Change it to 192.168.1.1 from 192.168.50.1 and make sure the subnet is not larger than 255.255.255.0 because I've read in the past that Asus's Network Map list doesn't support networks larger than /24.

 

[skeal]

The only thing left in my repair kit bag is if you can also try changing your router's IP subnet series. Change it to 192.168.1.1 from 192.168.50.1 and make sure the subnet is not larger than 255.255.255.0 because I've read in the past that Asus's Network Map list doesn't support networks larger than /24.

When I change the mode of the router to access point the list works.

 

[Asad Ali]

When I change the mode of the router to access point the list works.

I get that part already and right now all I'm doing is give you ideas for trial and success and changing the router's IP is the last one in my bag lol.

 

[5stringdeath]

Because of "Wan: Use local caching DNS server as system resolver (default: No)"

I'm not seeing this option exposed in the webGui for some reason (I thought I remember seeing it before) and I know at one time it wasn't an exposed option. Any chance something in this beta could have affected it on certain routers?

 

[Butterfly Bones]

I'm not seeing this option exposed in the webGui for some reason (I thought I remember seeing it before) and I know at one time it wasn't an exposed option. Any chance something in this beta could have affected it on certain routers?

Try Tools > Other Settings > Advanced Tweaks and Hacks (near bottom)

 

[nzwayne]

Dirty upgrade of the RT-AX88U from Alpha2 to Beta1. Everything functional, including the 2x RT-AC86U's (also updated to Beta1 from Alpha2) in the backhaul AiMesh config.
Quirks: The front panel 5GHz panel light wasn't enabled & the Wireless 5GHz control channel defined as 0 (zero), the only selection was "auto" (see pic).

To recover (fix), reloaded the beta1 code again on the AX88U. Light enabled on front panel, and control channels now available to select. Previous quirks like this in my ASUS router updates, fix was to reload the firmware again.

 

[5stringdeath]

Try Tools > Other Settings > Advanced Tweaks and Hacks (near bottom)

Ah yes, Merci

 

[RMerlin]

Quirks: The front panel 5GHz panel light wasn't enabled & the Wireless 5GHz control channel defined as 0 (zero), the only selection was "auto" (see pic).

That indicates either your 5 GHz radio is currently busy scanning for DFS interference (check the status on the WIreless Log page, DFS scanning can take about a minute), or your 5 GHz radio failed to initialize (in which case you need to power cycle your router).

This is unrelated to the firmware.

 

[htismaqe]

Is there any reason to update if we're not using amtm or any of the other add-ons? Also, if I upgrade and I'm not using amtm, I'm assuming just leave it alone. It runs in the background but otherwise affects nothing?

 

[cmkelley]

Is there any reason to update if we're not using amtm or any of the other add-ons? Also, if I upgrade and I'm not using amtm, I'm assuming just leave it alone. It runs in the background but otherwise affects nothing?

Router scripts such as amtm don't "run", unless you are ssh'd into your router and run them. Some scripts, such as scribe, install daemons that do run in the background, but once the daemon is set up and running (in scribe's case, syslog-ng), and you exit the script, that script is no longer running. Amtm by itself doesn't install any daemons, only other helper scripts, so it does not "run in the background".

 

[usamamus]

@usamamus I don't see why it wouldn't?

What firmware are you currently running? Are you using amtm and/or any scripts?

I would update all the scripts (including Entware) to the latest version, safely remove the USB drive(s) you have attached to the router and then flash the firmware.

Sorry actually this is my second time so I was just checking the name RX88 (other model than mine). I have installed the previous version of merlin on my RT-AC88u. How should i upgrade the beta version now? by just extracting the compressed file and importing the .trx file in router's firmware upgrade page?

 

[nzwayne]

That indicates either your 5 GHz radio is currently busy scanning for DFS interference (check the status on the WIreless Log page, DFS scanning can take about a minute), or your 5 GHz radio failed to initialize (in which case you need to power cycle your router).

This is unrelated to the firmware.

After the first Beta1 firmware, after leaving for 15mins, then powered off/on (have learnt to power off/on after firmware updates). Left for 7hrs due to work day and still no change. After the Beta1 refresh the light came on during the firmware refresh. Prompted to manually reboot the router (didn't get this on first refresh), which I did via Power off/on, after waiting for 15mins.
What I have noticed on this beta and the two alphas, the 2.4 & 5.0GHz lights will both go out for like 0.5 second every few minutes, then back on again during operation. Perhaps have a hardware issue, pending.

 

[DarkKnight75]

Can anyone confirm the message* Disassociated because sending station is leaving & 2.4/5ghz Wifi drops have been resolved as they were prevalent in my AC86U running 384.14 & 384.12_2 even after full clean install?

 

[bac2010]

Is there any reason to update if we're not using amtm or any of the other add-ons? Also, if I upgrade and I'm not using amtm, I'm assuming just leave it alone. It runs in the background but otherwise affects nothing?

I had the same questions/thoughts since I'm running a vanilla (minimal) configuration right now with no amtm or other add-ons. I assumed that there would be no problem in upgrading to this release for those in the same situation.

 

[Butterfly Bones]

Can anyone confirm the message* Disassociated because sending station is leaving & 2.4/5ghz Wifi drops have been resolved as they were prevalent in my AC86U running 384.14 & 384.12_2 even after full clean install?

I had the same questions/thoughts since I'm running a vanilla (minimal) configuration right now with no amtm or other add-ons. I assumed that there would be no problem in upgrading to this release for those in the same situation.

Posted and answered multiple times. Asus left over debug code. RMerlin can do nothing about it as it is closed source.
https://www.snbforums.com/threads/r...13-is-now-available.57860/page-35#post-515660

 

[htismaqe]

Router scripts such as amtm don't "run", unless you are ssh'd into your router and run them. Some scripts, such as scribe, install daemons that do run in the background, but once the daemon is set up and running (in scribe's case, syslog-ng), and you exit the script, that script is no longer running. Amtm by itself doesn't install any daemons, only other helper scripts, so it does not "run in the background".

Thanks!

 

[DarkKnight75]

Posted and answered multiple times. Asus left over debug code. RMerlin can do nothing about it as it is closed source.
https://www.snbforums.com/threads/r...13-is-now-available.57860/page-35#post-515660

I'm not having issues with this since I'm on 384.13 and it's been rock solid since i went back to it. The issues are in 384.14 & _2. I understand it's out of Merlin control and it's an ASUS issue. It still didn't answer my question.

Are these message prevalent in 384.15 and are there issues with 2.4 & 5ghz dropping?

 

[Maverickcdn]

I understand it's out of Merlin control and it's an ASUS issue. It still didn't answer my question.

The WLCEVENTD messages are out of his control

But the 'disassociated because sending station is leaving' was new for me in 384.14+. I havent tried 384.15 yet

I found a solution by selecting a channel above 64, not sure why but lower 5ghz channels were giving me this message with my Samsung Android devices constantly, I havent done a whole lot of testing but since moving to 157 and 20/40/80 width these disassociated messages have stopped
https://www.ekahau.com/blog/2019/04/18/channel-planning-best-practices-for-better-wi-fi/

My guess is it has to do with channel overlap (channel selection and width in MHZ) and local interference

 

[Butterfly Bones]

Are these message prevalent in 384.15 and are there issues with 2.4 & 5ghz dropping?

I'm on 384.15 beta 1 and they are there since Asus has not removed them. I use Scribe / syslog-ng, so scrape them out of the webgui syslog to their own log - net result, they are gone for me unless I go looking for them.

I have never had devices dropping from 2.4 or 5 ghz on my network. I see reports of those who do. The experts here make recommendations on wireless settings that will resolve them, but many want the "marketing magic promises" more than stability with slight compromises and do not make those changes.

 

[DarkKnight75]

The WLCEVENTD messages are out of his control

But the 'disassociated because sending station is leaving' was new for me in 384.14+. I havent tried 384.15 yet

I found a solution by selecting a channel above 64, not sure why but lower 5ghz channels were giving me this message with my Samsung Android devices constantly, I havent done a whole lot of testing but since moving to 157 and 20/40/80 width these disassociated messages have stopped
https://www.ekahau.com/blog/2019/04/18/channel-planning-best-practices-for-better-wi-fi/

My guess is it has to do with channel overlap (channel selection and width in MHZ) and local interference

Interesting, because i actually changed my 5ghz from 149 80 to 157 and 20/40/80 when i was on both 384.14 and 384.12_2 and performance still suffered as stated above. Since i have gone back to 384.13 (with some tweasks) messages have mostly dissapeared and no 5ghz drop on my Note 9. Well wait it out and see before upgrading to 384.15 to insure no major issues.