Clients keep getting Disassociated from AP = Reason 8

  • 1
  • Question
  • Updated 2 years ago
  • Answered
  • (Edited)
Well, the on-going saga continues.

I have an R600 that for some reason disassociates clients giving 'reason 8' that i found in the web UI log.

Could someone tell me what reason 8 is please?

Also, could someone maybe explain what the AP classes as 'interference'?

I am confused as to why the AP all of a sudden starts to SmartSelect to find a clearer 5G channel when there no other rogue 5G networks anywhere nearby.

Plus, the 2.4G network is perfectly stable and that has plenty of reason to hop about as there quite a fair few nearby networks.
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes

Posted 2 years ago

  • 1
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
Reason Codes are here:

http://www.aboutcher.co.uk/2012/07/linux-wifi-deauthenticated-reason-codes/

Reason Code 8 is due to client leaving the BSS by means of AP moving the client to another access point using non-aggressive load balancing.

In regards to Channel selection do you have Channel Fly turned on?
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Hi Sean, and thanks.

Interesting about the load balancing as there were only two clients connected at the time to the AP 5G network.

Yes, I have ChannelFly (smart select) turned on for 2.4 & 5 but the 5 just seems to drop everything and jump channel randomly, with no other networks nearby. (After checking, the 2.4 has done it a bit but not as much).

I am using the basic NetSpot to keep an eye on whats going on, and im the only 5G network that even gets picked up by that. This is why im wondering why the AP is channel flying.
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
Is this a home network?
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Yes it is.
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
The way Channel Fly works is that it is always trying to find the best channel to deliver throughput to the client by using predictive capacity management.

You can alter the mean time between channel changes using this cli command:

set channelfly wlan0 mtbc 500

In my opinion I would turn off Channel Fly is it can be destructive in nature to certain clients; I have a home network which is all Ruckus, and I don't use Channel Fly as my Sky Box does not like it.
(Edited)
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Thanks Sean,

I have turned off Channel Fly and everything seems to be settled for now.

Its a shame really as i'm sure its a great idea to keep the wifi availability as clean and clear as possible.

With regards to the non aggressive load balancing, would it still perform this even if there were only two clients connected to one AP?

I have noticed a couple of times, that with both near one AP, one has hopped to another but i havent thought about checking the log until recently, or even realised the load balancing feature.
Photo of Michael Brado

Michael Brado, Official Rep

  • 2114 Posts
  • 297 Reply Likes
Channelfly uses all 11 available 2.4G channels, while Background Scanning uses only channels 1/6/11, and should provide ~33% better client throughput.

Using the 'set channelfly wlanX mtbc 200' (mean time between changes) will decrease the frequency that you see APs change channels to avoid interference.

Only if you have clients which don't change channels well (Sky Box?) or VoIP badges, would we recommend turning off Channelfly, or better yet, run CF for a period of hours with default settings, then freeze your APs to those current channels when you disable it.

Client Load Balancing, which tries to equalize the number of clients on the same band of adjacent APs, will never disconnect already connected clients.  It will withhold probe responses and association responses from new clients, if the AP already has 20 or more clients connected.  Note: Client Load Balancing does not function if less than 20 (default) clients connected to AP radio.
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Thanks Michael,

I did indeed let the AP's settle on a channel and then manually locked them to those and all seems to be ok so far for the 5G band.

I have left the 2.4G with smart select for now as that is quite stable.

However, surely it would be better for the AP to look for clearer channels before it decides to change? 

Its a bit of pain that it decides to hop around and keep disconnecting clients. 
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
Channel Fly does asses all channels prior to changing.

Here is the feature sheet:

http://c541678.r78.cf2.rackcdn.com/feature-sheets/fs-channelfly.pdf

I have also heard that there is also a new version of Channel Fly coming out soon, who knows what that will bring :)
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
I have just checked the log and its shows a Reason 8 many times, and these are clients on the 2.4G network.

I do not have that many wifi clients in the house so maybe there is a firmware issue?

Just to point out that i had the same issue on the 5G network, and that was with only 2 clients connected.

One of them from the log...

"RuckusAP daemon.warn Eved: STA-DISASSOC-REASON,nimac=2c:f0:ee:06:ab:96,func=ieee80211_recv_mgmt,line=7033,hint=recv disassociate (reason 8),rx_rssi=59,ack_rssi=0,reason=8,freq=2472,chan=13,stats=(841,94534,940,228925)"

Would this show when a client has disconnected from the AP after leaving the house?
(Edited)
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
Is this Apple device still in your network: 2c:f0:ee:06:ab:96?

If it is not, then the reason code 8 is purely down to the fact that the STA has "Disassociated because sending station is leaving (or has left) BSS"

Here is an extract from Ruckus Support:

When disconnecting from an AP, what does reason code X mean?

Summary

This article provides insight into the reason codes for why an unsolicited notification management frame of type Disassociation, Deauthentication, DELTS, DELBA, or DLS Teardown was generated for a UE. This article lists the various reason codes along with a basic description.

Question

When disconnecting from an AP, what does reason code X mean?

Customer Environment

The customer operates any WIFI access network, where the 802.11 standard is adhered to by access points and UEs.

Root Cause

An AP may disconnect a UE for any number of reasons. These reasons are provided to the client by way of a reason code supplied in an unsolicited management frame.

Troubleshooting Steps

In a Ruckus AP Support File, note the disconnect reason cited for the particular disconnect in question, for example:
 

Mar 23 08:54:21 RuckusAP-kla daemon.info hostapd: @@204,clientDisconnect,"apMac"="xx:xx:xx:xx:xx:xx","clientMac"="64:76:ba:98:27:de","ssid"="MySSID",
"bssid"="54:3d:37:d8:9c:a8","wlanId"="49","tenantUUID"="839f87c6-d116-497e-afce-aa8157abd30c",
"apName"="RuckusAP-kla","apLocation"="My Test","clientIP"="10.2.12.2","vlanId"="100",
"radio"="b/g/n","encryption"="None","hostname"="macbookair","firstAuth"="1427100759",
"associationTime"="1427100759","ipAssignTime"="1427100766","disconnectTime"="1427100861",
"sessionDuration"="102","disconnectReason"="8","rxFrames"="305","rxBytes"="21118","txFrames"="85",
"txBytes"="13640","peakRx"="19934","peakTx"="13640","rssi"="25","receivedSignalStrength"="-69",
"Instantaneous rssi"="17","Xput"="0"

In this example, the disconnect was issued due to the sending station leaving (or having left) the BSS (reason code 8):

Resolution

When an Access Point (AP) disconnects a UE, according to the 802.11 standard, it must provide a reason code for why this event took place. Below is a table of the reason code numbers and their associated descriptions.


Outside of the above, what Firmware are you running and how do you have you WLAN configured?

Also please note that just because you see something in the log, does not make it an issue.

I would start with the approach of are you experiencing any connectivity issues (other than what you see in a log), if so then i would start to look at each of the mac addresses that are having the issues

Note: Reason codes are not all bad and Reason Code 8 in my eyes is one of these, as is Reason Code 4.
(Edited)
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Hi Sean, thanks for all the information!!

Yes, that particular device has indeed left, however, when i originally posted, this was two clients on the 5G network, with both of them right in front of me with one AP virtually above me on the ceiling.

With regards to the ChannelFly (however, I am using SmartSelect), when i initially had the problem, it was jumping every few minutes to a different channel and disconnecting clients that were associated with it. It was as if the AP had been rebooted (which it hadnt) and was doing the initial scan for the cleanest channel.

Therefore, because i was actually having random reboots i decided to drop the firmware back to 100....128 and so far so good.
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
Hi Jason,

No worries, your welcome.

If you are seeing issues where clients are dropping from the AP then that is certainly unusual behaviour.

I cant really offer any comment on the base 100 images, as I only use these to migrate AP's to our SCG and ZD platforms.

Good luck with it all

:)
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Ok thanks anyway!
Photo of Michael Brado

Michael Brado, Official Rep

  • 2114 Posts
  • 297 Reply Likes
Client devices determine when to roam and troubleshooting client connectivity is a common need.

The log message included the key bits "hint=recv dissassociate (reason 8)", so the AP reported
receiving the dissassociate from the client.  APs will follow these leaves with a clean-up sending
a dissassociate from the AP the client left (probably a few lines further in your logs).

Regarding 5G behavior specifically, if you live anywhere near a public airport or military base, you
can program your APs to avoid the middle UNII bands that have Radar/DFS associated with them.
APs seeing radar have to change channels and go silent, which can be disruptive for the brief
period.

Avoid this by setting your ZoneDirector's Configure/System, Country Code -> Channel Optimization
to Optimize for Compatibility choice.  All 5G wireless clients should have no problem operating on
the channels available for Channelfly/Background Scanning selection, when you have this set.
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Thanks Michael,

However, i am running the three in standalone without a ZD so i dont have this option.

Would the Unleashed controller give me this function?
Photo of Sean

Sean

  • 342 Posts
  • 87 Reply Likes
I would not consider Unleashed at the moment as it is very buggy.
Photo of Michael Brado

Michael Brado, Official Rep

  • 1982 Posts
  • 276 Reply Likes
Hi Sean, if you have any negative experience on Unleashed to lead you to think it's "buggy", can you please open a ticket with Tech Support?
What "problems" have you seen please, with how many APs in what type of physical environment?  With all type of clients or just some, etc?
Photo of Sean

Sean

  • 342 Posts
  • 87 Reply Likes
Hi Michael,

I work for a carrier and I cant dedicate resource to opening tickets for unleashed when its not a product we will be using

As you know the second you open a ticket, you end spending a lot off time helping with debugging the issues.

However when it does, there will no doubt be tickets galore ;)

Sean
(Edited)
Photo of Michael Brado

Michael Brado, Official Rep

  • 1982 Posts
  • 276 Reply Likes
Great, thank you.
Photo of Michael Brado

Michael Brado, Official Rep

  • 2114 Posts
  • 297 Reply Likes
Did I see someone else reply about 3 Standalone APs?  You can run Channelfly for a period of hours
during daily use, then statically save/assign the channels that were last selected.  Avoid the DFS/radar
channels in 5G, but you can advertise the same SSID(s) on both radios of all APs in a small business
or home environment.  From the title of this topic though, it is not unusuall, in fact expected, to see
dissassociated from AP msgs as clients move between APs.
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
I haven't opened a ticket, however, I have asked a question in the Unleashed forum.
Photo of Sean

Sean

  • 346 Posts
  • 88 Reply Likes
Here is some information that might help you:

https://forums.ruckuswireless.com/ruckuswireless/topics/unleashed-aps-with-zonedirector-1106?utm_source=notification&utm_medium=email&utm_campaign=new_comment&utm_content=reply_button&reply[id]=16227965#reply_16227965

I have not personally statically assigned IP addresses to the AP's, so cannot confirm if there is a work around to the bug that I, and others, have experienced.

Good Luck

Sean
(Edited)
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
I'm not sure if this thread is about channelfly, "reason:8" or "unleashed".If it's about channelfly then:

If you're in a crowded wifi environment where other people's APs in the area are competing w/ you for bandwidth, then channelFly may be helping you.

If you're using it in a controlled environment where you manage all the APs and there are no rogue APs, then (in my opinion) you should turn channelFly off because it causes more problems than it solves.
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Thanks Bill,

The original question was about "Reason 8" which has now been answered, and i think it drifted into Unleashed.

As you have advised, i did make the decision to fix the channels and now everything seems to be ok on the 5G networks.

However, the 2.4 is still on because of a few rogues nearby.

These are now jumping around all over the place when "Channel Flying" and not just doing the one hop. As i was told, it should scan first and then hop, but mine don't, and thats across 3 AP's.
(Edited)
Photo of Dave Watkins

Dave Watkins

  • 56 Posts
  • 10 Reply Likes
From my understanding, ChannelFly can't "scan first", it only has one radio and that is servicing clients, so the way it scans is by hopping and then seeing whats happening where it's landed. Over time it builds a good understanding of what channels are congested at what times of the day and then avoids them, building that initial data can take a couple of days and even after that hopping is common. 

On top of that, there seems to be a large number of 2.4Ghz devices/drivers that don't support the notification used by the AP to indicate it's changing channels. I see this even on dual band client cards, they happily seamlessly follow a ChannelFly enabled 5Ghz radio but fail to do so when on 2.4 and have to re-associate. For that reason I've never used ChannelFly on 2.4 after the initial test showed those results. I use background scanning with a long interval for 2.4
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Thanks Dave,

Another 'interesting' development is that on my R500, it does the scanning and settles on a channel, however, for some reason, when my iPhone (6s) connects to its 5G network, it "detects interference" and so channel hops and dumps the client.

This is the ONLY time it hops as i have tested it over the last few days, and with the very latest firmware released a few days ago and the logs show it in detail.

On my R600's everything seems to be ok and this doesnt happen. In fact, one of the R600's mainly has my iphone and Macbook connected and hasn't had this issue. 

Edited to add...

I am also noticed that one of my R600's is seemingly having issues.

During the night agin, my iPhone will randomly associate and then disassociate, and from what i can see in the logs gives Reason 0. 

I also now have the following: "wmi_peer_sta_kickout_event_handler:838 Kicking off STA *************** AID 1"

I have two R600's and the main one downstairs does not have this issue, as i am connected to it all day.
(Edited)
Photo of Monnat Systems

Monnat Systems, AlphaDog

  • 760 Posts
  • 163 Reply Likes
is your firmware on R500 and R600 same?
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
Yes they have the very latest standalone firmware
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
Re: "interference"
FYI: I have just over 100 Ruckus APs of various models.
Some of them have already been hard-coded to a channel to prevent "interference" messages and channel hopping.
Others are in high_density_of_AP areas where a manual channel plan is not practical or in low_density_of_AP areas where you'd think a manual channel plan wouldn't be necessary.
In the past 14 days I've gotten 390 "interference" messages about APs changing channels.
That's about 27 channel changes a day, or about 1/3 the number of APs per day.
Fairly often, the messages will show a single AP switching from one channel to another, and then right back to the original channel.

I'm not on the latest firmware but this situation has persisted through all the firmware updates I've done.

This is pretty far from the original "reason 8" topic/title.
Maybe it's time to open a new question.
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
FYI: I don't think you're causing yourself any extra channel hopping problems by running standalone firmware. Current generations of ZD firmware don't seem to do anything to coordinate what channels get selected by what APs. I would assume that "unleashed" also does not coordinate these things. (at least, not beyond what's hard coded in your config)

I *am* surprised to hear that unleashed doesn't allow for separate SSIDs per radio, since this is the solution that's often recommended by support reps when there are roaming issues.

I believe the only thing that a ZD (or unleashed) gives you is a single point of management. (and maybe logging)
If you're not going to be overly bothered by having to update firmware and configs once for each of your (3) APs, you should be OK.
Photo of JasonS

JasonS

  • 89 Posts
  • 8 Reply Likes
To be honest, Unleashed is a great tool, as i have tried it on one of my Ap's but while its still in its infancy, ill stick with the standalone firmware for now, as it does have a few additional features, although Unleashed does have 802.1X settings for assisted roaming!
Photo of John D

John D, AlphaDog

  • 497 Posts
  • 136 Reply Likes
BTW, the back and forth channel hopping thing with ChannelFly is normal, and how the algorithm works. It is supposed to statistically sample channels to determine the actual capacity, not just estimated capacity. Hopping back and forth simply means it wanted to update its sampling for that channel, but confirmed the original channel was better.

If your clients don't deal well with channel hopping (e.g. they don't support 802.11 channel switch announcements), you are better off turning off ChannelFly or running in run-stop mode.
Photo of Bill Burns

Bill Burns, AlphaDog

  • 203 Posts
  • 38 Reply Likes
Re: ChannelFly: (another topic that should really have it's own question)

The amount of channel hopping I'd have in my environment would be ridiculous if I turned ChannelFly back on.

They claim it should settle down after a few days, but for me it never did.
(I don't recall if run-stop mode existed back then)
And... I don't think ChannelFly data gets stored on the controller, so every time I updated firmware or had an AP reboot, ChannelFly would give me that wild channel hopping behavior again. (until the run-stop period was over)
With the channel plan as unstable as it is, I have no desire to give ChannelFly another try.

w/ no ChannelFly, I'm still getting 1/3 the number of channel hops every day as I have APs.
(due to "interference")

AFAIK: ChannelFly *sampling* happens via background scanning and does not involve channel hopping.

IMHO: ChannelFly is mainly useful for congested RF environments where you don't control all the APs. (where your neighbors APs push a lot of bandwidth)
..and where "it works for most people most of the time" is a good level of service.
Carrier WiFi is a good example.

If it works for you, that's great (and I'm glad to hear it) but I won't be using ChannelFly again.
Photo of John D

John D, AlphaDog

  • 497 Posts
  • 136 Reply Likes
Hey, no worries, Bill, I've ran into the same in the past: https://forums.ruckuswireless.com/ruckuswireless/topics/channelfly-and-rapid-channel-changes

It was implied that it was basically expected behavior. FWIW, I found this behavior was dramatically improved in firmware 9.12, where it now seems to be much more respectful of the MTBC setting (mean time between change), and i now see the behavior where it starts out quite aggressive and then settles down over the course of a day.

Right now, my outdoor AP makes 1 channel switch every day or so, and my indoor AP's average 1 switch every other day. MTBC is set to 600 minutes (10 hours).

I'm not trying to convince you to try it again, of course. Just reporting my observations.