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.
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
 
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.
 
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.
 
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.
 
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
 
Last edited:
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.
 
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.
 
Last edited:
Got this error when (remote) SSH-ing into the router:

Code:
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?
 
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.
 
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.

Code:
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.
 
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.
 
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
 
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.
 
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
Code:
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?
 
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.
 
Last edited:
I uploaded a few 384.14_1 test builds:

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

Changes since 384.14:

Code:
  - 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.
 
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.
 
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Staff online

Top