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
