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

[Huib]

People having the Internet disconnected issue, please report whether you ever messed with your bootloader or not.

Model: RT-AC68U
Firmware Version: 384.15_alpha1-wd-g7be95e7bd9
Bootloader (CFE): 1.0.2.1

internet disconnected issue (bootloader has a flag set to factory/debug mode), modified CFE for power & region

 

[RMerlin]

If this setting will be in next stable release I will do that way, but wasn't in 384.14, also when PMF enabled I observe ping jumps on my pc even with QOS on, and pc wasn't affected with bandwidth issue like mobile phones.

384.14 SDK wasn't Wifi 6 certified yet, and was also missing various Wifi 6 features like Wi-FI Agile support.

 

[RMerlin]

modified CFE for power & region

So you did modify your bootloader. That is the source of your problem, you flashed a CFE that was NOT configured for production use.

 

[RMerlin]

Does Dropbear in this version (384.14) support ed25519 keys?

(I know older versions did not)

There has been no Dropbear update since last April.

 

[Clark Griswald]

384.14_1 working Great!
Thank You RMerlin
Dirty upgrade from betas, and all was working well, but I always do a "Nuclear Reset" at every fw Final

 

[Huib]

So you did modify your bootloader. That is the source of your problem, you flashed a CFE that was NOT configured for production use.

Good to know, thanks for the confirmation.

 

[XIII]

There has been no Dropbear update since last April.

And I guess this has not been added between October 2018 (post I linked to) and April?

I'll keep using an RSA key then.

 

[RMerlin]

And I guess this has not been added between October 2018 (post I linked to) and April?

I'll keep using an RSA key then.

I don't know, you'll have to check the Dropbear changelog.

 

[XIII]

Looks like a "No": https://matt.ucc.asn.au/dropbear/CHANGES

 

[unsynaps]

Here are the rules for Protected Management Frames:

• If the Authenticatoin Method is WAP3-Personal, the Protected Management Frames will be Required.

Wow this is going to kill a lot of IOT devices. Had to shut off required when I saw it killed every single non 'computer' device on my wifi.

Ahh right. Turning on required kills my Logitech remote hub. So it seems like we are going to have WEP > WPA all over again. Where we have to run a older network because a few devices cant/wont be upgraded when we move to WPA3 base stations.

 

[XIII]

Got this error when (remote) SSH-ing into the router:

Socket error: Unknown error: -1

Also I can no longer log in on the web GUI using OpenVPN (which worked earlier today, as did SSH).

Anything I can try remotely, before returning home?

 

[XIII]

Turns out SkyNet banned the IP I was connecting from...

Using a commercial VPN I temporarily changed my IP address and then I could log in again to unban the “regular” IP!

Sorry, initially did not think of this. Would have posted in the SkyNet thread otherwise.

 

[Deleted member 62525]

Does anyone have an idea what this is? I'm on an rt-ac86u and 384.14. I have a vanilla configuration and the usual suspects (T.M.) are deactivated. The router was reseted to factory default after the upgrade to 384.14 and manually configured.

A google search came up basically empty. BDMF - Broadcom Device Management Framework, other than that - zilch. The systemlog is in debug mode and this was an isolated event in time by more than 2h.

Dec 19 22:11:41 kernel: ERR: bdmf_attrelem_add_as_buf#4250: ucast: status:Entry already exists. attribute:flow  index:4294967295
Dec 19 22:11:41 kernel: ^[[0;33;41m[ERROR pktrunner] runnerUcast_activate,1971: Cannot rdpa_ucast_flow_add^[[0m
Dec 19 22:11:47 kernel: ERR: bdmf_attrelem_add_as_buf#4250: ucast: status:Entry already exists. attribute:flow  index:4294967295
Dec 19 22:11:47 kernel: ^[[0;33;41m[ERROR pktrunner] runnerUcast_activate,1971: Cannot rdpa_ucast_flow_add^[[0m
Dec 19 22:11:56 kernel: ERR: bdmf_attrelem_add_as_buf#4250: ucast: status:Entry already exists. attribute:flow  index:4294967295
Dec 19 22:11:56 kernel: ^[[0;33;41m[ERROR pktrunner] runnerUcast_activate,1971: Cannot rdpa_ucast_flow_add^[[0m

Uptime: 5 days, 22h, 17m and 20sec

Have you found the issue? I am experiencing the same but cannot trace it down.

 

[miroco]

Have you found the issue? I am experiencing the same but cannot trace it down.

Unfortunately no.

I looked trough the system log just now. It seems as if it was a one-off event.

Maybe it's router fart, like in brain fart. There's been quite a few post lately about weird things in the log.

 

[Maverickcdn]

Mentioned in this post https://www.snbforums.com/threads/r..._2-are-now-available.60585/page-4#post-532548

But Ill mention it again as I know it wasnt appearing in 384.10, anytime you restart conntrack this appears

Dec 30 20:50:02 rc_service: service 2321:notify_rc restart_conntrack
Dec 30 20:50:02 modprobe: module nf_conntrack_proto_gre not found in modules.dep
Dec 30 20:50:02 modprobe: module nf_nat_proto_gre not found in modules.dep
Dec 30 20:50:02 modprobe: module nf_conntrack_pptp not found in modules.dep
Dec 30 20:50:02 modprobe: module nf_nat_pptp not found in modules.dep

 

[RMerlin]

But Ill mention it again as I know it wasnt appearing in 384.10, anytime you restart conntrack this appears

Just ignore these, this is because the router tries to load modules which are already built in the kernel itself.

 

[Puremin0rez]

I've done a full NVRAM erase fresh setup using the latest build available for my 87U (384-13_2).

I've had absolutely zero issues, but I noticed that after I changed a single setting in the wifi settings for 2.4ghz (20/40 to 20mhz), my router started to spam this all day in the log

Dec 30 23:05:45 acsd: scan in progress ...
Dec 30 23:05:45 acsd: scan in progress ...
Dec 30 23:05:45 acsd: scan in progress ...
Dec 30 23:05:46 acsd: scan in progress ...
Dec 30 23:05:46 acsd: scan in progress ...
Dec 30 23:05:46 acsd: scan in progress ...
Dec 30 23:05:46 acsd: scan in progress ...
Dec 30 23:05:47 acsd: scan in progress ...
Dec 30 23:05:47 acsd: scan in progress ...
Dec 30 23:05:47 acsd: scan in progress ...
Dec 30 23:05:47 acsd: scan in progress ...
Dec 30 23:05:48 acsd: selected channel spec: 0x1004 (4)
Dec 30 23:05:48 acsd: Adjusted channel spec: 0x1004 (4)
Dec 30 23:05:48 acsd: selected channel spec: 0x1004 (4)
Dec 30 23:20:48 acsd: scan in progress ...
Dec 30 23:20:49 acsd: scan in progress ...
Dec 30 23:20:49 acsd: scan in progress ...
Dec 30 23:20:49 acsd: scan in progress ...
Dec 30 23:20:49 acsd: scan in progress ...
Dec 30 23:20:50 acsd: scan in progress ...
Dec 30 23:20:50 acsd: scan in progress ...
Dec 30 23:20:50 acsd: scan in progress ...
Dec 30 23:20:50 acsd: scan in progress ...
Dec 30 23:20:51 acsd: scan in progress ...
Dec 30 23:20:51 acsd: scan in progress ...
Dec 30 23:20:51 acsd: selected channel spec: 0x1007 (7)
Dec 30 23:20:51 acsd: Adjusted channel spec: 0x1007 (7)
Dec 30 23:20:51 acsd: selected channel spec: 0x1007 (7)

It seems to be related to auto channel scanning (since my router is configured to auto for channel), but it seems weird that it didn't start doing this until I changed a single setting. It was already on Auto before (default ASUS value), but seemingly didn't "activate" until I changed something on the page. Is this normal behavior / reproducible for anyone else?

 

[alk630]

I don't know whether this problem is related to the latest version of Merlin's firmware or not, and some may scoff at this.

After the latest firmware update to 384.14,on my AC-86U routers, we started experiencing our Samsung TV turning on and then off at regular intervals of around three minutes. I reset the TV back to factory settings and put all the wireless information back in, but the problem persisted. This seems to be a common problem with Samsung TVs, with hundreds of complaints on the internet and some peoples saying they resolved the problem by disabling the TV internet connection. As I last resort, I downgraded to Merlin 384.13 and reset both the TV to factory settings, inputting all the wireless setting on the TV again. The problem has since disappeared. Is this anyone else has experienced at all?

The 384.14 firmware also caused problems with my Cyrus Lyric 09 hifi connected wirelessly to an Asset UPnP server. I have never experienced any problems until the latest firmware was updated, when the hifi refused to see my network until the router was reset, even though the 2.4 signal was strong on Android Wifi Analyser. This problem has since resolved since downgrading to 384.13 too.

 

[RMerlin]

I uploaded a few 384.14_1 test builds:

https://www.asuswrt-merlin.net/test-builds

Changes since 384.14:

  - 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)

Only affected models were uploaded, as none of these issues affected the RT-AC3200, RT-AC87U or RT-AX88U.

 

[RMerlin]

I don't know whether this problem is related to the latest version of Merlin's firmware or not, and some may scoff at this.

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.