Using AiMesh wired/wireless backhaul settings...

[OzarkEdge]

I've added a wired backhaul MoCA 2.5Gbps to my AiMesh, limited to 1GbE at the AC86U node WAN port. This wired backhaul has 3 segments, Ethernet at each end and MoCA in the middle. The AiMesh Ethernet Backhaul Mode system setting is set to the default disabled.

Some observations...

A) If the node Backhaul Connection Priority is set to the default Auto, then breaking any segment of the wired backhaul will cause failover to wireless backhaul. Good!

B) If the node Backhaul Connection Priority is set to WAN/Ethernet first, then only breaking the node Ethernet segment will cause failover to wireless backhaul. Not good enough! (Same might apply to any wired backhaul with multiple Ethernet segments/switches?)

C) When a wireless backhaul is active, its connection details appear in the Wireless Log. When a wireless backhaul is not active, its connection details eventually disappear from the Wireless Log. This suggests no WiFi is shared/reserved for a wireless backhaul until it is actually required for a wireless backhaul. This appears to be good!

Given the above, if I want the best backhaul and failover to the alternate backhaul, I should leave the node Backhaul Connection Priority set to the default Auto. And I should leave the AiMesh Ethernet Backhaul Mode set to the default disable and expect all WiFi to be available for clients until a wireless backhaul is actually active.

Perhaps someone has additional insight or can explain their non-default use of these settings.

OE

 

[bbunge]

I believe what you have observed and what you have decided to use is in line with other reports of AiMesh. Auto backhaul is the most reliable.

 

[OzarkEdge]

I believe what you have observed and what you have decided to use is in line with other reports of AiMesh. Auto backhaul is the most reliable.

I'm trying to understand what the non-default settings are for before I can decide how reliable they are. Auto I get and it works.

OE

 

[L&LD]

If there is even a possibility of having a wired backhaul connection break, Auto is the only solution.

Unless you want to know that the Moca connection is broken, of course (and can then do something about it).

Is the Moca connection prone to disconnect? If not using Auto, note it in big red letters, along with troubleshooting steps to rule out the issues a non-auto backhaul setup may cause.

 

[OzarkEdge]

If there is even a possibility of having a wired backhaul connection break, Auto is the only solution.

Apparently so. I still don't know what the use case is for 'WAN first', which makes it sound like it will try wireless next... it doesn't, at least not fully like Auto does. And Ethernet Backhaul Mode... what's the point of this setting?

Unless you want to know that the Moca connection is broken, of course (and can then do something about it).

I'll know it when it happens now that I've spent so much time using a wireless backhaul.

Is the Moca connection prone to disconnect? If not using Auto, note it in big red letters, along with troubleshooting steps to rule out the issues a non-auto backhaul setup may cause.

MoCA should be as reliable as any Ethernet adapter connection. I'll be using Auto for proper failover. The other settings make no sense to me... 'WAN first', what does that mean?! And it doesn't failover to wireless unless the break is at the node. I'd like to hear from anyone using a switch in their backhaul path... does 'WAN first' failover to wireless backhaul for all possible breaks upstream and downstream from the switch?

At this point, 'WAN first' is like a fake steering wheel on a child's stroller... something to play with now that you have a wired backhaul.

OE

 

[leerees]

I've added a wired backhaul MoCA 2.5Gbps to my AiMesh, limited to 1GbE at the AC86U node WAN port. This wired backhaul has 3 segments, Ethernet at each end and MoCA in the middle. The AiMesh Ethernet Backhaul Mode system setting is set to the default disabled.

Some observations...

A) If the node Backhaul Connection Priority is set to the default Auto, then breaking any segment of the wired backhaul will cause failover to wireless backhaul. Good!

B) If the node Backhaul Connection Priority is set to WAN/Ethernet first, then only breaking the node Ethernet segment will cause failover to wireless backhaul. Not good enough! (Same might apply to any wired backhaul with multiple Ethernet segments/switches?)

C) When a wireless backhaul is active, its connection details appear in the Wireless Log. When a wireless backhaul is not active, its connection details eventually disappear from the Wireless Log. This suggests no WiFi is shared/reserved for a wireless backhaul until it is actually required for a wireless backhaul. This appears to be good!

Given the above, if I want the best backhaul and failover to the alternate backhaul, I should leave the node Backhaul Connection Priority set to the default Auto. And I should leave the AiMesh Ethernet Backhaul Mode set to the default disable and expect all WiFi to be available for clients until a wireless backhaul is actually active.

Perhaps someone has additional insight or can explain their non-default use of these settings.

OE

To get my hack working (clients sharing the faster 5g2 with the backhaul) I have to setup my router in triband mode (with an ethernet backhaul) and then set the preference to wireless, then enable shared AX client access. Once this is done, I remove the ethernet cable connecting the backhaul.

If I don't do these steps, when I remove the ethernet cable, the mesh doesn't failover to wireless backhaul and they all remain disconnected from each other.

There was a much easier way of doing this that was "patched" by Asus on the AX92u. Coincidentally, at the same time they released the ZenWiFi which offers WiFi6 on 5ghz to clients by default.

 

[OzarkEdge]

To get my hack working (clients sharing the faster 5g2 with the backhaul) I have to setup my router in triband mode (with an ethernet backhaul) and then set the preference to wireless, then enable shared AX client access. Once this is done, I remove the ethernet cable connecting the backhaul.

If I don't do these steps, when I remove the ethernet cable, the mesh doesn't failover to wireless backhaul and they all remain disconnected from each other.

There was a much easier way of doing this that was "patched" by Asus on the AX92u. Coincidentally, at the same time they released the ZenWiFi which offers WiFi6 on 5ghz to clients by default.

I see (I have not seen a tri-band yet)... that's a bit unusual. And foregoes self-healing, though not a big deal.

I would like to see simple settings... pick the backhaul, pick the failover backhaul, if any. This 'Auto', 'WAN first', 'WiFi first' is just too ambiguous in meaning and implemention.

I think they are overwhelmed by their own firmware logic... they have been tweaking these settings/wording ever since they introduced them... which suggests a too loose coding plan... instead, design a plan, then code it once (if you're lucky).

Thanks for explaining your use case.

OE

 

[OzarkEdge]

I've added a wired backhaul MoCA 2.5Gbps to my AiMesh, limited to 1GbE at the AC86U node WAN port. This wired backhaul has 3 segments, Ethernet at each end and MoCA in the middle. The AiMesh Ethernet Backhaul Mode system setting is set to the default disabled.

Some observations...

A) If the node Backhaul Connection Priority is set to the default Auto, then breaking any segment of the wired backhaul will cause failover to wireless backhaul. Good!

B) If the node Backhaul Connection Priority is set to WAN/Ethernet first, then only breaking the node Ethernet segment will cause failover to wireless backhaul. Not good enough! (Same might apply to any wired backhaul with multiple Ethernet segments/switches?)

C) When a wireless backhaul is active, its connection details appear in the Wireless Log. When a wireless backhaul is not active, its connection details eventually disappear from the Wireless Log. This suggests no WiFi is shared/reserved for a wireless backhaul until it is actually required for a wireless backhaul. This appears to be good!

Given the above, if I want the best backhaul and failover to the alternate backhaul, I should leave the node Backhaul Connection Priority set to the default Auto. And I should leave the AiMesh Ethernet Backhaul Mode set to the default disable and expect all WiFi to be available for clients until a wireless backhaul is actually active.

Perhaps someone has additional insight or can explain their non-default use of these settings.

OE

I believe I have resolved my understanding of this after sleeping on it and allowing the router to indicate active wireless backhauls in the Log.

Ethernet Backhaul Mode disables all wireless backhauls and releases WiFi for client use only. All backhauls must be wired. Backhaul Connection Priority becomes fixed on 'WAN only'. Good!

Backhaul Connection Priority 'Auto' will prefer the best active backhaul and failover to the other active backhauls, if any. Good! 'Wan first' and 'WiFi first' appear to be for overruling 'Auto' and don't failover in my case (Ethernet-MoCA-Ethernet) so may need work. Not good!

TLDR Use the defaults unless you install all wired backhauls; then enable Ethernet Backhaul Mode to disable the wireless backhauls and release all WiFi for client use only. Use the default Backhaul Connection Priority 'Auto'... 'WAN first' and 'WiFi first' only apply when using both wired and wireless backhauls (not typical), which deprives WiFi from clients and doesn't failover in all cases, so no point.

Given wired backhaul and max WiFi for clients is preferable, the only practical failover/self-healing occurs between wireless bands when using wireless backhauls only.

I know, seems obvious... I was mislead by a slow-to-update Wireless Log.

OE

 

[L&LD]

Glad you came to the same conclusions.

 

[OzarkEdge]

Glad you came to the same conclusions.

Yeah, I got side-tracked by trusting the WLog. Once it showed the wireless backhauls still enabled, things fell into place. With some changes, the wireless backhaul connections would come and go immediately; but with other changes, not so fast.

OE

 

[OzarkEdge]

Glad you came to the same conclusions.

Question about the "2x RT-AX86U in wired backhaul (2.5GbE) AiMesh mode" in your sig... how is the node's 2G port configured for WAN after the node is added to the AiMesh?

OE

 

[L&LD]

I need to update my signature.

Main RT-AX86U, GT-AX6000 node.

No configuration needed (even with RT-AX86U node).

 

[OzarkEdge]

No configuration needed (even with RT-AX86U node).

Can you elaborate on that... given router 2.5G LAN5 to node 1G WAN wired backhaul, how do you set the node's 2.5G LAN5 port to be its 2.5G WAN port... or do you just wire it 2.5G LAN5 to 2.5G LAN5 and it works?

OE

 

[L&LD]

Yes, no configuration is needed for the node. 2.5GbE port from the main to 2.5GbE port on the node is all that is required.

 

[DroidST]

I believe I have resolved my understanding of this after sleeping on it and allowing the router to indicate active wireless backhauls in the Log.

Ethernet Backhaul Mode disables all wireless backhauls and releases WiFi for client use only. All backhauls must be wired. Backhaul Connection Priority becomes fixed on 'WAN only'. Good!

Backhaul Connection Priority 'Auto' will prefer the best active backhaul and failover to the other active backhauls, if any. Good! 'Wan first' and 'WiFi first' appear to be for overruling 'Auto' and don't failover in my case (Ethernet-MoCA-Ethernet) so may need work. Not good!

TLDR Use the defaults unless you install all wired backhauls; then enable Ethernet Backhaul Mode to disable the wireless backhauls and release all WiFi for client use only. Use the default Backhaul Connection Priority 'Auto'... 'WAN first' and 'WiFi first' only apply when using both wired and wireless backhauls (not typical), which deprives WiFi from clients and doesn't failover in all cases, so no point.

Given wired backhaul and max WiFi for clients is preferable, the only practical failover/self-healing occurs between wireless bands when using wireless backhauls only.

I know, seems obvious... I was mislead by a slow-to-update Wireless Log.

OE

We have a similiar setup, I have one additional ECB7250 to the my 68U (currently I am testing that 68U with wireless only in our Detached ADU).

I have Backhaul Connection Priority to Auto.

You are using Backhaul Connection Priority WAN first now, correct?
If so and assuming you have a Guest Network enabled, do you have any issues with clients connecting to the GN on the node?

When I was running Merlin on the primary, I had issues with GN clients on those nodes with Backhaul set to WAN first, seems they were not authenticating. Switching to Auto resolved that

If you are having success, I need to do some new testing.

One more question.
What happens with the Node after several minutes (Backhaul Connection Priority WAN first) and in the log when you just unplug the Ethernet cable between the Node and ECB7250)?

 

[OzarkEdge]

We have a similiar setup, I have one additional ECB7250 to the my 68U (currently I am testing that 68U with wireless only in our Detached ADU).

Wireless backhaul to a detached ADU AC68U will likely disappoint.

The preferred configuration would be... if all nodes have wired backhaul, enable Ethernet Backhaul Mode to disable all wireless backhauls (no failover; free all WLANs for client use only). Backhaul Connection Priority will default/fix to 'WAN only'.

I have Backhaul Connection Priority to Auto.

This seems to be the only fully reliable failover setting when using wired with wireless backhauls... at the moment anyway.

You are using Backhaul Connection Priority WAN first now, correct?
If so and assuming you have a Guest Network enabled, do you have any issues with clients connecting to the GN on the node?

No, I'm using the preferred configuration noted above and in my install notes. I disable all wireless backhauls now... this was the reason for buying MoCA 2.5 adapters, so there is no Backhaul Connection Priority, no failover, no uncertainty, no back and forth between wired and wireless backhauls depending on the whim of the firmware and radio conditions... just a robust, full-duplex, MoCA 2.5Gbps/1GbE wired backhaul.

I have some dumb Wyze cams that will reconnect to the far router 2.4 guest1 WLAN whenever the near node WLANs are restarted. I have to restart the Wyze cams for them to reconnect to the near node. This is a dumb Wyze cam/2.4-travels-far issue that my smarter clients do not exhibit. Fortunately, the Wyze cams still work when connected to the far router at low -85- dBm RSSI, so I don't have to restart them until I'm done messing with the network and/or I feel like it.

When I was running Merlin on the primary, I had issues with GN clients on those nodes with Backhaul set to WAN first, seems they were not authenticating. Switching to Auto resolved that

Be careful you don't draw the wrong conclusion... WiFi is hard and made harder by not knowing what the firmware is doing or suppose to do. This thread is an example of me doing this.

I recommend lagging behind in the use of certain current WiFi features to maintain backward compatibility with older/unknown clients. For guest/IoT WLANs, I use WPA2 authentication, not WPA3 authentication.

If you are having success, I need to do some new testing.

I think so, but it may not be what you might first think.

One more question.
What happens with the Node after several minutes (Backhaul Connection Priority WAN first) and in the log when you just unplug the Ethernet cable between the Node and ECB7250)?

For me, this was the only MoCA backhaul break/fault that properly failed over to wireless backhaul as expected... maybe because the node detected the loss of Ethernet and so began using wireless comms. Breaking the coax or the Ethernet at the router end simply put the node offline... it still had a seemingly good Ethernet connection to the MoCA adpater. I waited, but it never failed over to wireless backhaul.

And when this failover to wireless backhaul worked, the backhaul connections in the Wireless Log would come and go as expected. Otherwise, they were AWOL, at least during the time I was testing.

Regardless, failover to wireless backhaul is a moot issue, imo. The goal should be wired backhaul only... it's plenty good enough (no different than any wired client) and releases all WiFi for client use only, which you will want for that distant, old, slow AC68U trying to serve the ADU clients.

OE