99489 Views Previous 1 2 3 4 5 … Next 246 Replies Latest reply: Jan 6, 2010 10:05 AM by oldmacwoman Go to original post
I have finally remedied this situation on my system. The invasion of the never-ending alert popdown has been vanquished and has not returned all day.
I went to the network preferences, ready for the endless onslaught of alert dialogues. In between pressing return to "OK" the dialogue away I managed to get to the Network Configuration menu. During the endless cascade of alerts that continued I managed to click on the Airport check box, turning it off. I turned it on and off a couple of times, using nimble fingers to get past those pesky alert boxes. I worked in a couple of "Apply" hits as well. I then got back into the pull down menu and went to the PPP settings and the alert finally stopped. No idea why. I changed various things and hit apply every time, just trying to get it to hopefully save something somewhere that overwrote whatever data was causing this whole disturbance. I was not optimistic though because I managed to stop the alerts a day before just by switching locations, only to have it return.
Ultimately I did not actually alter any of my settings, I only turned the Airport checkbox on and off in the configuration list.
When I went to connect to the internet after closing out preferences, it did something new. It asked me for permission to access the Keychain for my "PPP Password". I granted permission and ever since everything has been perfect, and after a whole day of restarts and use, the alert box has not returned.. And I didn't have to re-enter settings, set up anything new, fiddle with preference files or frameworks or anything.
I will always fear the return of the neverending alert box though. The last two days have traumatized me to the the 10.4.11 network pref pane.
My apologies... where I said:
+"... and move the old framework out of the system using the mv(1) command..."+
I should have said:
+"...and move the new framework out of the system using the mv(1) command..."+
even though the UNIX commands are correct.
The idea is to move the new (bad) framework installed by the Security Update out of the PrivateFrameworks directory, and put the previous (good) version (from a backup) back in place of the new one.
Sorry for the confusion.
Sorry tonza, maybe I wasn't clear. I wasn't questioning the "old/new" file terminology from your original post. What I was asking was whether the "new/bad" file you moved to the top of the HD (NetworkConfig-SecUpdate2008-006.framework) could actually be trashed? Not being a UNIX or Terminal pro, I interpret your closing terminal session (copied below) to be a re-install of the "bad" file back to the System. Is this really a necessary step before applying any future updates? I didn't want to keep this file hanging around if it wasn't important to save.
"Important: before applying another system update, you should do the following before allowing Software Update to make further alterations to the system:
% sudo tcsh
# mv /System/Library/PrivateFrameworks/NetworkConfig.framework /NetworkConfig-Former.framework
# mv /NetworkConfig-SecUpdate2008-006.framework /System/Library/PrivateFrameworks/NetworkConfig.framework"
As a further note:
Unfortunately, your solution did not solve all my problems. While I did get my wireless connections back after restarts and logout/logins, I couldn't reconnect after a wake from sleep without redefining my network and WEP password. My system would still not auto connect on wake as it did before the update.
My ultimate solution was to restore a "clone" backup from 3 weeks ago (before the update). I updated some key files to the clone (mail, safari, etc) but I'm sure I missed something. Anyway I don't think I will be applying any future Apple security updates to my system. Apple seems to be getting very sloppy lately and I don't think they pay very much attention to Tiger/PPC platforms anymore. I would rather have a working system than protection against questionable security holes.
I've used some of the methods mentioned in this thread that don't require command line access and have solved part of the problem. Here's what I did:
1. Ran "Repair Permissions" using the Disk Utility software. A number of file permissions related to 802.11 networking were incorrect, probably left out of the recent Security Update.
2. Used the "Fast Fingers" keyboard and mouse method to break out of the System Preferences dialog loop.
3. Duplicated a Location and went into the Network Configurations. Used the new Location and switched a few things off and on without deleting anything.
4. Clicked the Lock on so that no changes could be made to the settings after I checked to make sure everything seemed correct.
5. Opened Keychain Access, selected the System keychain, and deleted the item there for my Airport network.
6. Restarted/Rebooted the system.
I can now access the Internet using Airport but I have to do that manually by typing in the name of the network and the password, even though I have the networking set to automatically connect to my Airport base station.
Interestingly, if I go into Keychain Access after doing all of the above and click on the button to show the password for my new Airport network entry it comes up with a dialog asking for my Keychain password. NONE of my passwords work and the password can't be shown. The only option is to click "Deny".
It seems to me that whatever process stores the password for accessing my Airport network is not correctly assigning permissions or the correct password.
I have had the same issues after updating my security. I am able to go online but cannot connect to any of our works networks. My boss hasn't had these issues as he is on leopard so what's the easiest way to reconfigure without losing the net and being able to connect back onto our network?
Message was edited by: JLLC
The new location and locking trick works for me as well - however, as I use my MacBook both at home and at work, I have to switch network environments every day (and therefore I have to constantly create new environments). Moreover, at least at home, I have to do this after sleep mode as well. I really hope that they soon fix the problem...
Yes, you do need to keep the original files that came with SecUpdate2008-006, for if and when Apple release another update through the Software Update mechanism, or you choose to install new software via Apple's installer on your Tiger system. The instructions from "... before applying another system update..." (the last 7 lines of my massively detailed message) relate to what you need to do *before accepting another system update from the System Update tool* after you have backed out the newer NetworkConfig.framework as per my last posting. This is in anticipation of future software updates for Tiger, including any that may fix this crippling issue introduced by SecUpdate2008-006.
Say, if Apple releases yet another system update for Tiger, and you have downgraded the NetworkConfig.framework as I have documented, the prerequisite could be that you have the latest NetworkConfig.framework installed rather than the older one swapped in to work around this issue. If you did have the older framework installed and you did a software update anyway, the Software Update tool may not be aware of this, or it could get confused, and do more damage to your system, or it might choose not to allow installation of a future update until the discrepancy is resolved. Swapping in the newer framework prior to letting Software Update run will ensure that the software that's actually installed on the machine matches the Software Update manifests/receipts/logs before Software Update proceeds to install more software onto your computer.
So, just as a kind reminder, I wrote those last 7 lines to note that you should restore the newer framework as per the instructions before installing any future software updates from the Software Update tool (including any that may resolve SecUpdate-2008-006's problems).
I would imagine that modifying system software, particularly in the /System directory, is not something that Apple supports, most likely because the Software Update and Installer mechanisms are not written to gracefully try and recover from such situations. So if you do modify the system like how I have described, you need to ensure that the system gets back into the state it was before the modification before the Software Update/Installer process next runs, otherwise future software installations may fail.
Hope this makes the picture all the clearer!
You have been digging into this deeper than almost anyone else. Can you tell me if anyone reports the issue that does not have PPP setups? I have updated three different systems, including an iBook connecting via Airport, without this issue arising, but I do not have anything setup except under TCP/IP on any of those Macs.
wish I could definitively say, but I can't because my system has both Bluetooth PPP (for using mobile phones as modems) and (internal analogue) Modem PPP configured, which I don't want to blow away!
All I can tell is this: there is a tool called NetCfgTool which, for some reason, writes to the file /Library/Preferences/SystemConfiguration/preferences.plist, which the Network system preferences pick up. Network prefs throws up a slip saying that the configuration has changed, because the preferences.plist file gets a new timestamp. Clicking on the "OK" button causes some unknown event (password/keychain related?) to happen, which causes NetCfgTool to re-write the preferences.plist, and the process repeats.
If the user ever manages to somehow select a different network configuration in the Location pop-up menu, and apply the changes before Network detects that the preferences.plist has changed, this breaks the repeat cycle! I have only succeeded to do this once... but closing the System Preferences application and re-opening it causes Network to fall back into this endless cycle of throwing up the "configuration changed by another application" dialogue slip.
It'd be interesting to see what happens when I blow away my entire system, re-install Mac OS X Tiger on my PowerBook G4 and apply all updates right through to SecUpd2008-006, and see if the problem recurs  without installing any additional Apple or 3rd party software apart from what appears in Software Update (for that, I'll have to add at least one configuration to the Network preferences for Ethernet access to get to Apple's software updates!). To test your circumstances further, I'd also have to see what happens when I add a configuration that includes a PPP password and see if the problem recurs then . If the problem doesn't recur at  but does at , then this will answer your question!
Will I do it? Maybe not -- it's going to be one painful exercise -- unless Apple haven't posted a fix within the next two weeks and I have lots of time to kill!