nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Gracefully shut down APs ?

jelle_alten_606

Is there a setting in the ZoneDirector to tell an AP to move all clients to neighbor APs?

I would like to shut one AP down, but without interrupting the clients where possible.

If not, I could turn the radio of that AP to low, hoping the clients will jump to other APs, but that sounds a bit funny.

Find more posts tagged with

Accepted answers

All comments

unknown

Maybe try deleting an AP from the ZD. I don't know how it handles that. It might just send out disassociation frames and then stops transmitting and answering any requests, so clients will want to connect to another BSSID.

Note to self: Sniff some packets for that.

But there is no way any AP can instruct any client on which AP it should connect to. It's up to the client always. An AP could send a dissociation frame, but the client can simply reconnect if it wishes.

jelle_alten_606

Can't we tell the AP to maximize the number clients to zero? Or some other trick?

unknown

OK, I did some sniffing.

If you disable a particular radio on an AP it will immediately start sending disassociation to clients. Can't get nicer than that.

unknown

Although I see that it takes a good 2 seconds before it stops all conversations.

jelle_alten_606

That sound like "gracefully". Nice.

unknown

Hmm, I take it back somewhat.

I don't know how it will behave in your scenario, but 2 seconds isn't short. I saw that my AP was answering to directed and broadcast probe requests in that time. After 1,2s it actually authenticated one client again and after 1,5s it sent a probe response and retried it like crazy. After that it answered some probe request again, put out some beacons and that lasted for almost 8s.

The problem might be that clients might think they can connect to the AP, however they will be denied each time. Maybe try just unplugging it 🙂

unknown

Maybe someone from Ruckus can explain the intended behavior.

marcus_burton

The problem is that once clients are associated to an AP, there is no widely supported way of moving clients to another AP--the APs don't have control over this decision. We can always send disassociations, but this is not graceful and would be the same as just unplugging the AP. 802.11v offers a mechanism to solve this problem, but clients today are not supporting it.

My only alternate suggestion would be to reduce the tx power on that AP that needs rebooting. If you reduce it to minimum, it might prompt some associated clients to seek a better AP and roam--of course, no guarantees here because client roaming is unpredictable and even at minimum tx power, the clients still might not be motivated enough.

jelle_alten_606

Thanks!

keith_redfield

We need more motivated clients.. Image_ images_messages_5f91c419135b77e247963a6a_603cb52fd332dfd1856b1235971596b6_tonyrobbins_inline-4a9360ad-f05e-43e7-b6f5-de20a2d968f9-397594630.jpg1389888890

Image_ images_messages_5f91c419135b77e247963a6a_603cb52fd332dfd1856b1235971596b6_tonyrobbins_inline-4a9360ad-f05e-43e7-b6f5-de20a2d968f9-397594630.jpg1389888890

jelle_alten_606

or gullible would be nice...

unknown

re: "no widely supported way":

I recall having a standalone AP that was continually detecting interference and changing channels.

The impact on end users was that they said connectivity was "slow".

(It was the only ruckus in the building at the time and clients didn't switch to a non-ruckus AP, they always stuck w/ the Ruckus when it appeared on another channel)

I *thought* (but have no Idea where I might have heard) that when a Ruckus AP detects interference and decides to do a channel-change, it did something to alert associated clients and let them know what channel it was changing to.

Did I completely imagine that?

Or... Is this a message that the majority of wireless clients would not understand?

keith_redfield

802.11h standard covers notification to clients. Intel Proset seem to have had some problems with these over the years, but it looks like very latest driver updates are taking care of it.

unknown

OK... Can you confirm that the notification tells the client what channel to meet the AP on or is it more of a "go away" message?

marcus_burton

The notification is called a Channel Switch Announcement (CSA). It's original purpose was to facilitate an AP's transition from one channel to another channel due to the presence of radar signatures on the first channel. Wi-Fi protocols are required to avoid radars. So yes, the CSA tells the client about the new channel and when the switch will officially take place so that the network can stay synchronized on the right channel.

Of course, not all clients support CSAs, but the majority do. One thing to be aware of is that when you first deploy a Ruckus AP that is using this channel switching technique (called ChannelFly), there will be a lot of channel changes. That is by design, so the AP can test all the channels and build an understanding which channels work best. Then it settles. You should not see a lot of ongoing, frequent (every few minutes would be a problem!) channel changes if the AP has been up and running for 24 hours or so.

unknown

Ah, good. I'm *not* imagining things.

In my case I was (once upon a time) seeing channel changes once-a-minute or more.

I wonder if this feature could be [ab]used to direct clients to a *different* AP.

I'm sure there'd be lots of concerns about "breaking the standard", etc.

What a cool feature that would be, though.

Hey! Feature request over here!

marcus_burton

It could be possible to confuse a client station with the CSA, but hijacking a station to another AP would not work. 🙂

If you sit down and read the 802.11 specs for a while, you can come up with dozens of potential DoS attacks (or annoyances) that could be performed simply by violating standard 802.11 behavior.