AImesh anyway to block client from node?

[djjsin]

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.


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.

nvram show 2>/dev/null | grep 'txpower\|SomethingNet\(Hi\)\?$'

will list the radios and their ssids something like this:

# 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

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.

Well then you wasted alot of your time cause like I already said and I've explained why (even though you choose to not accept or understand my reasoning) I'm not moving one to repeater mode. Not going to happen. I'm losing to much by doing that. Not with my time or effort for one device. In one small area if the house. I dont want nodes that have to be individually managed like you are describing.

 

[glens]

You're welcome.

I didn't waste a moment. I was curious for myself and merely shared the result. You can drink the water I've lead you to or you can stay thirsty. It's up to you.

Mainly I've been curious to see how disparate devices (one tri-radio, one dual-radio) control each other via AiMesh. It's rather a mess. Though it's evidently sufficient for folks who only want to get some Internet in to some devices. If there's any kind of meaningful traffic between wireless devices, or more than one within the network are consuming Internet simultaneously, or different nodes contend with different competing signals than the router sees, it's very far from ideal.

You've not explained anything, merely stated your stance. "I'm losing too much by doing that." means what, exactly? Please expound and enlighten me.

 

[OzarkEdge]

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.

Me, I'd want the ADU resident to be a guest on my network with Internet access only. And vice-versa.

How far apart are your 3 APs and how far are the kid bedrooms from the ADU AP?

OE

 

[djjsin]

You're welcome.

I didn't waste a moment. I was curious for myself and merely shared the result. You can drink the water I've lead you to or you can stay thirsty. It's up to you.

Mainly I've been curious to see how disparate devices (one tri-radio, one dual-radio) control each other via AiMesh. It's rather a mess. Though it's evidently sufficient for folks who only want to get some Internet in to some devices. If there's any kind of meaningful traffic between wireless devices, or more than one within the network are consuming Internet simultaneously, or different nodes contend with different competing signals than the router sees, it's very far from ideal.

You've not explained anything, merely stated your stance. "I'm losing too much by doing that." means what, exactly? Please expound and enlighten me.

For example the entire AImesh tab. I don't want to have to go different places to manage things. I don't want to have to log into another device. Right now I have the AImesh tab which cleanly shows me each client. What node they are connected to. I can relatively easily switch devices between nodes. Reboot nodes...see where devices are connected to after. It's clean
Simple. And easy to use. You may not find value in that, but I do. I work in IT. I have for decades. The last thing I want on my home network is to overcomplicate things more where I have multiple nodes I have to self manage taking up my time. Plus I also like the AImesh driven roaming. Sure clients roam on their own, but AImesh enhances roaming (hence the ability to turn AImesh roaming off). I've already stated this above. These are features id be giving up if I took away AImesh nodes and moved things to a repeater mode. May seem easy and unimportant to you, but it's important to me. Plus any sort of node downtime causes disruption somewhere. You may think it's easy to just reconfigure something into a repeater....but it's not easy. I have to schedule downtime with my mother in law. She stays up all night. It's a pain in the butt.

I have 60+ devices on my AImesh network. Xbox's running over WiFi. Tvs running. And under most circumstances AImesh is working extremely well. I get great speeds (300+) in most places. Low ping timings. No lag when gaming. A WiFi network that's able to sustain the 10 TVs I have running 4k HDR videos (sure not every single one at once but I probably could if I tried).

Plus I'm not even in agreement that turning the power down on my XT8 will solve my issue without creating more issues on its own.

What's even funnier is I rebooted the XT8 node the other day, and I have not heard my child complain about any issues while using his tablet in the same spot since. Sure I haven't been able to actually go and test bandwidth to see if I was seeing the same issue I was before, but it's not stopping him from what he's doing after the reboot so that's really all I care about at this point.

And to answer your question about Triband and dualband. The wifi node being Triband is the most important thing. It's communication with the dual band primary node is really no different then any other clients communication. Imo Triband is more.important on the wireleas node since it's using one band to talk to the primary node, and another band to server data out to the clients connected to it. And it is working well. The only issue I have is the inability to put the entire thing in 160mhz due to channel limitations since the Triband node splits the spectrum in 2, half for one band and half for the other band. The network being served out of the wireless node is actually a different channel then the network that is being served out inside my house. In order to get 160mhz working I'd have to enable DFS channels, which I've found causes a problem with Roku devices since they don't support dfs channels....so 80mhz is plenty for my needs. When I got a great signal to my XT8, I'm easily getting about 400Mbps off of which is PLENTY of bandwidth for my mother in law or any of my devices that are connected to it (like property cameras, or my pool, or when I do happen to walk in an area if the yard that is a dead zone for the non wifi nodes). Like I said before the issue isn't the WiFi backhaul. It's the distance, walls between the XT8 and the one specific spot upstairs my child is trying to sit at. Or maybe the XT8 just needed a reboot.

 

[djjsin]

Me, I'd want the ADU resident to be a guest on my network with Internet access only. And vice-versa.

How far apart are your 3 APs and how far are the kid bedrooms from the ADU AP?

OE

If it was a random tenant I'd agree with you. But since it's my mother in law who's constantly in my house....and my wife is constantly in her adu...I prefer it to be the same network. I have to manage it all. I have to manage all her devices. Plus as I stated before the node does also help with deadlines outside my house in my yard I'd hate to have to go and reconfigure some camera to use one ssid. While other cameras are configured to use a different ssid.

 

[OzarkEdge]

If it was a random tenant I'd agree with you. But since it's my mother in law who's constantly in my house....and my wife is constantly in her adu...I prefer it to be the same network. I have to manage it all. I have to manage all her devices. Plus as I stated before the node does also help with deadlines outside my house in my yard I'd hate to have to go and reconfigure some camera to use one ssid. While other cameras are configured to use a different ssid.

My preference would be to not trust any tenant and their guests to practice safe computing on my network. It's tricky enough to train and keep secure my own users. Does your tenant need/use access to your network?

How far apart are your 3 APs and how far are the kid bedrooms from the ADU AP?

OE

 

[djjsin]

My preference would be to not trust any tenant and their guests to practice safe computing on my network. It's tricky enough to train and keep secure my own users. Does your tenant need/use access to your network?

How far apart are your 3 APs and how far are the kid bedrooms from the ADU AP?

OE

I could agree with that. A simple solution would be to create a guest network or vlan for her to accomplish that security need....but really would do nothing to solve my kids issue since the XT8 would then be serving our both SSIDs.

The distance is the issue. The wires APs were fine before the adu was put in. They are both on opposite sides of the house and given the shirt insulation on the garage the coverage was fine over there.

Once the adu was put in where now the signal is having to travel through multiple more insulated walls is when I started seeing the issue.

The kids bedroom is upstairs real close to the adu. I would say the adu node and the primary node are closer then I'd like. The primary node is in an office. Not ideally where I'd like it, If I could move it closer to the adu I probably wouldn't need the adu node, but that would require moving where the internet line goes in the house. Getting under my house. Drilling holes in the floor to bring the cable up....or paying someone to do it. Not really looking to go through that hassle.

 

[OzarkEdge]

The distance is the issue.

Maybe... hard to know without the facts... or is it too much WiFi for the space... or is that the same thing...

The kids bedroom is upstairs real close to the adu.

Maybe too close... a sure way to screw up WiFi is to locate one AP over another.

I think you need to reconsider the issue and how best to solve it... besides blocking/binding clients.

OE

 

[glens]

In order to get 160mhz working I'd have to enable DFS channels, which I've found causes a problem with Roku devices since they don't support dfs channels....so 80mhz is plenty for my needs.

So long as the control channel is in an 80MHz slot the Roku knows it will succeed in getting its connection at 80MHz out of the 160 the APs are using otherwise. Or even 40 of it. You'd have to decide where to put the 160 also depending on which 5 GHz radio you want to use for what in the XT8's coverage area. Your best results will most likely be using 5-2 for the backhaul, though you'll never know what'd be best until you try things over time.

When I got a great signal to my XT8, I'm easily getting about 400Mbps off of which is PLENTY of bandwidth...

Yeah, for the use case of a single client at a time transacting off-site or dropping immediately to only wire within, the mesh works fine. Multiple simultaneous that or intra network full-wireless communication just tanks in the single-channel "mesh".

AImesh enhances roaming

I see absolutely no indication of that in practice. Don't know whether you've actually taken the effort to arrive at that conclusion empirically. Unless you mean by same radio parameters everywhere clients hop around more, needlessly and at times detrimentally, hahaha.

I don't intend to rag on you for wanting to do something a certain way. You did seek assistance for an issue and I offered as a solution what I would do based on experimentation, some of it over time.

By the way, you are already using the device as a repeater all the same, merely trading useful control for a small level of convenience.

On the rare occasion I need to administer my network I merely switch to the browser window which has a tab open to each device's wireless log page. Don't even need to log in again. Also, I find cycling through the tabs to see what's connected where vastly more useful than using the mesh interface.

If you haven't tried the system outside of "mesh" mode, it would behove you do so at some point. You may find the performance / simplicity ratios interesting.

 

[djjsin]

So long as the control channel is in an 80MHz slot the Roku knows it will succeed in getting its connection at 80MHz out of the 160 the APs are using otherwise. Or even 40 of it. You'd have to decide where to put the 160 also depending on which 5 GHz radio you want to use for what in the XT8's coverage area. Your best results will most likely be using 5-2 for the backhaul, though you'll never know what'd be best until you try things over time.

Yeah, for the use case of a single client at a time transacting off-site or dropping immediately to only wire within, the mesh works fine. Multiple simultaneous that or intra network full-wireless communication just tanks in the single-channel "mesh".

I see absolutely no indication of that in practice. Don't know whether you've actually taken the effort to arrive at that conclusion empirically. Unless you mean by same radio parameters everywhere clients hop around more, needlessly and at times detrimentally, hahaha.

I don't intend to rag on you for wanting to do something a certain way. You did seek assistance for an issue and I offered as a solution what I would do based on experimentation, some of it over time.

By the way, you are already using the device as a repeater all the same, merely trading useful control for a small level of convenience.

On the rare occasion I need to administer my network I merely switch to the browser window which has a tab open to each device's wireless log page. Don't even need to log in again. Also, I find cycling through the tabs to see what's connected where vastly more useful than using the mesh interface.

If you haven't tried the system outside of "mesh" mode, it would behove you do so at some point. You may find the performance / simplicity ratios interesting.

Ive actually just come up with a way to accomplish what I'm looking to do while keeping the mesh working. It's dirty but I think it would work.

I got a RT-AX88U pro which has vlan support⁹. The guest network pro allows me to create SSIDs and only put them in certain nodes. Any client connected to that would then be prevented from roaming to the ADU.

Ill just create 2 IoT networks. One for the adu. One for the house. And use that for stationary devices and things like his tablet I don't want connecting to the ADU in his room. Then I can remove all the bindings I have that prevent certain devices from roaming to the ADU after I move them to the IoT networks

Much better then killing the mesh imo