Updatex3
An anonymous commenter informed me that CheckPoint has released Build 002 of SecureClient for Mac OS X. You can download here. This update completely solves the Airport process problem. I can once again let WiFi do its automatic thing, its beautiful again. I was suprised all over again how fast OS X acquires a WiFi connection when waking up from sleep. It almost made me cry...
Updatex2
Mac OS X 10.4.9 did not solve this problem. No previous version of OS X was released with a higher then 10.x.9 final operating system update. If Apple follows the trend, this is the last 10.4 update, excluding serurity updates (10.3 Panther received a big security update when 10.4.9 was released). Checkpoint still has not released an update for SecureClient, and my money would now be on either the 10.4 client never being updated, or only when 10.5 Leopard ships. Actually, that is the cause for me of a lot of concern, if SecureClient doesn't work with Leopard, I can't use it when it ships, except from a seperate installation, it can't be my main OS. Assuming the worst for 10.4 and that the client never gets updated, what can people do about this problem? Well I kinda of stumbled on a variant of not adding preferred networks to the Airport list, which I am absolutely convinced is what triggers the Airport process to spin up, and something in the SecureClient kernel components is causing the infinite loop. Anyway, what I stumbled on was that you can add a preferred network (my home network is now WPA secured) to the Airport Extreme network configuration and then delete it. Why would you want to do this? Because apparently the password for that network remains in your Keychain even after the entry has been deleted. Honestly, I don't know if this was a bug (I got into this state pre-10.4.9) but now all I have to do is select my home network through the Airport icon in the menubar and boom I am on, no password entry since that's in the Keychain and automatically get's used. So the runaway Airport process no longer affects me, again.
Anonymous posted in the comments for this post possibly a more complete solution I certainly never thought of. I haven't implemented it yet, since I worked around the runaway process entirely, but Anon's solution might work for you. It certainly would have the benefit of always killed the Airport process.
Update
Apple has created a Support Article that address this specific issue. Basically, the onus is on VPN software manufacturers to update their software to work with 10.4.8. And I spoke to soon, I saw the issue yesterday, 12/7/06, even though I hadn't seen it in a month. For CheckPoint's SecureClient, an update still isn't available to address this issue. My guess, Apple made a change for security reasons and cannot change the airport process back to the pre-10.4.8 way. Common CheckPoint, update already.
Original Post
One software package that makes using an Intel Mac viable as my Windows developer platform is Check Point Software's SecureClient VPN-1 R56 for Mac OS X, Universal Binary. My company uses this VPN solution exclusively, and given that I work from home a decent amount, I need connectivity to the office. Before buying the Intel Macs, me and my co-workers did testing on a personal Intel Mac and my PowerPC Macs to see how well SecureClient for the Mac worked. It certainly worked as well as on Windows so we had no qualms.
A funny thing happened though in the window between our testing, purchase, and then reliance on the MacBook Pros to get work done, Mac OS X 10.4.8came out. Why is this notable, because after upgrading to 10.4.8 a system process, called airport would consume 100% of CPU resources and never give up doing whatever it was doing. As you might guess, SecureClient had something to do with this, but it took me weeks to fiure that out. See the problem would manifest itself when you the Airport WiFi card would save a preferred network and then try to connect to one after a sleep/wake cycle for example. The default configuration of OS X is to save wireless networks you connect to so reconnection in the future happens automatically.
My co-worker first experienced this, and my immediate reaction was a corrupt prefernce file. So we deleted her airport pref file, and this solves the problem because there are no preferred networks anymore. But as soon as you connected to another WiFi network and executed a sleep/wake cycle, the problem would return. We then reinstalled 10.4.8 on her machine, which didn't work. I even repaired permissions on my MacBook Pro, which did hardly anything and I checked the disk for corruption all without a change. I considered downgrading to 10.4.7, but there is no uninstaller for OS X updates, one of the Windows features that Apple should mercilessly steal for 10.5
I say on the Apple Support Discussion board that other's were having the same problem, though no one had pinned down a cause. I posted my workaround, which was to stop the Airport adapter from remembering preferred networks. But then another thread popped up and I posted about my workaround to the airport process problem and confirmed that uninstalling SecureCllient returned the airport process to normal operation even when remembering preferred networks, so clearly the intersection of 10.4.8 and SecureClient R56 Build 001 for OS X was the cause of the problem.
But the most interesting thing is that I reinstalled SecureClient and everything still works! This was stunning, but I had tried this anyway because I needed SecureClient to work from home. One new wrinkle though is that I had already had a preferred wireless network defined when I installed SecureClient. The other possibility is that my succesful tests so far had been without a site configured in SecureClient. But I am back up to full configuration now and I will see how OS X responds to a sleep/wake cycle when I am done for the day, I will keep my fingers crossed. This is probably the worst software interaction, and probable bug, I have yet seen on OS X in my 3.5 years of using the OS.
