The "Wide Awake Conscious Cafe" never seemed to be open.
There's a "Martial Art Center" on Highway 50. Fear my easel. My chalk and charcoal moves are unstoppable.
Sunday, August 23, 2009
Tuesday, August 11, 2009
Mac OS X failing to join a network
Supposing you have a nice shiny Mac OS X machine that, one day, out of the blue, just stops talking to your network. You've changed nothing, installed no new software, etc. but suddenly you're dead in the water. Other machines in your house are working just fine - i.e. they can access the internet. What's going on here?
First things first, let's check if you're seeing the same problem I'm about to describe. For a start, if no other machine in your house can get to the net either, then you probably have a problem with your internet connection. This post isn't going to help you in that case - call your internet service provider or check your modem, wireless hubs, switches, etc.
If it's just one of your Macs that's having the problem, the go to the System Preferences application on that Mac and select the "Network" pane in the "Internet & Network" section. You should now see a preference pane showing you the list of network devices on your computer. Some will have a green dot next to them and be labeled "Connected." Some may have a red dot and be labeled "Not Connected." Some may be grayed out and marked "Inactive." Don't worry if you don't see all three types - we just care about the green ones. If you don't see any green ones, then you're machine isn't even attempting to make a connection to the network. This _may_ indicate a hardware problem: if you're connected via an ethernet cable, then check your cables and hub/modem/etc. If you're connected wirelessly, check your wireless network settings, passwords, etc. If all else fails, have Apple check your Mac hardware.
If you see connected interfaces, click on one of them and see what it says under the "Status" label. If it says something like "self-assigned IP address", then you're probably hitting the problem I'm about to describe.
As a temporary work-around, go back to the System Preferences main window (click the "Show All" button at the top) and select the "Security" pane in the "Personal" section. Click on the "Firewall" tab. Select "Allow all incoming connections". Then go back to the "Network" pane. Click on one of the green interfaces and click on the "Advanced..." button. In the window that pops up, selected the "TCP/IP" tab and click on the "Renew DHCP Lease" button. Click on the "OK" button, then click on the "Apply" button. The "self-assigned IP address" text should go away. Repeat for any other green interfaces. You should now be able to access your network.
This isn't a very satisfactory long-term work-around, as turning off your firewall is generally not recommended. A more permanent solution is to fix the underlying problem.
So what's happened to your machine and why does this work-around work?
First, a bit of background. All of the bits and pieces of executable software that ships with Mac OS X are digitally signed by Apple. The signature is attached to a part of each executable, library, etc. on the machine, and can be checked by the Mac OS X kernel when it's asked to run that software. The signature is very very hard to forge - practically impossible, actually. If the software has been modified post-installation (e.g. by a virus), then the executable won't match the signature, and the kernel can refuse to run the executable, or give it lower privileges when it does run. Likewise, if an executable has no signature, then the kernel knows it wasn't installed by Apple, so it can't be implicitly trusted. One of the things an executable not signed by Apple can't explicitly do is accept incoming network connections - you may have seen that pop-up when you've run a 3rd-party program for the first time.
Now there are certain circumstances when the application firewall will remove the signature on an executable when it runs - for example, when the system's real-time clock is reset. I'm not sure why it does this, but it does. That's a real problem if your RTC battery dies, say.
So guess what happened: your RTC got reset, you started your Mac up, the DHCP client started up and tried to accept an incoming connection, the application firewall went "whoa" and stripped the signature from the DHCP client executable. Boom - no DHCP.
Here's how to fix it. Go to your backups (you are backing up your machine, right?) and replace the following 2 executables with ones from the day before your network died:
Then reboot - you should be all set. You can verify that the signatures are in place by using the codesign command on the executables:
First things first, let's check if you're seeing the same problem I'm about to describe. For a start, if no other machine in your house can get to the net either, then you probably have a problem with your internet connection. This post isn't going to help you in that case - call your internet service provider or check your modem, wireless hubs, switches, etc.
If it's just one of your Macs that's having the problem, the go to the System Preferences application on that Mac and select the "Network" pane in the "Internet & Network" section. You should now see a preference pane showing you the list of network devices on your computer. Some will have a green dot next to them and be labeled "Connected." Some may have a red dot and be labeled "Not Connected." Some may be grayed out and marked "Inactive." Don't worry if you don't see all three types - we just care about the green ones. If you don't see any green ones, then you're machine isn't even attempting to make a connection to the network. This _may_ indicate a hardware problem: if you're connected via an ethernet cable, then check your cables and hub/modem/etc. If you're connected wirelessly, check your wireless network settings, passwords, etc. If all else fails, have Apple check your Mac hardware.
If you see connected interfaces, click on one of them and see what it says under the "Status" label. If it says something like "self-assigned IP address", then you're probably hitting the problem I'm about to describe.
As a temporary work-around, go back to the System Preferences main window (click the "Show All" button at the top) and select the "Security" pane in the "Personal" section. Click on the "Firewall" tab. Select "Allow all incoming connections". Then go back to the "Network" pane. Click on one of the green interfaces and click on the "Advanced..." button. In the window that pops up, selected the "TCP/IP" tab and click on the "Renew DHCP Lease" button. Click on the "OK" button, then click on the "Apply" button. The "self-assigned IP address" text should go away. Repeat for any other green interfaces. You should now be able to access your network.
This isn't a very satisfactory long-term work-around, as turning off your firewall is generally not recommended. A more permanent solution is to fix the underlying problem.
So what's happened to your machine and why does this work-around work?
First, a bit of background. All of the bits and pieces of executable software that ships with Mac OS X are digitally signed by Apple. The signature is attached to a part of each executable, library, etc. on the machine, and can be checked by the Mac OS X kernel when it's asked to run that software. The signature is very very hard to forge - practically impossible, actually. If the software has been modified post-installation (e.g. by a virus), then the executable won't match the signature, and the kernel can refuse to run the executable, or give it lower privileges when it does run. Likewise, if an executable has no signature, then the kernel knows it wasn't installed by Apple, so it can't be implicitly trusted. One of the things an executable not signed by Apple can't explicitly do is accept incoming network connections - you may have seen that pop-up when you've run a 3rd-party program for the first time.
Now there are certain circumstances when the application firewall will remove the signature on an executable when it runs - for example, when the system's real-time clock is reset. I'm not sure why it does this, but it does. That's a real problem if your RTC battery dies, say.
So guess what happened: your RTC got reset, you started your Mac up, the DHCP client started up and tried to accept an incoming connection, the application firewall went "whoa" and stripped the signature from the DHCP client executable. Boom - no DHCP.
Here's how to fix it. Go to your backups (you are backing up your machine, right?) and replace the following 2 executables with ones from the day before your network died:
/usr/sbin/configd
/usr/sbin/mDNSResponderThen reboot - you should be all set. You can verify that the signatures are in place by using the codesign command on the executables:
$ codesign -d -vv /usr/sbin/configd
Executable=/usr/sbin/configd
Identifier=com.apple.configd
Format=Mach-O universal (i386 ppc7400)
CodeDirectory v=20001 size=1102 flags=0x0(none) hashes=50+2 location=embedded
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist=not bound
Sealed Resources=none
Internal requirements count=0 size=12
Monday, August 10, 2009
Subscribe to:
Posts (Atom)
