A few days ago, a friend came by with his AirPort Extreme base station (AEBS) and his external USB hard disk. He was having problems getting the hard disk recognized and shared through the AEBS in a seemingly random way. The AEBS would correctly share the disk, until you would directly connect it to a Windows PC to transfer files. After that, reconnecting it to the AEBS's USB port would lead to an unmountable network share on the Mac, and an empty share on the PC (Windows XP SP2).
We thought of a formatting problem, so we first reformatted the 500GB disk as an HFS+ volume, and tried again connecting it to the AEBS. Transfers would work both ways from the PC and the Mac through the AEBS. But after connecting the disk directly to the PC and transfering files with TransMac, then plugging the disk back on the AEBS, we would get the same problem with an unmountable share (the problem wouldn't appear after connecting the disk directly to the Mac).
We restarted the base station several times using the AirPort Utility without success. Until, on a hunch, I decided to try unplugging the power plug from the AEBS, and then plugging it back in. After trying the same procedure several times, this appeared to reliably lead to the recognition and mounting of the shared hard disk.
Unfortunately, we didn't have time to test more scenarios (like reformatting the disk as FAT32), but the bottom line is: restarting the AEBS from the AirPort utility doesn't seem enough, so unplugging the power and plugging it back may be more helpful.
While looking for a way to disable Apple Remote Desktop and other services from the command line, I happened to be in /System » Library » LaunchDaemons. In my boredom, I opened ssh.plist in that directory, and find that Bonjour is a key. Anyway, skipping a long explanation and some inevitable tinkering, I figured out how to stop Bonjour from pointing out to the world (or at least my local network) that I have ssh enabled.
Be warned that while I have had no problems, I can not insure that you will not. This hint edits a system file, and messes with Bonjour, so think before you act. It also may take a system restart, in addition to undoing this hint, to re-enable Bonjour broadcasting of ssh and sftp. I would make a backup of /System » Library » LaunchDaemons » ssh.plist first, as we will be be deleting two strings from that file. (When I tried commenting them out, they disappeared after I stopped and restarted ssh.)
After you've made your backup, here's one way to edit the file:
sudo vi /System/Library/LaunchDaemons/ssh.plist
In the editor, delete these two lines:
They should be found around lines 22 and 23. Save the file and quit the editor. Then go to System Preferences » Sharing » Services, unlock it, disable Remote Login, and final re-enable Remote Login. You can check if things worked by using Bonjour Browser or some such similar app to be sure ssh/sftp no longer show up.
Lastly, to explain the plus in the hint title: A simple grep -ir bonjour . showed that eppc.plist, ftp.plist, and telnet.plist also had the Bonjour key. I don't use them myself, so this same trick may or may not work for those services, too.
I recently picked up an AirPort Express to stream iTunes to my luxurious Apple Hi-Fi. However, it seems to lose the connection periodically, which is annoying at a minimum. I searched high and low and couldn't find a script to address this issue, so here is one I whipped out.
What it does:
Checks to see what time it is.
If reasonable time, checks to see if speakers are there.
If no speakers found, announces a restart and restarts iTunes and clicks play.
Post to the system log as we go so we know the script ran.
It's a rather clunky way to fix the issue; a better way would be just to enter the secret command that iTunes is sending, but how do I trap that? I also have a script that will restart the AirPort Express. However, I have not found a need for it yet, since restarting iTunes (6.0.2) seems to fix the issue. For this script to work, your speakers need to be named "Speakers" or "Fred's Speakers" or "Pokey's Speakers" -- or anything else with "speakers" in their name. I used Cronnix and put this in a cron script (yes they still work in Tiger) and it runs every 15 minutes.
I was looking at the Wireless Options in the new Airport Utility to configure my Airport Extreme router. I noticed you could reduce the power output of the wireless. Since I have the router in my living room it sounded very appealing, especially since I have a new baby in the flat. I tried reducing it to 25%, but the signal was barely strong enough to work in the kitchen, which affected performance.
I recently followed the tips in this article to see if they would help at all. Changing the channel and implementing MAC filtering means I can now set my AirPort Extreme at 10% power, and I still get full strength signal everywhere in the flat. I also have fewer incidents where I have to manually rejoin my wireless router.
[robg adds: You might also want to set your AirPort up as a closed network -- it won't be visible to the casual user who happens to be located nearby, though this won't stop dedicated hackers from finding it. Note that you may have some devices that won't work with a closed network (I had an old audio appliance that simply failed to connect if the network was closed).]
I often use Personal File Sharing to move files between the various Macs here at macosxhints.com HQ. A typical scenario will have me connecting to the desktop machine from my MacBook Pro to move some files I've modified back to the main machine. At some point after that, I'll move back to the main machine and continue working, then put the main machine to sleep when I'm done. Later in the day, I switch back to the MacBook Pro, and notice that the main machine's share is still mounted. "I should eject that, since I'm done with it now," I say to myself, forgetting that I've put the main machine to sleep.
Blammo. As soon as I press Eject, the MacBook Pro enters what turns out to be a 12-minute cycle of uselessness. I get the spinning rainbow in every application, and keyboard and mouse input is ignored -- everything except clicking on an application's window to activate it. (Yes, 12 minutes -- here's the log file, with some comments.) But I cannot get the Force Quit dialog to show, I can't type in Terminal, and the machine is essentially a brick. Then, 12 minutes later, the system realizes that the connected server is no longer there, ejects the mounted share, and everything returns to normal (and some number of the keyboard and mouse inputs I've entered are then processed en masse, which can be entertaining to watch).
I've had this problem for quite a while, but only got serious about debugging it a week or so ago. With some help from Kirk, we figured out what was going on. On Kirk's machine, ejecting a sleeping share resulted in the Finder (and only the Finder) hanging for a minute or so. When we compared out network setups, the only real difference was that Kirk uses DHCP IP addresses while I use static IP addresses. When I ran the same test with my machines set to use DHCP addressing, the 12-minute hang vanished, and I saw the same behavior as did Kirk.
I don't, however, want to use DHCP (not for any good reason, of course; just personal preference). So I did some more experimenting, trying to find a cleaner way to exit this hang when using static IP addresses. What I found was that if I clicked on the share's name in the sidebar, I'd get the much nicer one-minute Finder-only hang, instead of the 12-minute total lockup. (As a side note, I did find a couple of possibly-useful prefs settings (afp_reconnect_interval [default: 10] and afp_reconnect_retries [default:12]) in the com.apple.AppleShareClientCore section of the .GlobalPreferences plist file, but modifying them didn't seem to have any effect on the 12-minute hang.)
So the hint here is two-fold: first, use DHCP if you do a lot of AFP share mounting, as you'll avoid the problem entirely. But if you do use static IP addressing, then do not hit the Eject icon for any sleeping shares -- just click on the share name instead, and you'll see a much nicer (and quicker!) timeout process.
If you own a Mac with an AirPort card, but don't own a wireless router, here's a way to put the AirPort card to use: use it to share your internet connection with your Wii. First, make sure you're connected to the internet (via something other than the AirPort card, i.e. Ethernet). Also, make sure AirPort is on. Then do the following...
Step One: Turn on Internet Sharing
Go to System Preferences, click on the Sharing icon, then click on the Internet tab.
Change the 'Share your connection from' pop-up to Built-in Ethernet.
Under the 'To computers using' section, check the AirPort box.
Click Airport Options, and enter an easy name such as wii in the Network Name box.
OPTIONAL: Use any password that fits your settings (i.e. 128 bit WEP requires 13 characters).
Click OK if you're on the AirPort Options screen.
Click Start in the Internet Sharing panel.
Step Two: Gather Information
Open Terminal.app and type ifconfig en1.
In the output look for: inet xxx.xxx.xxx.xxx netmask ....
Take note of the IP address associated with the first inet, negating values after the # (mine was 10.0.2.1; yours may be different).
Type dig. Near the bottom of this output will be SERVER: followed by an IP address. This will be the DNS server address that you will use for your Wii.
OPTIONAL: Use an ASCII/hex converter (such as this one), and enter you password in ASCII to get the %-separated hex-equivalent. This should be 26 hex characters for a 13 ascii character password using 128 bit WEP.
On the Bluetooth System Preferences pane's Settings tab, click on the Bluetooth Device Name string to reveal details like the MAC address, adapter version (someone please confirm this?), and model/make.
Note that I'm using a USB Bluetooth adapter. If you are one of the lucky ones to have Bluetooth built-in to your Macs, your mileage might be better.
If you're like me, you often find yourself connecting to VPN networks. Every time I open my laptop, I must log on to the VPN in order to access the Internet. Not that this is a tedious task, but it is annoying. So I thought I'd write an AppleScript to automate the task. Right before I attempted to write the script (which would connect if and only if a specific wifi network is joined), I came across this free little application called PearportVPN (it's the third entry on that page).
It does all the work for you, and even disconnects from the VPN before putting your Mac to sleep. That feature is great -- otherwise you would receive a time-out message if you forget to disconnect from your VPN. Here's a screenshot of the pearPortVPN interface, in case you're curious as to what it looks like. I have no affiliation with pear, but thought others might find this app useful.
In setting up a VPN on my OS X Server at the office, I was having trouble getting the OS X client option Send all traffic over VPN to actually do what it says. In fact, the setting appeared to change nothing on my client machine. After much googling and searching the Apple Discussion forums, I couldn't find anything specific to my issue, so I wanted to reveal the solution here for others to enjoy.
Simply go to your Network Preferences, open your Network Port Configurations, and drag the VPN entry to the top of the list.
This seems to force all TCP/IP traffic over the VPN no matter what the Send all traffic over VPN setting is, but only when you are connected to a VPN. I don't think this is an ideal solution, but at least it allows me to tunnel all my traffic while traveling.
Background: A while back, I had to replace my old Linksys router with a newer one -- the old one maxed out well below my FIOS connections 15Mbps limit (Verizon supplied an ActionTEC router, which worked quite well, but whose admin interface I hated). After the switch, iPhoto and iTunes sharing no longer worked between my Macs, or to my AppleTV after it arrived. This bothered me enough to ask about it, but I sort of gave up when I didn't get any good responses. Our recent move to a new home gave me the chance to set the network up from scratch again, but sharing still didn't work. So I set out to do some more Googling for a solution.
The answer: To enable sharing with a newer Linksys Cable/DSL Router (I have a BEFSR41 v4.1), you need to modify your router's setup. Go to the Security page (i.e. http://192.168.1.1/Filter.htm), and down near the bottom, you'll see a setting for Filter Multicast. By default, it will be disabled -- which logically strikes me as the proper setting. However, if left disabled, sharing won't work -- change it to Enabled, save the settings, and you'll be good to go! Hooray!
The solution was originally posted by NCarter in this thread on Apple's Discussions site, so all credit to NCarter!