What's new

AImesh anyway to block client from node?

  • 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!

djjsin

Regular Contributor
So, I have an AImesh setup with an RT-AX88U Pro as my primary node and then connected via the 2.5Gb backhaul is a RT-AX86U aimesh node to cover my house.

Recently we converted my garage into an ADU for my mother in law to live. She was noticing wifi drops and issues, so I added a XT8 as a wireless node and stuck it in the ADU for her devices to connect to. Works great and fixes her issues. Ive been using bind to bind certain things (like fire sticks, tvs, xboxes, etc) to nodes that I don't want to Roam over to the XT8.

Problem I'm facing is my children's tablets. I notice when they are in their bedrooms the tablets roam over to the XT8 in my ADU because the Asus algorithm thinks it's the best signal, when the reality is the performance then turns to crap vs if they are connected to the RT-AX88U pro, even though it says the signal to the RT-AX88U pro is weaker.

But here's my issue. I don't want to bind the tablets to the RT-AX88U pro because at times I want them to roam over to the RT-AX86U when they are different parts of the house.

So my question is this...is there anyway to block just the tablets from roaming to the XT8, while still making it possible for the tablets to roam between the RT-AX88U Pro and the RT-AX86U? Like is there any sort of way to add the MACs to a Blocklist on the XT8? I don't see a way in the GUI, but maybe I'm missing something
 
Last edited:
Globally, you could use smart connect with the thresholds tweaked upward and perhaps achieve your goal.
 
Do you have access to the transmit power on the XT8 as a mesh node, decreasing it on the non-backhaul radios?
 
Do you have access to the transmit power on the XT8 as a mesh node, decreasing it on the non-backhaul radios?
I don't believe I do unless I don't know how. The only transmit power I see is a general one that I believe effects all 3 nodes.
 
This is exactly why IMO Aimesh isn't worth the "convenience". Router + AP requires separate management, but this enables separate detailed management. If the node in question is wired it'd be a simple matter to remove it as a node and set it up in AP mode. If it's got a wireless feed, perhaps "repeater" mode would net the same results as now along with separate radio power control.
 
This is exactly why IMO Aimesh isn't worth the "convenience". Router + AP requires separate management, but this enables separate detailed management. If the node in question is wired it'd be a simple matter to remove it as a node and set it up in AP mode. If it's got a wireless feed, perhaps "repeater" mode would net the same results as now along with separate radio power control.
Nah I'm not really interested in doing that. The benefits of aimesh out way the negatives. This is a very minor issue, not one that's really worth changing the whole setup to try and maybe solve, opening the door to other issues.
 
It's as simple as removing the node from the router's gui, if necessary resetting the node manually, and setting it up anew as a repeater.

If that avails you nothing, reset it again in the gui to be a mesh node and walk away - it'll come back again to exactly where you are now.

Will take less time than assisting the kids a few times with their issues as they arise.
 
It's as simple as removing the node from the router's gui, if necessary resetting the node manually, and setting it up anew as a repeater.

If that avails you nothing, reset it again in the gui to be a mesh node and walk away - it'll come back again to exactly where you are now.

Will take less time than assisting the kids a few times with their issues as they arise.
But then I lose the AImesh features like the automanagement of clients and where they are. The GUI AImesh client monitoring and management. Sure in this one specific case it's giving me problems due to the location of their bedrooms and the adu, and the fact that I don't want these portable devices binded to a specific node....but for my other 60 something devices it does the job pretty well. There's got to be a better solution then this.

Funny thing too is it general doesn't even cause issues in the whole bedroom....only in the one specific corner where they put the desk lol. But really I'd rather these devices to just never connect to that one wireless node.
 
Last edited:
Who's to say /what/ you'd lose? I've got an XT8 available to test "repeater" mode functionality, but I don't run Aimesh so could draw no comparisons that way.

Maybe best you don't try it. Doing so may give you a taste of what can be done without the Mesh shackles, and ruin things for you, hahah!.
 
Who's to say /what/ you'd lose? I've got an XT8 available to test "repeater" mode functionality, but I don't run Aimesh so could draw no comparisons that way.

Maybe best you don't try it. Doing so may give you a taste of what can be done without the Mesh shackles, and ruin things for you, hahah!.
No man. I got a household of 5 where everything runs over the internet. Video games. Television. Cameras. Alarms. 60+ devices. I don't just reconfigure like that on a whim and just "see what happens"
 
My notion of "just see what happens" pertains only to whether you gain effectual no-tradeoff control of the one unit only, which is in an outbuilding. Seems such a test would be totally non-disruptive to the rest of the system. Certainly less so than any other settings you can make via the mesh control scheme, which /will/ affect the /rest/ of the system whether it needs it or not. Sounds like your problem is acceptable since you're unwilling to even try something easy. Maybe someone else will stumble upon this and help you get what you're wanting some other way which looks better to you.

Enjoy.
 
It's too much effort for what it's worth. You claim it's easy. It's not in my environment where I have 4 other people who require stable internet for most daily activities. I have a system that generally works outside of this one outlier in a specific corner of the house. It's not worth spending the downtime it would require not only setting/configuring and also dealing with the issues afterwards, but giving up all the value that AImesh adds as a whole.
 
Recently we converted my garage into an ADU for my mother in law to live. She was noticing wifi drops and issues, so I added a XT8 as a wireless node and stuck it in the ADU for her devices to connect to. Works great and fixes her issues. Ive been using bind to bind certain things (like fire sticks, tvs, xboxes, etc) to nodes that I don't want to Roam over to the XT8.

Problem I'm facing is my children's tablets. I notice when they are in their bedrooms the tablets roam over to the XT8 in my ADU because the Asus algorithm thinks it's the best signal, when the reality is the performance then turns to crap

If the garage conversion had included an Ethernet connection, you could disable that crappy wireless backhaul and let your clients connect wherever they want.

OE
 
If the garage conversion had included an Ethernet connection, you could disable that crappy wireless backhaul and let your clients connect wherever they want.

OE
The issue isn't a wireless backhaul issue. It's a range issue to the XT8 from the bedroom. Performance from the XT8 works fine when your closer in the actual ADU. The XT8 is Triband.
 
When you add a device to the roaming block list, it creates entries in nvram:
wl0_rast_static_client=<EE:FF:00:DD:11:22
wl1_rast_static_client=<EE:FF:00:DD:11:22

There is an initial < before the MAC address. I don't know what the separators are if there are multiple devices.

Perhaps you could create these entries in nvram on the XT (via ssh/cli), with the excluded MAC addresses, and that might tell the XT not to allow these to roam on that node. Be sure to nvram commit when you are done.

I've only got one node, so I can't test if blocking on only one node would work. And I've no idea whether this would survive a reboot, so you may need to build a script on the XT that makes this change at each boot.
 
When you add a device to the roaming block list, it creates entries in nvram:
wl0_rast_static_client=<EE:FF:00:DD:11:22
wl1_rast_static_client=<EE:FF:00:DD:11:22

There is an initial < before the MAC address. I don't know what the separators are if there are multiple devices.

Perhaps you could create these entries in nvram on the XT (via ssh/cli), with the excluded MAC addresses, and that might tell the XT not to allow these to roam on that node. Be sure to nvram commit when you are done.

I've only got one node, so I can't test if blocking on only one node would work. And I've no idea whether this would survive a reboot, so you may need to build a script on the XT that makes this change at each boot.
Thanks for this! Though it's going to take me some time to work out ha.
 
The issue isn't a wireless backhaul issue. It's a range issue to the XT8 from the bedroom. Performance from the XT8 works fine when your closer in the actual ADU. The XT8 is Triband.

Maybe. Could use a wired second router with different SSIDs for the ADU... more like how it typically is for a separate dwelling.

OE
 
Last edited:
Maybe. Could use a wired second router with different SSIDs for the ADU... more like how it typically is for a separate dwelling.

OE
I thought about that, but then devices won't intelligently roam over when my mother in law is in my house or my wife is in the ADU. Plus there's dead spots in my yard and other devices like cameras that the ADU XT8 also serves to eliminate. So I really don't want to seperate things out two two different SSIDs.
 
Last edited:
It's too much effort for what it's worth. You claim it's easy. It's not in my environment where I have 4 other people who require stable internet for most daily activities.
Not much effort at all, and it /is/ easy & non-disruptive to the rest of the network. I spent some time messing with it yesterday.

When in "repeater" mode on the XT8 running latest stable gnuton/merlin the "Wireless" tab on the left is absent. The "General" and "Professional" tab content can be reached manually via the browser location bar, but the layout / content is very abbreviated and does not include transmit power adjustment. So back to AP mode, reduce transmit powers for the two client-facing radios [an aside: it's somewhat irksome that the adjustment requires a complete router reboot (couldn't just unload / load the modules?); /very/ irksome that it must be done sequentially rather than queuing and combining them into a single reboot].

Switch back to "repeater" mode and the power levels have remained at a reduced setting and everything appears to work as expected.

The power levels also remained as set when switching to "Media Bridge" mode as well as back to AP mode. I did not check "Router" or "AiMesh Node" modes.

So it's /somewhat/ tedious to make the power adjustment, but in all the flip-flopping around of just the one device, the rest of the network remained in fully-functional service, with no interruptions.

It's not worth spending the downtime it would require not only setting/configuring and also dealing with the issues afterwards, but giving up all the value that AImesh adds as a whole.
There is no need to bring down or even disrupt the rest of the network while thus adjusting the one device. And operating just the one unit in a different mode will not degrade /any/ of the AiMesh value present in the rest of the system.
-----
Okay, I spent a couple hours today, off and on, toying with this. I'm going to describe as tersely as I can what I have and what I did.

A pair of V1 XT8s operating in router / AP mode for the very real within-network performance increase over what can be achieved under AiMesh. On a very good sale price picked up a GT-AX6000 to use as the router so as to feed the XT8 AP with 2.5 Gb ethernet. Remaining XT8 used variously but mostly with 2.4 and 5-1 turned off, associating with only one computer on 5-2 (for very real performance boost). All running their latest stable gnuton/merlin firmware.

I reconfigured the spare XT8 as an AiMesh node, first to the other (AP) XT8 via 5-2 @160MHz, then to the GT (via 5-1 since that's where I have the GT operating). In-network performance plumeted, as expected, as well near total lack of control of the "node", as expected. Setting nvram variables in an attempt to decrease transmit levels followed by a reboot for them to take effect avails nothing. The radios are set up entirely by the controller each time the node boots up and becomes meshed. The only way to control /any/ radio transmit levels is entirely global for the mesh via the controller. This level of control and performance is drastically below that of my usual system configuration. Drastically.

I reconfigured the spare XT8 as a "repeater", once again both to each the GT router and XT AP. The first using the repeater's 5-1 radio (80MHz x 2) to the router ('cause that's the part of the band the router's assigned to - running 160MHz x 4), and via 5-2 (160MHz x 4) (one end of the house to the other one floor apart). Both worked as well as can be expected for the scheme: somewhat better than under AiMesh, but still poorly-performing within the network. There is no direct GUI access to adjust power levels in "repeater" mode. However, setting the appropriate wl?_txpower nvram variables via ssh followed by a command line "reboot" brought the unit up with the desired power levels in service.

I did all this, and more, while watching air-streamed entertainment. The only disruption to any of the network was any associated clients immediately and painlessly hopping over to another broadcaster.

Unless you're carrying an isolated guest network to the outbuilding, your entire system will operate just as it does now, with seamless roaming, et al, throughout; AiMesh just like you like it except for the outlying router, which you will be able to /MUCH/ better control.

In my setup sans AiMesh, each of the three web interfaces show ALL system-connected clients, indicated by wireless if directly associated or by wired if associated elsewhere.

Remove the one node from the mesh via the controller's GUI. When it comes back up (you will have to isolate it from any other XT8 broadcasting or it'll become a mesh node again), select operation as "repeater" and select the /particular/ broadcaster/band to use as its feed.
Fill in the exact same SSID(s) and passphrases you're currently using, and wait for it to reboot.

Once it's up, log into its GUI and enable ssh. Then ssh into it and issue the following two commands, substituting your client-use SSID for the example. I use two SSIDs, "SomethingNet" for 2.4 and 5 (or 5-1) operating as if "smartcast" though I have that disabled, and "SomethingNetHi" for the 5-2 radios.
Bash:
nvram show 2>/dev/null | grep 'txpower\|SomethingNet\(Hi\)\?$'
will list the radios and their ssids something like this:
Code:
# nvram show 2>/dev/null | grep 'txpower\|SomethingNet\(Hi\)\?$'
wl0_ssid=SomethingNet
wl0_txpower=100
wl1_ssid=SomethingNet
wl1_txpower=100
wl2_ssid=SomethingNetHi
wl2_txpower=100
wl_txpower=100
wlc_ssid=SomethingNetHi

Assuming you're using the 5-2 as your "backhaul" leave the "wl2_" stuff alone. wl0_* will be 2.4GHz and wl1_* will be 5-1.

Then
Bash:
nvram set wl0_txpower=50
nvram set wl1_txpower=50
reboot

"50" and "88" will be your two most likely values to use. You can swap them in at any time for testing purposes.

This will decrease the transmit power of the XT8 in the outbuilding and should keep it out of the kids' rooms yet still work well-enough in that building and it's immediate surroundings.

The option offered a few posts up to prevent roaming will not be satisfying if it even works.

At /any/ time you may log into the XT8's GUI and tell it you want it to become an AiMesh node. It will, after several minutes, perhaps with a little interaction on the router if necessary, show back up just exactly like it was before you started. The rest of your network will remain fully intact and operational throughout the process, either direction.
 

Similar threads

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