iMac loosing wired Internet connection after going to sleep

FWIW, I never sleep desktops or their HDs, just their displays, and run 24/7. Never lost an Internet connection. Try that and change your operating practices.

I recommend not sleeping since most electromechanical devices fail when you turn them on or hit them with a power surge. Displays don't fall into that category.

Why a problem now? More than likely all the nonsensical iOS integration and confusion between wired and wireless since they invoked the cloudy stuff (maybe checking for iOS devices). All I can suggest is that you File a bug reportwith Apple.

You probably have a corrup Plist file.

I lucked out one Saturday morning when I called Apple support and got a Tech who not only admited the problem existed, but knew several "fixes." He said the most common problem was a corrupt plist file.

Sadly, I took the "yeah, ok" attitude and failed to write down WHICH plist file was involved.

However, the major thing which I remembered him saying was -- after you move the plist file to the trash -- POWER OFF the computer, do NOT shut it down. Shutting it down will simply write out the same corrupt file again. When you power the sytem off and allow it to reboot, the file will be recreated! You then have to re-configure any changes you made to the default network configuration -- like host names, etc.

This was back in August, and since then, I have not had any connectivity problems -- with WiFi on my 27 inch iMac! ( I used to drop intenet connectivity randomly, every few hours.)

The energy savings are minimal, severely overwhelmed by wasting hours DLing from the MAS. Most of that is for them to appear green conscious, but belied by moving everything to the MAS and iCloud. This my energy saver icon, since I disdain dealing with mercury in the other things:

William H. Magill1 wrote:

However, the major thing which I remembered him saying was -- after you move the plist file to the trash -- POWER OFF the computer, do NOT shut it down. Shutting it down will simply write out the same corrupt file again

That's totally bogus. When you move a plist file out of its Preferences folder and restart or shutdown, RAM, where all code from those files is stored when running the machine is stored, the absence of any plist file causes the system to recreate the missing one with the default settings, which in turn is copied to RAM to run the machine. The techs aren't always correct. 😉

The plist file in the RAM will ALWAYS be re-written to disk on ANY SHUTDOWN. Period.

At SHUTDOWN, no check is made to see if the file exists or not.

That check is only made at boot time.

It does not matter if there is an existing file present or not the SHUTDOWN process simply wrrites out the contensts of RAM to disk. The contents of RAM are assumed to be correct and no check is therefore necessary.

That is normal OSX behivior, and the behavior which needs to be by-passed.

It is necessary to force RCREATION of the corrupt plist file.

If when a machine is booted, there is no plist file, THEN the OPERATING SYSTEM (not RAM or PRAM) re-creates the missing plist file from code in the Operating System module. -- Which is the goal.

First time I heard that, but I'm always open to enlightenment. BTW, what happens when RESTARTing? No one's ever said the moved plist wasn't recreated using the defaults for the moved app's previous plist. The reason I'm questioning is that a manual shutdown is a drastic procedure.

Correct, a manual shutdown PREVENTS all of those things related to saving "the current state of your system" from taking place. It is therefore "drastic."

There is a wide spread understanding that by simply trashing (moving to the Trash) a plist file ,it is automatically re-created on re-launch. This understanding is "mostly" correct for APPLICATIONS. But Applications are different from the Operating System itself, even one structured on a layered kernel as opposed to a monolithic kernel.

It is only a correct understanding for Applications which are in fact, completely quiescent (i.e. not running) at the time when a plist file is deleted! "Obviously," if you delete the plist file from a RUNNING application, the contents of that file are in RAM and will be written back out when the application quits.

One problem here is that by simply moving the plist file to the trash, and even emptying the trash, it does not "disappear" to the application. The location of that file is governed by the file location information contained in the application's RAM -- i.e. the program has no knowledge that you moved the file to the trash and then "emptied the trash." Consequently, when the Application is quit, it simply re-writes the contents of its RAM to the "last known" location of the plist file.

The second problem is that because the program is running, the CONTENTS of the plist file are known to the application. Unless there is specific code in the Application to CHECK for the existence of the plist file on termination and therefore re-create an EMPTY plist file, an Application will simply write out the information for the plist file currently contained in its RAM.

Most all Applications contain a "start up check" (on application launch) to see if this is the "First time" being launched, and therefore no plist file exists, so a "default" version should be created. This is why:

1- Quitting the application,

2- Moving the plist file out of its expected location (to the trash or anywhere)

3- And then relaunching the Application

will recreate the Application's plist file.

The difference with the OS is that OS Applications (like networking) are NOT quiescent -- they are in fact loaded into RAM in "known locations" and stay there until shutdown. During a "normal" shutdown, restart or sleep, (especially now in OSX) the OS attempts to "save state," so that it can recreate "the state" of the environment when shutdown occurred on reboot. (Reopening all of those apps you have open and all of the documents you were working on.) This "state saving" is why Shutdown takes so long. Power cycling the system also guarantees that RAM is wiped -- Power Cycling also runs the POST (Power On Self Test) which does not run on any restart or "normal" shutdown and reboot operation.

So, in short, your understanding of plists is correct for Applications, but "not quite" correct for the Operating System plists. (Knowing which plists this applies to is an arcane piece of knowledge requiring extensive training in the Black Arts!)

Well, since I've disabled all resume functions, disdaining mommy Apple;s saved state nonsense (have only had one power outage in fourteen years), so like journaling, I avoid it, I'll have to wrap my head around this new BS. BTW, everyone should know energy saver plists are stored in /Library/Preferences/SystemConfiguration/. I will test erasing the energy saver one when next I boot into Lion or ML and test your assertion. I'd like to see it restore that which has gone missing after a restart. FWIW, I see no saved state items for anything but apps, certainly not any background processes.

I've had this issue since FOREVER

it stopped a little bit after upgrading to mountain lion then it started again

Internet drops even though it still shows connected to the wifi

only fix is to wait a while or disconnect from wifi and reconnect to it

it had been doing it constantly, on a daily basis and every few hours

until 3 days ago I decided to shutdown my VMWARE FUSION app which is always running and since then NO DROPS!!!!

So just in case anyone runs virtual machines.... it may be related to that just as it apparently was in my case.

Bad news is I can't use VMWARE fusion or can't leave it open because it causes my internet to drop....

bleh

Thanks for the feedback. Good computing.

One of my iMacs is experiencing the same issue that sweetcaro has described. I can make the problem go away for a while by deleting the network adaptor and then adding it back. Unfortunately the problem eventually comes back. Does anyone know how to resolve this, or which plist files I could try removing?