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

[omiez]

Dirty Flash at My RT-AC86U from 384.14 to 384.14_2 and no problems so far after one day of usage.

Thank You very much Merlin,

 

[scjr]

The issue persists after factory reset and manual config.

Is it safe to rollback from 14 to 13 (with a factory reset)? I need my router in working condition and it was working well before upgrading to 14.

You can rollback to .13, but if you notice any odd behavior just factory reset .13.

 

[Rhialto]

Finally updated from old 380.x and thought all was fine but 2 hours later my gf tells me there is no wifi on her Mac, I check on my phone and she was right, no wifi. That never happened on previous version. I've read some others have same problem happened and usual answer I think is that wifi driver wasn't touched at all for a long time. What could cause this? If I look in log all I see is this:

Jan 2 12:51:20 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 12:51:20 acsd: Adjusted channel spec: 0xe29b (157/80)
Jan 2 12:51:20 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 12:51:20 acsd: acs_set_chspec: 0xe29b (157/80) for reason APCS_CSTIMER
Jan 2 13:06:23 acsd: selected channel spec: 0xe39b (161/80)
Jan 2 13:06:23 acsd: Adjusted channel spec: 0xe39b (161/80)
Jan 2 13:06:23 acsd: selected channel spec: 0xe39b (161/80)
Jan 2 13:06:23 acsd: acs_set_chspec: 0xe39b (161/80) for reason APCS_CSTIMER
Jan 2 13:21:25 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 13:21:25 acsd: Adjusted channel spec: 0xe29b (157/80)
Jan 2 13:21:25 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 13:21:25 acsd: acs_set_chspec: 0xe29b (157/80) for reason APCS_CSTIMER
Jan 2 13:36:27 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 13:36:27 acsd: Adjusted channel spec: 0xe29b (157/80)
Jan 2 13:36:27 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 13:36:27 acsd: acs_set_chspec: 0xe29b (157/80) for reason APCS_CSTIMER
Jan 2 13:51:29 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 13:51:29 acsd: Adjusted channel spec: 0xe29b (157/80)
Jan 2 13:51:29 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 13:51:29 acsd: acs_set_chspec: 0xe29b (157/80) for reason APCS_CSTIMER
Jan 2 14:06:32 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 14:06:32 acsd: Adjusted channel spec: 0xe29b (157/80)
Jan 2 14:06:32 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 14:06:32 acsd: acs_set_chspec: 0xe29b (157/80) for reason APCS_CSTIMER
Jan 2 14:21:34 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 14:21:34 acsd: Adjusted channel spec: 0xe29b (157/80)
Jan 2 14:21:34 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 14:21:34 acsd: acs_set_chspec: 0xe29b (157/80) for reason APCS_CSTIMER
Jan 2 14:36:36 acsd: selected channel spec: 0xe09b (149/80)
Jan 2 14:36:36 acsd: Adjusted channel spec: 0xe09b (149/80)
Jan 2 14:36:36 acsd: selected channel spec: 0xe09b (149/80)
Jan 2 14:36:36 acsd: acs_set_chspec: 0xe09b (149/80) for reason APCS_CSTIMER
Jan 2 17:11:21 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 17:11:21 acsd: Adjusted channel spec: 0xe29b (157/80)
Jan 2 17:11:21 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 17:11:21 acsd: acs_set_chspec: 0xe29b (157/80) for reason APCS_CSTIMER
Jan 2 17:26:24 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 17:26:24 acsd: Adjusted channel spec: 0xe29b (157/80)
Jan 2 17:26:24 acsd: selected channel spec: 0xe29b (157/80)
Jan 2 17:26:24 acsd: acs_set_chspec: 0xe29b (157/80) for reason APCS_CSTIMER

I will reset and cross fingers.

 

[Sanna1967]

I will reset and cross fingers

adjust 5 ghz manually on a channel ex: 157 and dont use smart connect

 

[dave14305]

You can rollback to .13, but if you notice any odd behavior just factory reset .13.

I would reset anyway because the formatting of the DHCP static list changed going from 13 to 14 (extra field for DNS). Might not work properly going from 14 to 13 with the extra characters.

 

[dave14305]

What could cause this?

The log entries are from having Auto channel selection on the 5Ghz WiFi. Choose a specific channel and observe.

 

[AntonK]

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)

Are these changes incorporated into the 384.15 Alpha?

 

[Rhialto]

I don't get it, I did a reboot from webpage but no wifi, I switched router OFF/ON and still no wifi. Stupid me, I go see in Wireless/Professional tab and see both radios are disabled. WHAT? I want to point out that just before I enabled both radios the internet was working fine, have 2 computers wired and twins were gaming just fine. So... after enabling both radios there was a message abour ISP DHCP not working properly. What? I switched router OFF/ON one more time, no go. I did the same with modem and when fully operational (watching modem's LEDs) there was still nothing after 20 seconds and maybe I was impatient but I again switched router OFF/ON and after that I waited more and finally I got an IP from ISP.

Still a mystery why both radios switched off... right after the firmware update everything was working normal so why 1-3 hours later (cannot pinpoint exactly when) this happened?

 

[CriticJay]

Dirty upgrade to 384.14_2 from 384.14 working A-OK for me ... for the past 12 hours or so.

No problems to report.

Thanks RMerlin!

 

[ChrisM]

AC86U
Dirty upgrade from 13 to 14 caused internet disconnect issues, and vpn lockouts.
Dirty upgrade from 14 to 14-2 same issues remain.
Purge Router to factory setting, format part's etc
Recovery mode reload 14-2
Everything working fine now, Excellent phew !

Pity had to enter all settings again but there you go sometimes things happen, new backups made.

Thank you Merlin -
your a star as always - your work is VERY much appreciated.

Ps.
did try the 15-alpha1 version before 14-2 was out and had same problems.

 

[ChrisM]

Dirty upgrade my ASUS RT-AC3100 from 384.13 to 384.14 and started to get internet disconnection every 30-40 minutes. Only a reboot will fix this. According to the release notes, 384.14_2 fixes this issue and, after upgrading, I still have the same issue.

Please be nice (first time in this forum) since I'm not use to this place etiquette yet (and, although I have a technical background, I'm not familiarized with the inner workings of Merlin).

Any ideas how to fix this? Is it a known issue? Right now, I'm about to be hanged by my family for the constant internet interruptions.

Had same problem
reset to factory setting
use recovery mode to load 14-2
worked for me

 

[ChrisM]

I just tried to update my AC86U to today’s 384.14-2, and something catastrophic has happened. I get a red WAN light, but more importantly no router interface or even WiFi AP.

dropbear is loaded, so I was able to SSH in from my wired PC. ‘dmesg’ does show bad blocks on the nand/jffs, but would that really prevent the whole system from booting?

I was also using USB swap for amtm/diversion/etc but USB in or out doesn’t make a difference.

Prior to today, it had been up for a couple of weeks with no issues. I did see those ipv6 errors (“Failed to send DHCPV6 message”) in the logs prior to upgrading, which was new to me, but I don’t know that it’s relevant (I don’t think my Fios has it yet and I may have set the router to look for one)

I did try a hard reset by pressing the reset button while online, but that didn’t actually do anything. Held it in while power cycling; the power light did start flashing, but it didn’t seem like it was doing anything else; rebooted normally and got right back to where I was.

Otherwise, I don’t know what other info is relevant beyond upgrading from a couple of versions ago (384.12 I think?). Anything I can do to try and recover?

Had same problem
Reset to factory settings, format etc
Use recovery mode to load 14-2
Worked for me

 

[ChrisM]

Neil62 said: ↑
Going from 384.13 to the latest 384.14 release, recommended reset of the router, opinions? 13 is just so stable.

https://www.snbforums.com/threads/r...2-are-now-available.60585/page-27#post-537578

Had an issue going to 14 but think I was unlucky
Lots of Peeps seem to have gone to 14 Dirty and been ok
I have been going Dirty from 10,11,12,13 and the interim's and not had an issue till now.
But I now know how to do a Recovery mode load of the router so a good lesson going forward and 14-2 working like a charm now.

 

[ChrisM]

Going from 384.13 to the latest 384.14 release, recommended reset of the router, opinions? 13 is just so stable.

Had an issue going to 14 but think I was unlucky
Lots of Peeps seem to have gone to 14 Dirty and been ok
I have been going Dirty from 10,11,12,13 and the interim's and not had an issue till now.
But I now know how to do a Recovery mode load of the router so a good lesson going forward and 14-2 working like a charm now.

 

[JarleH]

Been running RT-AX88U with 384.14 since release, all looks good to me...

 

[trongod]

I get that too but my reason is slightly different:

Jan  2 09:50:18 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated due to inactivity (4)
Jan  2 09:50:18 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan  2 09:51:31 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 84:AD:8D:9B:B2:38, status: 0, reason: d11 RC reserved (0)
Jan  2 09:51:31 wlceventd: WLCEVENTD wlceventd_proc_event(430): eth6: ReAssoc 84:AD:8D:9B:B2:38, status: 0, reason: d11 RC reserved (0)
Jan  2 09:53:12 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 84:AD:8D:9B:B2:38, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan  2 09:53:12 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan  2 09:53:48 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 84:AD:8D:9B:B2:38, status: 0, reason: d11 RC reserved (0)
Jan  2 09:53:48 wlceventd: WLCEVENTD wlceventd_proc_event(430): eth6: ReAssoc 84:AD:8D:9B:B2:38, status: 0, reason: d11 RC reserved (0)
Jan  2 09:56:19 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated due to inactivity (4)
Jan  2 09:56:19 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 84:AD:8D:9B:B2:38, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

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.

 

[XIII]

As of 1/1/20 my DNS keeps failing after some time on my AC86U. This happens on both 384.14 and 384.14_2, with DNS over TLS, using Cloudflare, Quad9, or NextDNS.

When I restart the dnsmasq service DNS works fine for a while, until it stops and I have to manually restart the service again.

How can I debug/fix this?

 

[Andy1932]

As of 1/1/20 my DNS keeps failing after some time on my AC86U. This happens on both 384.14 and 384.14_2, with DNS over TLS, using Cloudflare, Quad9, or NextDNS.

When I restart the dnsmasq service DNS works fine for a while, until it stops and I have to manually restart the service again.

How can I debug/fix this?

Just curious, when your dns goes out, have you noticed cpu spikes on the status page? This happens to me about every 2-3 days.

 

[XIII]

Just curious, when your dns goes out, have you noticed cpu spikes on the status page? This happens to me about every 2-3 days.

Will check the next time (frequency is much higher here: almost every hour?).

As a first debugging step I erased my flash drive and set up amtm, Diversion, Entware, and SkyNet from scratch (unfortunate side effect: NextDNS seems to no longer work now; but I already asked for help for that in the specific thread).

Hope I don't have to do a factory reset, but it's getting so annoying that I'm close to doing that.

 

[XIII]

Issue occurred again. No CPU spike here.