From time to time, I've encountered issues with OS X clients' network connections (Wired and Wireless, Leopard/Snow Leopard) where nothing will fix the issue, until you reboot.

  • Is there a particular 'network service/process' I should be watching out for?
  • I was thinking it would be useful to know of a command that will reset a 'network connection' type service/process (same as running a sudo /etc/init.d/networking restart).

After basic troubleshooting such as DHCP, DNS, checking for interface malfunction (disable/enable), checking logs and not finding enough helpful info, sometimes when everything else fails the best thing is just to reboot the machine. I'm not sure what all the 'init.d/networking restart' does in Linux, but I know it's way more helpful than disabling and enabling interfaces.


  • 1
    You say "nothing" will fix it....can you tell us what you have tried that hasn't worked? – TCampbell May 10 '10 at 17:31
  • Hehehe, pretty much everything within my grasp... and it hasn't been one issue, it has been many.. again, with both wired and wireless. For example, I've seen an issue where the network card will NOT re-act, even after disabling and enabling (on two different machines with different versions of OS X and different models). I wouldn't ask this if the issues weren't random :) – l0c0b0x May 10 '10 at 17:35
  • Have you managed to figure out how to get networking working again without rebooting, I am having the same issue. The really strange thing is that I am running Windows in VMWare and still have network connectivity from VMWare session. – user66201 Jan 9 '11 at 20:02
  • 2
    To be blunt, your question is a bit like going to the doctor and saying, "I'm sick, give me some medicine that will cure me." The /etc/init.d/networking restart basically drops the interface, raises it again and then applies the configured addressing. Some ethernet card drivers reinitialize the card every time it is raised. This may be why doing networking restart has worked so well for you. My point is, if you want a worthwhile answer, can you focus on the most irritating example of this? Are all your situations at the same location for example? Does "issues" mean "doesn't load webpages?" – etherfish Jan 10 '11 at 18:18
  • 1
    I've had an even gnarlier version. Every now and then, everything network will drop. The wifi dropdown beachballs and on the Network System Prefs panel the list on the side is empty. Theres not even a "wifi" to restart. ifconfig is empty, not even a localhost loopback. An /etc/init.d/network restart would be pretty sweet, but perhaps with the machine in that state a reboot is precisely whats needed. On lunix I can reload kernel modules, reboot the network, all sorts of well documented things. when the trusty ol' maccenbox gets this way, technically called "shitting the bed" I pull the plug:( – Shayne Jul 4 '18 at 15:51

You can bring down the network interface and bring it back up again, that should accomplish the same thing.

sudo ifconfig en0 down
sudo ifconfig en0 up
  • 2
    I think this would be the same as going to pref/panel and disabling the device and enabling back, right? (which, of course I've tried). – l0c0b0x May 10 '10 at 17:37
  • I have a lot more network interfaces than en0. This isn't really equivalent to the question being asked. – gman May 20 '16 at 10:08

No, there isn't an init.d/service/launchctl equivalent to 'init.d/networking'.

If it's wifi related, you can poke the interface from the command line (on SL) with: /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport

If it's wired, use ifconfig.

Other then that... I would check dmesg and /var/log/* for errors.

You can also unload/reload the kld or check it for errors.., and reload it, but I've never tried that, I'd rather just reboot. :)


kextfind(8) - find kernel extensions (kexts) based on a variety of criteria and print information
kextload(8) - load kernel extensions (kexts) into the kernel
kextunload(8) - terminate driver I/O Kit driver instances and unload kernel extensions (kexts)
kextutil(8) - load, diagnose problems with, and generate symbols for kernel extensions (kexts)

  • 2
    +1 for the a 'kernel related' answer. – l0c0b0x Jan 10 '11 at 13:18

If you want to do it from an ssh shell/remote:

sudo ifconfig <interface> down;sleep 1;sudo ifconfig <interface> up

If a simple ifconfig up/down won’t work, create an additional “Location” which has all of the network devices disabled, then run scutil to switch to it, sleep for a couple of seconds, then bring it back.

That said, I haven’t seen this happen on any of my Macs except where the DHCP server has had a fit and it’s coincided with lease renewal (and so the Mac has ended up misconfigured). Is the network configuration actually correct when this occurs? If they’re DHCP’d, does hitting the “Renew” button in Network Preferences > {Device} > TCP/IP have any effect? What about, in the case of wireless, turning the Airport off and on again? If you can find out what, besides a reboot, will bring it back, then you’re a big step closer to figuring out what’s actually triggering the behaviour — hitting it with a big stick (which is what bouncing the interfaces effectively is), is only ever going to effect the symptoms, not the cause.

  • Added some more info to the question. Yes, in this instance (this morning) DHCP was working fine, so was DNS. I'm looking for 'if everything fails' step that doesn't include a reboot of the OS. – l0c0b0x May 10 '10 at 23:17
  • 1
    on Linux, /etc/init.d/networking stop pretty much does just ifconfig ethX down for each interface. it might empty the routing table, too and possibly clear the ARP cache. the magic is in the start command, not the stop — and all that does is configure addressing and routes (or renew the DHCP lease, if appropriate) if the network device module is already present. Rebooting is very very very rarely the best course of action. – Mo. May 11 '10 at 12:35
  • to clarify — when you say DHCP and DNS are working fine, are the output from ifconfig and arp on the client machines the same as under normal circumstances? can your switch(es) reach them, even if they can’t see other things on the network? for this to be happening often enough (and with such varied conditions) for you to task the question, I’d be looking at a part of the infrastructure other than the clients themselves, in all honesty. – Mo. May 11 '10 at 12:39
  • Maybe that's mainly what I'm trying to answer here, what the networking stop/start actually do for you... and how you can do the same on OSX. In this instance, the OSX machine was able to acquire an IP, but not connect to an access point for authentication/active-portal (association was fine), I should have done a tcpdump to find out where the COM was breaking, but decided to reboot and that seemed to 'fix' the issue. My concern is that I've had issues before that even disabling/enabling a NIC didn't do 'the trick', when rebooting did. – l0c0b0x May 11 '10 at 17:26
  • okay… the closest equivalent to networking restart is disabling/enabling the interfaces — that’s what those shell scripts do. so, if that’s not doing the trick, then it’s a driver or hardware issue. Given that this is happening on a bunch of different machines on different OS versions, over both wired and wireless, the only real common factor is the infrastructure they’re connecting to. – Mo. May 11 '10 at 17:44

I had the same problem (network started to be slow after a few hours, I'm mostly working on a Mac connected by a wired network to a Windows Computer) and what it worked for me was to eject the computer that I was connected to (in Finder) and turn off the Ethernet (System Preferences -> Network -> Ethernet -> Off) and then connect those two again. :)

Not the answer you're looking for? Browse other questions tagged or ask your own question.