Westwind Computing
 206-522-3530
 Sales Information
 Customer Feedback
Westwind Computing
[New to Westwind?]  [Customers]  [News & Information] 



Reference


Mac OS X: Removing Spurious SLP Entries

The Problem

Mac OS X sometimes sees duplicate and/or invalid listings of servers in the "Local Network" (e.g. in the Finder's Connect to Server dialog box).

The Cause of the Problem

Mac OS X uses a protocol named SLP (Service Location Protocol) to find out what services are available on the local network, and how to connect to them. For example, when you use the Finder's "Connect to Server" feature, and select "Local Network", it lists all servers on the local network that advertise themselves with SLP.

Unfortunately, the list of servers being advertised over SLP doesn't always correspond with what's actually out there. It's fairly common (especially when file serving is enabled on client computers that get their addresses via DHCP) for the list to have some servers listed several times, and for some (or all) of the entries to have invalid network addresses attached (so if you try to connect to them, it can't actually reach them).

The root cause of the problem is that the SLP listings aren't being kept up to date. If a computer's IP address changes (i.e. because the DHCP server assigned it a new address), it may not stop advertising its services under the old address. It also may not start advertising its new address; if it does, you get duplicate listings, only one of which works; if it doesn't, you have just one entry, but it doesn't work. If this sort of thing happens repeatedly, you can wind up with an arbitrarily large number of invalid listings, and (if you're lucky) only one valid one.

The Workarounds

I haven't found a way to completely avoid the problem (other than putting all computers that provide any kind of service at static IP addresses), but the spurious listings can at least be purged by hand.

What you need to do is track down each computer that's advertising itself incorrectly, and force it to rebuild its SLP registration list. The cleanest way I've found is to delete the list (kept in the file /private/var/slp.regfile) and then reboot the computer.

This file's permissions are set so that no normal user can mess with it - you need root access to delete it. One possibility is to enable your root account (see Apple's knowledge base article #106290), log in as root, and do the dirty deed. But logging in as root tends to be dangerous (it's easy to destroy something you didn't intend to), and isn't generally recommended. It's much better to give yourself root access just long enough to delete the file, then go right back to normal. You can do this on the command line by using the sudo command. When you're logged into the computer as someone with administrative access, open the Terminal and enter the command:

sudo rm /private/var/slp.regfile
It'll probably give you a short speil about acting responsibly (it does that the first time you use sudo), and ask for your password (just to make sure you're really you). If it takes the password and doesn't give any error, reboot the computer.

At this point, you should be done (at least with that particular computer). It's a good idea to check the Local Network to make sure the spurious entries for that computer are gone; if not, something went wrong somewhere.

If possible, you might also want to reconfigure your DHCP server to use longer lease times on the addresses it hands out, or to otherwise prevent it from switching the clients around so fast. This won't prevent the problem from reapearing, but it should at least slow it down.

Additional Notes

If you're feeling adventurous, you can try editing the slp.regfile to remove just the spurious entries. It's a text file, with a series of entries seperated by blank lines. But you'll still need to reboot, and the valid entries will get rebuilt at reboot, so there's not much point to this.

It may also be possible to reset the SLP services without rebooting; I've experimented a but (mainly by using kill -HUP on various system daemons, but haven't been able to get this approach to work reliably. If you figure it out, please let me know...

Home | Specials | Products | Education | About Us | Services | Training | Support | Reference | Events | How-to
   Copyright © 2000-2004 Westwind Computing