What's new

Beta Asuswrt-Merlin 386.1 Beta is now available

Status
Not open for further replies.
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
 
Works fine with beta 2 and ax88u coming from 384.19, but I just figured out that skynet is offline.
When I try to run "firewall" I get this. I cant recognise the usb that was there before?

Skynet: [*] USB Not Found - Sleeping For 10 Seconds ( Attempt 1 Of 10 )
 
Last week I purchased an AC86U router so I could use my two AC66u-B1 routers as aimesh-nodes. First I installed the lastest Merlin firmware on all of them. That resultated in a bootloop and the only way out was to revert back. So i reverted al the routers back to the latest stock firmware of ASUS and bind the AC66 agian as an Aimeshnode. The router is very buggy, if i only do a restart it boots several times and i'm afraid to get again in bootloop. Also the protocol 0800 is buggy message is in my log. My configuration is an Ziggo Modem bridged to AC86U -> an TP link switch and two AC66u B1 nodes. I hope anyone van tell me the trick and i can solve this because before the AC66U was my router and rock stable!
 
I have an issue with 5Ghz wifi in Beta 2.
If I choose to Enable 160 Mhz and Control Channel: Auto, the channel 100 is on and all seems to be working. However, if I set the channel 100 manually, 5Ghz is off and doesn't present in Air. The same problem with other manually set up channels, 112, 116 etc.
 
Status
Not open for further replies.

Similar 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!
Back
Top