Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[PretorianADB]

Nothing!!! Still unable to use ethernet backhaul!!!!
someone can help me?

 

[SBSTNGRSS]

Same for me with my two RT-AC88U. Ethernet backhaul is not working with all possible options.

Nothing!!! Still unable to use ethernet backhaul!!!!
someone can help me?
View attachment 27651View attachment 27652View attachment 27653View attachment 27654

 

[Maverick009]

Same for me with my two RT-AC88U. Ethernet backhaul is not working with all possible options.

Did you just do an in place upgrade of the firmware or clean install? If it was just an upgrade over the previous firmware and settings kept, I would try a using the firmware restoration to do a clean install of the beta firmware as that should work and correct any lingering problems that may of carried over from the previous firmware.

 

[bradbort]

Just installed latest beta in AX88U today 11/14/2020. Unfortunately, it knocked my Brother MFC l2750DW offline. It is connected to the network, but neither pc nor airprint clients can see it anymore. Anyone have any ideas? It is showing as connected in the GUI. Everything else is working fine, from PCs to Idevices, to IOT devices. Just the printer...that I really need

 

[bradbort]

Just installed latest beta in AX88U today 11/14/2020. Unfortunately, it knocked my Brother MFC l2750DW offline. It is connected to the network, but neither pc nor airprint clients can see it anymore. Anyone have any ideas? It is showing as connected in the GUI. Everything else is working fine, from PCs to Idevices, to IOT devices. Just the printer...that I really need

I fixed this my removing the fixed address I had assigned to the printer, and rebooting the router. Must have been some sort of fargled up address issue.

 

[OzarkEdge]

Nothing!!! Still unable to use ethernet backhaul!!!!
someone can help me?
View attachment 27651View attachment 27652View attachment 27653View attachment 27654

Is that a router sitting on a subwoofer magnet?

OE

 

[L&LD]

I think it is! oops!

 

[PretorianADB]

Is that a router sitting on a subwoofer magnet?

OE

Yes but is only for a test, is not his usual place...

 

[cannondale]

Nothing!!! Still unable to use ethernet backhaul!!!!
someone can help me?
View attachment 27651View attachment 27652View attachment 27653View attachment 27654

Try this:
1) Remove AiMesh node(s) from main router (through Web UI)
2) Power cycle the main router and nodes (full off, then on again, not just reboot)
3) Add mesh nodes back to main router.

Hopefully Ethernet backhaul is now recognized. It worked for me on an AC68U that I recently upgraded to the newest firmware, where I also got stuck in WiFi backhaul.

 

[Moabdave]

Well another Saturday, another beta build of firmware. And another round of using paperclips to unfreeze frozen routers. I kinda like being a beta tester, but it's a little frustrating when I've reported the same bug for 3 firmware releases and that bug is not acknowledged as even existing. (Router frozen to the point it has to have the paper clip reset to respond is what I'd call a serious bug). Just in case someone in Asus is listening this time, my setup one last time:
Main router GT-AC5300
2 AiMesh nodes, both RT-AC88Us.
All connected via Ethernet cables, 1 unmanaged switch between main router and both nodes. System works with 384/385 firmware using Ethernet backhaul.
With 386 RC-8, and factory resets on all 3 routers, I can successfully add the first RC88U as an AiMesh node, if using Wi-Fi backhaul. If I stop here, the system appears to work.

The process hangs if I switch to Ethernet preferred or Ethernet only.

The bigger issues is as soon as I try to add the 2nd 88U, routers will freeze. On a good attempt only the two 88U's will freeze. However, sometimes (including one of the attempts today) all 3 will freeze. Must use paperclip reset to restore functionality.

With RC-7 and prior that was a true hard freeze, no sign of life on the frozen routers. With RC-8 it's somewhat improved. On the AImesh nodes I have intermittent connections on the Ethernet devices, but they complain about the intermittent connection and cannot fully function. No Wi-Fi connections on mesh nodes. Wi-Fi and Ethernet on the main router would continue to function, however I cannot access the GUI for the Router administration from either Wi-Fi or Ethernet connected devices to see any status or other information.

Once I give up and downgrade to 384/385 the system springs back to life. I don't even need to do a factory reset.

 

[Moabdave]

Hopefully Ethernet backhaul is now recognized. It worked for me on an AC68U that I recently upgraded to the newest firmware, where I also got stuck in WiFi backhaul.

However he has an AC88U, not an 86U. I am 1000% convinced there is a bug specific to the AC88U in the 386 beta firmware. If you scroll through the archives there's 3-4-5 of us, myself included, that have been screaming they can't get the system working with the 88U for some time. To my knowledge not one beta tester has said they have a working system when an 88U is involved. Initially I was just "oh well, I'll wait until the next build comes out", but now I'm getting more cynical that ASUS is even testing that model.

 

[cannondale]

However he has an AC88U, not an 86U. I am 1000% convinced there is a bug specific to the AC88U in the 386 beta firmware. If you scroll through the archives there's 3-4-5 of us, myself included, that have been screaming they can't get the system working with the 88U for some time. To my knowledge not one beta tester has said they have a working system when an 88U is involved. Initially I was just "oh well, I'll wait until the next build comes out", but now I'm getting more cynical that ASUS is even testing that model.

All I can offer is that when I upgraded my 68U to the latest production "3.0.0.4.386_40558" firmware (which uses the new AiMesh model), my one AiMesh node was stuck on WiFi backhaul, even though on the previous FW it was recognized as an Ethernet-connection node. I tried a few things, and the only thing that worked for me was to remove it from my main router, wait for it to factory reset, and then add it back as a new node. It was then immediately recognized for Ethernet backhaul. Every router is different of course.

 

[SandmanXX]

Well.... the GT-AC5300, primary router, firmware 9.0.0.4.386_40947-g7e1d916 , and the AX55, working as a AP router/aimesh node, altho I can't get it to be a node, is running firmware 9.0.0.4.386_40947-g7e1d916. For the life of me, following directions -exactly-, can not get the rx55 to be added as an aimesh node from the GT-5300. Could this be by design? I've tried it several times, both using the web UI and the app, where I can see both routers. The AX is sending off some odd SSIDs, not the same as the 5300, I'm assuming that's ok when trying to get it to be an aimesh node.
I even set up the router to operate as the AP/Aimesh node, which is what I ultimately want, and it still didn't work, even after the UI asks if I'm ok with clearing the AX and following through. I end up not being able to find a aimesh node.
Getting a RT-AX88U in the mail monday, I was hoping I could get some things set up ahead of time, at least getting the experience dealing with the setup, yeesh. Don't know what I'm missing.

 

[y-y]

Tested both RC7 and RC8 on a RT-AC5300 (on Verizon FIOS network). Got WAN IP address and internet connection, but the connection only maintained for a short period of time (like a minute). The network map showed Internet Status: Disconnected.

Tried:

- removed RT-AC68U node;​

- set DHCP query frequency to Normal and Continuous mode;​

- restored to factory default without custom setting changes (except SSIDs and WPA2).​

No stable internet connection.

Restored to 384_82072, got stable internet connection.

Retested RC8 on RT-AC5300, and I found the problem. When guest network 1 is enabled and once clients are connected to the guest network 1, internet connection will get disconnected. Workaround: use guest network 2 instead.

Anyone experiencing the same problem, or just me?

If this is really a problem, I hope it will get fixed because guest network 2 doesn't get replicated to the mesh nodes.

 

[Neil62]

@ASUSWRT_2020

Checked again today and still no RC8 firmware for the RT-AC86U, what's going on?

If the RT-AC86U is not going to receive RC8, please change the release notes for RC8 to indicate so.

 

[Squall Leonhart]

These beta's are not applying DST correction properly.

System timezone is set to GMT +10 Canberra/Melb/Syd and the DST time zone changes have been adjusted to the first sunday of october and april respectively,

General log says DST is active but reports 7:30pm as the time. It's 8:30pm.

 

[Stephen Harrington]

These beta's are not applying DST correction properly.

I can confirm this behaviour - I’m also in GMT +10 Canberra, Melbourne, Sydney.

 

[Squall Leonhart]

I can confirm this behaviour - I’m also in GMT +10 Canberra, Melbourne, Sydney.

It seems to be applying GMT +9? or DST is just broken for Canberra/Melb/Syd.
The Hobart setting applies +11 with DST enabled and its a +10 timezone.

 

[Scottp]

I'm currently on RC2-7, and for me it has been very solid. No random reboots at all, which was my biggest aggravation with the stock fw on my three XT8's. Now, I every so often experience some slowdowns. It feels as if datatransfer suddenly halts for some time and starts up again. I started looking at the systemlogs (again), and see this recurring:

Nov 14 07:18:47 kernel: CPU: 1 PID: 4378 Comm: dcd Tainted: P O 4.1.52 #2
Nov 14 07:18:47 kernel: Hardware name: Generic DT based system
Nov 14 07:18:47 kernel: [<c0026e60>] (unwind_backtrace) from [<c0022c38>] (show_stack+0x10/0x14)
Nov 14 07:18:47 kernel: [<c0022c38>] (show_stack) from [<c04b9f5c>] (dump_stack+0x8c/0xa0)
Nov 14 07:18:47 kernel: [<c04b9f5c>] (dump_stack) from [<c003aaec>] (get_signal+0x490/0x558)
Nov 14 07:18:47 kernel: [<c003aaec>] (get_signal) from [<c00221d0>] (do_signal+0xc8/0x3ac)
Nov 14 07:18:47 kernel: [<c00221d0>] (do_signal) from [<c0022658>] (do_work_pending+0x94/0xa4)
Nov 14 07:18:47 kernel: [<c0022658>] (do_work_pending) from [<c001f4cc>] (work_pending+0xc/0x20)
Nov 14 07:26:44 kernel: CPU: 1 PID: 11763 Comm: dcd Tainted: P O 4.1.52 #2
Nov 14 07:26:44 kernel: Hardware name: Generic DT based system
Nov 14 07:26:44 kernel: task: d5516400 ti: ce1c8000 task.ti: ce1c8000
Nov 14 07:26:44 kernel: PC is at 0xb6c7e39c
Nov 14 07:26:44 kernel: LR is at 0x1dd14
Nov 14 07:26:44 kernel: pc : [<b6c7e39c>] lr : [<0001dd14>] psr: 600f0010
Nov 14 07:26:44 kernel: sp : bee7d9e8 ip : 000a2050 fp : b5fff024
Nov 14 07:26:44 kernel: r10: 000a23c4 r9 : b5fffca8 r8 : 000a287c
Nov 14 07:26:44 kernel: r7 : b5fffce0 r6 : 000a2876 r5 : 00000000 r4 : b5fffc8c
Nov 14 07:26:44 kernel: r3 : 00000000 r2 : 00000000 r1 : 0007d612 r0 : 00000000

This was the kind of logs that was present during the time of random reboots. I have this sneaking suspicion that they (Asus) have somehow patched the FW to not trigger a reboot when this occurs, rather than fix the underlying problem. Maybe i'm paranoid - or just have three faulty XT8's

I have xt8 and was getting kernel stack traces in RC2-7 - stopped happening in rc2-8

 

[RMerlin]

Checked again today and still no RC8 firmware for the RT-AC86U, what's going on?

Maybe the fact that it's the weekend, and nobody's working at their office right now?

Just be patient... These are beta builds, they are hardly a matter of life and death.