Wireless Access

All,

We've all seen our share of "weird" behaviors with client devices, some more annoying than others, and their never seems to be one place to go to find out if this is a known issue with the client, driver, supplicant, OS, or even AP. Wanted to start a couple of threads around this to start documenting what we in the "field" see with these clients so we can all stop banging our head against the wall trying to diagnose why some clients have issues while others don't. This one will be for Mac, I will start another for Windows, and another for Linux......should be fun. Please add your input and will update this as often as possible when new updates are released.

Having trouble with slow connection times or no ability to connect on a 802.1x enabled SSID? Check this out:

MAC WLAN "Apple Menu Extra" (AME): That little WLAN icon in your menubar currently causes some issues with 802.1x authentication, specifically during a key exchange. Too build its list of "available networks", a Macbook will go and off-channel scan in the middle of its own dot1x exchange, missing some key exchange packets. In some cases this will result in a long time to finish the key negotiation and thus get an IP address, in many other cases, it will failed to complete the key negotiation at all and never connect. This happens in versions up to 10.5.6. To verify this is your issue, try the following command on the Aruba "show auth-tracebuf mac <MACADDR>", with the macaddr of the client.....notice any key message retrying and never completing? Should see 4 unicast and 2 group if using WPA(2).

To workaround this, try the following:

1. Disable the AME by holding "command", "left-mouse button", and grab the icon and drag onto desktop or by disabling in Network Preferences.
2. Increase "key message retry" count in 802.1x-profile on Aruba (try 3)
3. Increase "delay between Unicast and Group key" in 802.1x-profile on Aruba (100ms works)

Having trouble roaming with a Macbook on a 802.1x enabled SSID?

MacOS up to 10.5.6 does not support Opportunistic Key Caching (OKC), but this is enabled by default in the Aruba 802.1x-profile since it does work on Windows devices. Since Mac does not support this, on a roam, this could cause a significant delay or fail to connected.

To workaround this, try the following:

1. Disable OKC on the Aruba controller in the 802.1x-profile
2. Leave OKC enabled, but select "Validate-PMKID" in the 802.1x-profile....this will instruct the Aruba controller to allow the client to propose a PMKID on association to use for OKC, instead of the Aruba proposing a list of PMKIDs....this should allow a non-OKC enabled client to roam better.

Mac's and Mixed Mode SSIDs

I find sometime with 802.11n deployments that while it requires WPA2-AES (if using encryption), we need to support some legacy encryption like WPA-TKIP, until all APs and Clients are upgraded. Have seen issues with these "mixed-mode" SSIDs. To minimize interoperablity issues with clients and especially Mac's, try this:

1. Enable the SSID to do all of the following: WPA-TKIP, WPA-AES, WPA2-TKIP, WPA2-AES
2. Enabled "allow-weak-encryption"

Connection or Roaming problems when 802.11bgn AND 802.11an are available?

It has been observed in some Macbooks that roaming from 802.11bgn to 802.11an causes some disconnects. The latest Airport update from Mac seems to resolve this. Also, Macbook's usually tend to connect to 802.11bgn instead of 802.11an when the SSID is available on both bands, try "band-steering" out, it works wonders to move that client to the cleaner, higher performing band.

A note on Machine Authentication, or lack thereof

Mac's 802.1x implementation does not have a concept of machine authentication. This is problematic for environments that either need to enforce machine authentication on a WLAN or more commonly, need to have the laptop gain network connectivity even if the user is logged off, i.e., a laptop in a school used by multiple users.

To workaround this if you are "enforcing machine authenticatiion", try this:

1. Statically add the machine's macaddr to the master controller's internal DB, with a role of the "machine" role from your 802.1x-profile.

To workaround this for laptops that are used for multiple users where you need network connectivity when user is logged off, try this:

1. Try setting up a WLAN profile under the "System" account
2. Try EAP-TLS with certificates

A Note on Power Management for the WLAN NIC:

With the exception of the Macbook Air, all Macbook's will NOT use power management function on the WLAN NIC when the power adapter is plugged in, they will use power management when power via battery. For the Macbook Air, they will ALWAYS use power management function regardless of powered via adapter or battery. Desktop Mac's with WLAN, will NEVER use power management functions. This is important to note for throughput testing purposes.

Wondering what WLAN chipset is in use in your Macbook?

Check out the table at this link: http://en.gentoo-wiki.com/wiki/Apple_Macbook

Anything else that you've seen out there? Let's make this thread a goto source for these "nuances"!

Thanks,

Austin</MACADDR>

This is great info.

Some folks don't yet know you can hold down the alt/option button and single click the AME to get useful information like BSSID, RSSI, Channel, and transmit rate.

See attached screen-shot

Another cool utility buried in Mac is the "airport" command line utility, it is located here:

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport

If you link it to /usr/sbin, should be able to run this from anywhere, issue it with the "-I" flag and you get all sorts of useful information:

silentbob:tftp austinhawthorne$ airport -I
agrCtlRSSI: -44
agrExtRSSI: 0
agrCtlNoise: -88
agrExtNoise: 0
state: running
op mode: station
lastTxRate: 130
maxRate: 130
lastAssocStatus: 0
802.11 auth: open
link auth: wpa2-psk
BSSID: 0:1a:1e:82:29:a1
SSID: home-app
MCS: 15
channel: 6

`

Austin, do you use that on your MacWheel? Sorry, couldn't resist...hehehe

macwheel is catching on, look out!

Austin,

Thanks for a very, very useful post.

Have you ever seen a situation where the airport utility says "No beacon for too long time" and then drops out?

Thanks

Colin,

Have not seen this....does this imply that if Apple misses a beacon it drops its connection?

Austin

For whomever want to know more about OKC, here is the link to a very good OKC technical brief from Aruba:

http://www.google.com/url?sa=t&source=web&ct=res&cd=1&ved=0CAcQFjAA&url=http%3A%2F%2Fairheads.arubanetworks.com%2FvBulletin%2Fattachment.php%3Fattachmentid%3D70%26d%3D1258500453&ei=LwRuS5zhHJOVtgeuzfSIBg&usg=AFQjCNGaWyhosISl4LCVfIAIwvIHJkPJXw&sig2=H_AUWiOqLgYEDrf31B-08w

There is one issue that Snow leopard ran into... When they receive no wireless signal for more than 25 seconds (we have often seen in the elevator), they drop off from wireless. Would be nice to know how to change this behavior.

Meesick,

We're lacking some detail here. When the clients move away from the network for more than 25 seconds, they cannot get on again? What kind of encryption are you using? If WPA2-AES, did you enable "Validate PMKID"?

Hi Colin,

We tested this against both open ssid without encryption and closed ssid with WPA2-AES, and got the same test result. Validate PMKID has been enabled.

Here is the test procedure:

Host 1: Snow leopard, Broadcom BCM43xx 1.0 (5.10.91.19)
Host 2: Windows XP, Intel 5100 AGN (12.4.3.9)
Controller: 3400 3.4.2.0 build 23093
AP: AP-125 g, a, a-HT

Step 1: Both hosts connect to open ssid and started a continuous ping to 4.2.2.2, and VPN into corporate network.

Step 2: Both machines got into the elevator. When the elevator closed the door, both hosts started losing ping packets.

Step 3: For about 25 seconds, Snow leopard disassociated from the open ssid and terminated the VPN session. Windows appeared to be more tolerate and didn't disassociate to the open ssid and vpn session stays.

Step 4: Elevator opens the door, Windows associate to the nearest AP, resume pinging 4.2.2.2 and VPN session stays connected.

We can replicate this easily. I am willing to try anything that could lead us to a solution.


Thanks,
Eva

---

Austin,

Thanks for a very, very useful post.

Have you ever seen a situation where the airport utility says "No beacon for too long time" and then drops out?

Thanks

---

We have seen that message in the system logs on clients that correlated to the client disassociating and associating to the AP and have found that updating to 10.5.8 resolves that particular issue.

I'm seeing this delayed/not reconnecting issue on Macs with 10.5.8 and 10.6 using an SSID where I have OKC enabled, but Validate PMKID is not enabled. This would seem to imply that this is still a problem for OSX versions beyond 10.5.6. Is the easy fix just to enable Validate PMKID?

Don, in most cases you should check "validate-pmkid" as it leads to a more interoperable setup. We are likely going to be enabling that by default in future releases. I would recommend setting that in your environment.

---

Meesick,

We're lacking some detail here. When the clients move away from the network for more than 25 seconds, they cannot get on again? What kind of encryption are you using? If WPA2-AES, did you enable "Validate PMKID"?

---

What does the "Validate PMKID" do for us?
I am troubleshooting a few connectivity nuances on MACs, iPhones and Droids. They do not seem to roam to another AP after being connected. We are using 6.1.2.3 and AP105s across campus. A 802.1x, WPA2/AES, PEAP Radius Auth to AD ssid.
I see this issue when moving around within a building or between buildings. The device (client) seems to hang on to a connection that will not maintain the client connection, as I move through the building, I find I have to "reconnect"; sometimes disable and reenable the wireless on the device.
I have been through the messages here and have made a few changes - we'll see what things are like tomorrow, when I get back to campus.

fyi - in the last week, I have resolved nearly all our wireless client issues by referencing the material in these forums - thanks and keep the information flowing.

Can options like "key message retry" and others discussed here be changed in Instant Access Point? I didn't find any relevant options in the IAP CLI.

Anyone ever had any issues of a client dropping off a couple times a day?     I'm at an iMac,  later model,  running 10.6.8,   several times a day my wireless will drop, and i'll get disconnected from my chat programs.        I'm 15 feet from an AP 105 under low load.  

 

I'm guessing it might be happening when the AP changes channels?     If its happening to me,  i'm betting its happening with others in the building too.   Just want to figure out a solution before it becomes a problem.    

 

 

You can enable Client Aware on the ARM profile. That will prevent the AP from changing channels while you are connected.

 

But I would put your client and the AP you are connected to in debug mode on the controller, and after it happens look at the logs. Just to be on the safe side. It might be interference.

What kind of encryption and what version of ArubaOS?

 

type "show ap arm history ap-name <name of ap>" to determine when that AP changed channels if you suspect that is what is triggering it.

 

Also, what Aruba OS version are you running. I just saw a bug fixed in 6.1.2.4 which could explain your issues.

 

54872

A performance drop observed on AP-105 with 20 MHz HT enabled when connected to Mac clients
has been fixed. This performance drop was seen in the form of 10% to 13% packet loss on pings
to the default gateway on the controller.

Running the latest version,  6.1.2.5 - 

 

Looking at the settings in the ARM profile, client aware is already enabled.     It's not really a performance drop issue, its a connectivity drop.  The client would just drop connection, then come back.   Any chat clients or anything that relies on a constant connection,  like SSH,  drop out and disconnect.   

 

I put my computer in debug mode and checked it again after a drop.  Nothing jumped out at me in the log,  in fact,  I didn't see any new messages between when I was connected and when I reconnected.

 

Attaching my 802.11a ARM settings -   

 

 

At this point I would say you need to oped us a support case with TAC. This is beginning to sound like it may take some packet capture analysis to determine the root cause of this issue, if nothing is showing up in the debug log for your client.