[Release] Asuswrt-Merlin 384.14 (and 384.13_2) are now available

[CriticJay]

Issue occurred again. No CPU spike here.

If you disable DNS-over-TLS, does everything work fine?

 

[XIII]

If you disable DNS-over-TLS, does everything work fine?

I changed the NTP server and so far DNS keeps working (longer than before).

 

[SheikhSheikha]

I was interested in using the Merlin firmware because of this very issue on my RT-AC5300. It started after I upgraded to the stock firmware 3.0.0.4.384.81219 that was released on the Asus site dated 2019/11/07. I would look at my Network Map and it would show one device yet have a superscript 2 or 3 on the icon. If I hovered over it, it indicated there were X amount of clients connecting through it. If Merlin 384.14 is based on that version of Asus firmware, I would stay stay away from it. My devices were constantly dropping off the network, poor signal strength, packet loss and even the WAN connection bugging out. I tried a factory reset and it looked like things were going ok until it started dropping clients again. I'm going to wait until Asus fixes this in their release before going with Merlin though. Just to be safe.

So far after downgrading to 3.0.0.4.384.45717, the log has been practically empty. With version 3.0.0.4.384.81219, it would have been full of those events already.

Just install Merlin and forget the Asus firmware, check the M&M configuration (search in the forum for the links) to do a correct clean configuration of the Merlin firmware. Merlin puts your router into that spectrum where Asus continuously misses the ball. This means: stability, stability and again stability, better Wi-Fi performance, some really good enhancements. 384.14 is the current version and once you come to the same conclusion I am sure a contribution to RMerlin is something you will consider logical. With Asus you have some great piece of hardware, but it truly comes alive with the Merlin firmware.

 

[damaltor]

RT-AC3100 Mesh Router
RT-AC68U Mesh Node
Did dirty install from 384.13 to 384.14 on both routers, all was well.
Did end up doing a full factory reset afterwards though, just because it has been a while.
Now just did a dirty install from 384.14 to 384.14_2 and all is well, no issues detected.

Thank you Merlin, greatly appreciate all your efforts and those of others too!

 

[XIII]

I changed the NTP server and so far DNS keeps working (longer than before).

But unfortunately the issue is back. Time for a factory reset...

 

[sentinelvdx]

Now yes! [emoji122][emoji4] 384.14_2 solves my 2.4Ghz WiFi issues.
Now my devices has internet access 24/7
Thanks @RMerlin

Sent from S.G. S9 Plus Duos using Tapatalk

 

[Dathi]

A number of users mentioned a dnsmasq-script error appearing very frequently in remote logs since 384.14. EG:

Dec 27 10:43:40 RT-AC88U-58D8-AD6DCF9-C dnsmasq-script[351]: connect error: No such file or directory
Dec 27 10:43:40 RT-AC88U-58D8-AD6DCF9-C dnsmasq-script[351]: [SEND_AMAS_NODE_EVENT4684)] ERROR connecting:No such

It's only shown in the GUI logs if you choose debug. Merlin mentioned it's related to AiMesh (closed source). I raised a case with ASUS given it's been introduced with the latest ASUS firmware update that Merlin now includes. The reply was, er, interesting.

"In regards to your escalation request response, apparently the codes in the log is part of the debug logging - the debug will show more detail which is why it is visible when debugging is enabled. Otherwise, the firmware is working correctly, it is just a notification in this case."

I replied saying errors are not normal, and I hope they fix it with the next release.

 

[ppfoong]

384.14_2 running on AC86U. A lot of Letsencrypt service restart in the log. Is this normal?


Jan 4 07:25:00 rc_service: service 24641:notify_rc restart_letsencrypt
Jan 4 07:30:00 rc_service: service 25117:notify_rc restart_letsencrypt
Jan 4 07:35:00 rc_service: service 25601:notify_rc restart_letsencrypt
Jan 4 07:40:00 rc_service: service 26081:notify_rc restart_letsencrypt
Jan 4 07:45:00 rc_service: service 26581:notify_rc restart_letsencrypt
Jan 4 07:50:00 rc_service: service 27062:notify_rc restart_letsencrypt
Jan 4 07:55:00 rc_service: service 27542:notify_rc restart_letsencrypt
Jan 4 08:00:00 rc_service: service 28021:notify_rc restart_letsencrypt
Jan 4 08:05:00 rc_service: service 28512:notify_rc restart_letsencrypt
Jan 4 08:10:00 rc_service: service 28996:notify_rc restart_letsencrypt
Jan 4 08:15:00 rc_service: service 29492:notify_rc restart_letsencrypt
Jan 4 08:20:00 rc_service: service 29967:notify_rc restart_letsencrypt
Jan 4 08:25:00 rc_service: service 30450:notify_rc restart_letsencrypt
Jan 4 08:30:00 rc_service: service 30928:notify_rc restart_letsencrypt
Jan 4 08:35:00 rc_service: service 31411:notify_rc restart_letsencrypt
Jan 4 08:40:00 rc_service: service 31883:notify_rc restart_letsencrypt
Jan 4 08:45:00 rc_service: service 32379:notify_rc restart_letsencrypt
Jan 4 08:50:00 rc_service: service 393:notify_rc restart_letsencrypt
Jan 4 08:55:00 rc_service: service 888:notify_rc restart_letsencrypt
Jan 4 09:00:00 rc_service: service 1438:notify_rc restart_letsencrypt
Jan 4 09:05:00 rc_service: service 1959:notify_rc restart_letsencrypt
Jan 4 09:10:00 rc_service: service 2448:notify_rc restart_letsencrypt
Jan 4 09:15:00 rc_service: service 2953:notify_rc restart_letsencrypt
Jan 4 09:20:00 rc_service: service 3439:notify_rc restart_letsencrypt
Jan 4 09:25:00 rc_service: service 3927:notify_rc restart_letsencrypt
Jan 4 09:30:00 rc_service: service 4400:notify_rc restart_letsencrypt
Jan 4 09:35:00 rc_service: service 4886:notify_rc restart_letsencrypt
Jan 4 09:40:00 rc_service: service 5364:notify_rc restart_letsencrypt
Jan 4 09:45:00 rc_service: service 5866:notify_rc restart_letsencrypt
Jan 4 09:50:00 rc_service: service 6344:notify_rc restart_letsencrypt
Jan 4 09:55:00 rc_service: service 6835:notify_rc restart_letsencrypt
Jan 4 10:00:00 rc_service: service 7314:notify_rc restart_letsencrypt
Jan 4 10:05:00 rc_service: service 7805:notify_rc restart_letsencrypt
Jan 4 10:10:00 rc_service: service 8288:notify_rc restart_letsencrypt
Jan 4 10:15:00 rc_service: service 8782:notify_rc restart_letsencrypt
Jan 4 10:20:00 rc_service: service 9261:notify_rc restart_letsencrypt
Jan 4 10:25:00 rc_service: service 9761:notify_rc restart_letsencrypt
Jan 4 10:30:00 rc_service: service 10244:notify_rc restart_letsencrypt
Jan 4 10:35:00 rc_service: service 10726:notify_rc restart_letsencrypt
Jan 4 10:40:00 rc_service: service 11209:notify_rc restart_letsencrypt
Jan 4 10:45:00 rc_service: service 11705:notify_rc restart_letsencrypt
Jan 4 10:50:00 rc_service: service 12190:notify_rc restart_letsencrypt
Jan 4 10:55:00 rc_service: service 12672:notify_rc restart_letsencrypt
Jan 4 11:00:00 rc_service: service 13159:notify_rc restart_letsencrypt
Jan 4 11:05:00 rc_service: service 13650:notify_rc restart_letsencrypt
Jan 4 11:10:00 rc_service: service 14128:notify_rc restart_letsencrypt
Jan 4 11:15:00 rc_service: service 14623:notify_rc restart_letsencrypt
Jan 4 11:20:00 rc_service: service 15104:notify_rc restart_letsencrypt
Jan 4 11:25:00 rc_service: service 15588:notify_rc restart_letsencrypt
Jan 4 11:30:00 rc_service: service 16065:notify_rc restart_letsencrypt
Jan 4 11:35:00 rc_service: service 16546:notify_rc restart_letsencrypt
Jan 4 11:40:00 rc_service: service 17029:notify_rc restart_letsencrypt
Jan 4 11:45:00 rc_service: service 17524:notify_rc restart_letsencrypt
Jan 4 11:50:00 rc_service: service 18007:notify_rc restart_letsencrypt
Jan 4 11:55:00 rc_service: service 18489:notify_rc restart_letsencrypt
Jan 4 12:00:00 rc_service: service 18970:notify_rc restart_letsencrypt
Jan 4 12:05:00 rc_service: service 19457:notify_rc restart_letsencrypt
Jan 4 12:10:00 rc_service: service 19937:notify_rc restart_letsencrypt
Jan 4 12:15:00 rc_service: service 20443:notify_rc restart_letsencrypt
Jan 4 12:20:00 rc_service: service 20924:notify_rc restart_letsencrypt
Jan 4 12:25:00 rc_service: service 21413:notify_rc restart_letsencrypt
Jan 4 12:30:00 rc_service: service 21891:notify_rc restart_letsencrypt
Jan 4 12:35:00 rc_service: service 22379:notify_rc restart_letsencrypt
Jan 4 12:40:00 rc_service: service 22853:notify_rc restart_letsencrypt
Jan 4 12:45:00 rc_service: service 23345:notify_rc restart_letsencrypt
Jan 4 12:50:00 rc_service: service 23823:notify_rc restart_letsencrypt
Jan 4 12:55:00 rc_service: service 24309:notify_rc restart_letsencrypt
Jan 4 13:00:00 rc_service: service 24789:notify_rc restart_letsencrypt
Jan 4 13:05:00 rc_service: service 25282:notify_rc restart_letsencrypt
Jan 4 13:10:00 rc_service: service 25763:notify_rc restart_letsencrypt
Jan 4 13:15:00 rc_service: service 26259:notify_rc restart_letsencrypt
Jan 4 13:20:00 rc_service: service 26741:notify_rc restart_letsencrypt
Jan 4 13:25:00 rc_service: service 27233:notify_rc restart_letsencrypt
Jan 4 13:30:00 rc_service: service 27720:notify_rc restart_letsencrypt
Jan 4 13:35:00 rc_service: service 28212:notify_rc restart_letsencrypt
Jan 4 13:40:00 rc_service: service 28688:notify_rc restart_letsencrypt
Jan 4 13:45:00 rc_service: service 29183:notify_rc restart_letsencrypt
Jan 4 13:50:00 rc_service: service 29662:notify_rc restart_letsencrypt
Jan 4 13:55:00 rc_service: service 30143:notify_rc restart_letsencrypt
Jan 4 14:00:00 rc_service: service 30620:notify_rc restart_letsencrypt
Jan 4 14:05:00 rc_service: service 31109:notify_rc restart_letsencrypt
Jan 4 14:10:00 rc_service: service 31586:notify_rc restart_letsencrypt
Jan 4 14:15:00 rc_service: service 32083:notify_rc restart_letsencrypt
Jan 4 14:20:00 rc_service: service 32560:notify_rc restart_letsencrypt
Jan 4 14:25:00 rc_service: service 571:notify_rc restart_letsencrypt
Jan 4 14:30:00 rc_service: service 1105:notify_rc restart_letsencrypt
Jan 4 14:35:00 rc_service: service 1642:notify_rc restart_letsencrypt
Jan 4 14:40:00 rc_service: service 2120:notify_rc restart_letsencrypt
Jan 4 14:45:00 rc_service: service 2615:notify_rc restart_letsencrypt
Jan 4 14:50:00 rc_service: service 3092:notify_rc restart_letsencrypt
Jan 4 14:55:00 rc_service: service 3575:notify_rc restart_letsencrypt
Jan 4 15:00:00 rc_service: service 4053:notify_rc restart_letsencrypt
Jan 4 15:05:00 rc_service: service 4543:notify_rc restart_letsencrypt
Jan 4 15:09:22 kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link UP 1000 mbps full duplex
Jan 4 15:10:00 rc_service: service 5024:notify_rc restart_letsencrypt
Jan 4 15:15:00 rc_service: service 5523:notify_rc restart_letsencrypt
Jan 4 15:20:00 rc_service: service 6001:notify_rc restart_letsencrypt
Jan 4 15:25:00 rc_service: service 6485:notify_rc restart_letsencrypt
Jan 4 15:30:00 rc_service: service 6972:notify_rc restart_letsencrypt

 

[Xentrk]

384.14_2 running on AC86U. A lot of Letsencrypt service restart in the log. Is this normal?


Jan 4 07:25:00 rc_service: service 24641:notify_rc restart_letsencrypt
<snip>

https://www.snbforums.com/threads/r...service-every-five-minutes.46554/#post-488100

 

[John Adler]

I started a dirthy flash with the 384.14_2 ver.
nothing happened, after a while did it again, no activity.
after the 3rd intent it worked fine.
this never happened before.

 

[mrgnex]

I upgraded the firmware of my AC87U about a week ago. Since then I have random internet slowdowns where the internet on both cable and WiFi get incredibly slow, almost unusable.
I have two entries in my log that always seem to pop up around the time when the internet slows down.

Jan 4 13:29:38 kernel: br0: port 1(vlan1) neighbor 8000.(Router MAC address) lost
Jan 4 13:29:38 kernel: br0: topology change detected, propagating​

I Googled around to no avail. What is going on?

 

[RouterEnthusiast]

Asuswrt-Merlin 384.13_2 (RT-AC87U and RT-AC3200), and 384.14 (other models) are now available.

Jan 1st: 384.14_2 is available for the RT-AC68U, RTAC88U/3100/5300 and RT-AC86U, addressing a few issues specific to these models. Changes since 384.14:

  - FIXED: Missing cifs kernel module
  - FIXED: stubby was linked with OpenSSL 1.0 instead of 1.1
  - FIXED: some routers were reporting the Internet connection being
           disconnected.  If you were affected and you had flashed
           a customized bootloader, then please reflash your original
           bootloader, as your modded bootloader is invalid, and other
           potential issues may appear over time.
  - FIXED: Random traffic spikes logged in Traffic Monitor (regression
           from 384_81351)

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.

The 384.14 release for other models focuses on GPL merges and fixes.

The highlights:

• GPL updates: 384_6436 (RT-AX88U), 384_81351 (other models, with 384_81116 binary blobs used for the RT-AC88U/RT-AC3100), which contains Let's Encrypt fixes.
• Added option to prevent automatic DoH upgrade by Firefox. By default this option will only prevent automatic upgrade if you use DNSFilter or DNSPrivacy (DNS-over-TLS). You can change it to always prevent the upgrade. Note that this option has no impact if you manually decide to enable DoH in Firefox, only for its automatic option currently only available in the US.
• Updated components: miniupnpd 20190824, dnsmasq 2.80-95-g1aef66b, OpenSSL (1.0.2t/1.1.1d), curl (7.66), OpenVPN (2.4.8) and nano (4.4).
• Made self-generated SSL certificate compliant with new IOS 13 and MacOS 10.15 requirements (reduced duration to two years, and added missing attribute)
• Re-implemented the faketc script (which injects fq_codel support into Adaptive QoS) as a binary executable for better performance (reducing the chances of warning messages during QoS initialization if QoS took too long to initialize)
• Enhancements to the IPv6 firewall webui (now accepts empty fields to denote "Any IP", and improved EUI-64 handling)
• Re-added low nvram notification (was lost a few years ago in the move to 382)
• A number of fixes to Let's Encrypt support
• A number of misc fixes, please see the changelog for the complete list

Downloads are here.
Changelog is here.

Please keep posts focused on this specific release. Also note that I intend to lock this thread after a few weeks, once the release-specific issues have been handled, to avoid this thread devolving into a generic support discussion.

I am new here.. Not sure this is the right place to report a bug/issue. My router model is ASUS RT AC-88U.
I have had a bad WAN connectivity issue with the last two releases of Merlin: 384.14_0 and 384.14_2.
The issue appears to be that after upgrade the router no longer gets the default gateway/route from the ISP. Only local network routes are there.
The scenario is IPv4 only. Restoring firmware to 384.13_0 fixes it, so my conclusion is there is something that breaks the default route in the new firmware.

Otherwise, I really like Merlin, it really improves the official fw feature set. I never had any major issue till these last two releases.

 

[Patrick0525]

I am new here.. Not sure this is the right place to report a bug/issue. My router model is ASUS RT AC-88U.
I have had a bad WAN connectivity issue with the last two releases of Merlin: 384.14_0 and 384.14_2.
The issue appears to be that after upgrade the router no longer gets the default gateway/route from the ISP. Only local network routes are there.
The scenario is IPv4 only. Restoring firmware to 384.13_0 fixes it, so my conclusion is there is something that breaks the default route in the new firmware.

Otherwise, I really like Merlin, it really improves the official fw feature set. I never had any major issue till these last two releases.

Upgraded to 384.14_2 RT-AC68U default gateway did not change but I am running as an AP.

 

[broabander]

Recently I've updated my RT-AC3200 tot 384.13_2. It all works quite well but one thing isn't working anymore.
I use a raspberry PI for OpenVPN. I am able to connect to the PI but the whole network isn't available.
Where did I go wrong? What do I need to do to get it working again?

Thx

 

[alk630]

I would check the wifi settings. For instance, Asus recently enabled DFS channels in the US for the RT-AC86U, which might be problematic for some devices. Either disable automatic DFS channel selection, or manually configure a fixed, non-DFS channel (like 36) and see if it helps.

Just updated to 384.14.2 and the Samsung TV problem switching off and then back on at around three minute intervals returned immediately. Back flashing to 3.83.13 has again fixed the problem. Is there anything I should be looking at to further diagnose this problem?

 

[RMerlin]

Now yes!

384.14_2 solves my 2.4Ghz WiFi issues.

ZERO Wifi change to 384.14_2...

merlin@ubuntu-dev:~/amng$ git log --oneline 384.14-mainline..384.14_2-mainline
45ae9b6918 (HEAD -> 384.14_x, tag: 384.14_2-mainline, tag: 384.14_2, origin/384.14_x) Bumped revision to 384.14_2
91f5f74648 Updated documentation
1d31ab3018 webui: hide _0 extendno from firmware versions returned by cfg_sync
9edb5b64e8 build: re-add cifs.ko module (lost with GPL 81044 merge)
bfe637c825 rc: remove no longer required kludge for STP on HND models
5fa7992874 rc: fix bad GPL merge
35d1fd1184 Updated documentation
9132036d7d rc: log if router is in manufacturing mode at wanduck launch
6c4196a268 rstats: revert some of the 384_81044 changes in an attempt to resolve the traffic spikes
73c8e86ace rc: fail wanduck (and possibly other services) failing to start due to ate_mode check
8d832c2cbb getdns: provide explicit path to OpenSSL 1.1.1 (fixes regression fom GPL 81044 merge)
2b0654c7d9 Bumped revision to 384.14_1

 

[sentinelvdx]

ZERO Wifi change to 384.14_2...

merlin@ubuntu-dev:~/amng$ git log --oneline 384.14-mainline..384.14_2-mainline
45ae9b6918 (HEAD -> 384.14_x, tag: 384.14_2-mainline, tag: 384.14_2, origin/384.14_x) Bumped revision to 384.14_2
91f5f74648 Updated documentation
1d31ab3018 webui: hide _0 extendno from firmware versions returned by cfg_sync
9edb5b64e8 build: re-add cifs.ko module (lost with GPL 81044 merge)
bfe637c825 rc: remove no longer required kludge for STP on HND models
5fa7992874 rc: fix bad GPL merge
35d1fd1184 Updated documentation
9132036d7d rc: log if router is in manufacturing mode at wanduck launch
6c4196a268 rstats: revert some of the 384_81044 changes in an attempt to resolve the traffic spikes
73c8e86ace rc: fail wanduck (and possibly other services) failing to start due to ate_mode check
8d832c2cbb getdns: provide explicit path to OpenSSL 1.1.1 (fixes regression fom GPL 81044 merge)
2b0654c7d9 Bumped revision to 384.14_1

[emoji2369] then... with 384.14 2.4Ghz shows (!) On my phones, having no access to Internet.
Rolled back to 384.13, hard reset and manually configured... Now upgraded to 384.14_2 without hard reset and works just perfect.
Maybe didn't flash correct before I dont know

Sent from S.G. S9 Plus Duos using Tapatalk

 

[RMerlin]

Maybe didn't flash correct before I dont know

Or most likely, the fix to your problem was a router reboot, which occurred when you flashed a new firmware.

 

[MDM]

I upgraded the firmware of my AC87U about a week ago. Since then I have random internet slowdowns where the internet on both cable and WiFi get incredibly slow, almost unusable.
I have two entries in my log that always seem to pop up around the time when the internet slows down.

Jan 4 13:29:38 kernel: br0: port 1(vlan1) neighbor 8000.(Router MAC address) lost
Jan 4 13:29:38 kernel: br0: topology change detected, propagating​

I Googled around to no avail. What is going on?

It took me like 2 seconds on Google. Don't know your search method, but only search text after "kernel:"...
https://www.snbforums.com/threads/what-do-these-log-entries-mean.31446/

 

[mrgnex]

It took me like 2 seconds on Google. Don't know your search method, but only search text after "kernel:"...
https://www.snbforums.com/threads/what-do-these-log-entries-mean.31446/

That is indeed the only one thing I found. But I did not enable STP, I do not even know where I would find the option. I also do not own any Sonos devices.