What's new

[Release] Asuswrt-Merlin 384.14 (and 384.13_2) are 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.
On 384.13 2.4Ghz was simply perfect, but on a clean 384.14 (also noticed it in beta versions), 2.4Ghz on the AC88U has some kind of trouble with my S9+. This one gets an exclamation and stops accessing internet/intranet.. I have to turn off and on again to recover connectivity.

I've tried 384.13 again with same config (not using .cfg), just to check was not my phone, and on this version stays connected without any problem.

Based on my tests yesterday I did on my AX88U I can confirm that 384.14 is weaker on 2.4Ghz compared to 384.13, the reverse applies for 5 Ghz. Looks like embedded drivers have changed. I went back to 384.13 for the time being ....
 
How do you know this to be true?

Well - I did not say for certain. Was just an assumption - any other competent and firm explanation of the results I've seeing is more than welcome - especially since nothing than the FW changed ...
 
Last edited:
Well - I did not say for certain. Was just an assumption - any other competent and firm explanation of the results I've seeing is more than welcome - especially since nothing than the FW changed ...

If you go to the WebUI, Tools->Sysinfo, it will show you the wl0 Driver version.
On my AX88U, it says Aug 21 2019 16:50:02 version 17.10.25.1503.

If you can check 314.13, that would be interesting.
 
If you go to the WebUI, Tools->Sysinfo, it will show you the wl0 Driver version.
On my AX88U, it says Aug 21 2019 16:50:02 version 17.10.25.1503.

If you can check 314.13, that would be interesting.

Thanks for the info - currently on the road but will check later on. As 384.13 was released in July it is very likely the version to be different ...
 
I realize I'm not providing much helpful information here, but I've run into an issue 3x with 384.14.
After approx. 3 days of uptime on my 86u, web pages become unresponsive(won't load at all). I can log into the router and everything looks normal -- nothing at all in the log. The only thing I notice is the cpu core status dancing all over the place, but both cores always adding up to 100% total.
After a reboot, all is good again.

Hey Andy, I encountered a similar problem recently, and the culprit turned out to be asus wifi auto channel selector process. Easy fix was to change 2.4GHz wifi settings from 20/40MHz bandwidth to 20MHz, and set a channel manually. Whala, problem went away. Assuming you mainly use 5GHz, performance change is minimal.
 
The "couldn't open extension making ..." is normal and can be ignored.

Try switching the Time Machine server off and back on again under the USB Application page. Make sure that you re-select the destination disk.

There was a change in how the destination disk is named that 'broke' TM here if updating from a previous version. But once you have done the above on/off & re-select the destination disk, it functions normally with 384.14

Ah! Thank you. Yeah I also changed my hostname and this seems also to relate on the Time Machine one and I had to read the tm server on my client. (I already had re-enabled the tm-mount but did not recognize in my client the name changed...)

THank you!° :)
 
Hey Andy, I encountered a similar problem recently, and the culprit turned out to be asus wifi auto channel selector process. Easy fix was to change 2.4GHz wifi settings from 20/40MHz bandwidth to 20MHz, and set a channel manually. Whala, problem went away. Assuming you mainly use 5GHz, performance change is minimal.
Thanks for the reply.
I'm already on manual channels 20 mhz for 2.4 and 80 mhz for 5. I'm guessing it's dhcp/dns related?
 
Thanks for the reply.
I'm already on manual channels 20 mhz for 2.4 and 80 mhz for 5. I'm guessing it's dhcp/dns related?

Sounds like you need to see what's actually going on when it happens. Not hard to do, but you will need to SSH into the modem. Firstly, enable SSH (LAN Only) in your router under Admin / System. Then you can connect in with any SSH client program such as "Putty" for windows. Once you log in, the command "top" will show you exactly what process is hogging the cpu. To exit top type "q", and to exit the SSH session, type "exit".

The process you find at 100% may have nothing to do with Merlin's mod, but should lead to an answer.
 
Thanks for the reply.
I'm already on manual channels 20 mhz for 2.4 and 80 mhz for 5. I'm guessing it's dhcp/dns related?

Same issue here, my wifi just suddenly keeps dropping (as in no device can connect to the router) despite the wifi leds being on, however my wired connections work normally.
Code:
Dec 27 19:30:00 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind , status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Dec 27 19:30:00 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc , status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 27 19:30:03 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth , status: 0, reason: d11 RC reserved (0)
Dec 27 19:30:06 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth , status: 0, reason: d11 RC reserved (0)
Dec 27 19:30:11 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth , status: 0, reason: d11 RC reserved (0)
 
I’ve been hanging back on 384.13 and noting some posts about wanduck not being enabled and now Stubby being compiled against OpenSSL 1.0.2. Any significant finds in the build process?
 
Just figured that Wireless - Protected Management Frames - cannot be disabled under 384.14 for both bands on my AX88U. It is working though on my AC86U on 384.13. Any recommendation or ideas of impact?
 
384.13 works flawlessly for me, running the things I need on my RT-AC68U. I tried 384.14 and it didn’t like my NextDNS configuration. For now, I reverted back to 384.13 and will keep running it.
 
I have to go back to the 384.13 because I couldn't disabled this in latest fw. For me cause terrible lag for android mobile phones (lg v30 on latest pie update). Even then I sit next to the ruoter with link speed 866Mb/s max achievable with speedtest was 45Mb/s, so checked upstairs in my house, link speed 390Mb/s speed test 2Mb/s download and 4Mb/s uoload. Once I disable PMF in 384.13 I got full my broadband speed which is 70Mb/s no matter how far I'm away from router in my house.
 
I have to go back to the 384.13 because I couldn't disabled this in latest fw. For me cause terrible lag for android mobile phones (lg v30 on latest pie update). Even then I sit next to the ruoter with link speed 866Mb/s max achievable with speedtest was 45Mb/s, so checked upstairs in my house, link speed 390Mb/s speed test 2Mb/s download and 4Mb/s uoload. Once I disable PMF in 384.13 I got full my broadband speed which is 70Mb/s no matter how far I'm away from router in my house.

I can confirm the described behaviour on my AC86U - as soon as I enable PMF bandwidth is gone. Therefore I wanted to disable the same on the AX88U too, but as said not working under 384.14 - maybe there is a smart cheat to get it manually disabled?
 
Apparently is a bug in original asus fw base on which was done 384.14? If you flash back to 384.13 you can disable PMF.
 
Realized (since I didn't see it in the "compile from source" wiki) that I'd compiled a non-mainline .15 firmware, which misses a lot of changes, including the binary blobs... so that explains why my .15 build isn't seeing the problems I saw on the .14 Merlin build (no internet status when there is, and traffic spikes causing useless data in the traffic monitor graphs and data, and traffic statistic stops being updated after an hour or so)... so it looks like something must have crept into the sdk/binary blobs to cause these issues with my config.

Haven't had a chance to test yet but I've built a 384.14 firmware from the 384.14-mainline tag as well as one using that same tag, with the latest ac68u binary blob commit reverted to see what differences I can see in behavior.

Any status update on that testing?
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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