Open Radar

 
27-Oct-2009 02:45 PM Michael Lowry:
Summary: 
When connecting to our WLAN, some Macs hang. It seems that configd is swamping the kernel with requests, eventually exceeding the kernel’s ability to keep up. First System Preferences hangs, then the Finder, and eventually other applications too.

Steps to Reproduce:
1. Our access point configuration may be pertinent so I’ll describe this first. We use Cisco Aironet 1200 access points. Each one serves two different WiFi networks: IBMVISITOR, an open network; and IBM, a secured network. The IBMVISITOR network is visible (the SSID is broadcast); the IBM network is hidden (the SSID is not broadcast). Access to the IBM WiFi network is allowed via WPA Enterprise with either LEAP (ID & password) or TLS (user certificate).
2. Configure the Mac as follows: In Advanced network preferences for the AirPort interface, create a new 802.1X User profile with only LEAP checked. Enter the user name and password. Save and apply. Create a new AirPort network definition with Security:WPA Enterprise; and select the previously-defined LEAP 802.1X profile. Save and Apply.
3. Turn on AirPort.

Expected Results:
The Mac successfully associates with the IBM WiFi network.

Actual Results:
The Mac at first appears to associate successfully with the network, but this connection lasts just a few seconds if at all. Then the Mac descends into a death spiral where the computer becomes progressively less responsive. Eventually it may be so hung that it seems to be completely unresponsive to user input. Occasionally at this point it is possible to turn off AirPort using the icon in the menu bar. However, doing this requires patience—clicking on the menu bar icon and waiting a minute or two for the menu to appear, etc.

Regression:
I have reproduced this bug on two identically configured MacBook Pros (MacBookPro3,1), each with fresh installs of Mac OS X 10.6.1 on newly-formatted hard drives.
The problem does not appear to affect a newer unibody MacBook Pro (MacBook Pro5,1).

Notes: Connectivity from Macs to our WiFi network has been very unreliable. I suspect that this has to do with the combination of, among other things, these two factors: 1) the private network’s SSID is hidden, and 2) the same access points serve two networks simultaneously—one visible/open and one hidden/secured. 

'Mac Wifi assoc. hang.zip' and 'MacBookPro3,1.spx' were successfully uploaded

03-Nov-2009 02:41 PM Michael Lowry:
I tested this problem on a brand-new unibody MacBook Pro (MacBook Pro5,3). Although this Mac too definitely still exhibited problems reliably connecting to the WiFi network, the problem wherein kernel_task consumes 100% of the CPU did not occur.

04-Nov-2009 09:18 AM Michael Lowry:
A colleague has observed the same problem on his MacBook2,1.

13-Nov-2009 02:52 PM Michael Lowry:
PLEASE READ THE ENTIRE UPDATE.
THE BUG IS *NOT* FIXED.

I convinced the network administrator to enable SSID broadcast on two of the access points here. When the MacBookPro3,1 is within range of one of these access points, the problem does not occur. However, as soon as I move the computer to the area covered by one of the other access points (where SSID broadcast is still disabled), the problem immediately starts to happen. The network connection will go down (or up and down repeatedly), and kernel_task will take 100% of the CPU.

Usually, bringing the computer back within range of the APs with SSID broadcast enabled fixes things again. The network will come back up and kernel_task will calm down. However, I noticed that the problem sometimes persists even after I have moved the computer back within range of the APs with SSID broadcast enabled. Turning AirPort off and back on seems to make the problem go away; but it will pop up again as soon as the computer is moved into the range of one of the APs with SSID broadcast disabled.

This testing shows quite clearly that the bug rears its ugly head only when SSID broadcast is disabled.

The vast majority of IBM sites have SSID broadcast disabled, so it is important that a fix be developed for this bug.