Gracefully shut down APs ?

  • 1
  • Question
  • Updated 6 years ago
  • Answered
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.
Photo of Jelle Alten

Jelle Alten

  • 60 Posts
  • 12 Reply Likes

Posted 6 years ago

  • 1
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 49 Reply Likes
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.
Photo of Jelle Alten

Jelle Alten

  • 60 Posts
  • 12 Reply Likes
Can't we tell the AP to maximize the number clients to zero? Or some other trick?
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 49 Reply Likes
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.
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 49 Reply Likes
Although I see that it takes a good 2 seconds before it stops all conversations.
Photo of Jelle Alten

Jelle Alten

  • 60 Posts
  • 12 Reply Likes
That sound like "gracefully". Nice.
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 49 Reply Likes
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 :)
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 49 Reply Likes
Maybe someone from Ruckus can explain the intended behavior.
Photo of Marcus Burton

Marcus Burton, Official Rep

  • 34 Posts
  • 20 Reply Likes
Official Response
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.
Photo of Jelle Alten

Jelle Alten

  • 60 Posts
  • 12 Reply Likes
Thanks!
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 52 Reply Likes
We need more motivated clients..
Photo of Jelle Alten

Jelle Alten

  • 60 Posts
  • 12 Reply Likes
or gullible would be nice...
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 42 Reply Likes
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?
Photo of Keith - Pack Leader

Keith - Pack Leader

  • 860 Posts
  • 52 Reply Likes
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.
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 42 Reply Likes
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?
Photo of Marcus Burton

Marcus Burton, Official Rep

  • 33 Posts
  • 20 Reply Likes
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.
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 42 Reply Likes
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!
Photo of Marcus Burton

Marcus Burton, Official Rep

  • 33 Posts
  • 20 Reply Likes
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.
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 42 Reply Likes
Hey, the comment I replied to disappeared.
Where did your initial CSA comment go?

I'm not sure that having an associated AP send a Channel switch announcement to encourage a client to re-associate elsewhere would count as "hijacking" but ok.
Impossible is impossible.
Photo of Marcus Burton

Marcus Burton, Official Rep

  • 33 Posts
  • 20 Reply Likes
It is still there, but it looks like the forum has a type of auto-hide feature...news to me. :)

I thought you were suggesting that someone could maliciously use a CSA to hijack a client onto a rogue AP.

If you're talking about using a CSA to encourage a client to move from one AP on one channel to another AP on another channel (an approved AP!), then this also will not work because a CSA is designed for the associated AP and its service set only.

Now to your point, there is a feature in 802.11v that allows an AP to suggest that a client roam to another AP (a very useful function). It's not mandatory for the client to do what the AP suggests, though. And, the bigger problem is that very few clients support it (seeing the theme here...client vendors do not do what we want!!!), so it's not yet worthwhile to build a feature around this functionality...unfortunately.
Photo of Primož Marinšek

Primož Marinšek, AlphaDog

  • 413 Posts
  • 49 Reply Likes
@Marcus. Can you share which clients support 11v?