What's new

Beta Asuswrt-Merlin 386.10 beta is now available for AC models

  • 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.
Giving this one a try. (The alpha did not rock it for me). Installation seamless so now let's see what it does in action.
 
Asuswrt-Merlin 386.10 beta is now available for Wifi 5 (AC) models.

Code:
  - NOTE: 386_xx releases are only for Wifi 5 (AC) models.
  - NEW: Added Site Survey page under Network Tools tab.
         (RT-AC86U/GT-AC2900).
  - UPDATED: dnsmasq to 2.89.
  - UPDATED: openvpn to 2.6.0.
  - UPDATED: openssl to 1.1.1t.
  - UPDATED: miniupnpd to 2.3.3.
  - UPDATED: Asus security daemon updated to 2.0 engine (patch
             from Asus)
  - CHANGED: Moved WiFi Radar and Site Survey to the
             Network Tools tab
  - CHANGED: Disabled auto logout on System Log and
             Wireless Log pages.
  - CHANGED: Reduced EDNS packet size from 1280 to 1232
             bytes in dnsmasq, to better work with some
             upstream servers not fully supporting EDNS0.
  - FIXED: NTP redirection wouldn`t work properly with
           Guest Network, removed redirection for these.
  - FIXED: Added missing Tools icon on ROG UI (icon
           contributed by Cody).
  - FIXED: RT-AC68U may crash when using Media Bridge mode
           with a specific SSID length (patch from Asus)

Please keep discussions in this thread on this specific release. This thread will eventually be locked once the release feedback has died down.

Downloads are here.
Changelog is here.
Performed dirty upgrade from 386.9 on my RT-AC5300 router (not running in Mesh mode) and everything is running fine after 24 hours operation.
 
I'm guessing that if there's anything set on what will be the node, it couldn't be added as a node until it was wiped clean with a reset. Then it was found immediately by the router over Ethernet. I may remove it and try to add it again over wifi to see if it finds it again under the same cirumstances as so many folks have been having problems adding a node. Just to see if the same trick works (reset the node prior to adding it)

It's been a few hours and still going strong. Rock Solid...

This is good practice for when I go to 388 family on my AX88u router, AX86u nodes
It actually makes logical sense- in the case of a power failure, the system SHOULD return to practically instant functionality without issue on resumption of power.
(It's also an argument to wire nodes to the router rather than relying on wireless connections...)
you shouldn't need to test - if a node is at factory settings, it'll do what it was programmed to do.
 
Not sure if Asus.com DDNS server is down or there is an issue with this Beta Firmware causing the DDNS status to show Inactive with a Request error.

Anyone else having issues?

View attachment 48344
As I set it up last night it did take almost an hour for the Let’s Encrypt Cert to get created, but once that was done getting the actual name (after three tries to find a unique one) was quick.
 
It actually makes logical sense- in the case of a power failure, the system SHOULD return to practically instant functionality without issue on resumption of power.
(It's also an argument to wire nodes to the router rather than relying on wireless connections...)
you shouldn't need to test - if a node is at factory settings, it'll do what it was programmed to do.
Not sure it has anything to do with a power outage.

Lots of people have challenges adding a node to make a mesh,have also complained that it’s really problematic under Merlín firmware, and so did I until I reset it. Wired or not, it wouldn’t be found until after being reset. The process and dependencies aren’t that well documented either which helps add to the mystery.

But if converting a working/configured device to a node, a reset so the device gets it config, ID and password like a brand new/fresh device which I suspect is what the adding a node process wants in order to find and access the device to add/config it as a node (bridge ‍♂️)

If like me, you get rushed and mislabeled the router and node, knowing the configured device names when you have the AT&T router scan for devices to setup passthrough after spending an hour trying to access the device and wondering why there’s no WiFi and are unable to access it will be extremely helpful
 
Dirty flash over 386.9_0, all OK!
tnxs Merlin
 
Dirty upgrade from second 386-10 alpha on 3 ac1900's and 3 ac68u's.
Thanks RMerlin.
 
I notice that the VPN speed of my openvpn is 20% slower on the beta than on 386.7.2
Tested side by side with my two AC5300's on Openvpn provider Proton. Configuration: identical except the firmware release. Anyone a suggestion? When I switch off the VPN the speed on both routers is the same.
No temp rises or extra cpu load, no faulty packets. Simply 20% on average less speed with Opevpn and the beta.
 
Had an issue with scribe and the filters. Fresh install on AC5300's. SPDMerlin, OpenVPN wasn't showing up, a few others as well that typically do within Scribe/UIScribe. Skynet did show up though.

Not sure if I didn't create the issue by instaling scripts in the wrong order or not. Copied the filters from the logrotate and syslog-ng.d example directories to the actual logrotate.d and syslog-ng.d directories and restarted Scribe (which restarted UIScribe) taking care of the problem. So far so good, but with better visibily of the log I'll be able to share any results...

Not directly related to the beta but remains a bug/issue:
Though 802.11b was disabled on the router via the GUI, on the node it remained enabled - not a Merlin issue but a AIMesh/Wireless closed source one. In NVRAM wl0_rateset=ofdm/default (ofdm=802.11b disabled / default=802.11b enabled) - set, commit, reboot node, solved
 
Since updating to 386.10 beta on my RT-AC68U I occasionally see the following in my logs. I haven't seen that since I've owned the RT-AC68U

acsd: eth1: NONACSD channel switching to channel spec: 0x180a (8l)
acsd: eth1: NONACSD channel switching to channel spec: 0x1008 (8)
acsd: eth1: NONACSD channel switching to channel spec: 0x180a (8l)
 
Since updating to 386.10 beta on my RT-AC68U I occasionally see the following in my logs. I haven't seen that since I've owned the RT-AC68U

acsd: eth1: NONACSD channel switching to channel spec: 0x180a (8l)
acsd: eth1: NONACSD channel switching to channel spec: 0x1008 (8)
acsd: eth1: NONACSD channel switching to channel spec: 0x180a (8l)
Maybe see this old thread with somewhat similar log entries:
https://www.snbforums.com/threads/r...13-is-now-available.57860/page-54#post-529473
And RMerlin's response:
https://www.snbforums.com/threads/r...13-is-now-available.57860/page-54#post-529540
Don't use 40 Mhz on the 2.4 GHz band, switch to 20 MHz. Acsd is detecting interference, and downgrading your channel width.
 
Not sure if it had anything to do specifically with 386.10 or just a "regular" TM/Asus glitch, but wred crashed this afternoon on my RT-AC66U B1 running 386.10_beta1, dirty flashed from 386.9.

Code:
Mar  8 16:56:19 kernel: wred/1111: potentially unexpected fatal signal 11.
Mar  8 16:56:19 kernel: Pid: 1111, comm:                 wred
Mar  8 16:56:19 kernel: CPU: 1    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:19 kernel: PC is at 0x40431b18
Mar  8 16:56:19 kernel: LR is at 0x4021f96c
Mar  8 16:56:19 kernel: pc : [<40431b18>]    lr : [<4021f96c>]    psr: 80000010
Mar  8 16:56:19 kernel: sp : bdbfd1c8  ip : 40229f50  fp : 000009e0
Mar  8 16:56:19 kernel: r10: 000000f0  r9 : 40452180  r8 : 00000000
Mar  8 16:56:19 kernel: r7 : 404521b4  r6 : 0040a5b0  r5 : 4044c4f8  r4 : 000000e0
Mar  8 16:56:19 kernel: r3 : 0000001c  r2 : 00000000  r1 : 4044d27c  r0 : 40452180
Mar  8 16:56:19 kernel: Flags: Nzcv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:19 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
Mar  8 16:56:20 kernel: wred/1112: potentially unexpected fatal signal 11.
Mar  8 16:56:20 kernel: wred/1113: potentially unexpected fatal signal 11.
Mar  8 16:56:20 kernel: Pid: 1113, comm:                 wred
Mar  8 16:56:20 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:20 kernel: PC is at 0x403f6a8c
Mar  8 16:56:20 kernel: LR is at 0x402207ac
Mar  8 16:56:20 kernel: pc : [<403f6a8c>]    lr : [<402207ac>]    psr: 80000010
Mar  8 16:56:20 kernel: sp : bd7ffdf0  ip : 40229f60  fp : bd7ffe6c
Mar  8 16:56:20 kernel: r10: 4022e020  r9 : 4022e3dc  r8 : 00000000
Mar  8 16:56:20 kernel: r7 : 000000b3  r6 : bd7ffea0  r5 : bd7ffe00  r4 : 40229d74
Mar  8 16:56:20 kernel: r3 : 00000000  r2 : 80000000  r1 : 00000008  r0 : fffffdfe
Mar  8 16:56:20 kernel: Flags: Nzcv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:20 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
Mar  8 16:56:20 kernel: wred/1110: potentially unexpected fatal signal 11.
Mar  8 16:56:20 kernel: Pid: 1110, comm:                 wred
Mar  8 16:56:20 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:20 kernel: PC is at 0x403f6a8c
Mar  8 16:56:20 kernel: LR is at 0x402207ac
Mar  8 16:56:20 kernel: pc : [<403f6a8c>]    lr : [<402207ac>]    psr: 80000010
Mar  8 16:56:20 kernel: sp : bddffdf0  ip : 40229f60  fp : bddffe6c
Mar  8 16:56:20 kernel: r10: 4022e020  r9 : 4022e3dc  r8 : 00000000
Mar  8 16:56:20 kernel: r7 : 000000b3  r6 : bddffea0  r5 : bddffe00  r4 : 40229d74
Mar  8 16:56:20 kernel: r3 : 00000000  r2 : 80000000  r1 : 00000008  r0 : fffffdfe
Mar  8 16:56:20 kernel: Flags: Nzcv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:20 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
Mar  8 16:56:20 kernel: wred/1106: potentially unexpected fatal signal 11.
Mar  8 16:56:20 kernel: Pid: 1106, comm:                 wred
Mar  8 16:56:20 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:20 kernel: PC is at 0x403f5890
Mar  8 16:56:20 kernel: LR is at 0x4021fee4
Mar  8 16:56:20 kernel: pc : [<403f5890>]    lr : [<4021fee4>]    psr: 60000010
Mar  8 16:56:20 kernel: sp : be5fd440  ip : 40229de8  fp : 0007c210
Mar  8 16:56:20 kernel: r10: 00000000  r9 : 00078748  r8 : 4044d27c
Mar  8 16:56:20 kernel: r7 : 000000a2  r6 : 001e8481  r5 : be5fd468  r4 : 00000000
Mar  8 16:56:20 kernel: r3 : 00000001  r2 : 00000230  r1 : 00000000  r0 : fffffdfc
Mar  8 16:56:20 kernel: Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:20 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
Mar  8 16:56:20 kernel: wred/1095: potentially unexpected fatal signal 11.
Mar  8 16:56:20 kernel: Pid: 1095, comm:                 wred
Mar  8 16:56:20 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:20 kernel: PC is at 0x403f4878
Mar  8 16:56:20 kernel: LR is at 0x402204bc
Mar  8 16:56:20 kernel: pc : [<403f4878>]    lr : [<402204bc>]    psr: 60000010
Mar  8 16:56:20 kernel: sp : befe7c00  ip : 40229dfc  fp : 00000001
Mar  8 16:56:20 kernel: r10: 0033f2d8  r9 : 002607d8  r8 : 0002b110
Mar  8 16:56:20 kernel: r7 : 000000fc  r6 : ffffffff  r5 : 00000009  r4 : 00353828
Mar  8 16:56:20 kernel: r3 : ffffffff  r2 : 00000020  r1 : 00353828  r0 : fffffffc
Mar  8 16:56:20 kernel: Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:20 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
Mar  8 16:56:20 kernel: wred/1108: potentially unexpected fatal signal 11.
Mar  8 16:56:20 kernel: Pid: 1108, comm:                 wred
Mar  8 16:56:20 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:20 kernel: PC is at 0x403f5890
Mar  8 16:56:20 kernel: LR is at 0x4021fee4
Mar  8 16:56:20 kernel: pc : [<403f5890>]    lr : [<4021fee4>]    psr: 60000010
Mar  8 16:56:20 kernel: sp : be1fd1f0  ip : 40229de8  fp : 004613b0
Mar  8 16:56:20 kernel: r10: 00000000  r9 : 003f8c04  r8 : 4044d27c
Mar  8 16:56:20 kernel: r7 : 000000a2  r6 : 001e8481  r5 : be1fd218  r4 : 00000000
Mar  8 16:56:20 kernel: r3 : 00000001  r2 : 00000230  r1 : 00000000  r0 : 00000000
Mar  8 16:56:20 kernel: Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:20 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
Mar  8 16:56:20 kernel: wred/1097: potentially unexpected fatal signal 11.
Mar  8 16:56:20 kernel: Pid: 1097, comm:                 wred
Mar  8 16:56:20 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:20 kernel: PC is at 0x403f5890
Mar  8 16:56:20 kernel: LR is at 0x4021fee4
Mar  8 16:56:20 kernel: pc : [<403f5890>]    lr : [<4021fee4>]    psr: 60000010
Mar  8 16:56:20 kernel: sp : be7ffde8  ip : 40229de8  fp : be7ffe6c
Mar  8 16:56:20 kernel: r10: 4022e020  r9 : 4022e3dc  r8 : 00000000
Mar  8 16:56:20 kernel: r7 : 000000a2  r6 : befe7c98  r5 : be7ffe30  r4 : be7ffe30
Mar  8 16:56:20 kernel: r3 : 00000000  r2 : 00000230  r1 : be7ffe30  r0 : fffffdfc
Mar  8 16:56:20 kernel: Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:20 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
Mar  8 16:56:20 kernel: wred/1107: potentially unexpected fatal signal 11.
Mar  8 16:56:20 kernel: Pid: 1107, comm:                 wred
Mar  8 16:56:20 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:20 kernel: PC is at 0x403f64cc
Mar  8 16:56:20 kernel: LR is at 0x40664
Mar  8 16:56:20 kernel: pc : [<403f64cc>]    lr : [<00040664>]    psr: 60000010
Mar  8 16:56:20 kernel: sp : be3fd598  ip : 002556d0  fp : 0000000e
Mar  8 16:56:20 kernel: r10: ffffffff  r9 : 002555c4  r8 : 003fc048
Mar  8 16:56:20 kernel: r7 : 0000008e  r6 : be3fd65c  r5 : be3fd6dc  r4 : be3fd6e0
Mar  8 16:56:20 kernel: r3 : 00000000  r2 : 00000000  r1 : be3fd660  r0 : 00000001
Mar  8 16:56:20 kernel: Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:20 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
Mar  8 16:56:20 kernel: wred/1109: potentially unexpected fatal signal 11.
Mar  8 16:56:20 kernel: Pid: 1109, comm:                 wred
Mar  8 16:56:20 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:20 kernel: PC is at 0x403f6a8c
Mar  8 16:56:20 kernel: LR is at 0x402207ac
Mar  8 16:56:20 kernel: pc : [<403f6a8c>]    lr : [<402207ac>]    psr: 80000010
Mar  8 16:56:20 kernel: sp : bdfffdf0  ip : 40229f60  fp : bdfffe6c
Mar  8 16:56:20 kernel: r10: 4022e020  r9 : 4022e3dc  r8 : 00000000
Mar  8 16:56:20 kernel: r7 : 000000b3  r6 : bdfffea0  r5 : bdfffe00  r4 : 40229d74
Mar  8 16:56:20 kernel: r3 : 00000000  r2 : 80000000  r1 : 00000008  r0 : fffffdfe
Mar  8 16:56:20 kernel: Flags: Nzcv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:20 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
Mar  8 16:56:20 kernel: Pid: 1112, comm:                 wred
Mar  8 16:56:20 kernel: CPU: 1    Tainted: P             (2.6.36.4brcmarm #1)
Mar  8 16:56:20 kernel: PC is at 0x403f6a8c
Mar  8 16:56:20 kernel: LR is at 0x402207ac
Mar  8 16:56:20 kernel: pc : [<403f6a8c>]    lr : [<402207ac>]    psr: 80000010
Mar  8 16:56:20 kernel: sp : bd9ffdf0  ip : 40229f60  fp : bd9ffe6c
Mar  8 16:56:20 kernel: r10: 4022e020  r9 : 4022e3dc  r8 : 00000000
Mar  8 16:56:20 kernel: r7 : 000000b3  r6 : bd9ffea0  r5 : bd9ffe00  r4 : 40229d74
Mar  8 16:56:20 kernel: r3 : 00000000  r2 : 80000000  r1 : 00000008  r0 : fffffdfe
Mar  8 16:56:20 kernel: Flags: Nzcv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar  8 16:56:20 kernel: Control: 10c53c7d  Table: 9a93804a  DAC: 00000015
 
Not sure if it had anything to do specifically with 386.10 or just a "regular" TM/Asus glitch, but wred crashed this afternoon on my RT-AC66U B1 running 386.10_beta1, dirty flashed from 386.9.
This is one for @RMerlin I think...
 
Been awhile since I worked with AC Asus router on Merlin routers (AC5300 and Node, both 386.10) so not exactly sure if these are relavent or a bug in the beta.
Did do some Googling that showed that these were or might be related to TrendMicro / Traffic Analyzer / 40Mhz bandwidth on 2.4Ghz but all of these are off/disabled and these keep coming up in the log.
Or is it that the log is to verbose and these errors don't matter?

Repeats in Log:
Mar 9 17:03:16 RT-AC5300 rstats[557]: Problem loading /mnt/AMTM/tomato_rstats_1831bfab0680.gz. Still trying...
Mar 9 17:12:02 RT-AC5300 kernel: D0:FC:D0:21:34:B1 not exist in UDB, can't delete it
Mar 9 17:16:43 RT-AC5300 kernel: 00:11:32:61:44:FF not mesh client, can't delete it
Mar 9 17:16:43 RT-AC5300 kernel: D0:FC:D0:21:34:B1 not exist in UDB, can't delete it
Mar 9 17:18:17 RT-AC5300 rstats[557]: Problem loading /mnt/AMTM/tomato_rstats_1831bfab0680.gz. Still trying...
Mar 9 17:22:51 RT-AC5300 kernel: D0:FC:D0:21:34:B1 not exist in UDB, can't delete it
Mar 9 17:26:01 RT-AC5300 kernel: D0:FC:D0:21:34:B1 not exist in UDB, can't delete it

Mar 9 17:28:00 RT-AC5300 kernel: [tdts_shell_ioctl_stat:256] Recv ioctl req with op 2
 
Been awhile since I worked with AC Asus router on Merlin routers (AC5300 and Node, both 386.10) so not exactly sure if these are relavent or a bug in the beta.
Did do some Googling that showed that these were or might be related to TrendMicro / Traffic Analyzer / 40Mhz bandwidth on 2.4Ghz but all of these are off/disabled and these keep coming up in the log.
Or is it that the log is to verbose and these errors don't matter?
Are you running any AMTM scripts on the AC5300 or nodes? Your errors appear related to AMTM. Or do you have a USB hard drive attached?

Generally most seem to say using Asus stock firmware on AiMesh nodes is the way to go rather than using Asus-Merlin.
 
Are you running any AMTM scripts on the AC5300 or nodes? Your errors appear related to AMTM. Or do you have a USB hard drive attached?

Generally most seem to say using Asus stock firmware on AiMesh nodes is the way to go rather than using Asus-Merlin.
On the AC5300 router (same scripts as on my AX88), on the node SCMerlin and the LED scheduler and yes on the USB Stick (not HD) in both. Since I haven't used the 5300's since 386.3 and haven't used as AC based router in awhile I'm not familiar with what to expect in the log, but thse messages are captured/generated at the router.

I haven't installed/configured scribe on the node to forward to the router or the router to receive them or from the AT&T router/modem, yet. I've seen mention of enabling a Guest network causes some of this as well. If it's noise, I'll set the log levels to ignore them, if it's indicative of a problem then I can fix/reconfig to resolve it.

Just don't know whether it's something I need to be concerned with, or something to be ignored. That's the core issue, some to fix or something to ignore...
 
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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