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> 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> 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> 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
>>> 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
