Wireless Access


MAC WLAN Client "Nuances"


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 ", 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"!


Aruba Employee

AME Alt/Option Click for useful information

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
Micah Wilson

Re: MAC WLAN Client "Nuances"

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


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

Aruba Employee

Re: MAC WLAN Client "Nuances"

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

Re: MAC WLAN Client "Nuances"

macwheel is catching on, look out!
Guru Elite

Beacon Issue


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?


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars

Re: MAC WLAN Client "Nuances"


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

Occasional Contributor II

Re: MAC WLAN Client "Nuances"

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


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.
Guru Elite

Clients drop off


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"?

*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.4 User Guide
InstantOS 8.3 User Guide
Airheads Knowledgebase
Airheads Learning Videos
Aruba Central Documentation
Sign up for Security Alerts
Aruba Technical Webinars
Occasional Contributor II

Re: MAC WLAN Client "Nuances"

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 (
Host 2: Windows XP, Intel 5100 AGN (
Controller: 3400 build 23093
AP: AP-125 g, a, a-HT

Step 1: Both hosts connect to open ssid and started a continuous ping to, 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 and VPN session stays connected.

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

Search Airheads
Showing results for 
Search instead for 
Did you mean: