I guess I was thinking about the line that talks about the destination
port for all SLP messages... personally, I consider a reply an SLP
message! :)
There's not much I can set in my client... it's using the LiveTribe Java
SLP package for the User Agent, and (like OpenSLP) it pretty much only
lets me set the port for SLP or Notification messages. Defaults for them
are the standard 427 and 1847, and I've changed the SLP port to match
the port I'm using on the slpd server (44441). Maybe it's time to look
at the OpenSLP Java client instead... but if it's written to the rfc it
would have the same issue.
I can see where the rfc says to send replies and acks on the port from
which they were received. But since those replies are not from a
connected socket, that doesn't appear to make it very firewall
friendly... unless I'm missing something.
I'm now curious... how do other folks deal with SLP for their firewall
config? Do they not use firewalls on each machine? Or just open both src
and dest SLP ports?
Once again, thanks for taking the time to look at this!
Steve
On 01/10/2012 11:17 AM, Nick Wagner wrote:
Ok, looking at the first paragraph I think I misused "requests" and
"responses" a few times. What I meant to say was that if all clients
must listen to the SLP port to receive a response to their request, on
a single machine all client applications must listen on the same UDP
socket. That would require the client functionality to live in the
service/daemon.
On Tue, Jan 10, 2012 at 10:12 AM, Nick Wagner <ne...@wingedbeast.org
<mailto:ne...@wingedbeast.org>> wrote:
Is there any way you can force the client to use a port? Using
the SLP port for client reception would require that all client
responses are forwarded through a service/daemon, because there
can be only one socket receiving those requests and multiple apps
on the machine may need to perform requests. That's the reason the
SA & DA functionality is in a service.
The section I'm referring to is 6.1 in RFC 2608. I can see how it
might be slightly ambiguous, as it states that the SLP port is the
destination port for all SLP messages, but a following sentence
clarifies how replies are acknowledgements are to be sent.
--Nick
On Mon, Jan 9, 2012 at 7:10 PM, Steve Soloski <ssolo...@kynen.com
<mailto:ssolo...@kynen.com>> wrote:
Hi Nick,
The only problem with that is that the client will pick random
ports for sending out it's messages. For example, in the
snippet from below the AttrRqst message went out on port
47672, so that was the destination port for the AttrRply
message. In other testing, I've seen various ports used for
sending from the client... which makes sense. However, since
this happens, I can't see any way - other than opening the
firewall on the source port - that will let inbound server
messages come in by just opening on a destination port.
I'll look again, but I don't remember seeing that the replies
are sent to the to requesting port... if a connection has been
made between client and server, I could understand that. But
since the request is being made Multicast (ie connectionless)
and the reply is Unicast, I'm not sure how going back to that
same (random) port would be a good thing - at least from a
firewall perspective.
Thanks for a quick reply, though!
Steve
On 01/09/2012 07:16 PM, Nick Wagner wrote:
OpenSLP does make use of existing UDP sockets for sending
responses, so you're right that the source port is the same
as the multicast destination. But I don't think that's
really the issue here. From my reading of the SLP spec,
replies and acknowledgements are sent to the port from which
the request was issued. So it makes sense to me that the
responses have the destination ports listed.
Could you configure the firewall to open the ports used by
the clients for receiving as well?
--Nick
On Mon, Jan 9, 2012 at 1:32 PM, Steve Soloski
<ssolo...@kynen.com <mailto:ssolo...@kynen.com>> wrote:
I'm running slpd (from OpenSLP 20.0 beta 2) and am having
an issue with
my Fedora 15 firewall; I think it's a problem with
OpenSLP but I wanted
to get some input first.
My client is a Java app running LiveTribe SLP; I've
changed my SLP port
from the default of 427 to 44441 due to Linux security
issues. My client
is at address 10.18.60.108, the slpd server is at address
10.18.60.151.
My firewall has ports 44440-44442 open, 44441 for SLP and
the other two
for other client app usage.
When I start up my client app, Wireshark shows me the
following trace
(some messages deleted for clarity):
No. Source Destination Protocol Info
5 10.18.60.108 239.255.255.253 UDP Source port:
44442
Destination port: 44441
6 10.18.60.151 10.18.60.108 UDP Source port:
44441
Destination port: 44442
9 10.18.60.108 239.255.255.253 UDP Source port:
47672
Destination port: 44441
10 10.18.60.151 10.18.60.108 UDP Source port:
44441
Destination port: 47672
11 10.18.60.108 10.18.60.151 ICMP Destination
unreachable
(Host administratively prohibited)
Line 5 is the clients SrvRqst message, looking for a
specific service on
the server. On line 6, the server responds with a SrvRply
message,
indicating that the service was found. Line 9 is the
client asking for
the services attributes with an AttrRqst message, the
server replies on
line 10 with an AttrRply message. So far, so good - I
found the service,
and got it's attributes... but then come the firewall.
When I open a firewall port using system-config-firewall,
Fedora opens
the destination port, which makes sense... I wouldn't
want to have my
ports open based on the messages source port. So, if you
look at the
above, shouldn't the replies from the server - lines 6 an
10 - have
their destination port set to 44441 instead of their
source port? That
is the port that I'm using for my SLP messages, and the
port that I
(ultimately) want to open on my client. If I only had
port 44441 open, I
would have blocked all of the messages coming back from
the server... as
evidenced in what happens on line 11, when the server has
sent back the
attributes. If all of those messages from the server were
sent to a
destination port of 44441, then everything would work.
It appears that slpd is responding on the same socket
that it got the
incoming message on, rather than on an outgoing socket
for slp messages.
It appears that the way slpd is currently my firewall is
pretty useless.
Am I missing something here?
Any enlightenment would be appreciated! :)
Steve
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you
don't need a complex
infrastructure or vast IT resources to deliver seamless,
secure access to
virtual desktops. With this all-in-one solution, easily
deploy virtual
desktops for less than the cost of PCs and save 60% on
VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Openslp-users mailing list
Openslp-users@lists.sourceforge.net
<mailto:Openslp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/openslp-users
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Openslp-users mailing list
Openslp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-users
