Is there an equivalent command for 'init.d/networking restart' in OS X

Question

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!

Solution 1

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

Solution 2

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)

Solution 3

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

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

Solution 4

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.

Solution 5

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

View more solutions

Comments

[l0c0b0x]

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.

[Mo.]

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.]

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.

[l0c0b0x]

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.

[Mo.]

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.

[l0c0b0x]

+1 for the a 'kernel related' answer.

[Brian Deterling]

I was having a problem connecting to a Cisco AnyConnect VPN using OpenVPN anytime I switched wireless networks. I tried stopping and starting the interface, but rebooting was the only thing that helped until I found this. Based on this answer I created a network location called 'Dead' with no services; now, when the VPN won't connect, I switch to Dead and then back to Automatic and it works.

[gman]

I have a lot more network interfaces than en0. This isn't really equivalent to the question being asked.