Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

Thanks!

share|improve this question
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
add comment

4 Answers

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
share|improve this answer
1  
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
add comment

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. :)

See:

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)

share|improve this answer
1  
+1 for the a 'kernel related' answer. –  l0c0b0x Jan 10 '11 at 13:18
add comment

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.

share|improve this answer
    
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
    
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
show 1 more comment

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

sudo ifconfig <interface> down;sleep 1;sudo ifconfig <interface> up
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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