Higher Education

We have been getting increasingly frequent complaints from the students of being disconnected regularly from the wireless network.  Aside from the usual difficulties of getting the students to provide further details it has also been difficult to track down when the students do give details.  The problem can happen in the middle of an active session like a Skype call, but is often just a pop up on Windows laptops notifiying them of the loss of connectivity or they see the spinning wheel on an OS X laptop.  As the reports go the commputers often reconnect without any action needed but sometimes the computer only connects if the student shutsdown wifi and turns it back on. In all cases the students are  Setting debugging on the clients has not shown any obvious patterns. Sometimes the logs shown a Client Match event, other times they show the client timed out and was deauth'd, and sometimes nothing obvious is in the logs.  I can not reproduce the problem, predict when it will happen next or find a clean way of identifying it has happened in the logs.  Any suggestions are greatly appreciated.

 

We are running 6.4.2.2, having upgraded from 6.4.1.0 two weeks ago.  We have a pair M3's as the Master and two 7220's as local controllers sharing the load between ~560 APs.

 

It could be something in 6.4 and I am considering going back to the latet 6.3.  We went to 6.4 for the improvements in Airgroup and the addition of getting the Chromecast to work. 

#7220

We are a small shop with one 7210 controller and about 170 APs and we are seeing exactly what you describe after moving to 6.4.2.2 from 6.4.1.0.  We are new to Aruba (about three months and counting) so we are not as familiar with the tools available to troubleshoot, but likewise we have not been able to pin it to any particular event.  We are also thinking about bumping back down to 6.4.1.0.  Our primary SSID is 802.1X, and we also provide an open SSID for students to register devices.  Most that we've heard from are on the 802.1X network but we are not sure that it is exclusive.  Would be interested to hear if 802.1X is also involved for you.

 

#7210

---

@jwhitaker@transy.edu wrote:

We are a small shop with one 7210 controller and about 170 APs and we are seeing exactly what you describe after moving to 6.4.2.2 from 6.4.1.0.  We are new to Aruba (about three months and counting) so we are not as familiar with the tools available to troubleshoot, but likewise we have not been able to pin it to any particular event.  We are also thinking about bumping back down to 6.4.1.0.  Our primary SSID is 802.1X, and we also provide an open SSID for students to register devices.  Most that we've heard from are on the 802.1X network but we are not sure that it is exclusive.  Would be interested to hear if 802.1X is also involved for you.

 

---

jwhitaker,

 

Welcome to Aruba.  Please look at the article here:  http://community.arubanetworks.com/t5/Technology-Blog/Removing-the-Bottleneck-in-Wireless/ba-p/77978 to see a list of things that you can check to determine what your problem is.

If you open a TAC case in parallel, it would help everyone on this thread if you report back on any progress you make.

 

#7210

We are seeing the same problems in our environment.  We are seeing complaints only from our 802.1x SSID.  We are also seeing some issues where students are not able to connect at all despite fantastic signal strength and almost zero interference.  

 

We too upgraded to 6.4 for improvements in Airgroup.  We first started noticing problems in 6.4.2.0 but we suspect that there were some problems in 6.4.1.0 as well.  We updated to 6.4.2.2 code today to try to mitigate some of the issues.  

 

We are running a single 3600 as a master with 4 M3s.  We have a total of 878 access points with a mixture of 105, 130 series, and 220 series with a few 175 and 275.  We see the issues across all models.

 

Did you first notice the problem after you updated to 6.4?

Have any TAC cases been opened to investigate these issues?

 

interesting to know as I am running a hotspot network on 6.4.2.2 and I haven't heard of any issues yet but obviously the configuration is much simpler and we are running an open SSID.

We started on 6.4.1.0 because we have AP-205s and needed 6.4 to support them, so we've not known anything different.  And, we have been in the process of rolling out Aruba across campus and replacing our previous system, so there was a lot of stuff in flux - if someone had an issue, we said "we're under construction" most times.  Eventually, we got it rolled out everywhere and things seemed OK.  From our view, 6.4.2.2 made it worse, or at least that's when we started hearing more complaints.

 

#AP205

Thanks for all of the replies!

 

I have just opened a case with TAC on this issue.

 

I am not sure if we had this problem before 6.4.  It has been trickling up for a while and I am not sure if it goes back to this summer or earlier.

802.1x is how are students connect.  We do have a PSK network for things that have difficulty with 1x.  The examples I have are all 1x.

 

Logs and user-debug are uploaded to the ticket.  I will let you know what I find.

 

Thanks!

What type of APs are you using ?

We have a mix of 105, 125 and 225 APs.  Within a building the model type is usually the same.

We are using primarily 134 and 135s.  We have a few buildings that are running 224s and a few 105s in select locations.  For our outdoor environment we have 50 AP175P and 4 275

The reports that have actually given any details came in for Windows 7 Pro SP1 and OS X (10.9.3).  The word of mouth includes every flavor of Windows or OS X laptop.

 

802.1x EAP-PEAP for us.  We worked through some problems with Bradford Network Sentry earlier in the semester but we are not seeing any correlation of the disconnects with RADIUS events.  Patching and then upgrading to the latest with Bradford has taken them out of the process.  

 

 

I'm no authority here, but I believe we started seeing something similar when we upgraded to 6.3.xx. I know we opened a case with Aruba Support and believe we had to tweak our client-match settings. Since then, things have been much more stable. We are now happily running all 220 local controllers(3200's, 3400's and 7210's) and approx. 6000 APs(AP125, AP135 or AP225's) on 6.3.1.5.
I'm sure the new Apple OS versions aren't helping matters any. We noticed the problem most significantly on our Macbooks, they tended to drop randomly and took a long time to reconnect. At the time, we had to upgrade to 6.3 to support the AP225's. We initially thought it was an issue with the 225's and the 802.11ac settings.
The client-match adjustment may have been necessary because of our implemented 802.1x (EAP-PEAP, MSCHAPv2) settings where we still use WPA-AES and not WPA2. There was some issue related to that, I just don't recall what it was.
I hope that's somewhat helpful and not misleading

#AP225
#7210

So a fair amount of people have mention "twerks" (and not the Miley Cyrus kind) to client match that seemed to stabilize the situation. What adjustments were made if you guys don't mind?

I am curious what you all have for your SSID/Advanced settings, specifically basic and transmit rates.  

 

We have been fairly stable minus some odd disconnect issues with some of our 10.10 OSx users.  We are running 802.1x PEAP - WPA2-aes.

 

 

before making the adjustments i would ask support.  I've heard that the 'defaults' for CM where changed in some revision of 6.3.  Having said that here are the commands for it.  

 

cm-report-interval

cm-unst-ageout-intvl

cm-band-a-min-signal

cm-sticky-check-inter

cm-sticky-snr

cm-sticky-snr-delta

cm-sticky-min-signal

cm-steer-timeout

cm-lb-thresh

cm-stale-age

cm-max-steer-fails

cm-lb-client-thresh

cm-lb-snr-thresh

cm-lb-signal-delta

 

other things to look at are. 

 

how often are power settings changing

how often are channels changing

default data rates in that area

default beacon rates. 

 

all these could cause disconnects for roaming clients. 

Aaron,

 

I had to double-check the post because I thought I wrote it.  We have roughly the same AP's, same complaints, almost the same controllers (was actually hoping the 7200's were better since we're just M3's still), the same reason for upgrading (chromecast) and running the same ArubaOS.  6.3 didn't seem any better for us and we also have some new AP-104's that we loan out for students in their dorms.

 

This year has been brutal for us.  The prior 7 were great. People want to know what's up with wifi. My best guess at this point:

 

 

I think there is only so much I can 'fix'.  

It looks like I hit a nerve with this topic!  Wish I started it weeks ago.

 

It looks like the problem predates 6.4 for us.  One of my reports from two months ago mentions the problem going back a year.

 

TAC is on the case, so I will let folk know how it goes.

The nearby Colleges are struggling with similar problems as well - and they are not Aruba customers.  I guess these devices are really being tweaked for home and/or open networks; compatible with anything you could ever plugin.

Are these all types of devices or only OSX? If the latter, what version?

For us it is mostly OSX.  MacBooks are also the most common device we have.  When I ask our student workers if they see it with Windows Laptops as well the response was 'oh, yeah, those are even worse'.  However the configuration is generally the problem with Windows (or virus, software firewall, wired port doesn't work either, etc...); at least from what I've been able to get my hands on.

I love the graph!

---

@pgemme wrote:

Aaron,

 

I had to double-check the post because I thought I wrote it.  We have roughly the same AP's, same complaints, almost the same controllers (was actually hoping the 7200's were better since we're just M3's still), the same reason for upgrading (chromecast) and running the same ArubaOS.  6.3 didn't seem any better for us and we also have some new AP-104's that we loan out for students in their dorms.

 

This year has been brutal for us.  The prior 7 were great. People want to know what's up with wifi. My best guess at this point:

 

 

I think there is only so much I can 'fix'.  

---

pgemme,

 

You are missing a slice for "the real problem" (excellent graph, by the way).  

 

For everyone on this thread who is having issues and it is mission critical; if you are over your head with dealing with a problem, and TAC cannot help you, please consider having a trained professional take a look at it.  Basic troubleshooting and even TAC can only go so far.  Old and incorrect assumptions often cloud and delay defining a problem and getting to a resolution.  Unhelpful user feedback can also sway a situation in the wrong direction.  A trained professional can look at all the facts and narrow things down to something of substance, so that your issues can be defined and systematically dealt with.

 

Every environment is different and many times specific deployments require specific approaches.  That advice normally can only be given by someone who is onsite and gets a full picture of what could be happening.  Basic principles and even best practices can only go so far; those principles and practices need to be modified to suit your specific deployment.

 

Your Aruba Sales team would normally be aware of a go-to professional in your region who would be able to give you the help you need.

 

Another thing to look at is not only 802.1x but client match, channel utilziation, and whether clients are 2.4 only with roaming issues. We have run into issues like this as well but have found that a lot of the devices having the issue have poor 2.4 only 1x1 and 2x2 NICs. We end up disabling roaming in the driver settings. 

 

In regards to 802.1x take a look at your VAP, and AAA profile. Also take one of the users or one of your test machines you have been able to replicate the issues on. Look at your asscioation times/timeouts and compare to RADIUS or what ever your using for auth. I would also look at what your using whether it be EAP-Peap, EAP-TLS, etc and verify your not having issues there. Also look at your load balencer if your using one for Radius, etc

I too have had several complaints about this...I've got 2 different AOS versions, a 6.4.1.0 and a 6.3.1.6.  So far, only have complaints in 1 area on the 6.4.1.0 code version... I went there myself, with several different machines (android, mountian lion, yosemite, and windows 7), and experienced issues with all but the android, all simultaneously. 

 

My initial complaint came from a student who had just upgraded to yosemite... I've got a ticket open with Dell, who in turn has one open with Aruba on this matter. 

 

My experience was not only a disconnect - reconnect, but a failure to connect. I have several 802.1x networks, hitting several different radius servers, as well as an open network...During this failure to connect time-period, not a single SSID worked for me on the laptops... My android phone however, no issues....

---

@lkfirestone wrote:

I too have had several complaints about this...I've got 2 different AOS versions, a 6.4.1.0 and a 6.3.1.6.  So far, only have complaints in 1 area on the 6.4.1.0 code version... I went there myself, with several different machines (android, mountian lion, yosemite, and windows 7), and experienced issues with all but the android, all simultaneously. 

 

My initial complaint came from a student who had just upgraded to yosemite... I've got a ticket open with Dell, who in turn has one open with Aruba on this matter. 

 

My experience was not only a disconnect - reconnect, but a failure to connect. I have several 802.1x networks, hitting several different radius servers, as well as an open network...During this failure to connect time-period, not a single SSID worked for me on the laptops... My android phone however, no issues....

---

lkfirestone,

 

If you can go to the dashboard and look at one or two access points in the area, you might want to see what the channel utilization is for them in the area at that time when you are having issues.  If there is a hidden source of interference or high utilization, dropped or corrupted packets during 802.1x could prevent a client from connecting period.  It could also be environmental as in a non-wifi device causing interference.  How many SSIDs are you broadcasting in that area and do you have "Drop Broadcast and Multicast" enabled on all of your SSIDs?  Check out the post here:  http://community.arubanetworks.com/t5/Technology-Blog/Removing-the-Bottleneck-in-Wireless/ba-p/77978 to see if there are small things that you can check for...

 

 

Also take into account OSX Yosemite has known issues.

http://community.arubanetworks.com/t5/Education/Yosemite-roaming-issues/gpm-p/211019#M1106

We have seen the same issue and are running 6.3.1.10 with three M3 controllers (Master & two local) and about 590 AP's (105, 125, 134/5, 175 and some 225).  We are having random disconnects and dificulties reconnecting after (need to disable adapter or reboot computer).  More OS X users than Windows but not enough data to draw any defenite conclusions.

We got rid of some interference in one of the buildings and that helped a little bit with the number of times this happens.  However, students are still disconnecting randomly and the debug logs don't give any more information. We started getting reports of this problem about 4-5 weeks ago but we ran on the 6.3.1.10 long before that.  Please post if you were able to figure something out with TAC.

Just wanted to toss my hat into the ring as I am seeing some of these same issues. Small shop here, 4 - 3000 series controllers, dedicated master (3200xm) with three locals (3200xm, 3400 & 3600), running 6.4.2.0 across the board. Currently about 200 AP's, mix of 93's, 105's and now 225's. I have been seeing it on Win7 machines, iPads, iPhones and rarely on an Android. I haven't seen it on win8 though... hmmm there is some food for thought.

 

Anyway, I was attributing a lot of it to needed updates to various wireless drivers and whatnot, there apparently a known issue with the latest iOS and there was an update released for "known WIFI related issues" (according to our web designers iPad anyway). Now I am seeing the similarities and am thinking this is the same issue as everyone else here. Ill be monitoring this thread to see how it progresses too.

Since everybody is throwing in their hat. 

We are seeing the issue here at Boston College.  Dedicated Master with 8 local's (6.3.1.8) 

Windows/Apple OS on various devices. 

 

6.3.1.13 here and we're hearing of similar issues.   i'm trying to corner a client so i can catch a debug and get some client match and roaming information to see if i can pinpoint it..

 

7200 controllers master - local setup with roughly 4000 access points.  

 

If anyone catches some good info in a debug log let us know.

 

Thanks,

 

Brodi3man

 

We're having the same issues mostly from OSX (random disconnects and dificulties reconnecting after, no red flags in logs). We're running 6.3.1.8. We have 10 M3s (inlcuding master) and one 7220.

 

Has anyone tried disabling client match? Are folks running 80MHz channels in 5GHz?

 

Mike

#7220

---

@mldickson wrote:

We're having the same issues mostly from OSX (random disconnects and dificulties reconnecting after, no red flags in logs). We're running 6.3.1.8. We have 10 M3s (inlcuding master) and one 7220.

 

Has anyone tried disabling client match? Are folks running 80MHz channels in 5GHz?

 

Mike

---

 

We had a ticket (or 3) open with TAC regarding this issue.  They tried turning off client-match but it did not resolve the issue.  We worked with them for several weeks on this issue and had no luck resolving the problem.  We then made a few changes with them regarding our NAC (not Clearpass) and it seemed to fix the problem.  Recently we found out that the problem still exists but users had stopped reportin the issue to IT.

 

In our TAC support case we worked with head engineers and were not able to find a problem in the Arubas system but at the time nobody at TAC or engineering had heard of the issue.

 

Glad it's not jsut us

 

#7220

Here is an update on the latest from TAC.  They looked at the user debug for one of the few students reporting the problem in detail and are attributing the disconnect to "User Idle Timeout".  This was already on our list of suspects and it was interesting to get the same from them.  It does explain some, but not all, of the disconnects.

 

Last week we changed the timeout from default 300 seconds to 600 seconds.  This morning I have doubled it again to 1200 seconds.  Really hoping it does not cause problems in other areas but very curious to see how it goes.

 

I just sent them a user debug of another student from last night that was definitely using his computer to visit different web sites (they included a screen shot of their browser log!) when it (Windows 7 Pro SP1) was disconnected.  The logs showed the reauth but there was nothing leading up to it.  Waiting to hear back.

Make certain that your new user-idle-timeout does not exceed your DHCP max lease time. Otherwise, you could run into issues when the next client attempts to claim that same IP address (assuming you have Prohibit IP spoofing enabled).

Hi All,

I just searched throuh my archive and discovered this .....

 

Description: Macbooks client intermittently getting disconnected

 

Latest Status changed to:
It was found that the client was changing channels (moving to a to g radio) due to radar detected on DFS channel. The AP did not change channels..

Next Action changed to:
Recommendation to mitigate this is to remove DFS channels from regulatory domain profile. TAC is investigating to see if this is a known Apple issue..

 

I also reviewed my Client Match settings and they don't look that different from the defaults.

 

I might not have remembered all the events that surrounded our upgrade to 6.3 correctly. Apologies if I conveyed misleading information.

 

 

---

@jkotch wrote:

Hi All,

I just searched throuh my archive and discovered this .....

 

Description: Macbooks client intermittently getting disconnected

 

Latest Status changed to:
It was found that the client was changing channels (moving to a to g radio) due to radar detected on DFS channel. The AP did not change channels..

Next Action changed to:
Recommendation to mitigate this is to remove DFS channels from regulatory domain profile. TAC is investigating to see if this is a known Apple issue..

 

I also reviewed my Client Match settings and they don't look that different from the defaults.

 

I might not have remembered all the events that surrounded our upgrade to 6.3 correctly. Apologies if I conveyed misleading information.

 

 

---

jkotch,

 

You bring up a good point.  Do not run DFS channels unless you have absolute control over your clients.  In some cases, entire manufacturers do not have DFS certified or enabled on their clients.  Other manufactuerers that have enabled DFS channels don't scan on them often, so you could end up with an access point that serves few if any clients.  You would be creating black holes and irregular coverage for those devices with no DFS support.  In some cases, Radar will geniuinely create issues with DFS channels, but there is a chance that there are false positives. Disabling DFS channels will sidestep these issues.

 

If you used DFS to obtain spectrum, you should have a plan to unbond channels so that you can regain channel separation when you disable DFS.

 

 

 

I now also remember we had to adjust our 802.1x High and low watermarks, but I don't remember why.  We were seeing a lot of Throttling occurring before the adjustments.

I previously stated we're happily running 6.3.1.5 but it has just come to light that our Field Technicians all received new Macbooks last month and many of them are complaining of getting disconnected from one of our two 802.1X networks. I have to gather much more information still, but I believe they are experiencing this on MacOS. I have not heard complaints of Windows dropping connections.

Jkotch,

Is there any way you can be more specific about what parameters you had to change and in response to what?

I'm not purposely being elusive. I wish I could remember all the details. I welcome someone to connect up with me and take a look at our configuration. I don't want to post any false information so I am reluctant to post much of anything.
I believe that we customized our high and low watermark settings on the 7210 controllers because of some sort of 802.1x authentication issue that we had while running 6.3.1.5. I can't say for certain it was related to the disconnects, but there is a good chance it was. We were seeing a lot of 'throttling' happen and we had to keep adjusting the settings until we found the correct ones. We may have adjusted some of our Client Match settings as well. Based on other posts in this thread, I'm guessing the issue has something to do with 802.1X authentication.

Our current values.
Dot1x high watermark..................120
Dot1x low watermark...................114
Dot1x stm throttling percent..........50

 

 

If there's any more information you would like, please let me know.

#7210

jkotch,

 

No worries.  Thanks for being honest.  Maybe it will jog someone's memory.

 

There are alot of different issues in this thread.  Maybe someone can find something useful in everything that is contributed.

Update from SUNY Oneonta: 

 

Last Thursday night we worked with TAC on this and we changed ARM to maintain mode. Now reports from the two buildings where we made report better but still seeing disconnects. This is a client report from Airwave of currently connected clients. The problem exist AP's on campus not just one group, RF profile etc. So far I no matter what we have thrown at it nothing seems to change. Now this is the very same profile for RF that we have used for the past two years but haven't seen this problem. There are some increased devices from the student's side but we have pretty much the same enviroment in the reshalls as last fall semester that worked fine without a problem.  I'm digging up on my backup drive for a compairson of connected users then to now, but it really stands out when looking at the Duration and Association Time how big the problem is. Hays and Grant  AP's are where we have made changes with TAC. Hulbert below has all New AP 115's intalled in a Dense deployment.

 

 

 

For some reason it won't allow me to attach a file but here is the information that I wanted to convey. This is just a shortend version but I can send you the full file if you want to review. At this time there were 2508 users connected. But here are samples of what I'm seeing. Now this is all at random intervals, with not all the same client's bumped at the same time or from the same AP, or RF Profile.

 

Duration	Association Time	AP/Device	Sig. Qual.	Speed	Goodput	AOS Device Type	Role	SSID	Connection Mode	Usage	Ch BW
1 day 0 hours 16 minutes	11/11/14, 9:41 AM	Wilber-7E:0A	41	65	18	iPad	Admin-3	Red Dragon WiFi	11n 5 GHz	1.23 Kbps	HT20
1 day 0 hours 19 minutes	11/11/14, 9:37 AM	Macduff-104	32	36	55	iPod	registration	Red Dragon WiFi	11g 2.4 GHz	420 bps	-
1 day 0 hours 9 minutes	11/11/14, 9:48 AM	Higgins-A4:24	34	227	30	OS X	Resnet-9	Red Dragon WiFi	11n 5 GHz	10 Kbps	HT40
1 day 10 hours 18 minutes	11/10/14, 11:39 PM	Ford-C6:EE	41	0	48	iPad	Resnet-5	RedDragonSecure	11a 5 GHz	2.35 Kbps	-
1 day 10 hours 20 minutes	11/10/14, 11:37 PM	Grant-E0:EA	23	52	48	Android	Resnet-15	RedDragonSecure	11n 2.4 GHz	1.97 Kbps	HT20
1 day 10 hours 27 minutes	11/10/14, 11:29 PM	Hulbert-C019.aruba.oneonta.edu	52	0	26	Win 8	Resnet-15	Red Dragon WiFi	11n 5 GHz	314 bps	HT40
1 day 10 hours 31 minutes	11/10/14, 11:26 PM	Tobey-E2:39	35	0	20	iPad	Resnet-7	Red Dragon WiFi	11n 5 GHz	84 bps	HT40
1 day 10 hours 39 minutes	11/10/14, 11:17 PM	Huntington-CC:40	33	0	53	Windows	Resnet-13	RedDragonSecure	11a 5 GHz	773 bps	-
1 day 10 hours 9 minutes	11/10/14, 11:48 PM	Grant-E2:19	41	65	30	iPod	registration	Red Dragon WiFi	11n 2.4 GHz	445 bps	HT20
1 day 11 hours 1 minute	11/10/14, 10:56 PM	Matteson-2B:3A	32	36	45	iPod	Resnet-16	Red Dragon WiFi	11g 2.4 GHz	20 bps	-
1 day 11 hours 11 minutes	11/10/14, 10:45 PM	Matteson-CD:B6	39	35	45	Win 8	Resnet-16	Red Dragon WiFi	11a 5 GHz	4.26 Kbps	-
1 day 11 hours 14 minutes	11/10/14, 10:43 PM	Tobey-26:A7	44	0	70	OS X	Resnet-14	Red Dragon WiFi	11n 2.4 GHz	3 bps	HT20
1 day 11 hours 14 minutes	11/10/14, 10:43 PM	Wilber-7A:7E	49	64	25	Win 7	Resnet-16	RedDragonSecure	11n 2.4 GHz	1.41 Kbps	HT20
1 day 11 hours 25 minutes	11/10/14, 10:32 PM	Wilber-E2:C1	36	65	22	iPod	Resnet-1	Red Dragon WiFi	11n 2.4 GHz	49 bps	HT20
1 day 11 hours 38 minutes	11/10/14, 10:19 PM	Hulbert-B001.aruba.oneonta.edu	69	71	35	registration	Red Dragon WiFi	11n 2.4 GHz	0 bps	HT20
1 day 11 hours 47 minutes	11/10/14, 10:10 PM	Golding-E2:24	31	3	0	Win 8	Resnet-9	RedDragonSecure	11n 2.4 GHz	7.34 Kbps	HT20
1 day 11 hours 58 minutes	11/10/14, 9:59 PM	Hulbert-E011.aruba.oneonta.edu	63	65	18	iPad	Resnet-3	Red Dragon WiFi	11n 5 GHz	77 bps	HT20
1 day 11 hours 58 minutes	11/10/14, 9:59 PM	Wilber-7D:F7	0	0	46	registration	Red Dragon WiFi	11n 2.4 GHz	96 bps	HT20
1 day 12 hours 23 minutes	11/10/14, 9:33 PM	Higgins-c1:a4:2e	36	0	19	iPhone	Resnet-1	Red Dragon WiFi	11n 5 GHz	120 bps	HT40
1 day 12 hours 30 minutes	11/10/14, 9:26 PM	Littell-437.aruba.oneonta.edu	69	130	31	Win 8	Resnet-16	Red Dragon WiFi	11n 2.4 GHz	21 bps	HT20
1 day 12 hours 54 minutes	11/10/14, 9:02 PM	Huntington-317	39	30	54	registration	Red Dragon WiFi	11g 2.4 GHz	203 bps	-
1 day 12 hours 58 minutes	11/10/14, 8:59 PM	Hulbert-B031.aruba.oneonta.edu	58	0	90	iPad	Resnet-8	Red Dragon WiFi	11n 5 GHz	17 bps	HT20
1 day 13 hours 28 minutes	11/10/14, 8:28 PM	Hulbert-C016.aruba.oneonta.edu	58	65	18	iPad	Resnet-9	Red Dragon WiFi	11n 5 GHz	20 bps	HT20
1 day 13 hours 3 minutes	11/10/14, 8:53 PM	Blodgett-A3:2F.aruba.oneonta.edu	34	300	36	OS X	Resnet-4	Red Dragon WiFi	11n 5 GHz	1.99 Kbps	HT40
1 day 13 hours 5 minutes	11/10/14, 8:52 PM	Macduff-BC:32	29	0	49	iPod	Resnet-2	Red Dragon WiFi	11g 2.4 GHz	62 bps	-
1 day 13 hours 58 minutes	11/10/14, 7:59 PM	Littell-A4:7A	29	150	29	AppleTV	registration	Red Dragon WiFi	11n 5 GHz	736 bps	HT40

 

18 minutes	11/12/14, 9:39 AM	Hulbert-D074.aruba.oneonta.edu	31	65	55	iPhone	Resnet-8	Red Dragon WiFi	11n 5 GHz	62.5 Kbps	HT40
18 minutes	11/12/14, 9:39 AM	Hulbert-D077.aruba.oneonta.edu	44	2	21	Android	Resnet-9	Red Dragon WiFi	11n 2.4 GHz	96.4 Kbps	HT20
18 minutes	11/12/14, 9:39 AM	Hulbert-E004.aruba.oneonta.edu	73	0	46	Win 8	Resnet-16	Red Dragon WiFi	11n 2.4 GHz	53 bps	HT20
18 minutes	11/12/14, 9:39 AM	Hulbert-E019.aruba.oneonta.edu	27	65	16	iPod	registration	Red Dragon WiFi	11n 2.4 GHz	3.36 Kbps	HT20
18 minutes	11/12/14, 9:39 AM	Hulbert-E029.aruba.oneonta.edu	20	68	13	registration	Red Dragon WiFi	11n 2.4 GHz	0 bps	HT20
18 minutes	11/12/14, 9:39 AM	Hulbert-E029.aruba.oneonta.edu	61	283	189	OS X	Resnet-1	RedDragonSecure	11n 5 GHz	0 bps	HT40
18 minutes	11/12/14, 9:39 AM	Hulbert-E029.aruba.oneonta.edu	56	0	21	iPhone	Resnet-1	RedDragonSecure	11n 2.4 GHz	163 Kbps	HT20
18 minutes	11/12/14, 9:39 AM	Hulbert-E029.aruba.oneonta.edu	40	150	24	iPhone	Resnet-5	RedDragonSecure	11n 5 GHz	273 Kbps	HT40
19 hours 10 minutes	11/11/14, 2:47 PM	Tobey-E2:9E	31	150	19	iPad	Resnet-16	Red Dragon WiFi	11n 5 GHz	2.06 Mbps	HT40
19 hours 20 minutes	11/11/14, 2:36 PM	Huntington-225	47	0	51	Android	Resnet-6	RedDragonSecure	11g 2.4 GHz	28 Kbps	-
19 hours 31 minutes	11/11/14, 2:26 PM	Grant-E2:15	26	65	9	iPad	Resnet-9	Red Dragon WiFi	11n 5 GHz	412 bps	HT20
19 hours 34 minutes	11/11/14, 2:23 PM	Hulbert-D050.aruba.oneonta.edu	38	65	18	iPod	Resnet-1	Red Dragon WiFi	11n 2.4 GHz	0 bps	HT20
19 hours 34 minutes	11/11/14, 2:23 PM	Hulbert-D055.aruba.oneonta.edu	54	150	19	iPad	Resnet-12	Red Dragon WiFi	11n 5 GHz	20 bps	HT40
19 hours 41 minutes	11/11/14, 2:15 PM	Blodgett-CD:A0	32	33	54	registration	Red Dragon WiFi	11g 2.4 GHz	203 bps	-
19 hours 41 minutes	11/11/14, 2:15 PM	Curtis-5D:4F.aruba.oneonta.edu	30	0	34	Android	Resnet-5	Red Dragon WiFi	11n 5 GHz	13 bps	HT20
19 hours 41 minutes	11/11/14, 2:15 PM	Littell-446.aruba.oneonta.edu	33	65	53	iPad	registration	Red Dragon WiFi	11n 5 GHz	1.83 Kbps	HT20
19 hours 42 minutes	11/11/14, 2:14 PM	Matteson-c9:5d:42	30	148	103	iPad	Resnet-12	Red Dragon WiFi	11n 5 GHz	0 bps	HT40
19 minutes	11/12/14, 9:37 AM	24:de:c6:ca:db:9e	28	150	19	iPhone	Resnet-2	Red Dragon WiFi	11n 5 GHz	90.5 Kbps	HT40
19 minutes	11/12/14, 9:37 AM	24:de:c6:ca:db:9e	47	0	34	iPod	Resnet-4	Red Dragon WiFi	11g 2.4 GHz	56.8 Kbps	-
19 minutes	11/12/14, 9:37 AM	24:de:c6:ca:db:9e	29	150	19	iPod	Resnet-18	Red Dragon WiFi	11n 5 GHz	66 Kbps	HT40
19 minutes	11/12/14, 9:37 AM	24:de:c6:ca:db:a2	61	0	-	OS X	Resnet-10	RedDragonSecure	11n 5 GHz	9 bps	HT40
19 minutes	11/12/14, 9:37 AM	24:de:c6:ca:db:bc	23	33	6	Android	Admin-3	Red Dragon WiFi	11n 2.4 GHz	842 bps	HT20
19 minutes	11/12/14, 9:37 AM	24:de:c6:ca:db:bc	18	81	18	iPhone	Resnet-18	Red Dragon WiFi	11n 5 GHz	322 bps	HT40
19 minutes	11/12/14, 9:37 AM	24:de:c6:ca:de:f4	41	50	25	iPhone	Resnet-5	Red Dragon WiFi	11n 2.4 GHz	505 bps	HT20

8 minutes	11/12/14, 9:49 AM	Hays-CC:94	25	24	9	iPhone	Resnet-16	Red Dragon WiFi	11g 2.4 GHz	0 bps	-
8 minutes	11/12/14, 9:49 AM	Hays-CC:94	24	21	38	iPod	Resnet-18	RedDragonSecure	11g 2.4 GHz	0 bps	-
8 minutes	11/12/14, 9:49 AM	Hays-CC:B0	0	0	26	iPhone	Resnet-14	RedDragonSecure	11g 2.4 GHz	0 bps	-
8 minutes	11/12/14, 9:49 AM	Hays-CC:B2	30	36	27	iPhone	Resnet-18	Red Dragon WiFi	11g 2.4 GHz	0 bps	-
8 minutes	11/12/14, 9:49 AM	Hays-CC:B2	44	0	-	OS X	Resnet-2	Red Dragon WiFi	11a 5 GHz	0 bps	-
8 minutes	11/12/14, 9:49 AM	Hays-CC:C6	18	36	21	iPhone	Resnet-14	Red Dragon WiFi	11a 5 GHz	0 bps	-
8 minutes	11/12/14, 9:49 AM	Hulbert-B005.aruba.oneonta.edu	21	0	-	iPhone	Resnet-2	Red Dragon WiFi	11n 5 GHz	0 bps	HT40
8 minutes	11/12/14, 9:49 AM	Hulbert-B010.aruba.oneonta.edu	32	0	34	iPhone	Resnet-14	Red Dragon WiFi	11n 5 GHz	0 bps	HT40
8 minutes	11/12/14, 9:49 AM	Hulbert-B012.aruba.oneonta.edu	40	147	25	iPhone	Resnet-17	Red Dragon WiFi	11n 5 GHz	0 bps	HT40
8 minutes	11/12/14, 9:49 AM	Hulbert-B013.aruba.oneonta.edu	23	0	9	iPhone	Resnet-4	Red Dragon WiFi	11n 5 GHz	0 bps	HT40
8 minutes	11/12/14, 9:49 AM	Hulbert-B016.aruba.oneonta.edu	49	0	23	Win 7	Resnet-14	Red Dragon WiFi	11n 2.4 GHz	0 bps	HT20
8 minutes	11/12/14, 9:49 AM	Hulbert-B017.aruba.oneonta.edu	55	0	19	iPod	Resnet-11	Red Dragon WiFi	11n 5 GHz	0 bps	HT40
8 minutes	11/12/14, 9:49 AM	Hulbert-B035.aruba.oneonta.edu	30	91	131	Android	Resnet-13	RedDragonSecure	11n 5 GHz	0 bps	HT40

gilmorr,

 

There is no attachment.

 

Taking Ryan's advice one step further, you should coordinate your idle time-out, DHCP lease time, and 802.1X reauth intervals so tha they don't occur at the same time very often.  For example, If your idle timeout is 5 minutes, your reath interval is 10 minutes, and your DHPC time is 20 minutes, two of those will coincide every 10 minutes and all three every 20 minutes.  If you set them to 6 minutes, 11 minutes and 19 minutes, it will be an hour before 2 of them coincide, and a very long time before all three do.

I am having the same issues here.  I am running a single 7210 with around 500 AP's.  The complaints started out as gaming consoles and Apple TV's being disconnected every 10 minutes after upgrading from 6.4.1.0 to 6.4.2.2 because of the security flaw. 

 

However, it is not apparent its much more than the gaming consoles and apple TV's.  I have windows machines and OSX devices. 

 

I have noticed on a couple clients through AirWave that they have been moved frequenty due to client match. 

 

Curious if anyone has had any tweaks (not twerks :-) ) that have made a difference.

 

Thanks,
Chris

 

Lee University

#7210

---

@cgolden07 wrote:

I am having the same issues here.  I am running a single 7210 with around 500 AP's.  The complaints started out as gaming consoles and Apple TV's being disconnected every 10 minutes after upgrading from 6.4.1.0 to 6.4.2.2 because of the security flaw. 

 

However, it is not apparent its much more than the gaming consoles and apple TV's.  I have windows machines and OSX devices. 

 

I have noticed on a couple clients through AirWave that they have been moved frequenty due to client match. 

 

Curious if anyone has had any tweaks (not twerks :-) ) that have made a difference.

 

Thanks,
Chris

 

Lee University

---

 

We had noticed the same thing on windows, OSx, and iOS devices.  We worked with TAC on some client match tweaks and even more with a third-party vendor but it did not make much difference at all unfortunately.

#7210