What's new

Beta Asuswrt-Merlin 386.1 Beta is 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.
First time a saw a timeout from an iPhone 12 due to inactivity.o_O
Code:
Dec 26 10:40:38 hostapd: eth7: STA fe:be:8f:XX:XX:XX IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)

AX88U Beta 2
5GHz fixed channel WPA2/WPA3
 
Last edited:
I couldn't find this in a search, so just wanted to mention that the Traffic Classification pie charts (adoptive qos section) aren't showing on my AX3000 running 386.1 beta 2, came from 384.19 with a gui restore/initialize and jffs format at boot before and after installation and manually configured settings -
 

Attachments

  • Screen Shot 2020-12-26 at 1.18.48 PM.png
    Screen Shot 2020-12-26 at 1.18.48 PM.png
    64.3 KB · Views: 174
Hi all and thank you RMerlin for your great work.

I own an Asus RT-AC86U and I use the Asus Merlin 386.1 beta 2. All is working fine but the Traffic Analyzer (both Traffic Monitor and Statistics) and the QOS Bandwidth Monitor.

The QOS Bandwidth Monitor shows only a few Kb/s when the real usage of the bandwidth is over 50 Mb/s. The Traffic Monitor starts to show traffic but, after a while, it goes completely out of scale (screenshot below):

traffic_monitor.png


Another example, in the QOS Classification I correctly see a 24,39 GB of "Video and Audio Streaming" traffic (screenshot below):

qos_classification.png


but in Traffic Analyzer Statistics I only have a few hundreds of MB of traffic in the same time range (screenshot below):

traffic_statistics.png


I state that I have also performed a factory reset and configured the router from scratch, but nothing has changed.

Is there someone who can help me to solve this problem?

Thank you.

Bye.
 
Last edited:
I'm missing GPLs for two models, so no, that won't be released soon.

Looks like Asus is right back to there old ways. Thought things would change with the 386 code base. 386.1 B2 does work quite well on the AX58U so guess it don't really matter at this time. Thanks for your efforts Merlin !!!
 
RT-AX86U
Web History has stopped and doesn't do updates anymore on beta 2

1609038646676.png


P.S.
Looks like a dance with a tambourine helped to resolve the issue. I turned on and then turned off Dual WAN.
 
Last edited:
You could release for the models you do have. Might help speed up any issues that may need addressing.
With a gigabit connection, how high have you seen the CPU load on the 3 cores?
 
so what's the consensus? Beta 1 or 2 guys?
 
2
 
I'm using stock asus firmware(3.0.0.4.386_40558)
Should I update to 386.1_beta2 and then re-register the devices in use node with AIMESH(2.0) ? (One Merlin Router and Two stock node)
(Wanna to check the temperature of each node)
3333.png
 
Running 386.1 beta 2 on AX86u, entware with only skynet and diversion installed, loads of DCD tainted errors.

(this is the last that crashed 18944 admin 15760 S < dcd -i 3600 -p 43200 -b -d /tmp/bwdpi/ )

Trying to see what might be causing the issue and disabled skynet. I set the syslog to debug. I noticed that I do not see any "Kernel Drop" log messages. Usually I get about 5-10 Skynet "block" per minute, in the past when skynet was disabled, these blocks would be replaced by the asus firewall with Drop. Now they seems they arent.

Why there is no Drops in the log?
 
Beta 2 of course!
 
Seeing these messages on RT-AX58U with latest 386.1 Beta 1 release. Not a critical issue or anything, just curious what these kernel messages are and if our fellow RT-AX58U users on latest 386.1 Beta 1 are seeing same messages. Noticed that @Trent Hubbert got these messages a couple months back on 384.19 Beta 1.

Dec 7 22:22:47 kernel: SUSPREQ 0 SUSPREQ1 0 SUSPREQ2 0
Dec 7 22:22:47 kernel: CHNSUSP_STATUS 0 CHNSUSP_STATUS1 0 CHNSUSP_STATUS2 0
Dec 7 22:22:47 kernel: FLUSHREQ 0 FLUSHREQ1 0 FLUSHREQ2 0
Dec 7 22:22:47 kernel: CHNFLUSH_STATUS 0 CHNFLUSH_STATUS1 0 CHNFLUSH_STATUS2 0
Dec 7 22:22:47 kernel: intstatus 0x0 intmask 0x10000 aqm_intstatus 0x0 aqm_intmask 0x0
Dec 7 22:22:47 kernel: DMA 0:
Dec 7 22:22:47 kernel: RX0: DMA64: rxd64 d6c10000 rxdpa 0x16c10000 rxdpahi 0x0 head d95fc740 tail d9696e40 rxin 1033 rxout 1533
Dec 7 22:22:47 kernel: rcvcontrol 0x36c0851 rcvaddrlow 0x16c10000 rcvaddrhigh 0x0 rcvptr 0x5fd0 rcvstatus0 0x20004090 rcvstatus1 0x4120 rxfilled 500
Dec 7 22:22:47 kernel: currdescr 1033 activedescr 1042 lastdescr 1533
Dec 7 22:22:47 kernel: rxuflo 0
Dec 7 22:22:47 kernel: TX0(p32): DMA64: txp (null) txd64 d51f0000 txdpa 0x151f0000 txdpahi 0x0 head (null) tail d56cb200 txin 6 txout 6 txavail 2047 txnodesc 0 flags:0x19c00
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x151f0000 xmtaddrhigh 0x0 xmtptr 0x60 xmtstatus0 0x20008980 xmtstatus1 0xca30
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: txuflo 0
Dec 7 22:22:47 kernel: AQM0: DMA64: txp (null) txd64 d6c74000 txdpa 0x16c74000 txdpahi 0x0 head (null) tail (null) txin 6 txout 6 txavail 1023 txnodesc 0 flags:0x500
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x16c74000 xmtaddrhigh 0x0 xmtptr 0x4060 xmtstatus0 0x10004060 xmtstatus1 0x4060
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0x0
Dec 7 22:22:47 kernel: DMA 1:
Dec 7 22:22:47 kernel: RX1: rxuflo 0
Dec 7 22:22:47 kernel: TX1(p33): DMA64: txp (null) txd64 d9078000 txdpa 0x19078000 txdpahi 0x0 head (null) tail d5708e40 txin 1187 txout 1187 txavail 2047 txnodesc 0 flags:0x19c00
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x19078000 xmtaddrhigh 0x0 xmtptr 0xca30 xmtstatus0 0x20008980 xmtstatus1 0xca30
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: txuflo 0
Dec 7 22:22:47 kernel: AQM1: DMA64: txp (null) txd64 d6c04000 txdpa 0x16c04000 txdpahi 0x0 head (null) tail (null) txin 224 txout 224 txavail 1023 txnodesc 0 flags:0x500
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x16c04000 xmtaddrhigh 0x0 xmtptr 0x4e00 xmtstatus0 0x10004e00 xmtstatus1 0x4e00
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0x0
Dec 7 22:22:47 kernel: DMA 2:
Dec 7 22:22:47 kernel: RX2: rxuflo 0
Dec 7 22:22:47 kernel: TX2(p34): DMA64: txp (null) txd64 d6ca8000 txdpa 0x16ca8000 txdpahi 0x0 head (null) tail d33b6740 txin 6 txout 6 txavail 2047 txnodesc 0 flags:0x19c00
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x16ca8000 xmtaddrhigh 0x0 xmtptr 0x8060 xmtstatus0 0x20008980 xmtstatus1 0xca30
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: txuflo 0
Dec 7 22:22:47 kernel: AQM2: DMA64: txp (null) txd64 d73f0000 txdpa 0x173f0000 txdpahi 0x0 head (null) tail (null) txin 3 txout 3 txavail 1023 txnodesc 0 flags:0x500
Dec 7 22:22:47 kernel: xmtcontrol 0x3780a41 xmtaddrlow 0x173f0000 xmtaddrhigh 0x0 xmtptr 0x30 xmtstatus0 0x10000030 xmtstatus1 0x30
Dec 7 22:22:47 kernel: DMA64: DMA avoidance applied 0
Dec 7 22:22:47 kernel: intstatus 0x0 intmask 0x0 aqm_intstatus 0x0 aqm_intmask 0x0
Dec 7 22:22:47 kernel: DMA 3:
Dec 7 22:22:48 kernel: dmada 0 dmade 0 rxoflo 0 dmape 0
Dec 7 22:22:48 kernel: txerr mac 0200 phy 8280 0000 0200 tst 2020 dur 0014
Dec 7 22:22:48 kernel: pctlen 0014 pctls 0a40 0000 0003 0000 0000 0000
Dec 7 22:22:48 kernel: plcp 00b4 0000 || 040a 05a0 0000 || 0000 0000 || 00

i've seen this on the latest stock firmware on my ax58u.
 
Updated all units from 386.19 Alpha 4 to Beta 2, then Hard Factory Reset to each. The re-setup of the Add-Ons (Diversion, Skynet, FlexQoS etc.) took awhile. All's running well.

1609098462259.png
1609098694623.png
 
Hey folks,

I got some funkiness with 386.1 beta 1 & 2. Didn't see the same problem with the stable 384.19 at all.

I have setup everything the same as I have done before like 384.19, except setting "All" on "Sync to AiMesh Node" for my guest wifi for both 2.4/5ghz. That's the only difference and the main reason to use 386.1. And I only have guest wifi on index 1.

My environment is an ax3000 as the main router, then ac86u, ac88u, ac1900 & ac68w all as aimesh nodes. All ethernet back haul to the aimesh nodes via the wan port. With google fiber 1g uplink to the internet. I don't use adaptive qos since I have 1g connection. Though, I do have all network protections on but no parental control.

I did a clean hard reset using the wps button for fresh setup.

The issue appears only on the ac68 (both ac1900 & ac68w) platform. Neither the ac86u nor ac88u have such issue.

The symptom is that everything working well fresh after install. But after a few days, on the ac68 nodes, for devices that connect via those 2 nodes either by wifi or ethernet ports, becomes sluggish, delayed, load extra slow, speed test goes down the toilet. It's like some artificial throttling. And it's not like it's not working or not resolving dns, it's just slow and delayed.

I tried rebooting all router and nodes, and tried rebooting just the ac68 nodes. It does not resolve the issue.

I also tested all my cables and ports and etc, all are in good conditions.

I don't see packet dropped in the ac68 nodes as far as I can tell.

I did a clean hard reset and started with fresh manual config again couple times, after few days, same thing happens no matter.

After spending quite a bit of time messing around and testing by disabling various options, I came to the conclusion of that the problem seems to be related to "Sync to AiMesh Node" option.

While the problem is going on with ac68 nodes, if I change the option to sync to "Router only", everything would right off the bat back to normal and working fine for the devices connected via the ac68 nodes.

Also if I remove the 5g guest one and leave the 2.4g with sync to all nodes, all things would be good and back to normal for the devices that connect via the ac68 nodes.

It's kinda strange and bizarre. The main thing is, it takes a few days before the problem appears from a fresh clean install/config.

Anyone has any idea what's going on? Or any idea/command I can run to check things out?

Or anyone seeing something similar?

Thanks.

-AC
 
Last edited:
This might not be your problem and it’s just a thought... You have an AX3000 and 4 AiMesh nodes. How large is your house? Actually, how wide is the area that you are trying to cover?

I had an AC68U running as a Media Bridge. I had installed the 386.1 code on my AX88u and two AX58u (both as nodes). One on each floor of my house. Ran well.
One day I thought, might as well update the AC68U and make it a nodes as well.
Over time, devices were connecting to odd nodes. The 68u was essentially in between the AX88u and the nodes.

I decided to turn the 68U back to Media Bridge and I feel my “system” is operating better

I wonder if there is such a thing as too many nodes?

You might want to try and disable one or two and see how things go...
 
same problem.... not using guest network at the moment because of that. It's the same with official beta version.

Ah... I see, damn I wasted so much time on this, at least it's not me, and appears the official beta version seems to have problem too.

Is there a thread somewhere talking about this? If so, appreciate if you could point it out to me.

Plus, how many nodes do you have, I'd like to see if JGrana's point is valid. But from the way you are talking about, it sounds like it's more an ac68 platform issue than number of nodes issue.

Thanks.

-AC
 
Not that huge honestly, but I have basement, so it's 3 story total. And I just like to have solid connection at every corner of my house... LOL!

I'll try your suggestion, but the thing is that it's only on my ac68 devices are having issue, if it's a number of node issue, I'd think that the ac86u/ac88u would have random issue too, but they don't.

Also, once I don't sync the guest network to all the aimesh nodes, there is no more problem any more.

Thanks.

-AC

This might not be your problem and it’s just a thought... You have an AX3000 and 4 AiMesh nodes. How large is your house? Actually, how wide is the area that you are trying to cover?

I had an AC68U running as a Media Bridge. I had installed the 386.1 code on my AX88u and two AX58u (both as nodes). One on each floor of my house. Ran well.
One day I thought, might as well update the AC68U and make it a nodes as well.
Over time, devices were connecting to odd nodes. The 68u was essentially in between the AX88u and the nodes.

I decided to turn the 68U back to Media Bridge and I feel my “system” is operating better

I wonder if there is such a thing as too many nodes?

You might want to try and disable one or two and see how things go...
 
I'm a noob at compiling and building, but I've been trying to compile and build the source code myself. Has anyone been able to do it? Are the commands on https://github.com/RMerl/asuswrt-merlin.ng/wiki/Compile-Firmware-from-source-using-Ubuntu still valid? Merlin says he uses a Ubuntu-Linux 20.04 LTS virtual machine, so I set up the same OS version on my VirtualBox, but the commands on the wiki don't quite work well. If anyone else has done it, could they share their build script?

After building, would the resultant firmware file match the SHA256 signature on https://www.asuswrt-merlin.net/download ?
 
same problem.... not using guest network at the moment because of that. It's the same with official beta version.

Ah... I found the discussion on the asuswrt official side. It seems to be isolated for ac68u/ac67u platform as the aimesh node.

I read that one person's workaround is to replace his/her ac68u with a different asus router that works, lol.

Oh well... not sure if I'd like to do that.

-AC
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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