A reader at Stack Exchange asked an interesting question about whether it was possible to set up an "airplane mode" for OS X. The idea was to ensure that there is no network activity through any possible network interfaces.
It's actually pretty simple to do this. If you go to the Network pane of System Preferences, you'll see a Location popup menu at the top of the window. Click on that menu and choose Edit Locations. Click on the + icon to add a new location, then enter a name, such as AirplaneMode. Click on Done.
Next, choose that location in the Location menu, and click on each available network interface in the list at the left of the window. Click on the Configure iPv4 menu, and choose Off. For Wi-Fi, just click on the Turn Wi-Fi Off button. Click Apply, and this location will block all network activity.
To activate the location, there are two ways. You can click on the Apple menu, then Location, and choose the location. Or, if you wish to do this from the command line, as the poster had requested, you can run this command:
networksetup -switchtolocation AirplaneMode
Replace AirplaneMode with the name you've chosen for the location.
Using airplane mode can be useful if you're worried about security when using a laptop in public places. It can also save battery power, as Wi-Fi will go off, and your Mac will no longer search for networks.
You can find out which wi-fi networks a Mac has connected to by going to the Network preference pane, then clicking on Advanced, then on the Wi-Fi tab; they'll be listed in Preferred Networks. But if you want to do this from Terminal - say for a Mac you've connected to via ssh - this hint, posted on OS X Daily, can do it as well:
defaults read /Library/Preferences/SystemConfiguration/com.apple.airport.preferences RememberedNetworks | egrep -o '(SSID_STR|_timeStamp).+' | sed 's/^.*= \(.*\);$/\1/' | sed 's/^"\(.*\)"$/\1/' | sed 's/\([0-9]\{4\}-..-..\).*/\1/'
The list will be the same as that in Preferred Networks, and you can't alter it, but it my be useful in some situations.
When managing a server at work, I noticed my home server was showing up in the list of managed servers. Trying to see if I could connect by supplying my credentials was unsuccessful. I figured it must be showing up because I had signed into the same iCloud account on both machines. I then wondered if using the Back to My Mac URL for iCloud would allow me to connect.
To test, in Server.app I selected Manage > Connect to Server... From there chose "Other Mac." For the Hostname I inserted the Back to My Mac URL in the form server.XXXXXXXX.members.btmm.icloud.com. (see this hint to find how to construct the correct URL for your Mac), supplied my credentials and clicked Connect. The remote server came right up and I was able to manage my home server with no issues.
A hint last year mentioned Wi-Fi Diagnostics, an application hidden in /System/Library/CoreServices. It turns out that you can also access this by Option-clicking the AirPort menu in your menubar and choosing Open Wi-Fi Diagnostics.
[kirkmc adds: This was available under Lion, but wasn't in the original hint, so it's worth posting.]
If you're running two Macs with iCloud support (Lion or Mountain Lion), then you can use iCloud's network to remote SSH back into your home computer no matter where you are with just a few commands in Terminal.
The process is explained by the One Thing Well blog, but you need to set up a few things before you get started. First, you need to make sure Back to My Mac is enabled in iCloud (System Preferences > iCloud > Back to My Mac). Next, you need to set up your home computer for sharing if it isn't already. Head to System Preferences > Sharing and turn on at least File Sharing and Remote Login. With everything set, you can now remotely log in to your home computer using iCloud's network wherever you have internet access.
To start with, you need to do is find your Back to My Mac account number. In Terminal (Applications > Utilities), type:
dns-sd -E
The final nine digit number is your Back to My Mac account number. Next, it's time to SSH into your other machine:
If you don't know your username or computer name, head to System Preferences > Sharing on the destination computer and click on Remote Login. Your Computer name is listed at the top (if it's multiple words use the address with the dashes). Your username is listed on the line below Remote Login right before the @ symbol. You will need to do this before you try to SSH into your computer when you're away.
With that, you should have access to your Mac no matter where you are. Head over to One Thing Well for a few more tricks and shortcuts for using the iCloud network to remote SSH.
So, as a reminder, to flush the DNS cache in Mac OS X 10.5 and 10.6, run this command in Terminal:
sudo dscacheutil -flushcache
To do the same in 10.7 and 10.8, run this command:
sudo killall -HUP mDNSResponder
As Apple points out, you might need to do this in the following situation:
"OS X keeps a local cache of resolved DNS queries for a time defined by the DNS server, but sometimes it may be necessary to reset the cache immediately and re-query a DNS server. For example, you might do this after an entry on the server is changed or a new entry is added."
This is a hint about phantom NFS shares that may linger on your system long after you stopped accessing the share, and that may cause slowdowns and errors with various disk utilities. The information here applies to Lion, and may differ in earlier and later versions.
I used to have a NAS device that I named "dns323," and which was visible in the Finder as an NFS share. (The unit used a Linux-formatted disk.) In the past few months, whenever I used the excellent Yasu system maintenance utility, it would report an error message, saying that the file "dns323" wasn't found. I eventually realized that this problem started when I stopped using that NAS device. I also noticed that Find Any File was starting very slowly; and when I used Find Any File to see if it could find any trace of "dns323," it listed the file in its results list, but said that the item had disappeared.
I eventually realized that there was a directory named "dns323" in my user folder, but that directory wasn't visible in the Finder, even if I made invisible files visible. The directory name was visible in Terminal, but if I tried to cd into it, I got a message saying "Connection refused." None of the standard Unix commands for deleting a directory had any effect; I typically got a message saying "Resource busy" when I tried.
Eventually, with the help of the experts on the forum on this site, I found that "dns323" was listed in the table of mounts that appeared in Terminal when I entered typed the df command. The dns323 item was listed as "map -static" which, as I understand from other posts, means that it's a mount that isn't actually mounted, but which the system has ready for mounting when needed.
After a lot of other effort, I finally discovered what was creating this phantom mount. There was a .plist file in this folder: /var/db/dslocal/nodes/Default/mounts. The .plist file contained a name that was something like 10.0.1.8%2Fmnt_a2.plist (I'm writing that from memory); the name began with the IP address that the share had when I used it.
I didn't try deleting or moving this plist file while running OS X normally, but I think (on the basis of other postings in other forums about similar files) I could have used sudo rm <filename> to delete it. Instead I booted into single-user mode and moved the file to another location where I could restore it if needed (although I didn't need it). I then booted normally again, opened Terminal and entered rmdir ~/dns323, which was successful.
After this, Find Any File started working at top speed again, and Yasu stopped reporting an error. If file utilities and directory listings seem sluggish on your system, then it may be worth looking for files that create phantom shares in the directory listed above.
You may want to keep both 5.6 and 6.0 versions. I used Pacifist, and manually reinstalled the 5.6 version side by side. Lots of missing features in the new utility. No way to tweak wireless options for Mode, Frequency, Multicast Rate or Transmit Power, and such a tiny window for port mapping list. An elegant interface, but at a price.
For a thorough review and pointers to stand alone updates, read here.
[crarko adds: Consider this a public service announcement. It also appears that AirPort Utility 6.0 only functions with the 802.11(n) compatible base stations, so that old AirPort Express you may have (like I do) is not supported. I've actually saved many older versions of the utility, even for the original Graphite (flying saucer) bases.]
I've been using Airport Express wireless-g for years to stream music to my stereos. And they work great once you get them working, but with the wireless-g models, I have always had problems setting them up on a new network after they have already been setup on another network. I use it as a streaming device, so it is set up as a device on my network, and not as my router. The problem with dropouts when streaming music over an Airport Express g can be resolved by changing the network settings on the wireless router.
First of all, the Airport Utility never seems able to find an Airport Express that does not have factory settings and is not set to communicate with the existing wireless network. Sometimes holding down the reset button on the AE until the light blinks rapidly while it is plugged in works. In other cases, I have had to hold it down before plugging it in and then plug it in to get it to work. I have often had to repeat these steps multiple times before I can get the Airport Utility to recognize it. It takes persistence, but eventually the Airport Utility will recognize it.
Once it is recognized, the setup is straight-forward. However, every time I set one up, I seem to forget about the dropout issues. I've found that dropouts occur when the network router wireless settings allow for both TKIP and AES security protocols (on a WPA security setting). I've found that by changing my router wireless settings to either TKIP or AES, but not allowing the use of both, the dropouts no longer occur.
Hope this works for people, as I love the AE's once they work. Just got a new wireless-n AE, and it seems some of the issues may have been resolved.
[crarko adds: I remember seeing some of these issues with the older AirPort Express as described here. I thought they were fixed with firmware updates, but I'm not absolutely sure. This sounds worth trying if you still have the dropout problem.]
When run as root this will use the guest account to mount the volume -- it's a work around and only recommended for those whom understand the root account.
