Higher Education

oh my!

 

I've come accross an odd issue with [appears to be newer] macbooks and how they reauthenticate to a  wpa2-aes-peap-mschapv2 networks.... ie roam to a new bssid.   I first noticed this with a colleagues new macbook-retina running 10.8.4 - his desk is located righly right between 2 AP's and likely on the edge for eithers 5Ghz - in anycase it would not be unusal for his macbook to roam - without actually moving.    He would experience apparent random disconnects from the network - macbook would be stuck in the authenticating state - toggle wifi off/on and he'd be back online.... until it happened again.
 

I come to find out that - specifically when reauthneticating - I'll see a 10-20second delay in response from the macbook to the TLS exchange for setting up the PEAP tunnel.  (using wiresharp to monitor eap on the macbook)   the client starts the TLS handshake with a Client Hello - the controller responds with a Server Hello - then the macbook is silent for 10-20 seconds before responding with certificate, client key exchange, change ciper etc.... then authentication proceeds normally.

 

on 6.1.3.2 and 6.3.0.0 that 10-20 delay is too long for the default timers on the aruba controller.  extending the ir request timeout to 30 - give enough delay for the macbook to do whatever it needs to.... but still that's 10-20 seconds of network outage - just for roaming?!  Is anyone else seeing this?   It does appear to be related to the certificate in use.   I currentlyam using a cert via incommon.org an intermediate for addtrust.com - and its based on a 2048 bit key.   If i use my expired 1024bit based geotrust cert... I do not see this delay - also see this delay with aruba's selfsigned 2048 bit key on 6.3   I do note with my current key - the TLS Server Hello is large so fragmented into 3 packets to accomadate 2048 bit certs and intermediates etc...

 

is this just an issue that macos does not like 2048 bit certs or perhaps fragmented server hellos? (though on initial wifi turn up - this delay is not seen and the same certificate is in use).

 

This can be replicated at will, by issueing a "aaa user delete mac <macbook>" on the controller - and captureing the eap traffic via wireshark on the macbook when it attempts to rejoin the network it was just kicked from.

 

I see this for our eduroam ssid as well - so for networks where peap is terminated on the controller and ones that it isn't

 

ssid's are wpa2 with aes.   using eap-peap with mschapv2 for authentication.

 

Anyone else see this?  perhaps I can just tweak how I present my certificates - don't relish changing back to another CA for 1024 bit certs  (if I could find a CA still issuing those)

 

Travis

This is insanely interesting. I've observed this via user complaints as well as with my own MacBook. Everything is exactly as you describe. I know 10.8.5 is on the horizon and rumors are there are wifi fixes. I hope you can verify that against your tests.

Yeah, not sure if its certificate related since its used on initial connect too (as you pointed out). Is there the same amount of fragmenting on initial connect as there is during the roaming event?

And the aaa dot1x timer...you say increasing allows for an eventual connect without bouncing the radio? If so, to which timer specifically are you referring?

initial connect and and a re-auth appear the same - just that added delay between the server hello and the macbook responding with the encrypted handshake message.

 

In my 802.1x auth provide I changed the "Interval between Identity Requests" from the default of 5 to 30 seconds.

!

aaa authentication dot1x "<profile-name>"
  timer idrequest_period 30

!

 

 

 

 

 

If anyone's interested here's what I see capturing eap packets on the macbook itself:

### inline comments highlighted the delay seen

### I start the capture - then on the controller "aaa user delete mac 28:cf:e9:1a:83:09"

1 2013-08-07 10:27:00.887552000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 EAP Request, Identity [RFC3748]
2 2013-08-07 10:27:00.887832000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 EAP Response, Identity [RFC3748]
3 2013-08-07 10:27:00.889222000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 EAP Request, PEAP [Palekar]
4 2013-08-07 10:27:00.890602000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Client Hello
5 2013-08-07 10:27:00.891929000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done
6 2013-08-07 10:27:00.892440000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 EAP Response, PEAP [Palekar]
7 2013-08-07 10:27:00.893285000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done
8 2013-08-07 10:27:00.893694000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 EAP Response, PEAP [Palekar]
9 2013-08-07 10:27:00.894490000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done

###notice the delay here - particualy bad 20 seconds before macbook responds
10 2013-08-07 10:27:20.913454000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
11 2013-08-07 10:27:20.921292000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Change Cipher Spec, Encrypted Handshake Message
12 2013-08-07 10:27:20.922331000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 EAP Response, PEAP [Palekar]
13 2013-08-07 10:27:20.923792000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Application Data
14 2013-08-07 10:27:20.923967000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Application Data
15 2013-08-07 10:27:20.925785000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Application Data
16 2013-08-07 10:27:20.925988000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Application Data
17 2013-08-07 10:27:20.971770000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Application Data
18 2013-08-07 10:27:20.972316000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Application Data
19 2013-08-07 10:27:20.978457000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Application Data
20 2013-08-07 10:27:20.978710000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Application Data
21 2013-08-07 10:27:20.980302000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 EAP Success

### so I do get connected.... no I toggle the macbooks wifi off and back on:
22 2013-08-07 10:27:48.763879000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 EAP Request, Identity [RFC3748]
23 2013-08-07 10:27:48.769827000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 EAP Response, Identity [RFC3748]
24 2013-08-07 10:27:48.771249000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 EAP Request, PEAP [Palekar]
25 2013-08-07 10:27:48.772942000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Client Hello
26 2013-08-07 10:27:48.774251000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done
27 2013-08-07 10:27:48.774718000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 EAP Response, PEAP [Palekar]
28 2013-08-07 10:27:48.775540000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done
29 2013-08-07 10:27:48.775877000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 EAP Response, PEAP [Palekar]
30 2013-08-07 10:27:48.776672000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done

#no delay here! transaction appears the same....
31 2013-08-07 10:27:48.800952000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
32 2013-08-07 10:27:48.807489000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Change Cipher Spec, Encrypted Handshake Message
33 2013-08-07 10:27:48.808353000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 EAP Response, PEAP [Palekar]
34 2013-08-07 10:27:48.809816000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Application Data
35 2013-08-07 10:27:48.809980000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Application Data
36 2013-08-07 10:27:48.811567000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Application Data
37 2013-08-07 10:27:48.811928000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Application Data
38 2013-08-07 10:27:48.853859000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Application Data
39 2013-08-07 10:27:48.854216000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Application Data
40 2013-08-07 10:27:48.856809000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 TLSv1 Application Data
41 2013-08-07 10:27:48.856991000 28:cf:e9:1a:83:09 00:1a:1e:14:a1:f4 TLSv1 Application Data
42 2013-08-07 10:27:48.858440000 00:1a:1e:14:a1:f4 28:cf:e9:1a:83:09 EAP Success

HI Travis,

 

Curious, what is the controller model you are using, M3 or 72xx? And what are the models of APs?

 

I'm wondering if 2048 bit certs are causing a lag because of the crypto engine peformance. We also use an incommon.org cert with an intermediate for addtrust.com. I recall it took significantly longer creating the 2048 CSR over a 1024 CSR. We use EAP-TTLS/PAP..

 

Mike

We are using M3 controllers - and this behavior has been seen with AP125, AP105, AP135 - even RAP5's

 

I'm sure the 2048 certs have more overhead - but the odd part is that from a state where the wifi was off then turned on - the authentication has no delay - and similar for other devices - ie win7 laptop - its only when the macbook is rejoining an ssid that this pause is seen.

 

Travis

We're using 2048 bit certificates as well and we've been experiencing this problem around our campus on Mac's only. 

 

Any workaround you guys know of?

I did contact Apple about this - they did acknowledge that it appears to be an issue in macOSx - that's causing a cert validation delay.  So it could be possible to tweak cert settings/trusts on macos itself to mitigate issue - but a special config on each client is not something I see as a viable long-term solution - so I have not really tested that angle.   So far - just tweaking the timers as listed above - has allowed the macbooks to self-recover - which is a big plus... but there's still a signifigant break in connectivity when roaming.

 

I need to check up to see if Apple has any update.   We don't actually have any support contact with apple - so I haven't been pushing them too hard -  been monitoring for system updates - haven't seen anything to specifically address this and most recent patches have not altered behavior.   Apple was interested in having me test Mavericks-beta to see if issue persisted... but I'm not an active developer member....

 

Please feel free to contact Apple and reference my case (#  480081631) - just to keep the pressure on!

 

And if anyone else reading this thread has found any better work-arounds/mitigations, please share!

 

 

Setting the timer to 30 seconds works, to a point. They still end up losing connection for a time which disrupts Airplay or any other constant connection program. It seems to happen when they get bounced from one AP to another as well. 

 

Doing testing revealed this happening on 10.8.4 and 10.8.5. Near consistent 22 second time to get authenticated. Hence the 30 second window for re-auth working. 

I've found that on macosx if you go into the keychain and for the cert used for 802.1x auth - if you modify the trust settings to also always trust for SSL - it eliminates the delay I've been seeing when a macbook re-auths to the ssid.

 

The cert gets set to always trust for eap and x.509 when you first trust it....  guessing the apple bug has something to do with 2048 bit cert and not seeing this as an eap transaction...etc... but at the core its an ssl transaction - so explicitly trusting the cert for ssl - makes validation really quick :)

 

So far at least for my test station... Not a great solution as the users need to update settings... and obscure security certificate ones at that.... but should ease the pain for users that are willing to attempt - need to see if I can get any of mine to try this.

 

 

If you use QuickConnect for supplicant configuration, I believe the
profile will trigger the root CA to be trusted for the connection in the
key chain.

You have to include the root CA cert in the config profile and select it as
trusted under the PEAP options.

I assume it would be the same with other products like XpressConnect.

does QuickConnect have the ability to adjust trust settings for certs at this level.   

 

ie - does it just tell macosx to trust this cert for wireless auth - which I imagine would only trust it for EAP and x.509

or does quick connect install the cert and have the knobs to tell macosx to trust it for SSL, EAP, and X.509?

 

Travis

Will confirm tomorrow on a Mac.

Last I knew, anything configured via profile is explicitly trusted by OSX.

So by just connecting normally, without QuickConnect, it looks like the certificate is "Always trusted" by default for EAP after connecting successfully. Are you saying that the SSL option needs to be trusted as well?

 

Correct.   By having SSL also set to always trust has removed the cert validation delay seen for 2048 bit based certs in my tests

 

I just tested this, and you are correct, by selecting "Always Trust" on the SSL line of the cert (even though EAP was already set to always trust), it fixed the delay issue.  Replicated 2 times to be sure, and without the SSL line set to Always Trust, I clearly saw the 20s or so delayed when roaming, but 0 delay with SSL set to Always Trust. 

Hmm, very interesting, thank you much for that discovery.  I am not sure why that SSL portion should be checked, since this cert is only used for 802.1x presented by our radius server, in our case, radius.du.edu issued by Thawte. 

This is really good infomration. Thanks for sharing. 

 

I would guess that is has someting do with a 2048 bit cert and for reauthentication - the macbook is not seeing it as an EAP use case.... but technically the eap is just a wrapper for an inner SSL based secure connection... so that is why trusting SSL works.

 

Apple has been oddly less than forthcoming about any bug ID - or particulars on the issue... other than it appears to be a known issues dealing with cert validation delay.....

 

 

We're working on how best to distribute info on this workaround.... help deks folk are understandibly leary of explaining the process to users....

 

So looking into some applescript examples online.... I was able to make the attached script... I made it as a proof of concept... that this can be scripted relatively easily on a mac - but shoudl be made more robust.... ie keychain access needs to be closed or the script breaks etc....   Not sure an  automated script [that changes cert settigns in your local keychain] is better than walking a user through the steps.... but  I don't think we can wait for mavericks to hopefully fix it - since we can't count on all users upgrading right away (though most seemed to upgrade to iOS 7 pretty quick - but then that 's a free upgrade)

 

I supposed I could also turn off all but one AP for a Residense Hall - that should keep the macbook from roaming... ;)

 

##################################################################

#applescript

##################################################################

set CertName to "eap.noc.ucdavis.edu"

 

-- Setup permissions on the certificate
tell application "Keychain Access"
  activate
  tell application "System Events"
    tell application process "Keychain Access"
      keystroke "f" using {command down, control down}
      keystroke CertName
      delay 1
      keystroke "i" using {command down}
      delay 0.5
      click checkbox 1 of scroll area of window CertName
      click pop up button 2 of scroll area of window CertName
      keystroke "a"
      keystroke return
      delay 0.5
      click button 1 of window CertName
      delay 1
      tell application "Keychain Access" to quit
    end tell
  end tell
end tell

############################################################

 

All,

 

Workaround of selecting "Always Trust" for SSL, hasn;t worked for me. I was still able to see the issue. I did not see issue when I used 2048 bit self signed cert. Self signed cert of 1024 & 2048 bit private key is working for me in my setup. 

 

Not sure if anyone else has tested same. 

odd I get same behavior when using aruba's built-in cert - on 6.1.3.7 it is a 2048 bit based cert.   Deleting it from my keychain and letting it re-install when autheticating for "first-time"  it trust eap and x.509 by default..

 

I delete myself - the reauth takes about 20 seconds before I'm back online....   if I modify the securelogin.arubanetworks.com cert in my macbook's keychain to always trust for SSL - I can delete myself again - and be back online under 5 seconds

 

For my macbook this is very reproducible - I can change the cert trust setting for SSL - and with it always trusted reauth is quick... with it using default(no value specified) take ~ 25 seconds to reauth.

 

Are the self-signed certs using different extensions from the built-in aruba cert?

 

I'll look at creating some self-signed certs via default options with openssl - and see if I get different behavior.

I found checking "Rate Optimization for delivering EAPOL frames" under your SSID Profile, fixed the roaming issue on 10.8.5 and 10.9.  I can now roam between APs with virtually no disconnection/delays.

What version of AOS?  Did some testing on my 6.3.x test box - and even with "Rate Optimization for delivering EAPOL frames" enabled - I still experience same cert validation delay as before.....   any other changes along with this?

6.2.1.3

No other changes.

I'm not in Education, but we see this in our environment.  It started in 10.8.4 from what I can see.  No idea what was changed.  I've been able to use some timer tweaks to get things down a bit, but prioritizing EAPOL frames didn't seem to help.  This was both on 6.1.3.8 and 6.3.0.2.

---

@trschick wrote:

I would guess that is has someting do with a 2048 bit cert and for reauthentication - the macbook is not seeing it as an EAP use case.... but technically the eap is just a wrapper for an inner SSL based secure connection... so that is why trusting SSL works.

 

Apple has been oddly less than forthcoming about any bug ID - or particulars on the issue... other than it appears to be a known issues dealing with cert validation delay.....

 

 

We're working on how best to distribute info on this workaround.... help deks folk are understandibly leary of explaining the process to users....

 

So looking into some applescript examples online.... I was able to make the attached script... I made it as a proof of concept... that this can be scripted relatively easily on a mac - but shoudl be made more robust.... ie keychain access needs to be closed or the script breaks etc....   Not sure an  automated script [that changes cert settigns in your local keychain] is better than walking a user through the steps.... but  I don't think we can wait for mavericks to hopefully fix it - since we can't count on all users upgrading right away (though most seemed to upgrade to iOS 7 pretty quick - but then that 's a free upgrade)

---

Anyone know if these delays got fixed/improved with Mavericks?

 

Nope... Not yet... Mavrick hasn;t fixed it yet!!!

We are experiencing a very very bizarre yet similar issue with many of our 10.8.5 Mac Machines (iMac or Macbook).

 

We have an open Guest SSID network that uses captive portal to redirect to our CPPM site.  The certificate is valid and we are using a 2048 bit from Incommon with the root being Add Trust External CA.  Aruba OS is 6.3.1.2 but we were seeing the identical issue with 6.1 as well.

 

When the Mac connects to the SSID (except not normally on a clean reboot - crazy I know) after the redirect to the login page and once the certificate is accepted keychain will no longer work (it just hangs every time).  This seems to prevent the loading of any https website at all (i.e. google, outlook, faceboot, twitter, etc...).  Not just that but we are then unable to jump onto any other secure network (open will work - minus secure sites).  This goes so far as to break our wired-only connection as well for all https.

 

Now - note firefox will actually function just fine the entire time - but Safari and Chrome do not.  In Chrome we'll be able to get to other non-https sites - but Safari usually is useless for anything.

 

A reboot fixes everything (until we start jumping around SSIDs again).

 

In the keychain under 'login' we deleted the Add Trust External CA and that actually appeared to fix our issue.  The other thing we tried was to 'Always Trust' the Add Trust certificate - which I was then able to get to https sites, but keychain becomes unusable again and hoping to a secure SSID won't work.  Wired will work just fine though.

 

We only see it on Mac's, and it's been really difficult to pin it down to a certificate on an open-network, but we've watched as keychain hangs the instant the redirect to the ClearPass Page happens.

Issue getting discussed on this thread is happening to dot1x ssids only, where macbook stop responding to eap frames for about 10 sec. 

In your case, it is open ssid. So issue doesn't look same. Did you try playing with DCSP settings in your browser? Try to disable OCSP and see if it helps. If so later on you can whitelist ocsp urls in ACLs. 

 

Also start new thread for further discussion on issue you are facing. This way we are not mixing up multiple issues at one place. 

We are also connecting the clients to a dot1x SSID through ClearPass as well - which of course gets a very similar certificate issued.  The issue started around the same time we started hoping between the two for testing.

 

I've disabled DCSP in all the browsers and also whitlisted the ocsp urls in ACLs.  It is such an odd issue it seemed possible it was related to this topic.  I'd be curious if anyone with the above issue had any keychain issues during the pauses; otherwise I'll open a new thread for this.

FYI All,

 

Apple recently released (1/10/14) a knowledge base article regarding the Macbook 802.1X EAP exchange latency with a similar workaround that Travis and others have been referring to.

 

http://support.apple.com/kb/TS5258

 

Cheers,
Ken

 

I have a MacBook with a fresh install of OS X Mavericks with this issue.  I have trusted the SSL and EAP on all of the certs installed during the Onboarding process for ClearPass.  It will now connect to the wifi network after clicking the Disconnect button in the nag message from the operating system(see screenshot).  If I didn't change the settings on the certs, it would disconnect and never reconnect.  Has anybody seen or heard any new information about this issue?  Anything new from Apple other than change the trust settings?  I can't really make these changes on all of our MacBooks every time a new user logs in user network credentials.

 

Yeah, I know.  If you use Cloudpath XpressConnect, they now can do it for you automatically. 

Hey All

 

I have been seeing the same exact issue for the last several months and I have tried all the suggested tweaks with 0 success.

I have an AppleCare case open and we have upgraded all our Macs to 10.9.2 as suggested by AppleCare but still we see no improvement at all.

 

I was wondering if anyone else has had success on 10.9.2?

 

Below are some details of our wifi setup:

 

AOS 6.1.3.9
Aruba Controllers 3200/3400/3600/6000
AP125
2048 bit cert
OSx 10.9.2


Tweaks Tried:
 
AOS
- "Rate Optimization for delivering EAPOL frames" under SSID Profile, did NOT fix the roaming issue for us.

- Below suggestions from Aruba support
wlan ssid-profile "SSID"
eapol-rate-opt
local-probe-req-thresh 25


OSx
- Trusting SSL cert has NOT worked - http://support.apple.com/kb/TS5258

Shaun,

 

We ran into the same issue not too long ago. Re-auth on Macs were taking anywhere from 30 seconds to 2 minutes, however, if we killed the connection manually and reconnected, it was instant. We were able to resolve the issue by going into the Mac Keychain, finding the certificate for our wireless network and setting not only SSL, but also, EAP and X.509 Basic Policy to "Always Trust." After we made those changes, it brought re-auth times down to less than a second. 

 

Can you do a packet capture from one of the Macs, filter on eap, and then roam from one access point to another? I am curious to see what the results of this are.

I wish I could.  We have tried all of that as well and still have the same problem.  We've given our feedback to Apple as part of our ongoing AppleCare case.  Such feedback seems to be thrown into a void from which no useful information returns.

Hey Guys, thanks for all your responses so far.


cjoseph@ yes I have opened a Tac case long ago. Work with both helpdesk as well as senior engineers testing many different settings on the controllers but still no luck. To be fair to them they did tell me just after I opened the case that this was an Apple issue and after much testing now myself I do agree with them.


macca42@ thanks for that tip however I'm not able to do that due to security lockdown however I have installed the cert many times on a number of different Macs with the same results.


JRose003@ sounds exactly like the issue I am facing. I have tried that fix from Apple but still no luck.

I'm not able to share a full packet capture with you but I have taken some screen shots and attached them here which I hope gives you what you are looking for, please let me know if you spot something out of the ordinary that I may have missed.

I've also attached a ping screen which shows how long it takes during the roaming but please keep in mind that sometimes it takes much longer than 10 seconds.


JohnKilpatrick@ I could not agree with you more. The really frustrating issue for us is the roaming that is taking place when the users are working on their desks stationary. This does not happen to alot of users but for the ones that are affected they don't really understand what is happening and are just hating the wifi at the moment.

I have found the below command on this forum that is supposed to make the Macs roam less often but I personally have see no difference but give it a try and see if that helps you guys out at all.

Shaun,

 

Is a 200 millisecond ping time in your environment typical?  Can you ping your default gateway, instead and see if you still get the same times?  

Hi cjoseph@

 

For that IP that latency is expected yes but ping the gateway I get the below:

icmp_seq=0 ttl=255 time=1.657 ms

 

Regardless of what IP I'm pinging I get the same result on the Macs.

 

I did not mention this earlier but we are not seeing these issues on Windows or ChromeOS, just the Macs.

Shaun,

 

Thank you.

 

We are seeing the same thing in our environment - Mac users (mainly MacbookPro running 10.9.1 + ) are having just horrible roaming issues. Sometimes a student will be at their desk, and not moving, have full signal, and then their device will just pop-off the network, and go into a 30 minute roaming cycle... where their machine, during this time, will not attach to any of our APs.

But the rub... It is an intermittent problem, it is hard to reproduce (I have had a macbook on my tech desk now for over two weeks and have not been able to reproduce it. But when it happens, it is just painful.

The end users are also not happy because their response is that they have the best computer money can buy and the people at the mac store says their computer is working in perfectly.

I guess I am just trying to not pull any more of my hair out over this... Is this an Aruba issue or a OSx 10.9.x issue?

I have tried all the work-arounds above and have no success on anything permanent.

 

danstl,

 

If you are having roaming issues when not moving, please make sure your access points:

 

- Are not broadcasting above 18

- Are not less than 55 or 60 feet apart.

 

We have seen issues with roaming while standing still when devices have too much coverage.  If you have excellent coverage, please make sure your access points are at a max of 18 to start.

 

I believe most of the people with the MAC roaming issues are roaming while actually moving and it is easily reproducible.

 

Are you talking transmit on the radio config, or the ARM config, or both?

 

We do have very good coverage in most areas where the students are located.  I will check these things out - I may have to break up my APs into smaller groups to better manage the radio powers....

Danstl,

 

If you have ARM Enabled (on Single-Band), only the ARM-MAX-TX and ARM-MIN-TX control the transmit power.  The power under the radio does not have any effect when ARM is enabled.

 

If you have good coverage, examine what power all of the access points are at.  Also check to see if you are running 20 mhz or 40mhz channels.  You know you are running 40mhz channels if the access points has a + or a - after the channel.  Lastly use inssider or another utility to see how many access points you can see from where a single person is sitting.

 

 

Hey danstl 

 

I am seeing exactly the same issues that you have described.

To answer your question from my point of view, "Is this an Aruba issue or a OSx 10.9.x issue?"

I believe this to be an OSx issue as I have tried everything that has been suggested in this forum and by Aruba tac and we have made no progress.

 

We also use ChromeOS and Windows and those devices are working as expected.

---

@shaun wrote:

Hey danstl 

 

I am seeing exactly the same issues that you have described.

To answer your question from my point of view, "Is this an Aruba issue or a OSx 10.9.x issue?"

I believe this to be an OSx issue as I have tried everything that has been suggested in this forum and by Aruba tac and we have made no progress.

 

We also use ChromeOS and Windows and those devices are working as expected.

---

We also have windows and ChromeOS deployed and only see this issue with Macs, specifically 10.9.x

To make the ssl issue reproducible at will I delete the user from the controller:

 #aaa user delete mac a:b:c:d:e:f

 

Not exactly a roam event since the macbook typically rejoins the same ssid in my test environment - but to the macbook  it is now forced to attempt to reconnect to the ssid.   And this demonstratoed the iMacOSx ssue with verifying 2048bit SSL certs that only occured when the macbook was in a reconnect state vs a new connection.

 

if it truly only occurs when the macbook moves to a new bssid.... get a microwave near the macbook or AP and start making popcorn for the office? and bring in your own AP using 40Mhz channels on 2.4 - some 802.11b-only printers/game systems...(ie simulated dorm environment) :)

@danstl wrote:

[..]

But the rub... It is an intermittent problem, it is hard to reproduce (I have had a macbook on my tech desk now for over two weeks and have not been able to reproduce it. But when it happens, it is just painful.

 

Shaun, danstl

 

Not sure how you guys are making out with this issue. I upgraded a mac to 10.9.2 last night to do some more testing. Roaming seemed a little slower at first; I removed the certs completly from the machine and reinstalled, re-auth times are back down under 1 second. 

 

Macbook Pro OSX 10.9.2

Aruba Controller Version 6.3.1.2

Primarily AP-105s

WPA2 eap-peap

 

 

 

 

 

---

@JRose003 wrote:

Shaun, danstl

 

Not sure how you guys are making out with this issue. I upgraded a mac to 10.9.2 last night to do some more testing. Roaming seemed a little slower at first; I removed the certs completly from the machine and reinstalled, re-auth times are back down under 1 second. 

 

Macbook Pro OSX 10.9.2

Aruba Controller Version 6.3.1.2

Primarily AP-105s

WPA2 eap-peap

 

 

 

 

 

---

All of our mac users are BYOD - so getting them to upgrade can be a pain - I will notify all our mac users to stay on 10.8.x or if they are on 10.9 then make sure they upgrade to 10.9.2

 

It is just really odd because we are not seeing it on most devices, but some just love to not connect.

Shaun,

Have you opened a case with Aruba TAC? It could be something that is configuration-specific.

After running some testing, the only way I was able to return the Mac
OS back to reliable connectivity was to unjoin it from our domain,
create a new local user, onboard as usual. Somehow when joined to the
domain the cert never made it into the keychain correctly.

Sent from my iPhone

Dear All.

first guied me how to post new problem in Airheads  community.

second i have 7200 controllers master backup and Aps 105 225 25 275 ets.

now i  have 275 outdoor AP i want to make this AP mesh portal is it possible are if yes the how can i make this happend pleas guide me

. 

Please start here:  http://www.arubanetworks.com/techdocs/ArubaOS_65x_WebHelp/Web_Help_Index.htm#ArubaFrameStyles/Mesh/Mesh.htm%3FTocPath%3DArubaOS%2520User%2520Guide%2520Topics%7CSecure%2520Enterprise%2520Mesh%7C_____0