Server Location Protocol (SLP)

Symptom:

I always forget how to check for proper functioning of the Server Location Protocol (SLP). Here's an aide-memoire.

Howto:

The purpose of SLP is, service daemons register their service and port on their own host's slpd. Clients send a multicast query for a service and receive responses from slpd on each host where that service is registered. This involves a timeout; default is 5 seconds.

SLP uses port 427/udp and tcp under the name svrloc. Normally it uses multicast UDP. See below for the special handling needed if you have a network bridge.

To check operation of SLP, use these commands:

• To determine the service types registered anywhere, do:

  slptool findsrvtypes

  service:service-agent refers to the SLP service itself, and is not listed in the output of findsrvtypes.

• To get a list of server URLS for each service, use this command. It is reported in the form of a URL prefixed with service:. Following is comma and an integer; this is some kind of priority and on my system they're mostly the same. I think lower is preferred over higher numbers.

  slptool findsrvs service:$SRV #for example:
  slptool findsrvs service:printer

These are the services registered on my network, showing the response from slptool. (All) means that all hosts respond; otherwise only certain hosts provide the service.

• Service-agent: service:service-agent://192.9.200.193,65535 (all; numeric IP, no port specified)
• SSH: service:ssh://iris.cft.ca.us:22,65535 (Secure Shell) (all)
• FISH: service:fish://iris.cft.ca.us:22,65535 (mount SSH filesystem) (all)
• NTP: service:ntp://iris.cft.ca.us:123,65535 (Network Time Protocol) (all)
• Domain: service:domain://iris.cft.ca.us:53,65535 (Domain Name Service, DNS) (all)
• LDAP: service:ldap://jacinth.cft.ca.us,65535 (master sites, port not specified)
• LDAPS: service:ldaps://jacinth.cft.ca.us,65535 (master sites, port not specified) (using deprecated intrinsic TLS without STARTTLS)
• SMB: service:smb://jacinth.cft.ca.us,65535 (Samba, CIFS, Windows filesystem from UNIX; port not specified)
• Printer: service:printer:ipp://diamond.cft.ca.us:631/printers/lp2-color,270 (Each printer is reported on a separate line. The real URL starts with ipp and this URL can be given to an IPP-aware print client to get service, minus the comma and ranking.)
• Scanner.sane: service:scanner.sane://diamond.cft.ca.us:6566,65535 (remote document scanner protocol)

Many of my machines have a network bridge, for hostapd (802.11) support and for virtual machines. For SLP to work you need to tweak the bridge's configuration, as follows. I put this in a boot script so it happens automatically.

• Multicast router mode values: 0 = no multicast, 1 (default) = detect subscriptions on each interface; 2 = send multicasts to all bridged devices.

  echo 2 > /sys/class/net/br0/bridge/multicast_router

• Pick one host to send multicast queries, which keep neighbors informed of subscriptions. Otherwise they time out.

  echo 1 > /sys/class/net/br0/bridge/multicast_querier

• IEEE 802.11 handles multicast poorly. The wireless host can send multicast packets and the router (Linux box running hostapd) can re-send them to the wired network, but multicast packets sent from the wired network do not make it to the client. However, when the wireless client makes a query the servers will use unicast UDP to respond, and the client should receive them. But a SLP server on a wireless machine cannot hear multicast queries.

Multicast DNS (mdns on port 5353) offers very similar information, and in fact slpd and avahi-daemon I think were developed coordinately by the same person, Lennart Poettering. Do:

dig @$HOST -p 5353 _services._dns-sd._udp.local. PTR

It will give you a list of PTRs to both UDP and TCP services. (_services._dns-sd._tcp.local. gives nothing.) Dig for one of the referents such as _ssh._tcp.local. You get a PTR to the same on a specific host (the one whose mdns server you're using), e.g. jacinth._ssh._tcp.local. The mdns server will gratuitously include all the payload records for it, which in this case is a TXT (content "") and a SVR (0 0 22 jacinth.local.) plus the "A" and two AAAA records for jacinth.local.

Here are some variants on the @$HOST option:

• Omit it; the server listed in /etc/resolv.conf will be used.
• Localhost and its IP addresses: This kind of network has no MDNS service, the query will be dropped and dig will time out.
• Hostname or nonlocal IPv4 or IPv6 address of this or another host: The daemon gets the query and replies.
• Special case on a multi-homed host: if you direct your query to the address that will actually be used for the reply, it works, but if to the other address, dig will toss answers from addresses it did not send to, with an error message.
• Multicast 224.0.0.251: dig will toss answers from other IPv4 addresses, i.e. actual hosts with information.
• Multicast ff02::fb : This time it works, and the local host almost certainly will be the first one to answer.