Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0

[OzarkEdge]

rt-ax88u + rt-ax58u backhaul wireless (with AX) seems to work fine with latest version.
Only thing, which is a question mark for me. How does biding work?
I tried it to bind my oneplus nord to aimesh node(ax58u). It was attached there, then I wanted to check what happen if aimesh node goes down suddenly...does it connect to main router if possible. That worked fine. But when I turned aimesh node back on, it did not go back to that.

Perhaps wait or reconnect the client to see if it honors its binding.

OE

 

[SloPoke]

I'm trying to go back to the RC2-4 firmware. I can do that on the router, but the nodes don't stay connected long enough to do the downgrade. Guess I'm going to have to connect to each with an ethernet cable from my laptop and downgrade. A real pain in the neck.

 

[Mattias]

Perhaps wait or reconnect the client to see if it honors its binding.

OE

Yes reconnect helps...but that seems not to be the correct way? I mean the reason why i did try this. Is to have iot devices that has bad connection to main router. I want the to connect always to the aimesh node where the connection is good. Only connect to the main if something goes wrong, like the aimesh node goes down or I update firmware on it or something like that. But it should recover and go back automatically(I would think?)

 

[OzarkEdge]

Yes reconnect helps...but that seems not to be the correct way? I mean the reason why i did try this. Is to have iot devices that has bad connection to main router. I want the to connect always to the aimesh node where the connection is good. Only connect to the main if something goes wrong, like the aimesh node goes down or I update firmware on it or something like that. But it should recover and go back automatically(I would think?)

Should, but perhaps not all IoT are created equal or smart enough. That and security and privacy and consumer lock-in and early obsolescence and ... seem to be IoT traits.

Maybe when the connection release is renewed the IoT device will return to its binding? If so, can it tolerate that delay?

OE

 

[cniedzi]

@ASUSWRT_2020 Thx, my preferable backhauls are set to correct routers as you've shown, but AiMesh reconfigures itself after some time (and I don't know why)

Btw. I have noticed higher RSSI values with 386 FW vs 384

This is a system log including automatic AiMesh reconfiguration events from optimum to not optimum backhauls:

....
Oct 23 17:02:22 kernel: invalid dirty_p detected: ffffffc000000000 valid=[ffffffc03c919a40 ffffffc03c919b80]
...

Oct 23 17:02:28 wlceventd: wlceventd_proc_event(474): eth7: Deauth_ind A4:349:FD:6A:06, status: 0, reason: Unspecified reason (1)
Oct 23 17:02:28 kernel: CONSOLE: 234473.435 wl1.0: wlc_ampdu_flush_scb_tid flushing 0 packets for a4:34:d9:fd:6a:06 AID 27 tid 0
Oct 23 17:02:28 kernel: CONSOLE: 234473.435 wl1.0: wlc_ampdu_flush_scb_tid flushing 0 packets for a4:34:d9:fd:6a:06 AID 27 tid 1
Oct 23 17:02:28 kernel: CONSOLE: 234473.435 wl1.0: wlc_ampdu_flush_scb_tid flushing 0 packets for a4:34:d9:fd:6a:06 AID 27 tid 2
Oct 23 17:02:28 kernel: CONSOLE: 234473.435 wl1.0: wlc_ampdu_flush_scb_tid flushing 0 packets for a4:34:d9:fd:6a:06 AID 27 tid 3
Oct 23 17:02:28 kernel: CONSOLE: 234473.435 wl1.0: wlc_ampdu_flush_scb_tid flushing 0 packets for a4:34:d9:fd:6a:06 AID 27 tid 4
Oct 23 17:02:28 kernel: CONSOLE: 234473.435 wl1.0: wlc_ampdu_flush_scb_tid flushing 0 packets for a4:34:d9:fd:6a:06 AID 27 tid 5
Oct 23 17:02:28 kernel: CONSOLE: 234473.435 wl1.0: wlc_ampdu_flush_scb_tid flushing 0 packets for a4:34:d9:fd:6a:06 AID 27 tid 6
Oct 23 17:02:28 kernel: CONSOLE: 234473.435 wl1.0: wlc_ampdu_flush_scb_tid flushing 0 packets for a4:34:d9:fd:6a:06 AID 27 tid 7
Oct 23 17:02:28 kernel: CONSOLE: 234473.435 wl1: random key value: 2283F8E062D759041AB3027FEA17837591B7DC3ACA4E0DFF7A1F2EB81DD142DF
Oct 23 17:02:28 kernel: CONSOLE: 234473.436 wl1: wlc_txbf_delete_link_serve failed for a4:34:d9:fd:6a:06
Oct 23 17:02:28 kernel: CONSOLE: 234473.439 iov:SCB_DEAUTH
Oct 23 17:02:28 kernel: CONSOLE: 234473.439 iov:SCB_DEAUTH
Oct 23 17:02:30 kernel: invalid dirty_p detected: ffffffc000000000 valid=[ffffffc03d8b4d40 ffffffc03d8b4e80]

...

is there any reason?

 

[lilstone87]

@dave14305 This is what I got back, when I ran that command. I am on my AX88U.

Firmware Version: 9.0.0.4.386_40577

filter parent 1: protocol all pref 3 u32 fh 807::800 order 2048 key ht 807 bkt 0                                                                                                                                                                                                 flowid 1:13
  mark 0x80000000 0xc03f0000 (success 278)

 

[dave14305]

@dave14305 This is what I got back, when I ran that command. I am on my AX88U.

Firmware Version:9.0.0.4.386_40577

filter parent 1: protocol all pref 3 u32 fh 807::800 order 2048 key ht 807 bkt 0 flowid 1:13
  mark 0x80000000 0xc03f0000 (success 278)

Thanks. Same old, same old.

 

[drabisan]

Yes, Ethernet Backhaul Mode is checked and always has been. Ok, reset the router and set it up again. Reset one of the nodes and added it back in again. It gets added with a weak wireless backhaul despite ethernet backhaul being checked, stays connected for about a minute, and then disconnects entirely.

I don't have the same router models. My router is a GT-AC5300 and node it's a RT-AX88U. With "Ethernet Backhaul Mode" on, if I unplug the cable it doesn't fail over to wifi. I simply loose the node and all the hosts behind it (wifi ones will eventually connect to router over 2.4, but wireless clients are dead no matter how much I wait).
It may be an inconsistent behavior between models.
I have 0 ideas why this is happening to you.

 

[semigator]

Yes reconnect helps...but that seems not to be the correct way? I mean the reason why i did try this. Is to have iot devices that has bad connection to main router. I want the to connect always to the aimesh node where the connection is good. Only connect to the main if something goes wrong, like the aimesh node goes down or I update firmware on it or something like that. But it should recover and go back automatically(I would think?)

I am using nodes and binding for my IoT devices that I want to use a node. When the node goes down, the device connects to a different AP and there is an icon in the web page that shows the device is connect to a non-preferred node. Then when the assigned node comes back up, my experience is the device immediately is moved to the correct node.

 

[drabisan]

I am using nodes and binding for my IoT devices that I want to use a node. When the node goes down, the device connects to a different AP and there is an icon in the web page that shows the device is connect to a non-preferred node. Then when the assigned node comes back up, my experience is the device immediately is moved to the correct node.

"immediately is moved to the correct node."
Immediately may be a too high expectation!
Clients are stubborn.
Some chipsets may not understand the frames indicating roaming decision (802.11k,v, r support on client side).
It does take a good while for AiMesh to establish the topology. DFS channels are not just coming up. They must listen for 1 minute or so.
Bugs, on both client side or AiMesh side.

Rebooting a client will work most times. But you shouldn't be surprised if a client sticks to the last working BSSID. And it will choose to stay there no matter what! Short of a factory reset for that client.

There's no way around! I wish there would be one!

 

[Slawek P]

Hello all, I have 2 RT-AX88U both running this Rc-7 release. Clean install on both units. Node is using wifi backhaul.

One thing I have noticed is running the speed test from the router gives significantly lower results than running the same test from the desktop PC app - both connecting to the same server. Pc is Cat 6 cabled directly to the main router. The PC gives the faster result over the router inbuilt test.

Yes had the same on AX88U, see my other posts, it basically renders Ookla test useless.
Ookla test does not use all AX88 CPUs

 

[Slawek P]

It may happen. The speedtest on router using the router's CPU.
If there are many network activities, the speedtest result may be lower.

That's not the case. It is Ookla CLI not using all four CPUs of AX88
Ookla test does not use all AX88 CPUs
http://www.snbforums.com/threads/spdmerlin-automated-speedtests-with-graphs.55904/post-619130
http://www.snbforums.com/threads/spdmerlin-automated-speedtests-with-graphs.55904/post-620577

 

[WET]

That's not the case. It is Ookla CLI not using all four CPUs of AX88
Ookla test does not use all AX88 CPUs
http://www.snbforums.com/threads/spdmerlin-automated-speedtests-with-graphs.55904/post-619130
http://www.snbforums.com/threads/spdmerlin-automated-speedtests-with-graphs.55904/post-620577

 

[WET]

Has anyone verified USB applications work on the access nodes with AIMesh 2.0 per release notes below?

1. AiMesh 2.0
- System optimization: one click in AiMesh to optimize the topology
- System Ethernet backhaul mode, all nodes will only connect by ethernet, all bands will be released for wireless clients.
- System factory default and reboot.
- Client device reconnect, make the device to offline and online again.
- Client device binding to specific AP.
- Guest WiFi on all Mesh nodes (all node need to upgrade to 3.0.0.4.386 firmware)
- Access nodes USB application.

 

[SloPoke]

Cannot add more than one XT8 node to my setup. The second one never connects properly and eventually disappears completely.

 

[Darren Rockach]

Hmmm. Power cycle all. Does the webUI Status show the backhaul LAN port at 1 Gbps? Thing is, it worked before.

OE

Exactly the same here. AX11000 and two XT8 nodes.

 

[OzarkEdge]

Exactly the same here. AX11000 and two XT8 nodes.

It always seems like the niche models have niche issues... DSL gateway, Lyra, Blue Cave, ZEN XT, ZEN CT...

OE

 

[SloPoke]

I don't have the same router models. My router is a GT-AC5300 and node it's a RT-AX88U. With "Ethernet Backhaul Mode" on, if I unplug the cable it doesn't fail over to wifi. I simply loose the node and all the hosts behind it (wifi ones will eventually connect to router over 2.4, but wireless clients are dead no matter how much I wait).
It may be an inconsistent behavior between models.
I have 0 ideas why this is happening to you.

Beats me too. Every beta up to and including rc2-4 installed fine on the router and all nodes, even without doing a factory reset. Everything since has been a disaster, even with a factory reset. For some reason the only setup it will accept with rc2-7 is one XT8 router and one XT8 node. Any attempt to add a third node fails.

 

[OzarkEdge]

Beats me too. Every beta up to and including rc2-4 installed fine on the router and all nodes, even without doing a factory reset. Everything since has been a disaster, even with a factory reset. For some reason the only setup it will accept with rc2-7 is one XT8 router and one XT8 node. Any attempt to add a third node fails.

I wonder if turning OFF the first node before adding the second node would sneak by the issue.

OE

 

[semigator]

It does take a good while for AiMesh to establish the topology. DFS channels are not just coming up. They must listen for 1 minute or so.

Been using AiMesh since beta - just sharing my experience with AiMesh 2.0 and binding. It's immediately after the node comes back up and I can watch it. I have 9 different types of IoT clients using binding to 4 total access points. I use static defined wifi channels, so no DFS for me.