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
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> openslp-devel@lists.sourceforge.net</tt>
|
|
<br><tt> 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? You need
|
|
to run autogen.sh to</tt>
|
|
<br><tt> 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> available in the source directories. If you
|
|
do not use MSVC and you are a</tt>
|
|
<br><tt> Windows developer, then you will be used to trying
|
|
to get MSVC makes to</tt>
|
|
<br><tt> 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.
|
|
It currently works</tt>
|
|
<br><tt> many operating systems including: Linux, BSD, Solaris,
|
|
Tru64, HPUX, UnixWare,</tt>
|
|
<br><tt> OSR5, and Win32</tt>
|
|
<p><tt><b>Q:</b> I am having trouble discovering attributes using FindAttr()
|
|
and "slptool</tt>
|
|
<br><tt> findattrs". The functions seem to execute properly,
|
|
and the services URL's</tt>
|
|
<br><tt> can be discovered, but no attributes are returned.
|
|
I am registering</tt>
|
|
<br><tt> services in slp.reg files. I don't think it is my
|
|
syntax in the slp.reg</tt>
|
|
<br><tt> file, because the example registrations in that file
|
|
do not return</tt>
|
|
<br><tt> attributes either. 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> do the following:</tt>
|
|
<p><tt> Contents of the slp.reg:</tt>
|
|
<br><tt> ------------------------</tt>
|
|
<br><tt> service:myservice1.x://myhost.caldera.com,en,65535</tt>
|
|
<br><tt> owner=Matt Peterson</tt>
|
|
<br><tt> email=mpeterson@caldera.com</tt>
|
|
<p><tt> service:myservice1.x://yourhost.yourdomain.com,en,65535</tt>
|
|
<br><tt> owner=Kim Jackson</tt>
|
|
<br><tt> email=bjackson@yourhost.yourdomain.com</tt>
|
|
<br>
|
|
<p><tt> IMPORTANT: Restart slpd and check the /var/log/slpd.log
|
|
to ensure that</tt>
|
|
<br><tt> there were no errors during parsing of the .reg file</tt>
|
|
<p><tt> Use slptool to find attributes</tt>
|
|
<br><tt> ------------------------------</tt>
|
|
<br><tt> $ slptool findsrvs service:myservice1.x</tt>
|
|
<br><tt> service:myservice1.x://myhost.caldera.com.com,65535</tt>
|
|
<br><tt> service:myservice1.x://yourhost.yourdomain.com,65535</tt>
|
|
<p><tt> $ slptool findattrs service:myservice1.x://myhost.mydomain.com</tt>
|
|
<br><tt> (owner=Matt Peterson),(email=mpeterson@caldera.com)</tt>
|
|
<p><tt> $ slptool findattrs service:myservice1.x://yourhost.caldera.com</tt>
|
|
<br><tt> (owner=Kim Jackson),(email=bjackson@yourhost.yourdomain.com)</tt>
|
|
<p><tt> 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> <a href="http://www.openslp.org/doc/html/UsersGuide/Installation.html">http://www.openslp.org/doc/html/UsersGuide/Installation.html.</a></tt>
|
|
<br><tt> 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> However, in our SVT lab, the multicasts requests never
|
|
work. We always</tt>
|
|
<br><tt> have to edit the slp.conf file and turn on broadcast.
|
|
Have any others seen</tt>
|
|
<br><tt> this? Do you recall what the solution was?
|
|
We have spent a great deal of</tt>
|
|
<br><tt> 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.
|
|
I should put this in</tt>
|
|
<br><tt> the FAQ because I get a lot of questions. The
|
|
following is a list of the</tt>
|
|
<br><tt> most common problems along with trouble shooting and
|
|
resolution info:</tt><tt></tt>
|
|
<p><tt> No multicast route</tt>
|
|
<br><tt> -------------------</tt>
|
|
<br><tt> A very common problem with some OS installations (especially
|
|
Linux) is</tt>
|
|
<br><tt> that there is no multicast or default route set up.
|
|
On systems with BSD</tt>
|
|
<br><tt> derived TCP/IP stacks (nearly all OSes), broadcast
|
|
and multicast traffic</tt>
|
|
<br><tt> are delivered using the unicast routing table.
|
|
If the unicast routing</tt>
|
|
<br><tt> table does not have either a default route or an explicit
|
|
multicast route,</tt>
|
|
<br><tt> then the kernel does not know where to send the SLP
|
|
datagram and returns</tt>
|
|
<br><tt> an error 101 - network unreachable error which translates
|
|
into a SLPError</tt>
|
|
<br><tt> -23 SLP_NETWORK_ERROR. A quick test is to try to ping
|
|
SLP multicast:</tt><tt></tt>
|
|
<p><tt> $ ping 239.255.255.253</tt><tt></tt>
|
|
<p><tt> If ping returns an error that the network was unreachable,
|
|
you will need</tt>
|
|
<br><tt> to set up a default route or a multicast route.</tt>
|
|
<br><tt> </tt>
|
|
<br><tt> Note you may not get any responses to the ping.
|
|
This may not indicate</tt>
|
|
<br><tt> a problem. The only thing to be concerned about
|
|
is if there is an error</tt>
|
|
<br><tt> actually sending the ping.</tt>
|
|
<br><tt> </tt>
|
|
<br><tt> Please read the installation instructions for more
|
|
information on how</tt>
|
|
<br><tt> to install a multicast route:</tt><tt></tt>
|
|
<p><tt> http://www.openslp.org/doc/html/UsersGuide/Installation.html</tt><tt></tt>
|
|
<p><tt> </tt>
|
|
<br><tt> The "smart switch /stupid router" problem</tt>
|
|
<br><tt> ------------------------------------------</tt>
|
|
<br><tt> The smart switch / stupid router (or no router) problem
|
|
is something that</tt>
|
|
<br><tt> happens on switched ethernet networks only.
|
|
If you do not have a</tt>
|
|
<br><tt> switched ethernet network, then you do not have this
|
|
problem. If you do</tt>
|
|
<br><tt> have a switched ethernet network, then you may have
|
|
this problem if you</tt>
|
|
<br><tt> are using newer switching hardware. The reason
|
|
is that ethernet</tt>
|
|
<br><tt> switching hardware is smart enough to monitor IGMP
|
|
traffic and only</tt>
|
|
<br><tt> forward multicast ethernet frames to those ports that
|
|
are connected to a</tt>
|
|
<br><tt> host that has maintained the appropriate IGMP conversations
|
|
with the</tt>
|
|
<br><tt> router.</tt><tt></tt>
|
|
<p><tt> At a very high level, IGMP works like this. First,
|
|
the host joins the</tt>
|
|
<br><tt> multicast group by sending the router an IGMP message.
|
|
The router</tt>
|
|
<br><tt> responds periodically with request to the host to
|
|
see if the host is</tt>
|
|
<br><tt> still interested in multicast traffic. Since
|
|
IGMP conversations are</tt>
|
|
<br><tt> handled transparently by the kernel level IP stack
|
|
implementations, most</tt>
|
|
<br><tt> developers and users do not even realize anything
|
|
is happening.</tt><tt></tt>
|
|
<p><tt> However, "smart" ethernet switches do realize something
|
|
is happening!</tt>
|
|
<br><tt> If they do not see the IGMP messages being sent from
|
|
the router to a host</tt>
|
|
<br><tt> that is plugged into a given port of the switch, then
|
|
they will will not</tt>
|
|
<br><tt> forward multicast ethernet frames to that port.
|
|
This is good and bad.</tt>
|
|
<br><tt> It is good because it makes multicast extremely efficient
|
|
in terms of</tt>
|
|
<br><tt> physical network usage. However, it also makes
|
|
it so multicast will not</tt>
|
|
<br><tt> work at all if a router does not exist (or does not
|
|
support IGMP) to</tt>
|
|
<br><tt> maintain it's end of the IGMP conversation.</tt><tt></tt>
|
|
<p><tt> Trouble Shooting:</tt><tt></tt>
|
|
<p><tt> Monitor IGMP traffic! Make sure that periodic
|
|
IGMP traffic is happening</tt>
|
|
<br><tt> on your network. IGMP traffic can be monitored
|
|
on Linux (and many other</tt>
|
|
<br><tt> OSes) with the following command:</tt>
|
|
<br><tt> </tt>
|
|
<br><tt> # tcpdump igmp</tt><tt></tt>
|
|
<p><tt> Issue this command before starting slpd. You
|
|
will notice that several</tt>
|
|
<br><tt> IGMP "report" messages are sent. The important
|
|
thing to look for a IGMP</tt>
|
|
<br><tt> "query" message from the router. If you do not
|
|
see the IGMP query</tt>
|
|
<br><tt> message from the router then you will soon find that
|
|
you will no longer</tt>
|
|
<br><tt> see any "report" messages either.</tt><tt></tt>
|
|
<p><tt> Another good test is to try to ping the multicast address
|
|
and see where</tt>
|
|
<br><tt> it is visable.</tt>
|
|
<br><tt> </tt>
|
|
<br><tt> $ ping 239.255.255.253</tt><tt></tt>
|
|
<p><tt> Finally, the best advice is to read the normally untouched
|
|
section of</tt>
|
|
<br><tt> your ethernet switch manual that describes how the
|
|
switch handles</tt>
|
|
<br><tt> multicast. Stupid/inexpensive switches treat
|
|
multicast frames exactly</tt>
|
|
<br><tt> like broadcast frames which means that they are forwarded
|
|
to every port</tt>
|
|
<br><tt> of the switch. Smart/Expensive switches often
|
|
allow this behavior to be</tt>
|
|
<br><tt> configured. If you are on a network without
|
|
a router, then it is</tt>
|
|
<br><tt> possible that you might need to "dumb down" your switch.</tt><tt></tt>
|
|
<p><tt> Broken NIC driver</tt>
|
|
<br><tt> ------------------</tt>
|
|
<br><tt> Some NICs do not support multicast operation, so the
|
|
driver does the</tt>
|
|
<br><tt> work by placing the NIC into permiscuous mode
|
|
(accept everything) then</tt>
|
|
<br><tt> the driver filters out what is not needed. The
|
|
problem with this is</tt>
|
|
<br><tt> that sometimes on a very busy ethernet, the NIC buffers
|
|
may not be able</tt>
|
|
<br><tt> to keep up with all the traffic and some frames will
|
|
be dropped. This</tt>
|
|
<br><tt> is normally not a problem since SLP is designed to
|
|
work on unreliable</tt>
|
|
<br><tt> physical networks, but if enough frames are dropped,
|
|
OpenSLP may not</tt>
|
|
<br><tt> be able to find DAs or other services. This
|
|
would result in erratic</tt>
|
|
<br><tt> behavior.</tt>
|
|
<br><tt></tt>
|
|
<br><tt></tt>
|
|
<br>
|
|
</body>
|
|
</html>
|