When I was reconfiguring the IP address on my OS X box to move from one network to another, I noticed that my netmask was 255.255.255.1 instead of 255.255.255.0. I hadn't noticed any problems before. But every time I tried to change it to 255.255.255.0, it would go back to 255.255.255.1 when I hit the Apply button. Everything seems to work still, except I couldn't log into my .1 router even though I can ping it.
To my surprise, when I changed the netmask to 255.255.254.0, the Mac accepted the change. And now when I changed it to the correct 255.255.255.0 netmask, it stayed!
This was one of the more bizarre network strangeness I've seen. Hopefully, the hint will save some headaches out there. Note: I'm running OS X Server 10.2.6. Don't know if the anomaly has been seen elsewhere.
[robg adds: If anyone has any thoughts on what might cause this problem, please post them!]
The Cocoa framework indeed has a lot of peculiar features. For example, you don't have to write IP addresses like everyone else does. Every segment of an IP address is a number between 0 and 255. (You could also say that they are a byte each). This can be translated into a number. So if you take the IP address of macosxhints.com, 18.104.22.168, and do this calculation:
You get 3,475,821,262. Now if you enter that number (without the commas -- 3475821262) into a Cocoa based browser (Firebird and Safari will do, Internet Explorer won't as it's a Carbon app), you will be at the macosxhints.com homepage. It seems to work in Cocoa based apps. I tried it with Safari, Firebird, and several CLI apps like traceroute, ping, telnet and ftp.
Practical? Maybe, but mostly as a gimmick. Of course, it can save you some typing. Anyone have any ideas for optimum usage?
We use LinkSys BEFSX41 router / gateway / firewall / VPN appliances to interconnect the LANs at three sites via VPN. Since two of the sites have DHCP-supplied WAN IP addresses, we needed a way to notify the other sites when the LinkSys' WAN IP address changes. This is required so the Remote Security Gateway's IP address for the VPN tunnel can be updated.
Since the addresses don't change that often, I wrote a script to detect any change and send email to the interested parties. If you are interested, that script is available for download (download 2KB script), and usage is explained in the script comments.
I wound up making this process harder than it actually is, so this hint is to help y'all from making the same mistakes I made. Here's the deal ... you're not at home, but need info on your Mac that is subnetted to an AirPort Base Station that has a (static) IP address.
What you'll need to know: The usual IP address the Base Station assigns to your machine (ie 10.0.1.2), which is easily found in the network system prefs. Using the AirPort Admin Utility, log into your Base Station and "Show All Settings." Click on the "Port Mapping" tab, then click "Add."
For Public and Private port, put 22 (the standard SSH port number), and for "Private Address," put in the usual IP address (ie 10.0.1.2) assigned to your machine. Click on "Update" in the lower right corner, and wait while your Base Station reboots.
Once it does (I had problems doing this remotely from a friend's Mac, so you might want to do this at home), you'll be able to log into your subnetted machine by doing the following:
Once you give your password, you're in! Using the -p command line option of ssh, and modifying the port mapping in the AirPort Admin Utility, you should be able to get access to all your wireless machines. Hope this is helpful!
[robg adds: I haven't tested this myself, though I should as it could be quite useful at times.]
Basically, this is a very easy little hint, but it saves me some time over a network here at home. If you're on a network, simply disable View -> Show Icons while in column mode. Browsing network-mounted volumes will now be much quicker.
I didn't see this listed anywhere ... but it's kind of useful for me anyways.
This isn't a revolutionary tip -- it just puts together several well-known tricks into something useful. Today I was downstairs with my iBook, and I wanted to play some music. Thanks to iTunes4, I can play all the songs in my desktop G4's library via the wireless network. That's great, because now I can keep everything in one place, and the G4 can be the music server for the entire house.
But two problems: The G4 is upstairs in my home office, and iTunes wasn't running. he easy solution is, of course, for me to get off my ass, trudge up the stairs, call up the dock, and start iTunes. Then go back downstairs and enjoy my music on the iBook. But, like any good computer geek, I'm lazy. So instead I did this:
Use ssh to log on remotely to the G4.
Give this command: open -a iTunes
Upstairs, the G4 starts up iTunes.
Log off the G4, and enjoy the music on the iBook.
In step one, I could have used telnet instead of ssh, if the G4 were set to allow it, but ssh is more secure, of course. And of course, the library will only be available if I've previously set the G4 to share its music library. Hopefully this tip will be a useful reminder to anyone as lazy as I am: You can log on remotely and use the open command to start up any app you might need.
[robg adds: Yes, it's basic, but useful and not (near as I can tell) published here before in this general form. I do a similar thing to launch VNC (a remote control client), as described in this hint.]
I have all my iTunes data on a linux NFS server, which I had previously used with a Windows box via Samba. The new iMac uses NFS to access the same data store. I found changing ID3 tags to be very, very slow compared to the Windows box. It turns out that write performance seriously lagged. smb_fs mounts performed well, but could not be automounted, so I ended up tuning the NFS settings.
The critical factor that affected performance was the number of nfsiod threads. Adding more threads means that more simultaneous NFS operations can occur at once (including read-ahead and write-behind operations). To increase this value, simply edit the file /System -> Library -> StartupItems -> NFS -> NFS, and change the line that reads:
nfsiod -n 4
Replace the 4 with 8 or more, followed by rebooting or manually killing and re-running nfsiod. You will notice an increase in throughput when writing large files. To test the speed, run the following command before and after the change:
time dd if=/dev/zero of=/mnt/home/testfile bs=16k count=16384
Going from 4 to 8 nfsiod threads resulted in write speeds going from 700k/sec to over 3.2mb/sec! Further tuning can be found by reading the Linux NFS How-To Performance Section.
Ever find it annoying that you can't rename your iDisk mounted on your desktop? Well here's a solution. In Finder click Go -> iDisk to mount the iDisk. Then open Applications -> Utilities -> Terminal. In the Terminal, type:
mv idisk_user_name new_idisk_name
Your iDisk will now disappear from the desktop. Now go to the Finder and click Go -> iDisk to re-mount your iDisk. Voila! You have just renamed your iDisk!
[robg adds: Amazingly enough, this seemed to work just fine. I haven't tested it extensively, but the disk did re-mount with the new name, and a quick copy to/from the disk worked fine. I have no idea if this will survive a logout or a restart, but I wouldn't think it would (anyone care to find out?).]
iTunes 4 lets you see how many users are connected to your shared stream, but not what they're listening to. Terminal to the rescue! Use lsof to figure out who's listening to what:
% lsof | grep mp3
% lsof | grep m4a
Etcetera, etcetera. This only works if you use filename suffixes, though. Or, if you'd just like to see everything at once, and all your music is in a central music folder, for example, "Music", do this:
% lsof | grep Music
Woot! Perhaps this will make its way into iTunes as an update at some point.
[robg adds: I chose to run this hint and the next hint separately, as they are two unique methods, and comments on both could go either direction...]
With the release of iTunes 4, interest in library sharing is growing. The iTunes Sharing preference pane tells you how many people are connected to your library, but not who they are. Here's a one-line terminal command (shown on two with the "" continuation character, so cut and paste should work) to show who is browsing your iTunes library:
If you want to kick off a specific user, all I can think to do is to add a rule to your firewall:
sudo ipfw add deny tcp from (user) to any 3689
This blocks connections from that user to your iTunes sharing port. If anyone has further ideas or wants to wrap this into a pretty app, I'd love to see it!
PS: Note that sharing your library with strangers may violate the iTunes EULA; it may or may not fall under the "personal use" that you "click agree" to when you turn on the sharing feature. Share at your own risk.