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.
So after updating my 87 I'm still seeing 384.13_1 not 384.13_2. The file name I have is RT-AC87U_384.13_2

Because you haven't updated to 384.13_2. :)

Remove all USB devices from the router. Reboot and wait at least 10 minutes for the router to settle. Flash the version you want to use.
 
Dirty from beta 3 on an Ax88. 'Connect to DNS server automatically' had magically returned to yes, and I was seeing ISP DNS servers. Everything else - including wifi power levels - seem fine and stable.
 
After protocol level changes, your client computers must be rebooted to force them to re-negotiate the supported protocols. Windows does not do this at access time, only at first connection time.

Merlin, thanks for the response. Still having issues with 384.14.

With 384.13/final using Samba in SMBv2 mode only, I have no issues accessing either USB drive shares.

As soon as I upgrade to 384.14, they become inaccessible. Even after rebooting the router, computer, unmounting and re-mounting the USB drives, etc., it still doesn’t work. As soon as I flash back to 384.13 it works like normal.

In 384.14, if I force to SMBv1 + SMBv2 mode and reboot the router, computer, etc., Samba still doesn’t work unless using SMBv2. If I force Win10 to install/run on SMBv1 (after rebooting of course), v1 works.

I had to go back to 384.13 on my RT-AX88U for the time being.
 
Merlin, thanks for the response. Still having issues with 384.14.

With 384.13/final using Samba in SMBv2 mode only, I have no issues accessing either USB drive shares.

As soon as I upgrade to 384.14, they become inaccessible. Even after rebooting the router, computer, unmounting and re-mounting the USB drives, etc., it still doesn’t work. As soon as I flash back to 384.13 it works like normal.

In 384.14, if I force to SMBv1 + SMBv2 mode and reboot the router, computer, etc., Samba still doesn’t work unless using SMBv2. If I force Win10 to install/run on SMBv1 (after rebooting of course), v1 works.

I had to go back to 384.13 on my RT-AX88U for the time being.
Did you update the router’s computer name after upgrading to 384.14? Mine had reset to the default (e.g. RT-AC68U-ABCD).
 
Update reset the hostname for some reason. Had to change it and recommit.

Seems to have reset my DHCP range as well.
 
Last edited:
Did a dirty flash on my AC68U. Everything is working fine. Except, the Internet status is shown as disconnected in the Network Map. Turned off Network Monitoring by both DNS Query and Ping as suggested elsewhere.

Any help regarding this?

@RMerlin can you please confirm whether it's a bug or a problem from my end?
 

Yes, I attempted that initially despite the changelog saying excluding the RT-AX88U (my model).

I reflashed the RT-AX88U from 384.13 to 384.14 again tonight and changed the "Host Name" on LAN->LAN IP, applied settings, rebooted the computer, no luck. I even tried changing the "Device Name" under USB Applications->(Samba), applied settings, rebooted the computer, no luck. In Windows Explorer->Network->Computers, I can see RT-AX88U's Samba device; however, when I click on it, I get "Cannot Access." Flashed back to 384.13, and things are once again functional.

Alternatively, I flashed my RT-AC68U from 384.13 to 384.14. Now, on this model (in AP Mode), I don't have any USB devices attached to it. However, I did find that, after flashing, the changelog's guidance is correct where "Host Name" was renamed to RT-AC68-ABCD, which I corrected and applied the changes. Here's the difference, if I enable Samba sharing on it (SMBv2, applying changes and restarting my computer), I can see the 68U's Samba Device name in Windows Explorer->Network->Computers and actually access the empty folder... unlike my RT-AX88U above.

Any other suggestions? Not sure if something changed regarding Samba between 384.13 and 384.14 specifically for the RT-AX88U? I never used the .14 betas.
 
Last edited:
The 384.13_2 release mostly focuses on fixes backported from 384.14. Since the 382 and 384 codebases are now too different, compiling these two older models with newer GPL code is not possible unless obtaining special binary components from Asus, which I was not able to do for 384.14.

Hi there, i just bought AC87U /manifactured 2018/ and after a week, i gave a Merlin a try - very smooth experience, even better than the original firmware.
Will there be a possibility in the future for AC87U to be upgraded to 384 codebase, or it wont be possible obtaining these binary components, which can lead to abandon this great router :)

@RMerlin just out of curiosity, what is your router set up :)
thank you
 
Last edited:
I stopped here. Commits from 384.15 very good.
 
Hi there, i just bought AC87U /manifactured 2018/ and after a week, i gave a Merlin a try - very smooth experience, even better than the original firmware.
Will there be a possibility in the future for AC87U to be upgraded to 384 codebase, or it wont be possible obtaining these binary components, which can lead to abandon this great router :)

Thank you for confirming that Asus were still making AC87U's in 2018, hopefully we can expect few more years of support from them, though it probably won't get the 384 codebase due to it having a separate Quantenna chipset for the 5 Ghz radio.

Hopefully Asus can continue providing RMerlin with the binary blobs needed to support it. And not being on the 384 codebase so far has been a good thing as the router has been more stable than the 384 models without missing any of the features you need.

Welcome to the forum! Take a look at some of the popular threads for ways to expand the functionality of your router.
 
So you are lucky :) - the re-added feature just saved you from severe problems in near future by this notification. Do check stored variables in NVRAM and try to free the some NVRAM.
Hello FTC, can you tell me how can check and free some NVRAM??
 
I've 2 RT-AC68U in mesh configuration and I've recently discovered that if I activate AI-protection all the ports I set will disappear and if I try to add them I don't see them in the list. For now I disable AI-protection, but can anyone tell me what I can try?
 
Hello! Can i do a dirty update from 384.13 to 384.14 on my RT-AC66U B1 or i must do factory reset?
 
You can, but always better to save your config in case there are problems.
If there are you can go back and load saved config, or do a factory reset an hope it will solve your issues.
 
RT-AC86U here. Dirty upgrade from beta-3 to 384.14 a day ago. This morning i found my router had lost connection with cable modem. No GUI as well. Both 2.4G and 5G are ok, but no internet access. Restarted it and it went back to normal. but nothing in the log. Very weird.
 
Hello FTC, can you tell me how can check and free some NVRAM??
Hi, the idea is to simplify your environment and do a full reset and re-add the configuration manually. This will get rid of all NVRAM wasted while trying things that you finally chose not to use and temporary and no longer used NVRAM values, such as device assignments names NVRAM space used for devices that no longer exist and so on.

Failing above suggestions, you can clear up many NVRAM variables that are set to blank plus the temporary one holding client names by issuing from a ssh session:

nvram unset client_info_tmp
for line in `nvram show | grep =$ `; do var=${line%*=}; nvram unset $var; done
nvram commit

The following line will show a sorted list of NVRAM contents by size and may give you some ideas on what else to clear off :

nvram show | awk '{print length(), $0 | "sort -n -r"}' | cut -d"=" -f 1 | head -n 20

Note however :

1. I had fully tested this as a no harming in my previous rt-ac3200. Now in my RT-AX88 I do not need to free NVRAM so I have not tested it (use at your own risk)
2. Remember that when you reboot some of the gained space will be lost again (not all though), so at best this is a bypass solution, not a definitive one
 
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