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!
The following script will let you use, or not use, an SSH proxy depending on your machine's location. What you need to make it all work:
connect.c for proxying (installed in /usr/local/bin or some such; change script as needed).
netcat to act as a "null" proxy (available through Fink).
The script -- remember to make it executable and store it somewhere on your path.
Here's how things work, in a nutshell. If you have a proxy configured, then the script will find the hostname and port of the proxy for the given protocol (look for the ****Proxy that you want by doing scutil --proxy -- it's a regex, so it must match the case). Then it will find the username and password for that proxy in your keychain and store them in environment variables that connect.c will understand.
If you don't have a proxy configured, the script will see that there's no proxy and just use netcat to simulate connect.c, and you can go about your SSH as normal. To use it, I have this line...
...at the top of ~/.ssh/config -- this means that every SSH connection is automatically proxied when my network "Location" is 'Work,' but not when I'm at 'Home.' Assuming you're using SSH key authentication, you should be able to get to the remote machine without ever entering a single password and still be secure; even with an authenticating proxy between you and the remote machine. Hope this helps somebody.
My hotel room only has a modem with Windows drivers, so I got it running under Parallels Desktop Windows XP. However, I wanted to check my email with Apple Mail, so I found this solution:
Set Parallels Desktop' Network Options to "Host-only network"
Start Windows and run the XP Network Setup Wizard
Share Your direct Connection
Open OS X's Network System Preferences panel, and refresh your automatic DHCP address from your local built-in Ethernet. If your Ethernet takes a long time to refresh, and ends up with a random adress like 184.108.40.206 or so, check the Windows network again, and enable the Netbios function for DHCP. It should then get an Adress like 192.168.0.2 or 10.0.0.2.
It runs pretty well, too -- congratulations to Parallels for making the Windows drivers work directly ... wow!