You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

233 lines
12 KiB

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.77C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.2 i686) [Netscape]">
<title>OpenSLP FAQ</title>
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000">
<h2>
OpenSLP - Frequently Asked Questions</h2>
<hr WIDTH="100%">
<p><tt>A really compresensive FAQ is not yet available for OpenSLP so please
send</tt>
<br><tt>your questions to the OpenSLP mailing lists:</tt>
<p><tt>&nbsp;&nbsp;&nbsp; openslp-devel@lists.sourceforge.net</tt>
<br><tt>&nbsp;&nbsp;&nbsp; openslp-users@lists.sourceforge.net</tt>
<p><tt><b>Q:</b> Where is the configure script to build OpenSLP?</tt>
<br><tt><b>A:</b> Did you read section 3 of the README?&nbsp; You need
to run autogen.sh to</tt>
<br><tt>&nbsp;&nbsp; generate the configure script.</tt>
<p><tt><b>Q:</b> How do I build OpenSLP on Windows?</tt>
<br><tt><b>A:</b> The MSVC project files used by the developers who ported
OpenSLP to win32</tt>
<br><tt>&nbsp;&nbsp; available in the source directories.&nbsp; If you
do not use MSVC and you are a</tt>
<br><tt>&nbsp;&nbsp; Windows developer, then you will be used to trying
to get MSVC makes to</tt>
<br><tt>&nbsp;&nbsp; work with your tools</tt>
<p><tt><b>Q:</b> Will OpenSLP work on my operating system</tt>
<br><tt><b>A:</b> Yes, the OpenSLP code has proven to be very portable.&nbsp;
It currently works</tt>
<br><tt>&nbsp;&nbsp; many operating systems including: Linux, BSD, Solaris,
Tru64, HPUX, UnixWare,</tt>
<br><tt>&nbsp;&nbsp; OSR5, and Win32</tt>
<p><tt><b>Q:</b> I am having trouble discovering attributes using FindAttr()
and&nbsp; "slptool</tt>
<br><tt>&nbsp;&nbsp; findattrs".&nbsp; The functions seem to execute properly,
and the services URL's</tt>
<br><tt>&nbsp;&nbsp; can be discovered, but no attributes are returned.&nbsp;
I am registering</tt>
<br><tt>&nbsp;&nbsp; services in slp.reg files. I don't think it is my
syntax in the slp.reg</tt>
<br><tt>&nbsp;&nbsp; file, because the example registrations in that file
do not return</tt>
<br><tt>&nbsp;&nbsp; attributes either.&nbsp; Can anyone help?</tt>
<br><tt><b>A:</b> If you just want to use slptool to see if things are
working, you need to</tt>
<br><tt>&nbsp;&nbsp; do the following:</tt>
<p><tt>&nbsp;&nbsp; Contents of the slp.reg:</tt>
<br><tt>&nbsp;&nbsp; ------------------------</tt>
<br><tt>&nbsp;&nbsp; service:myservice1.x://myhost.caldera.com,en,65535</tt>
<br><tt>&nbsp;&nbsp; owner=Matt Peterson</tt>
<br><tt>&nbsp;&nbsp; email=mpeterson@caldera.com</tt>
<p><tt>&nbsp;&nbsp; service:myservice1.x://yourhost.yourdomain.com,en,65535</tt>
<br><tt>&nbsp;&nbsp; owner=Kim Jackson</tt>
<br><tt>&nbsp;&nbsp; email=bjackson@yourhost.yourdomain.com</tt>
<br>&nbsp;
<p><tt>&nbsp;&nbsp; IMPORTANT: Restart slpd and check the /var/log/slpd.log
to ensure that</tt>
<br><tt>&nbsp;&nbsp; there were no errors during parsing of the .reg file</tt>
<p><tt>&nbsp;&nbsp; Use slptool to find attributes</tt>
<br><tt>&nbsp;&nbsp; ------------------------------</tt>
<br><tt>&nbsp;&nbsp; $ slptool findsrvs service:myservice1.x</tt>
<br><tt>&nbsp;&nbsp; service:myservice1.x://myhost.caldera.com.com,65535</tt>
<br><tt>&nbsp;&nbsp; service:myservice1.x://yourhost.yourdomain.com,65535</tt>
<p><tt>&nbsp;&nbsp; $ slptool findattrs service:myservice1.x://myhost.mydomain.com</tt>
<br><tt>&nbsp;&nbsp; (owner=Matt Peterson),(email=mpeterson@caldera.com)</tt>
<p><tt>&nbsp;&nbsp; $ slptool findattrs service:myservice1.x://yourhost.caldera.com</tt>
<br><tt>&nbsp;&nbsp; (owner=Kim Jackson),(email=bjackson@yourhost.yourdomain.com)</tt>
<p><tt>&nbsp;&nbsp; Note that you need to supply the service-url as returned
by findsrvs</tt>
<p><tt><b>Q:</b> I have a multi-homed machine and OpenSLP is not working.</tt>
<br><tt><b>A:</b> Please read the updated installation guide</tt>
<br><tt>&nbsp;&nbsp; <a href="http://www.openslp.org/doc/html/UsersGuide/Installation.html">http://www.openslp.org/doc/html/UsersGuide/Installation.html.</a></tt>
<br><tt>&nbsp;&nbsp; There are special instructions for users of multi-homed
machines.</tt><tt></tt>
<p><tt><b>Q:</b> In our development lab, the multicast SLP requests work
just fine.</tt>
<br><tt>&nbsp;&nbsp; However, in our SVT lab, the multicasts requests never
work.&nbsp; We always</tt>
<br><tt>&nbsp;&nbsp; have to edit the slp.conf file and turn on broadcast.&nbsp;
Have any others seen</tt>
<br><tt>&nbsp;&nbsp; this?&nbsp; Do you recall what the solution was?&nbsp;
We have spent a great deal of</tt>
<br><tt>&nbsp;&nbsp; time trying to figure this one out without success.</tt>
<br><tt><b>A: </b>Yes, others have seen this behavior -- I know I have.&nbsp;
I should put this in</tt>
<br><tt>&nbsp;&nbsp; the FAQ because I get a lot of questions.&nbsp; The
following is a list of the</tt>
<br><tt>&nbsp;&nbsp; most common problems along with trouble shooting and
resolution info:</tt><tt></tt>
<p><tt>&nbsp;&nbsp; No multicast route</tt>
<br><tt>&nbsp;&nbsp; -------------------</tt>
<br><tt>&nbsp;&nbsp; A very common problem with some OS installations (especially
Linux) is</tt>
<br><tt>&nbsp;&nbsp; that there is no multicast or default route set up.&nbsp;
On systems with BSD</tt>
<br><tt>&nbsp;&nbsp; derived TCP/IP stacks (nearly all OSes), broadcast
and multicast traffic</tt>
<br><tt>&nbsp;&nbsp; are delivered using the unicast routing table.&nbsp;
If the unicast routing</tt>
<br><tt>&nbsp;&nbsp; table does not have either a default route or an explicit
multicast route,</tt>
<br><tt>&nbsp;&nbsp; then the kernel does not know where to send the SLP
datagram and returns</tt>
<br><tt>&nbsp;&nbsp; an error 101 - network unreachable error which translates
into a SLPError</tt>
<br><tt>&nbsp;&nbsp; -23 SLP_NETWORK_ERROR. A quick test is to try to ping
SLP multicast:</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; $ ping 239.255.255.253</tt><tt></tt>
<p><tt>&nbsp;&nbsp; If ping returns an error that the network was unreachable,
you will need</tt>
<br><tt>&nbsp;&nbsp; to set up a default route or a multicast route.</tt>
<br><tt>&nbsp;</tt>
<br><tt>&nbsp;&nbsp; Note you may not get any responses to the ping.&nbsp;
This may not indicate</tt>
<br><tt>&nbsp;&nbsp; a problem.&nbsp; The only thing to be concerned about
is if there is an error</tt>
<br><tt>&nbsp;&nbsp; actually sending the ping.</tt>
<br><tt>&nbsp;</tt>
<br><tt>&nbsp;&nbsp; Please read the installation instructions for more
information on how</tt>
<br><tt>&nbsp;&nbsp; to install a multicast route:</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; http://www.openslp.org/doc/html/UsersGuide/Installation.html</tt><tt></tt>
<p><tt>&nbsp;</tt>
<br><tt>&nbsp;&nbsp; The "smart switch /stupid router" problem</tt>
<br><tt>&nbsp;&nbsp; ------------------------------------------</tt>
<br><tt>&nbsp;&nbsp; The smart switch / stupid router (or no router) problem
is something that</tt>
<br><tt>&nbsp;&nbsp; happens on switched ethernet networks only.&nbsp;
If you do not have a</tt>
<br><tt>&nbsp;&nbsp; switched ethernet network, then you do not have this
problem.&nbsp; If you do</tt>
<br><tt>&nbsp;&nbsp; have a switched ethernet network, then you may have
this problem if you</tt>
<br><tt>&nbsp;&nbsp; are using newer switching hardware.&nbsp; The reason
is that ethernet</tt>
<br><tt>&nbsp;&nbsp; switching hardware is smart enough to monitor IGMP
traffic and only</tt>
<br><tt>&nbsp;&nbsp; forward multicast ethernet frames to those ports that
are connected to a</tt>
<br><tt>&nbsp;&nbsp; host that has maintained the appropriate IGMP conversations
with the</tt>
<br><tt>&nbsp;&nbsp; router.</tt><tt></tt>
<p><tt>&nbsp;&nbsp; At a very high level, IGMP works like this.&nbsp; First,
the host joins the</tt>
<br><tt>&nbsp;&nbsp; multicast group by sending the router an IGMP message.&nbsp;
The router</tt>
<br><tt>&nbsp;&nbsp; responds periodically with request to the host to
see if the host is</tt>
<br><tt>&nbsp;&nbsp; still interested in multicast traffic.&nbsp; Since
IGMP conversations are</tt>
<br><tt>&nbsp;&nbsp; handled transparently by the kernel level IP stack
implementations, most</tt>
<br><tt>&nbsp;&nbsp; developers and users do not even realize anything
is happening.</tt><tt></tt>
<p><tt>&nbsp;&nbsp; However, "smart" ethernet switches do realize something
is happening!</tt>
<br><tt>&nbsp;&nbsp; If they do not see the IGMP messages being sent from
the router to a host</tt>
<br><tt>&nbsp;&nbsp; that is plugged into a given port of the switch, then
they will will not</tt>
<br><tt>&nbsp;&nbsp; forward multicast ethernet frames to that port.&nbsp;
This is good and bad.</tt>
<br><tt>&nbsp;&nbsp; It is good because it makes multicast extremely efficient
in terms of</tt>
<br><tt>&nbsp;&nbsp; physical network usage.&nbsp; However, it also makes
it so multicast will not</tt>
<br><tt>&nbsp;&nbsp; work at all if a router does not exist (or does not
support IGMP) to</tt>
<br><tt>&nbsp;&nbsp; maintain it's end of the IGMP conversation.</tt><tt></tt>
<p><tt>&nbsp;&nbsp; Trouble Shooting:</tt><tt></tt>
<p><tt>&nbsp;&nbsp; Monitor IGMP traffic!&nbsp; Make sure that periodic
IGMP traffic is happening</tt>
<br><tt>&nbsp;&nbsp; on your network.&nbsp; IGMP traffic can be monitored
on Linux (and many other</tt>
<br><tt>&nbsp;&nbsp; OSes) with the following command:</tt>
<br><tt>&nbsp;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; # tcpdump igmp</tt><tt></tt>
<p><tt>&nbsp;&nbsp; Issue this command before starting slpd.&nbsp; You
will notice that several</tt>
<br><tt>&nbsp;&nbsp; IGMP "report" messages are sent.&nbsp; The important
thing to look for a IGMP</tt>
<br><tt>&nbsp;&nbsp; "query" message from the router.&nbsp; If you do not
see the IGMP query</tt>
<br><tt>&nbsp;&nbsp; message from the router then you will soon find that
you will no longer</tt>
<br><tt>&nbsp;&nbsp; see any "report" messages either.</tt><tt></tt>
<p><tt>&nbsp;&nbsp; Another good test is to try to ping the multicast address
and see where</tt>
<br><tt>&nbsp;&nbsp; it is visable.</tt>
<br><tt>&nbsp;</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; $ ping 239.255.255.253</tt><tt></tt>
<p><tt>&nbsp;&nbsp; Finally, the best advice is to read the normally untouched
section of</tt>
<br><tt>&nbsp;&nbsp; your ethernet switch manual that describes how the
switch handles</tt>
<br><tt>&nbsp;&nbsp; multicast.&nbsp; Stupid/inexpensive switches treat
multicast frames exactly</tt>
<br><tt>&nbsp;&nbsp; like broadcast frames which means that they are forwarded
to every port</tt>
<br><tt>&nbsp;&nbsp; of the switch.&nbsp; Smart/Expensive switches often
allow this behavior to be</tt>
<br><tt>&nbsp;&nbsp; configured.&nbsp; If you are on a network without
a router, then it is</tt>
<br><tt>&nbsp;&nbsp; possible that you might need to "dumb down" your switch.</tt><tt></tt>
<p><tt>&nbsp;&nbsp; Broken NIC driver</tt>
<br><tt>&nbsp;&nbsp; ------------------</tt>
<br><tt>&nbsp;&nbsp; Some NICs do not support multicast operation, so the
driver does the</tt>
<br><tt>&nbsp;&nbsp; work by&nbsp; placing the NIC into permiscuous mode
(accept everything) then</tt>
<br><tt>&nbsp;&nbsp; the driver filters out what is not needed.&nbsp; The
problem with this is</tt>
<br><tt>&nbsp;&nbsp; that sometimes on a very busy ethernet, the NIC buffers
may not be able</tt>
<br><tt>&nbsp;&nbsp; to keep up with all the traffic and some frames will
be dropped.&nbsp; This</tt>
<br><tt>&nbsp;&nbsp; is normally not a problem since SLP is designed to
work on unreliable</tt>
<br><tt>&nbsp;&nbsp; physical networks, but if enough frames are dropped,
OpenSLP may not</tt>
<br><tt>&nbsp;&nbsp; be able to find DAs or other services.&nbsp; This
would result in erratic</tt>
<br><tt>&nbsp;&nbsp; behavior.</tt>
<br><tt></tt>&nbsp;
<br><tt></tt>&nbsp;
<br>&nbsp;
</body>
</html>