[Beta] Asuswrt-Merlin 384.14 Beta is now available

[John Adler]

Hi
just did a dirty flash of ß3 on my router
VPN PPTP/L2TP working fine!
many thanks again!

 

[Butterfly Bones]

Looks like I spoke too soon, no issues with 384.14_b3 .... found this within 24 hours...

Dec 7 13:16:11 kernel: device eth0 entered promiscuous mode
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:11 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:16 kernel: protocol 0800 is buggy, dev eth0
Dec 7 13:16:16 kernel: protocol 0800 is buggy, dev eth0
Dec 7 13:16:17 kernel: protocol 0800 is buggy, dev eth0
Dec 7 13:16:17 kernel: protocol 0800 is buggy, dev eth0
Dec 7 13:16:17 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:18 kernel: protocol 0800 is buggy, dev eth0
Dec 7 13:16:18 kernel: protocol 0800 is buggy, dev eth0
Dec 7 13:16:18 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:16:19 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:17:35 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:17:35 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:17:35 kernel: protocol 0800 is buggy, dev eth0
Dec 7 13:17:36 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:17:36 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:17:36 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:17:36 kernel: protocol 0000 is buggy, dev eth0
Dec 7 13:17:39 kernel: device eth0 left promiscuous mode

Long term know issue, here is a reply from RMerlin from 2012.
https://www.snbforums.com/threads/test-builds-with-openvpn-available.7875/page-4#post-47788

 

[Butterfly Bones]

Also have a ton of these lines in 384.14_b3...

Dec 6 22:30:39 wlceventd: WLCEVENTD wlceventd_proc_event(430): eth6: ReAssoc A0:72:2C:79:85:1A, status: 0, reason: d11 RC reserved (0)
Dec 6 22:31:02 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc A0:72:2C:79:85:1A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 6 22:31:02 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth A0:72:2C:79:85:1A, status: 0, reason: d11 RC reserved (0)
Dec 6 22:31:02 wlceventd: WLCEVENTD wlceventd_proc_event(430): eth6: ReAssoc A0:72:2C:79:85:1A, status: 0, reason: d11 RC reserved (0)
Dec 6 22:31:13 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc A0:72:2C:79:85:1A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 6 22:31:13 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth A0:72:2C:79:85:1A, status: 0, reason: d11 RC reserved (0)
Dec 6 22:31:13 wlceventd: WLCEVENTD wlceventd_proc_event(430): eth6: ReAssoc A0:72:2C:79:85:1A, status: 0, reason: d11 RC reserved (0)
Dec 6 23:26:33 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 78:32:1B:A9:F0:12, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 6 23:36:04 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 78:32:1B:A9:F0:12, status: 0, reason: d11 RC reserved (0)
Dec 6 23:36:04 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc 78:32:1B:A9:F0:12, status: 0, reason: d11 RC reserved (0)
Dec 7 00:29:22 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 60:8C:4A:AC:5A:8A, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 7 00:29:26 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 60:8C:4A:AC:5A:8A, status: 0, reason: d11 RC reserved (0)
Dec 7 00:29:26 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc 60:8C:4A:AC:5A:8A, status: 0, reason: d11 RC reserved (0)
Dec 7 00:35:17 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 44:61:32:E5:405, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 7 00:35:48 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth 44:61:32:E5:405, status: 0, reason: d11 RC reserved (0)
Dec 7 00:35:48 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc 44:61:32:E5:405, status: 0, reason: d11 RC reserved (0)
Dec 7 00:49:22 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Disassociated due to inactivity (4)
Dec 7 00:49:22 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc E0:89:7E:0C:9C:08, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)
Dec 7 00:49:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind E0:89:7E:0C:9C:08, status: 0, reason: Class 3 frame received from nonassociated station (7)

Also an old know issue, here is the RMerlin explanation.
https://www.snbforums.com/threads/r...13-is-now-available.57860/page-35#post-515660

 

[CaptainSTX]

Updated from 14 B.1 - B.3. The link rate on my one stream AC 5 Ghz devices (primarily dot speakers ) dropped from 433/433 per wireless section of log to 6/6. Reverted back to B.1 and bandwidth restored.

 

[Treadler]

Keeping my 7756 based AX88 firmware for now unless there is a good reason to change (so far no stability issues as far as I've noticed. Havn't checked logs for errors though)

Yup, that’s what I’m doing.
I don’t use Qos, & the only issue for me is the ‘apply’ button on the system page not working. (& AiProtect complaining wpa2/3 “weak”).

Wpa2/3 working fine.
Happy.

 

[Val D.]

Updated from 14 B.1 - B.3. The link rate on my one stream AC 5 Ghz devices (primarily dot speakers ) dropped from 433/433 per wireless section of log to 6/6. Reverted back to B.1 and bandwidth restored.

6/6 usually indicates power saving state of the device.
What you see may not be a problem, but an improvement in log accuracy.

 

[Kingp1n]

Anyone on RT-AC86U have resetted their router after a dirty flash to beta3 and their 2.4 ghz signal doesnt work after reboot? Or maybe after a 2nd reboot? As soon as i flash back to 384.13, my signal returns.

 

[RMerlin]

More problems with Letsencrypt:

Status :    Authorizing
Issued to :  
SAN :    undefined
Issued by :  
Expires on :

Look at your System Log, it will tell you why. There's a good chance that either you are being throttled by Let's Encrypt's servers, or your /jffs partition is full.

 

[RMerlin]

Also have a ton of these lines in 384.14_b3...

Nothing abnormal there, wlceventd logs wireless events.

 

[RMerlin]

Updated from 14 B.1 - B.3. The link rate on my one stream AC 5 Ghz devices (primarily dot speakers ) dropped from 433/433 per wireless section of log to 6/6. Reverted back to B.1 and bandwidth restored.

This has nothing to do with the beta, the wireless driver hasn't changed since Beta 1.

 

[CaptainSTX]

6/6 usually indicates power saving state of the device.
What you see may not be a problem, but an improvement in log accuracy.

None of the spots would do anything or respond to any commands. Power cycling them didn't fix the problem. Immediately after reverting they were all functioning normally. Didn't feel like doing any further experimenting at this time.

 

[CaptainSTX]

This has nothing to do with the beta, the wireless driver hasn't changed since Beta 1.

When I have a chance I will upgrade again and see if I can find the issue. I was surprised by the issue as I didn't see anything in the notes indicating changes is WiFi. In meantime B.1 works fine.

Just to provide some additional information. All the spots connect on a guest network. I did not check to see what the link speed was on the primary 5 Ghz network. Doesn't seem like it should make any difference but who knows.

 

[randomName]

Not sure if my beta install went smooth but after installing FreshJR I noticed 'Runner' and 'Flow Cache' are still enabled in the Tools>Sysinfo>HW acceleration section. Anyone else seeing this or did something go wrong on my end?

Thanks

 

[SheikhSheikha]

384.14 beta 3 on AC5300 quick and dirty upgrade (side by side to AC5300 384.13), these are my FIRST impressions:

• L2TP VPN client works stabile but the ping increased with 25-30ms
• RAM Basic Memory usage has decreased (with only a few Mb but it is less)
• CPU Temp dropped a few degrees
• Signal Strength of both 5MHz has dropped with 6% compared to 384.13 (bummer!)
• I have the impression that the LAN to WAN speed has improved but I need more time to come to a final conclusion (I have it running for less than an hour)
• Simple sharing name Samba seems broken.
• I have the impression that the router response is snappier and faster.

Serious improvement compared to beta 2. I will test it further in the coming days.

 

[ryannathans]

AC5300 - updating from 384.13

100% usage on one CPU core after update
Seems to be samba related
Samba share seems to be non-accessible
After turning samba share off [mtdblock3] seems to be using unusual cpu - around 10% (not sure if related or red herring)

Samba on with no external drive plugged in results in the same

EDIT: renaming the device (from NootworkStorage to Noot) in the samba menu seems to have fixed the problem. I have not rebooted so the drive is still mounted at /mnt/tmp/NootworkStorage but CPU usage looks normal now

 

[Wade Coxon]

Not sure if my beta install went smooth but after installing FreshJR I noticed 'Runner' and 'Flow Cache' are still enabled in the Tools>Sysinfo>HW acceleration section. Anyone else seeing this or did something go wrong on my end?

I'm seeing this on Beta2 as well.

 

[FLA_NL]

Dirty update from beta2 to beta3 and running for 11 hours without dnsmasq issues. (RT-AC86U)

 

[charlie2alpha]

Not sure if my beta install went smooth but after installing FreshJR I noticed 'Runner' and 'Flow Cache' are still enabled in the Tools>Sysinfo>HW acceleration section. Anyone else seeing this or did something go wrong on my end?

Thanks

I don't understand why you expect that to change, Adaptive QoS keeps hardware acceleration enabled. FreshJR just tweaks Adaptive QoS, it's not doing anything on it's own.

 

[kisbalazs83]

Thank's Merlin!
384.14_beta3 works fine on AC66U_B1.
2.4GHz wifi much better.

 

[skeal]

Look at your System Log, it will tell you why. There's a good chance that either you are being throttled by Let's Encrypt's servers, or your /jffs partition is full.

Only error I see in the process is in system log:

Dec  7 17:05:40 kernel: cat: write error: Invalid argument

Nothing wrong with my jffs. It is so far from full.

4.34 / 63.00 MB

I left this over night and still the same in the morning. @RMerlin the throttling you speak of is not the issue as the log shows all the directories being created. Can I send you my logs in a private message please?