What's new

[Release 384/NG] Asuswrt-Merlin 384.5 is 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!

I had a RT-66U that was rock solid (was using 380.69_2) but due to merlin no longer supporting it I went ahead and got a RT-88U as an upgrade.
As soon as it arrived I put merlin's latest firmware (384.4_2) and have had chronic issues with 2.4ghz having to be rebooted every few days.
I've tried changing several options that have been suggest but nothing works.
In effort to see if its just a bug introduced in the newer code I want to downgrade from 384.5 to 380.70. Is there anything I should know before doing this / is it even supported?
 
I had a RT-66U that was rock solid (was using 380.69_2) but due to merlin no longer supporting it I went ahead and got a RT-88U as an upgrade.
As soon as it arrived I put merlin's latest firmware (384.4_2) and have had chronic issues with 2.4ghz having to be rebooted every few days.
I've tried changing several options that have been suggest but nothing works.
In effort to see if its just a bug introduced in the newer code I want to downgrade from 384.5 to 380.70. Is there anything I should know before doing this / is it even supported?

Yes, 380.70 runs very nice on ac88u.
 
I had a RT-66U that was rock solid (was using 380.69_2) but due to merlin no longer supporting it I went ahead and got a RT-88U as an upgrade.
As soon as it arrived I put merlin's latest firmware (384.4_2) and have had chronic issues with 2.4ghz having to be rebooted every few days.
I've tried changing several options that have been suggest but nothing works.
In effort to see if its just a bug introduced in the newer code I want to downgrade from 384.5 to 380.70. Is there anything I should know before doing this / is it even supported?

looks like as I was posting this from last nights left opened tab, someone else has had the same question and thought. flash then reset.
 
I have noticed the httpd gets pretty funct quite often too. I couldn't get it to respond at all today after only 4 hours up-time and did a "service restart_httpd" to restart it. After that it's snappy again for a while.
 
You can flash it over 380.67 directly but after that a complete factory reset with Intialize option and setting everything from scratch without using backups is recommended.


Sent from my iPhone using Tapatalk
Thanks! I will do it!
 
Quick update: Upgraded 384.2_2 to 384.5_0, no issues, works fine.

BTW, uptime on 384.2_2 was from twos days after it released to yesterday. :D
 
Last edited:
1.) NVRAM now have maximum lengths enforced... means some very long lists of settings might no longer be possible on 384.xx. What's "very long?"

It varies from setting to setting (which is one reason why it's so hard for John to properly handle this in his script). For some settings the limit is 1000 characters, others it's 2500.

2.) Removed Firewall setting... firewall rules now auto created but "postconf" can override. Does that mean the entire GUI Firewall setting & 5 tabs of sub-settings have been removed or...?

This is only related to OpenVPN, which had a firewall setting that was removed, it has nothing to do with the actual router firewall itself.

3.) Removed option to respond to DNS queries - enabling the option to Push DNS will also handle it? Does that mean enabling Push DNS will respond to DNS?

Yes. The two settings were effectively merged together.

I use Gibson Research to regularly scan for a few select vulnerabilities as well as nmap & one other i cant remember off the top of my head. Would that identify if the unfixed CVE's & bug fixes had been exploited?

No. That scan is mostly useless on an Asus router, because by default none of the services it would scan are exposed to the WAN.
 
Installed 384.5 a few days ago,

While it works fine, my AC86-U now reboots by itself every day or so for unknown reason. My uptime with the previous firmware was 20 days +.

I have this constant error showing up in my logs.

Any input on how to fix this ?

Code:
May 21 10:51:39 Mastiff: init
May 21 10:52:16 kernel: pgd = ffffffc011d98000
May 21 10:52:16 kernel: [36223a2e] *pgd=00000000147d3003, *pud=00000000147d3003, *pmd=0000000000000000
May 21 10:52:16 kernel: CPU: 0 PID: 4293 Comm: mastiff Tainted: P           O    4.1.27 #2
May 21 10:52:16 kernel: Hardware name: Broadcom-v8A (DT)
May 21 10:52:16 kernel: task: ffffffc0192b00c0 ti: ffffffc011c98000 task.ti: ffffffc011c98000
May 21 10:52:16 kernel: PC is at 0xf6d6b218
May 21 10:52:16 kernel: LR is at 0x0
May 21 10:52:16 kernel: pc : [<00000000f6d6b218>] lr : [<0000000000000000>] pstate: 60010010
May 21 10:52:16 kernel: sp : 00000000ffc574a0
May 21 10:52:16 kernel: x12: 00000000ffc574c4
May 21 10:52:16 kernel: x11: 00000000f6e387a8 x10: 00000000f6e387d8
May 21 10:52:16 kernel: x9 : 0000000036223a22 x8 : 0000000000000018
May 21 10:52:16 kernel: x7 : 0000000000222820 x6 : 0000000000222808
May 21 10:52:16 kernel: x5 : 0000000000000070 x4 : 0000000000222798
May 21 10:52:16 kernel: x3 : 00000000f6007d22 x2 : 0000000000000131
May 21 10:52:16 kernel: x1 : 0000000000000000 x0 : 0000000000000000
May 21 10:52:40 rc_service: watchdog 854:notify_rc stop_aae
May 21 10:52:40 rc_service: watchdog 854:notify_rc start_mastiff
May 21 10:52:40 rc_service: waitting "stop_aae" via watchdog ...
May 21 10:52:40 NAT_Tunnel: AAE Service is stopped
May 21 10:52:40 NAT_Tunnel: AAE Service is stopped
May 21 10:52:40 NAT_Tunnel: AAE Service is stopped
May 21 10:52:40 AAE: AAE Service is started
May 21 10:52:40 Mastiff: init
May 21 10:53:17 kernel: pgd = ffffffc011c0f000
May 21 10:53:17 kernel: [36223a2e] *pgd=000000001444c003, *pud=000000001444c003, *pmd=0000000000000000
May 21 10:53:17 kernel: CPU: 0 PID: 4351 Comm: mastiff Tainted: P           O    4.1.27 #2
May 21 10:53:17 kernel: Hardware name: Broadcom-v8A (DT)
May 21 10:53:17 kernel: task: ffffffc0170ba180 ti: ffffffc012f8c000 task.ti: ffffffc012f8c000
May 21 10:53:17 kernel: PC is at 0xf7138218
May 21 10:53:17 kernel: LR is at 0x0
May 21 10:53:17 kernel: pc : [<00000000f7138218>] lr : [<0000000000000000>] pstate: 60010010
May 21 10:53:17 kernel: sp : 00000000ff8dcba0
May 21 10:53:17 kernel: x12: 00000000ff8dcbc4
May 21 10:53:17 kernel: x11: 00000000f72057a8 x10: 00000000f72057d8
May 21 10:53:17 kernel: x9 : 0000000036223a22 x8 : 0000000000000010
May 21 10:53:17 kernel: x7 : 000000000030fa68 x6 : 000000000030fa58
May 21 10:53:17 kernel: x5 : 0000000000000070 x4 : 000000000030f9e8
May 21 10:53:17 kernel: x3 : 00000000f7007d22 x2 : 00000000000000e9
May 21 10:53:17 kernel: x1 : 0000000000000000 x0 : 0000000000000000
May 21 10:53:40 rc_service: watchdog 854:notify_rc stop_aae
May 21 10:53:40 rc_service: watchdog 854:notify_rc start_mastiff
May 21 10:53:40 rc_service: waitting "stop_aae" via watchdog ...
May 21 10:53:40 NAT_Tunnel: AAE Service is stopped
May 21 10:53:40 NAT_Tunnel: AAE Service is stopped
May 21 10:53:41 NAT_Tunnel: AAE Service is stopped
May 21 10:53:41 AAE: AAE Service is started
May 21 10:53:41 Mastiff: init
May 21 10:54:17 kernel: pgd = ffffffc012f2b000
May 21 10:54:17 kernel: [36223a2e] *pgd=0000000011e5a003, *pud=0000000011e5a003, *pmd=0000000000000000
May 21 10:54:17 kernel: CPU: 1 PID: 4401 Comm: mastiff Tainted: P           O    4.1.27 #2
May 21 10:54:17 kernel: Hardware name: Broadcom-v8A (DT)
May 21 10:54:17 kernel: task: ffffffc01e022b80 ti: ffffffc011cac000 task.ti: ffffffc011cac000
May 21 10:54:17 kernel: PC is at 0xf6c7e218
May 21 10:54:17 kernel: LR is at 0x0
May 21 10:54:17 kernel: pc : [<00000000f6c7e218>] lr : [<0000000000000000>] pstate: 60010010
May 21 10:54:17 kernel: sp : 00000000ffcd0f10
May 21 10:54:17 kernel: x12: 00000000ffcd0f34
May 21 10:54:17 kernel: x11: 00000000f6d4b7a8 x10: 00000000f6d4b7d8
May 21 10:54:17 kernel: x9 : 0000000036223a22 x8 : 0000000000000018
May 21 10:54:17 kernel: x7 : 000000000017b820 x6 : 000000000017b808
May 21 10:54:17 kernel: x5 : 0000000000000070 x4 : 000000000017b798
May 21 10:54:17 kernel: x3 : 00000000f6007d22 x2 : 0000000000000131
May 21 10:54:17 kernel: x1 : 0000000000000000 x0 : 0000000000000000
May 21 10:54:42 rc_service: watchdog 854:notify_rc stop_aae
May 21 10:54:42 rc_service: watchdog 854:notify_rc start_mastiff
May 21 10:54:42 rc_service: waitting "stop_aae" via watchdog ...
May 21 10:54:42 NAT_Tunnel: AAE Service is stopped
May 21 10:54:42 NAT_Tunnel: AAE Service is stopped
May 21 10:54:43 NAT_Tunnel: AAE Service is stopped
May 21 10:54:43 AAE: AAE Service is started
May 21 10:54:43 Mastiff: init

Crash occurs in the closed-source mastiff service. I know it's tied to Asus's NAT tunnelling/AiHome service, but beyond that I have no further information. No idea what it does exactly.

Might be an incompatibility caused by using components from different GPL releases, something I'm forced to do due to how Asus releases their firmware nowadays. Not much I can do about it, short of no longer providing updates for all supported models, and only supporting 1-2 models per release.

it's one of those various little things that are gradually killing this project.
 
In effort to see if its just a bug introduced in the newer code I want to downgrade from 384.5 to 380.70. Is there anything I should know before doing this / is it even supported?

Good luck. I tried this tonight on my RT-3200 to troubleshoot some wireless issues I was having and ultimately ended up re-flashing 384.5.

I was able to flash 380.70 with the ASUS restore tool... but after getting my settings in there and giving the router a final reboot it would get stuck in a bootloop. I suspect this is related to the nvram size change on specific router. In my limited reading on the matter, a factory reset was supposed to fix this issue but in my case it didn't. I tried it three or four times and ultimately got stuck in a bootloop each time.

After an hour and some change, I just got frustrated and put 384.5 back on here.
 
384.5 working perfectly on my RT AC5300
 
Good luck. I tried this tonight on my RT-3200 to troubleshoot some wireless issues I was having and ultimately ended up re-flashing 384.5.

I was able to flash 380.70 with the ASUS restore tool... but after getting my settings in there and giving the router a final reboot it would get stuck in a bootloop. I suspect this is related to the nvram size change on specific router. In my limited reading on the matter, a factory reset was supposed to fix this issue but in my case it didn't. I tried it three or four times and ultimately got stuck in a bootloop each time.

After an hour and some change, I just got frustrated and put 384.5 back on here.

I think I read somewhere that for a or some specific model, it's not possible to go back once you've upgraded to 384.x. I do not remember which model this apply to, but certain that this is not the case with AC88U. Try a forum search regarding this matter.

I'm not sure either if it would help to enable Administration->System->format jffs on next boot, in order to reset when you go back to a fw without the Initialize button.

Also remember to clear browser cache between 380 and 384
 
Last edited:
I loaded 384.5 on my brand new 86U on day 1 of release and I seem to be getting reboots every couple hours. I've been looking at it all week and haven't been able to figure it out at all. Is there any way to troubleshoot this?

Should I go back a release and see what happens? Ideas? About the only thing I am doing on it is running VPN Client & Server. Nothing else has been enabled such as Ai, or QOS. Just pretty plain jane.

Installed 384.5 a few days ago,

While it works fine, my AC86-U now reboots by itself every day or so for unknown reason. My uptime with the previous firmware was 20 days +.

I have this constant error showing up in my logs.

Any input on how to fix this ?
Thanks for reporting the issues. I support an AC86U at a B&B and will refrain from flashing with 384.5 until your issues are resolved. It appears that other AC86U owners are not having the issues. I will monitor the thread for now. I upgraded three AC88Us last week with no issues and no factory reset from 384.4_2 to 384.5.
 
it's one of those various little things that are gradually killing this project.
This would be sad. Your firmware is biggest reason I own an Asus router.

If I were Asus, I would be concerned if this happened. Having your firmware available is a selling point for them. Whatever you decide Eric, people will always appreciate your efforts to improve this firmware. Thank you!
 
This current build on my RT-AC3200 working fine. Not sure if @RMerlin has fixed the "nat: apply nat rules (/tmp/nat_rules_eth0_eth0" issue that I had personally had but when I change anything WAN related I do not get that stupid NAT Error, so kudos if you have.
 
Reading the changelog I noticed a couple of interesting lines.

Removed "Push LAN" and "Redirect Gateway", replaced with new Client Access setting
Removed option to respond to DNS queries - enabling the option to Push DNS will also handle it

I used both options on my AC68U, Firmware version 384.4_2

My goal is that clients should be able to,

1. Reach my NAS/router webUI, pc's on the home network when connection to my vpn
2. Get my home DNS/Gateway to be able to stream local Netflix when abroad. This is tested and also works in countries where there still no Netflix.
Also works with some other local streaming services that requires I'm on my home network....or at least they think so.

I'm actually not sure what is required for both but I guess Redirect gateway for Netflix and other local streaming services and Push LAN to clients to be able to reach my NAS/Home network

So now I'm a bit confused about "Replaced with new Client Access setting"

Does this mean I now need these options in my client.ovpn files?
Or perhaps in my in my ccd files (I have one for each client which is a blank file for now.)

Actually I prefer the ccd files option if possible and if this is the way to go

Still I'm not sure what I need for my 2 requirements and it was quite easy for me with the now older firmware.

Been playing a bit around and figured out (mapped) the options in the config.ovpn with the webUI
(example IP's)

WEBUI SERVERSIDE CONFIG.OVPN
Push LAN to clients: push "route 192.168.1.0 255.255.255.0 vpn_gateway 500"
Advertise DNS to clients: push "dhcp-option DNS 192.168.1.1"
Direct clients to redirect Internet traffic: push "redirect-gateway def1"

Hope somebody can advise since it's a bit difficult for me to test as it is a function only useful/needed from abroad
 
So now I'm a bit confused about "Replaced with new Client Access setting"

Does this mean I now need these options in my client.ovpn files?

No, it means you have to configure it here now:

upload_2018-5-22_12-36-24.png
 

Sign Up For SNBForums Daily Digest

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