/usr/share/doc/openslp-doc/html/faq.html is in openslp-doc 1.2.1-11.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 | <!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>
|