openslp-users — user issues and questions

Re: [Openslp-users] attach to device failed

[Nick W. <ne...@wi...>]

I'm afraid I don't have the expertise to critique your three workarounds.
 Does anyone else on the list care to comment?  My typical approach to
these sorts of problems is usually to a) patch the application to handle
network changes, b) have something on the system detect the network changes
and do the appropriate application restarts, or c) make sure everything
starts late enough that there's an address and let the user restart the app
if they change the machine's address.

--Nick

On Mon, Apr 2, 2012 at 7:01 AM, Ryan Raasch <rya...@gm...> wrote:

> On 1 April 2012 19:48, Nick Wagner <ne...@wi...> wrote:
> >>
> >> Yea, you are kinda' right. I want the daemon to listen on any and all
> >> interfaces
> >> ie. 0.0.0.0. But it seems that when the slp daemon starts up, and there
> is
> >> not
> >> default gw, the multicast setup fails. This is probably a fundamental
> >> misunderstanding
> >> on my part. If multicast needs a default route when any interface is
> >> used, that means
> >> that only one interface sends out the IGMP group join stuff. That
> >> would mean only
> >> one interface sends the service multicast packets (our is only a SA).
> >> What am i doing
> >> wrong, or do I just misunderstand the problem?
> >>
> >
> > Sockets that want to send multicast over a particular network interface
> must
> > set a socket option to send over that interface.  Otherwise, the stack
> will
> > only send it out whatever network interface it considers the
> > primary/default.  And the socket option (IP_MULTICAST_IF) takes an ip
> > address,  although I have no idea if that preference "sticks" if the
> > interface changes its address subsequent to the setsockopt.   I've never
> > tried to do any of this with 0.0.0.0, it could be that it just fails.
> >
> Ok. I think i have an understanding of the startup. The daemon starts up,
> and
> must send out IGMP join requests on the interfaces. If the 0.0.0.0 is
> given, then
> the kernel just chooses the default route, and sends it. That is why when
> our
> system does not yet have the default route setup, the mulicast setup fails.
>
> BTW, our concerns are about restarting the slp daemon. In an small system,
> there are always ewww responses, when a daemon needs to be restarted.
> I know most don't see an issue with this, but there could be blocking
> issues with restarting the damon (using system()).
>
> > I don't know anything about your device/product, but is there a point in
> > your device that you know it has the necessary ip addresses?  Either via
> > moving the daemon startup in rc.d, or using whatever watchdogs your
> device
> > may have?  And is slpd the only program on your device that has this
> sort of
> > ip address issue?
>
> The difference would be that most daemons only listen, where the slp needs
> to
> register itself, ie. send data to a multicast address.
>
> I have guessed 3 "possible" work-arounds to this.
>
> 1. Is there a way to setup a routing rule with iptables or equivalent,
> to forward
> multicast addresses from the loopback interface?
>
> 2. Some type of simple userspace daemon which listens to loopback multicast
> and then forwards the traffic to the interfaces. Of course, this is a
> thought without
> reading the slp protocol in depth :-P
>
> 3. Allow SIG_HUP to call re-initialize network also (opposite to
> HandleSigTerm())
>  without exiting daemon.
>
> /Ryan
>
> >
> > --Nick
>

Re: [Openslp-users] attach to device failed

[Ryan R. <rya...@gm...>]

On 1 April 2012 19:48, Nick Wagner <ne...@wi...> wrote:
>>
>> Yea, you are kinda' right. I want the daemon to listen on any and all
>> interfaces
>> ie. 0.0.0.0. But it seems that when the slp daemon starts up, and there is
>> not
>> default gw, the multicast setup fails. This is probably a fundamental
>> misunderstanding
>> on my part. If multicast needs a default route when any interface is
>> used, that means
>> that only one interface sends out the IGMP group join stuff. That
>> would mean only
>> one interface sends the service multicast packets (our is only a SA).
>> What am i doing
>> wrong, or do I just misunderstand the problem?
>>
>
> Sockets that want to send multicast over a particular network interface must
> set a socket option to send over that interface.  Otherwise, the stack will
> only send it out whatever network interface it considers the
> primary/default.  And the socket option (IP_MULTICAST_IF) takes an ip
> address,  although I have no idea if that preference "sticks" if the
> interface changes its address subsequent to the setsockopt.   I've never
> tried to do any of this with 0.0.0.0, it could be that it just fails.
>
Ok. I think i have an understanding of the startup. The daemon starts up, and
must send out IGMP join requests on the interfaces. If the 0.0.0.0 is
given, then
the kernel just chooses the default route, and sends it. That is why when our
system does not yet have the default route setup, the mulicast setup fails.

BTW, our concerns are about restarting the slp daemon. In an small system,
there are always ewww responses, when a daemon needs to be restarted.
I know most don't see an issue with this, but there could be blocking
issues with restarting the damon (using system()).

> I don't know anything about your device/product, but is there a point in
> your device that you know it has the necessary ip addresses?  Either via
> moving the daemon startup in rc.d, or using whatever watchdogs your device
> may have?  And is slpd the only program on your device that has this sort of
> ip address issue?

The difference would be that most daemons only listen, where the slp needs to
register itself, ie. send data to a multicast address.

I have guessed 3 "possible" work-arounds to this.

1. Is there a way to setup a routing rule with iptables or equivalent,
to forward
multicast addresses from the loopback interface?

2. Some type of simple userspace daemon which listens to loopback multicast
and then forwards the traffic to the interfaces. Of course, this is a
thought without
reading the slp protocol in depth :-P

3. Allow SIG_HUP to call re-initialize network also (opposite to
HandleSigTerm())
  without exiting daemon.

/Ryan

>
> --Nick

Re: [Openslp-users] attach to device failed

[Nick W. <ne...@wi...>]

>
>
> Yea, you are kinda' right. I want the daemon to listen on any and all
> interfaces
> ie. 0.0.0.0. But it seems that when the slp daemon starts up, and there is
> not
> default gw, the multicast setup fails. This is probably a fundamental
> misunderstanding
> on my part. If multicast needs a default route when any interface is
> used, that means
> that only one interface sends out the IGMP group join stuff. That
> would mean only
> one interface sends the service multicast packets (our is only a SA).
> What am i doing
> wrong, or do I just misunderstand the problem?
>
>
Sockets that want to send multicast over a particular network interface
must set a socket option to send over that interface.  Otherwise, the stack
will only send it out whatever network interface it considers the
primary/default.  And the socket option (IP_MULTICAST_IF) takes an ip
address,  although I have no idea if that preference "sticks" if the
interface changes its address subsequent to the setsockopt.   I've never
tried to do any of this with 0.0.0.0, it could be that it just fails.

I don't know anything about your device/product, but is there a point in
your device that you know it has the necessary ip addresses?  Either via
moving the daemon startup in rc.d, or using whatever watchdogs your device
may have?  And is slpd the only program on your device that has this sort
of ip address issue?

--Nick

Re: [Openslp-users] attach to device failed

[Ryan R. <rya...@gm...>]

On 30 March 2012 18:04, Nick Wagner <ne...@wi...> wrote:
> I personally prefer a solution where the daemon can handle network
> infrastructure changes, but while the group has talked about possible
> solutions now and then we've never implemented it.
>
Yea, that would be nice.

> Isn't this a larger issue for your application, though?  Aren't other system
> services (or applications you need to run) going to have to deal with having
> an invalid interface on startup? If that's not the case, why not delay
> startup of the daemon instead?

Yea, you are kinda' right. I want the daemon to listen on any and all interfaces
ie. 0.0.0.0. But it seems that when the slp daemon starts up, and there is not
default gw, the multicast setup fails. This is probably a fundamental
misunderstanding
on my part. If multicast needs a default route when any interface is
used, that means
that only one interface sends out the IGMP group join stuff. That
would mean only
one interface sends the service multicast packets (our is only a SA).
What am i doing
wrong, or do I just misunderstand the problem?

Thanks for the reply,
/Ryan

>
> --Nick
>
>
> On Fri, Mar 30, 2012 at 5:14 AM, Ryan Raasch <rya...@gm...> wrote:
>>
>> Hello,
>>
>> I have an application where we use the slpd. When the system is
>> started, however, our network interfaces are not ready when the init.d
>> scripts
>> are run. So, a network aware application needs to restart the daemon
>> when the network is ready. The network interface needed to be binded
>> is the 0.0.0.0 interface. But if the daemon, again is started too
>> early, although
>> the network is up, this error occurs.
>>
>> ****************************************
>> Mon Jan 26 02:25:39 1970
>> SLPD daemon started
>> ****************************************
>> Command line = /usr/sbin/slpd
>> Using configuration file = /etc/slp.conf
>> Using registration file = /etc/slp.reg
>> Listening on loopback TCP...
>> Listening on loopback UDP...
>> Couldn't bind to (IPv4) multicast for interface 0.0.0.0 (No such device)
>> Unicast socket on 0.0.0.0 ready
>> Agent Interfaces = 0.0.0.0
>> Startup complete entering main run loop ...
>>
>> Through the communication interface, there is no way of querying what
>> the status of the slpd is (which interfaces are available, etc.). To
>> remedy the
>> problem I made a small hack to exit the daemon if the multicast stuff
>> failed.
>>
>> As the damon is today, I understand there is no possibility to re-iterate
>> the
>> network interfaces. A restart is needed for this case. Could there not be
>> a
>> config parameter or switch to instruct the daemon to exit if it cannot
>> fulfill the
>> config's parameters as expected? Or an extra query api to the daemon to
>> determine net interface properties?
>>
>> diff --git a/slpd/slpd_incoming.c b/slpd/slpd_incoming.c
>> index bbb28cf..dc8869d 100644
>> --- a/slpd/slpd_incoming.c
>> +++ b/slpd/slpd_incoming.c
>> @@ -721,10 +721,13 @@ int SLPDIncomingInit(void)
>>                         sizeof(addr_str)));
>>          }
>>          else
>> +        {
>>             SLPDLog("Couldn't bind to (IPv4) multicast for interface
>> %s (%s)\n",
>>                   SLPNetSockAddrStorageToString(&myaddr, addr_str,
>>                         sizeof(addr_str)),
>>                   strerror(errno));
>> +           return 1;
>> +        }
>>       }
>>       else if (SLPNetIsIPV6() && myaddr.ss_family == AF_INET6)
>>       {
>>
>> Cheers,
>> Ryan
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Openslp-users mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>
>

Re: [Openslp-users] attach to device failed

[Nick W. <ne...@wi...>]

I personally prefer a solution where the daemon can handle network
infrastructure changes, but while the group has talked about possible
solutions now and then we've never implemented it.

Isn't this a larger issue for your application, though?  Aren't other
system services (or applications you need to run) going to have to deal
with having an invalid interface on startup? If that's not the case, why
not delay startup of the daemon instead?

--Nick


On Fri, Mar 30, 2012 at 5:14 AM, Ryan Raasch <rya...@gm...> wrote:

> Hello,
>
> I have an application where we use the slpd. When the system is
> started, however, our network interfaces are not ready when the init.d
> scripts
> are run. So, a network aware application needs to restart the daemon
> when the network is ready. The network interface needed to be binded
> is the 0.0.0.0 interface. But if the daemon, again is started too
> early, although
> the network is up, this error occurs.
>
> ****************************************
> Mon Jan 26 02:25:39 1970
> SLPD daemon started
> ****************************************
> Command line = /usr/sbin/slpd
> Using configuration file = /etc/slp.conf
> Using registration file = /etc/slp.reg
> Listening on loopback TCP...
> Listening on loopback UDP...
> Couldn't bind to (IPv4) multicast for interface 0.0.0.0 (No such device)
> Unicast socket on 0.0.0.0 ready
> Agent Interfaces = 0.0.0.0
> Startup complete entering main run loop ...
>
> Through the communication interface, there is no way of querying what
> the status of the slpd is (which interfaces are available, etc.). To
> remedy the
> problem I made a small hack to exit the daemon if the multicast stuff
> failed.
>
> As the damon is today, I understand there is no possibility to re-iterate
> the
> network interfaces. A restart is needed for this case. Could there not be a
> config parameter or switch to instruct the daemon to exit if it cannot
> fulfill the
> config's parameters as expected? Or an extra query api to the daemon to
> determine net interface properties?
>
> diff --git a/slpd/slpd_incoming.c b/slpd/slpd_incoming.c
> index bbb28cf..dc8869d 100644
> --- a/slpd/slpd_incoming.c
> +++ b/slpd/slpd_incoming.c
> @@ -721,10 +721,13 @@ int SLPDIncomingInit(void)
>                         sizeof(addr_str)));
>          }
>          else
> +        {
>             SLPDLog("Couldn't bind to (IPv4) multicast for interface
> %s (%s)\n",
>                   SLPNetSockAddrStorageToString(&myaddr, addr_str,
>                         sizeof(addr_str)),
>                   strerror(errno));
> +           return 1;
> +        }
>       }
>       else if (SLPNetIsIPV6() && myaddr.ss_family == AF_INET6)
>       {
>
> Cheers,
> Ryan
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Openslp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>

[Openslp-users] attach to device failed

[Ryan R. <rya...@gm...>]

Hello,

I have an application where we use the slpd. When the system is
started, however, our network interfaces are not ready when the init.d scripts
are run. So, a network aware application needs to restart the daemon
when the network is ready. The network interface needed to be binded
is the 0.0.0.0 interface. But if the daemon, again is started too
early, although
the network is up, this error occurs.

****************************************
Mon Jan 26 02:25:39 1970
SLPD daemon started
****************************************
Command line = /usr/sbin/slpd
Using configuration file = /etc/slp.conf
Using registration file = /etc/slp.reg
Listening on loopback TCP...
Listening on loopback UDP...
Couldn't bind to (IPv4) multicast for interface 0.0.0.0 (No such device)
Unicast socket on 0.0.0.0 ready
Agent Interfaces = 0.0.0.0
Startup complete entering main run loop ...

Through the communication interface, there is no way of querying what
the status of the slpd is (which interfaces are available, etc.). To remedy the
problem I made a small hack to exit the daemon if the multicast stuff failed.

As the damon is today, I understand there is no possibility to re-iterate the
network interfaces. A restart is needed for this case. Could there not be a
config parameter or switch to instruct the daemon to exit if it cannot
fulfill the
config's parameters as expected? Or an extra query api to the daemon to
determine net interface properties?

diff --git a/slpd/slpd_incoming.c b/slpd/slpd_incoming.c
index bbb28cf..dc8869d 100644
--- a/slpd/slpd_incoming.c
+++ b/slpd/slpd_incoming.c
@@ -721,10 +721,13 @@ int SLPDIncomingInit(void)
                         sizeof(addr_str)));
          }
          else
+	 {
             SLPDLog("Couldn't bind to (IPv4) multicast for interface
%s (%s)\n",
                   SLPNetSockAddrStorageToString(&myaddr, addr_str,
                         sizeof(addr_str)),
                   strerror(errno));
+	    return 1;
+	 }
       }
       else if (SLPNetIsIPV6() && myaddr.ss_family == AF_INET6)
       {

Cheers,
Ryan

Re: [Openslp-users] Slpd doesn't give any response to the SrvRqst.

[Nick W. <ne...@wi...>]

I'm not sure what code is in your package, but I did fix some v1 bugs in
slpd last September.  Would it be possible to download the latest code from
our sourcesafe repository and test it?

--Nick

On Tue, Mar 27, 2012 at 9:23 PM, 尹乐 <yin...@gm...> wrote:

> Hi,
>
> I have a issue with the the OpenSLP v2, can someone give a help about it?
> Thanks a lot.
> My service installed  the OpenSLP v2 :
>  # rpm -qa |grep slp
> openslp-server-2.1.beta5-183
> openslp-2.1.beta5-183
>
>
> It seems that when the slpd is running well it doesn't give any response
> for the SrvRqst whatever the message is multicast or broadcast.
> When it does respond in any way to unicast, it returns that it doesn't
> support any service types at all...
> # slpd -v
> slpd version: 2.0.beta1
> compile options:
>    debugging:            disabled
>    predicates:           enabled
>    slpv1 compatability:  enabled
>    slpv2 security:       enabled
>
>
> The SrvRqst is sent from a UA with OpenSLP v1.
> Attached is the SrvRqst package captured by tcpdump that UA sent to it.
>
> And here is the log I got about the slpd when sending SrvRqst to it:
> Tue Mar 27 02:58:12 2012 *** WARNING Parse Error *** Peer IP address:
> 50.0.0.111 message size = 205 message dump follows: 0x02(' ') 0x01(' ')
> 0x00(' ') 0x00(' ') 0xcd(' ') 0x20(' ') 0x00(' ') 0x00(' ') 0x00(' ')
> 0x40('@') 0x16(' ') 0x3d('=') 0x00(' ') 0x02(' ') 0x65('e') 0x6e('n')
> 0x00(' ') 0x83(' ') 0x35('5') 0x30('0') 0x2e('.') 0x30('0') 0x2e('.')
> 0x30('0') 0x2e('.') 0x31('1') 0x38('8') 0x38('8') 0x2c(',') 0x35('5') .....
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Openslp-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>
>

Re: [Openslp-users] OpenSLP, ports, and firewalls

[Steve S. <sso...@ky...>]

Hey Nick,

I looked into changing the LiveTribe SLP code so that it uses a defined 
port for the client UDP socket - just like you mentioned - and got it 
working. I'll have to open two ports, but that's better than opening 
them all!

Once again, thanks for all the help.

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...@wi... 
> <mailto:ne...@wi...>> 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 <sso...@ky...
>     <mailto:sso...@ky...>> 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
>>         <sso...@ky... <mailto:sso...@ky...>> 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
>>             Ope...@li...
>>             <mailto:Ope...@li...>
>>             https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>>
>
>
>

Re: [Openslp-users] OpenSLP, ports, and firewalls

[Steve S. <sso...@ky...>]

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...@wi... 
> <mailto:ne...@wi...>> 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 <sso...@ky...
>     <mailto:sso...@ky...>> 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
>>         <sso...@ky... <mailto:sso...@ky...>> 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
>>             Ope...@li...
>>             <mailto:Ope...@li...>
>>             https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>>
>
>
>

Re: [Openslp-users] OpenSLP, ports, and firewalls

[Nick W. <ne...@wi...>]

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...@wi...> 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 <sso...@ky...> 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 <sso...@ky...> 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
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>>
>>
>>
>>
>

Re: [Openslp-users] OpenSLP, ports, and firewalls

[Nick W. <ne...@wi...>]

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 <sso...@ky...> 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 <sso...@ky...> 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
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>
>
>

Re: [Openslp-users] OpenSLP, ports, and firewalls

[Steve S. <sso...@ky...>]

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 <sso...@ky... 
> <mailto:sso...@ky...>> 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
>     Ope...@li...
>     <mailto:Ope...@li...>
>     https://lists.sourceforge.net/lists/listinfo/openslp-users
>
>

Re: [Openslp-users] OpenSLP, ports, and firewalls

[Nick W. <ne...@wi...>]

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 <sso...@ky...> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>

[Openslp-users] OpenSLP, ports, and firewalls

[Steve S. <sso...@ky...>]

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

Re: [Openslp-users] RFC-3082 support?

[John C. <joh...@gm...>]

Steve,

We have no current plans. Please feel free to add support and post a patch
for review and inclusion into the code base.

Regards,
John

> -----Original Message-----
> From: Steve Soloski [mailto:sso...@ky...]
> Sent: Friday, December 30, 2011 12:43 PM
> To: ope...@li...
> Subject: [Openslp-users] RFC-3082 support?
> 
> Hello,
> 
> I have an SLP application whose clients depend on notification messages
for
> service registration and de-registration messages per RFC-3082. In
migrating
> my server-side code to OpenSLP I noticed SLPD does not generate these
> notification messages. Does anyone know if there are any plans for adding
> this functionality, or has anyone else done this?
> Before I try adding it myself I thought I would ask...
> 
> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users

[Openslp-users] RFC-3082 support?

[Steve S. <sso...@ky...>]

Hello,

I have an SLP application whose clients depend on notification messages 
for service registration and de-registration messages per RFC-3082. In 
migrating my server-side code to OpenSLP I noticed SLPD does not 
generate these notification messages. Does anyone know if there are any 
plans for adding this functionality, or has anyone else done this? 
Before I try adding it myself I thought I would ask...

Steve

Re: [Openslp-users] OpenSLP windows problem

[Gerard v. d. B. <ge...@de...>]

Solved, problem existed between keyboard and chair.
The code I use to register to the OpenSLP service is included in a DLL, 
I linked correctly against the DLL but forgot to replace it with the one 
in the folder where my executable is located.

Sorry for the inconvenience.

Regards,
Gerard


On 12/22/2011 11:38 AM, Gerard van den Bosch wrote:
> Yes this was switched on by default, just installed VS2008Express and
> opened the project file.
> Switched it off manually and it only gave a warning and compiled.
>
> Ok, this is the code that works under Linux with V1.2.1:
>
> void xmlpcp_db::MySLPRegReport(SLPHandle hslp, SLPError errcode, void
> *cookie)
> {
>       *(SLPError *)cookie = errcode;
> }
>
> void xmlpcp_db::xmlpcp_registerservice(QString service, QString address,
> quint16 port)
> {
>       SLPError err;
>       SLPError callbackerr;
>       SLPHandle hslp;
>
>       /* Register service locally */
>       this->iLastSubscriptionID = 1;
>       this->iSubscribersAmount = 0;
>       this->sService = service;
>
>       /* Register service to the SLP server */
>       err = SLPOpen("en",SLP_FALSE,&hslp);
>       if(err != SLP_OK)
>       {
>           qDebug()<<  "Failed to open SLP handle";
>           return;
>       }
>
>       this->sSLPUrl =
> "service:"+service+"://"+address+":"+QString::number(port);
>       err =
> SLPReg(hslp,this->sSLPUrl.toAscii().data(),SLP_LIFETIME_MAXIMUM,0,"",SLP_TRUE,MySLPRegReport,&callbackerr);
>       if((err != SLP_OK) || (callbackerr != SLP_OK))
>       {
>           qDebug()<<  "Error registering service to SLP";
>           return;
>       }
>
>       SLPClose(hslp);
>
>       emit sendLog("Registered service: "+service);
> }
>
> Regards,
> Gerard
>
> On 12/22/2011 11:30 AM, Hird Matthew wrote:
>> Ah sorry, my bad, I made that change recently but have no way to test on
>> windows. I'll commit your patch, thanks. I'm guessing it only actually
>> failed as you've got 'treat warnings as errors' switched on? If you switched
>> that off, it'd just be a warning?
>>
>> Could you email the code you're trying to use to register your own service?
>> My company blocks pastebin unfortunately.
>>
>> Does this code work under linux?
>>
>> cheers
>> Matt
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Gerard van den Bosch [mailto:ge...@de...]
>> Sent: 22 December 2011 09:57
>> To: Hird Matthew
>> Cc: ope...@li...
>> Subject: Re: [Openslp-users] OpenSLP windows problem
>>
>> Matthew,
>>
>> Thanks for your reply, I have build the latest revision from the repository.
>> At first it wouldn't compile(VS express 2008) due to this:
>> ..\..\slpd\slpd_process.c(204) : error C2220: warning treated as error - no
>> 'object' file generated
>>     ..\..\slpd\slpd_process.c(204) : warning C4018: '>' : signed/unsigned
>> mismatch
>>
>> Fixed this error with a small change:
>> Index: slpd_process.c
>> ===================================================================
>> --- slpd_process.c    (revision 1688)
>> +++ slpd_process.c    (working copy)
>> @@ -201,7 +201,7 @@
>>               size_t currentPosFromStart = (*sendbuf)->curpos -
>> (*sendbuf)->start;
>>
>>               /* check to make sure we're growing by at least the size of the
>> tmp buffer */
>> -          *sendbuf = SLPBufferRealloc( (*sendbuf),
>> ((*sendbuf)->allocated + ((tmp->end - tmp->start)>   grow_size?(tmp->end -
>> tmp->start):grow_size)) );
>> +          *sendbuf = SLPBufferRealloc( (*sendbuf),
>> ((*sendbuf)->allocated + ((size_t)(tmp->end - tmp->start)>
>> grow_size?(tmp->end - tmp->start):grow_size)) );
>>               if (*sendbuf == 0)
>>               {
>>                  retVal = SLP_ERROR_INTERNAL_ERROR;
>>
>> When I add a server manually now with the slptool tool it continues to
>> exist, however registering my own application still fails.
>>
>> Regards,
>> Gerard
>>
>> On 12/21/2011 03:50 PM, Hird Matthew wrote:
>>> Gerard
>>>
>>> I'm not sure why your windows version doesn't work but if you don't
>>> mind compiling from source, I would step up to the latest revision
>>> (1688) for both from the repository if I was you -
>>> http://sourceforge.net/scm/?type=svn&group_id=1730
>>>
>>> The problem you are having with services disappearing is because there
>>> is a pid watch facility enabled on the daemon. As soon as the pid
>>> disappears from the process table, any services associated with it are
>>> removed. You can either switch it off via the slp.conf file or step up
>>> to the latest revision as I believe somebody has put a patch in to
>>> stop this happening from slptool.
>>>
>>> cheers
>>> Matt
>>>
>>>
>>> -----Original Message-----
>>> From: Gerard van den Bosch [mailto:ge...@de...]
>>> Sent: 21 December 2011 12:51
>>> To: ope...@li...
>>> Subject: [Openslp-users] OpenSLP windows problem
>>>
>>> Hello,
>>>
>>> I have made a server application in Qt, in order to automatically
>>> discover the server I've implemented code that talks with the OpenSLP
>>> API and registers the server. This code works fine on Linux but I am
>>> having troubles to get it running on Windows (XP).
>>>
>>> I have a small version difference, the version of SLPD on my Linux
>>> machine is 1.2.1 and the one on my Windows version is 2.0.0, I assumed
>>> the interface would stay the same so this wouldn't be a problem.
>>>
>>> On both OS's I compiled against SLP.h and on Linux linked with -lslp
>>> and with Windows I have linked against slp.dll.
>>>
>>> I have adapted the code from the openslp.org site, my code can be
>>> found
>>> here: http://pastebin.com/dak6YGnE
>>>
>>> The weird thing is also when I register a dummy service by hand with
>>> the slptool it disappears within a few seconds. I've also tried to run
>>> slpd.exe in debug mode but nothing showed up.
>>>
>>> Can anyone point me where this might be going wrong?
>>>
>>> Regards,
>>> Gerard
>>>
>>>
>>> ----------------------------------------------------------------------
>>> ------
>>> --
>>> 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
>>> Ope...@li...
>>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>>
>>> This email, including any attachment, is a confidential communication
>>> intended solely for the use of the individual or entity to whom it is
>>> addressed. It contains information which is private and may be
>>> proprietary or covered by legal professional privilege. If you have
>>> received this email in error, please notify the sender upon receipt,
>>> and immediately delete it from your system.
>>>
>>> Anything contained in this email that is not connected with the
>>> businesses of this company is neither endorsed by nor is the liability of
>> this company.
>>> Whilst we have taken reasonable precautions to ensure that any
>>> attachment to this email has been swept for viruses, we cannot accept
>>> liability for any damage sustained as a result of software viruses,
>>> and would advise that you carry out your own virus checks before opening
>> any attachment.
>>
>> This email, including any attachment, is a confidential communication
>> intended solely for the use of the individual or entity to whom it is
>> addressed. It contains information which is private and may be proprietary
>> or covered by legal professional privilege. If you have received this email
>> in error, please notify the sender upon receipt, and immediately delete it
>> from your system.
>>
>> Anything contained in this email that is not connected with the businesses
>> of this company is neither endorsed by nor is the liability of this company.
>>
>> Whilst we have taken reasonable precautions to ensure that any attachment to
>> this email has been swept for viruses, we cannot accept liability for any
>> damage sustained as a result of software viruses, and would advise that you
>> carry out your own virus checks before opening any attachment.
>>
>
>
> ------------------------------------------------------------------------------
> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users

Re: [Openslp-users] OpenSLP windows problem

[Gerard v. d. B. <ge...@de...>]

Yes this was switched on by default, just installed VS2008Express and 
opened the project file.
Switched it off manually and it only gave a warning and compiled.

Ok, this is the code that works under Linux with V1.2.1:

void xmlpcp_db::MySLPRegReport(SLPHandle hslp, SLPError errcode, void 
*cookie)
{
     *(SLPError *)cookie = errcode;
}

void xmlpcp_db::xmlpcp_registerservice(QString service, QString address, 
quint16 port)
{
     SLPError err;
     SLPError callbackerr;
     SLPHandle hslp;

     /* Register service locally */
     this->iLastSubscriptionID = 1;
     this->iSubscribersAmount = 0;
     this->sService = service;

     /* Register service to the SLP server */
     err = SLPOpen("en",SLP_FALSE,&hslp);
     if(err != SLP_OK)
     {
         qDebug() << "Failed to open SLP handle";
         return;
     }

     this->sSLPUrl = 
"service:"+service+"://"+address+":"+QString::number(port);
     err = 
SLPReg(hslp,this->sSLPUrl.toAscii().data(),SLP_LIFETIME_MAXIMUM,0,"",SLP_TRUE,MySLPRegReport,&callbackerr);
     if((err != SLP_OK) || (callbackerr != SLP_OK))
     {
         qDebug() << "Error registering service to SLP";
         return;
     }

     SLPClose(hslp);

     emit sendLog("Registered service: "+service);
}

Regards,
Gerard

On 12/22/2011 11:30 AM, Hird Matthew wrote:
> Ah sorry, my bad, I made that change recently but have no way to test on
> windows. I'll commit your patch, thanks. I'm guessing it only actually
> failed as you've got 'treat warnings as errors' switched on? If you switched
> that off, it'd just be a warning?
>
> Could you email the code you're trying to use to register your own service?
> My company blocks pastebin unfortunately.
>
> Does this code work under linux?
>
> cheers
> Matt
>
>
>
>
>
> -----Original Message-----
> From: Gerard van den Bosch [mailto:ge...@de...]
> Sent: 22 December 2011 09:57
> To: Hird Matthew
> Cc: ope...@li...
> Subject: Re: [Openslp-users] OpenSLP windows problem
>
> Matthew,
>
> Thanks for your reply, I have build the latest revision from the repository.
> At first it wouldn't compile(VS express 2008) due to this:
> ..\..\slpd\slpd_process.c(204) : error C2220: warning treated as error - no
> 'object' file generated
>    ..\..\slpd\slpd_process.c(204) : warning C4018: '>' : signed/unsigned
> mismatch
>
> Fixed this error with a small change:
> Index: slpd_process.c
> ===================================================================
> --- slpd_process.c    (revision 1688)
> +++ slpd_process.c    (working copy)
> @@ -201,7 +201,7 @@
>              size_t currentPosFromStart = (*sendbuf)->curpos -
> (*sendbuf)->start;
>
>              /* check to make sure we're growing by at least the size of the
> tmp buffer */
> -          *sendbuf = SLPBufferRealloc( (*sendbuf),
> ((*sendbuf)->allocated + ((tmp->end - tmp->start)>  grow_size?(tmp->end -
> tmp->start):grow_size)) );
> +          *sendbuf = SLPBufferRealloc( (*sendbuf),
> ((*sendbuf)->allocated + ((size_t)(tmp->end - tmp->start)>
> grow_size?(tmp->end - tmp->start):grow_size)) );
>              if (*sendbuf == 0)
>              {
>                 retVal = SLP_ERROR_INTERNAL_ERROR;
>
> When I add a server manually now with the slptool tool it continues to
> exist, however registering my own application still fails.
>
> Regards,
> Gerard
>
> On 12/21/2011 03:50 PM, Hird Matthew wrote:
>> Gerard
>>
>> I'm not sure why your windows version doesn't work but if you don't
>> mind compiling from source, I would step up to the latest revision
>> (1688) for both from the repository if I was you -
>> http://sourceforge.net/scm/?type=svn&group_id=1730
>>
>> The problem you are having with services disappearing is because there
>> is a pid watch facility enabled on the daemon. As soon as the pid
>> disappears from the process table, any services associated with it are
>> removed. You can either switch it off via the slp.conf file or step up
>> to the latest revision as I believe somebody has put a patch in to
>> stop this happening from slptool.
>>
>> cheers
>> Matt
>>
>>
>> -----Original Message-----
>> From: Gerard van den Bosch [mailto:ge...@de...]
>> Sent: 21 December 2011 12:51
>> To: ope...@li...
>> Subject: [Openslp-users] OpenSLP windows problem
>>
>> Hello,
>>
>> I have made a server application in Qt, in order to automatically
>> discover the server I've implemented code that talks with the OpenSLP
>> API and registers the server. This code works fine on Linux but I am
>> having troubles to get it running on Windows (XP).
>>
>> I have a small version difference, the version of SLPD on my Linux
>> machine is 1.2.1 and the one on my Windows version is 2.0.0, I assumed
>> the interface would stay the same so this wouldn't be a problem.
>>
>> On both OS's I compiled against SLP.h and on Linux linked with -lslp
>> and with Windows I have linked against slp.dll.
>>
>> I have adapted the code from the openslp.org site, my code can be
>> found
>> here: http://pastebin.com/dak6YGnE
>>
>> The weird thing is also when I register a dummy service by hand with
>> the slptool it disappears within a few seconds. I've also tried to run
>> slpd.exe in debug mode but nothing showed up.
>>
>> Can anyone point me where this might be going wrong?
>>
>> Regards,
>> Gerard
>>
>>
>> ----------------------------------------------------------------------
>> ------
>> --
>> 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
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>> This email, including any attachment, is a confidential communication
>> intended solely for the use of the individual or entity to whom it is
>> addressed. It contains information which is private and may be
>> proprietary or covered by legal professional privilege. If you have
>> received this email in error, please notify the sender upon receipt,
>> and immediately delete it from your system.
>>
>> Anything contained in this email that is not connected with the
>> businesses of this company is neither endorsed by nor is the liability of
> this company.
>> Whilst we have taken reasonable precautions to ensure that any
>> attachment to this email has been swept for viruses, we cannot accept
>> liability for any damage sustained as a result of software viruses,
>> and would advise that you carry out your own virus checks before opening
> any attachment.
>
> This email, including any attachment, is a confidential communication
> intended solely for the use of the individual or entity to whom it is
> addressed. It contains information which is private and may be proprietary
> or covered by legal professional privilege. If you have received this email
> in error, please notify the sender upon receipt, and immediately delete it
> from your system.
>
> Anything contained in this email that is not connected with the businesses
> of this company is neither endorsed by nor is the liability of this company.
>
> Whilst we have taken reasonable precautions to ensure that any attachment to
> this email has been swept for viruses, we cannot accept liability for any
> damage sustained as a result of software viruses, and would advise that you
> carry out your own virus checks before opening any attachment.
>

Re: [Openslp-users] OpenSLP windows problem

[Hird M. <Mat...@uk...>]

Ah sorry, my bad, I made that change recently but have no way to test on
windows. I'll commit your patch, thanks. I'm guessing it only actually
failed as you've got 'treat warnings as errors' switched on? If you switched
that off, it'd just be a warning?

Could you email the code you're trying to use to register your own service?
My company blocks pastebin unfortunately. 

Does this code work under linux? 

cheers
Matt

 



-----Original Message-----
From: Gerard van den Bosch [mailto:ge...@de...] 
Sent: 22 December 2011 09:57
To: Hird Matthew
Cc: ope...@li...
Subject: Re: [Openslp-users] OpenSLP windows problem

Matthew,

Thanks for your reply, I have build the latest revision from the repository.
At first it wouldn't compile(VS express 2008) due to this:
..\..\slpd\slpd_process.c(204) : error C2220: warning treated as error - no
'object' file generated
  ..\..\slpd\slpd_process.c(204) : warning C4018: '>' : signed/unsigned
mismatch

Fixed this error with a small change:
Index: slpd_process.c
===================================================================
--- slpd_process.c    (revision 1688)
+++ slpd_process.c    (working copy)
@@ -201,7 +201,7 @@
            size_t currentPosFromStart = (*sendbuf)->curpos -
(*sendbuf)->start;

            /* check to make sure we're growing by at least the size of the
tmp buffer */
-          *sendbuf = SLPBufferRealloc( (*sendbuf), 
((*sendbuf)->allocated + ((tmp->end - tmp->start) > grow_size?(tmp->end -
tmp->start):grow_size)) );
+          *sendbuf = SLPBufferRealloc( (*sendbuf),
((*sendbuf)->allocated + ((size_t)(tmp->end - tmp->start) >
grow_size?(tmp->end - tmp->start):grow_size)) );
            if (*sendbuf == 0)
            {
               retVal = SLP_ERROR_INTERNAL_ERROR;

When I add a server manually now with the slptool tool it continues to
exist, however registering my own application still fails.

Regards,
Gerard

On 12/21/2011 03:50 PM, Hird Matthew wrote:
> Gerard
>
> I'm not sure why your windows version doesn't work but if you don't 
> mind compiling from source, I would step up to the latest revision 
> (1688) for both from the repository if I was you - 
> http://sourceforge.net/scm/?type=svn&group_id=1730
>
> The problem you are having with services disappearing is because there 
> is a pid watch facility enabled on the daemon. As soon as the pid 
> disappears from the process table, any services associated with it are 
> removed. You can either switch it off via the slp.conf file or step up 
> to the latest revision as I believe somebody has put a patch in to 
> stop this happening from slptool.
>
> cheers
> Matt
>
>
> -----Original Message-----
> From: Gerard van den Bosch [mailto:ge...@de...]
> Sent: 21 December 2011 12:51
> To: ope...@li...
> Subject: [Openslp-users] OpenSLP windows problem
>
> Hello,
>
> I have made a server application in Qt, in order to automatically 
> discover the server I've implemented code that talks with the OpenSLP 
> API and registers the server. This code works fine on Linux but I am 
> having troubles to get it running on Windows (XP).
>
> I have a small version difference, the version of SLPD on my Linux 
> machine is 1.2.1 and the one on my Windows version is 2.0.0, I assumed 
> the interface would stay the same so this wouldn't be a problem.
>
> On both OS's I compiled against SLP.h and on Linux linked with -lslp 
> and with Windows I have linked against slp.dll.
>
> I have adapted the code from the openslp.org site, my code can be 
> found
> here: http://pastebin.com/dak6YGnE
>
> The weird thing is also when I register a dummy service by hand with 
> the slptool it disappears within a few seconds. I've also tried to run 
> slpd.exe in debug mode but nothing showed up.
>
> Can anyone point me where this might be going wrong?
>
> Regards,
> Gerard
>
>
> ----------------------------------------------------------------------
> ------
> --
> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>
> This email, including any attachment, is a confidential communication 
> intended solely for the use of the individual or entity to whom it is 
> addressed. It contains information which is private and may be 
> proprietary or covered by legal professional privilege. If you have 
> received this email in error, please notify the sender upon receipt, 
> and immediately delete it from your system.
>
> Anything contained in this email that is not connected with the 
> businesses of this company is neither endorsed by nor is the liability of
this company.
>
> Whilst we have taken reasonable precautions to ensure that any 
> attachment to this email has been swept for viruses, we cannot accept 
> liability for any damage sustained as a result of software viruses, 
> and would advise that you carry out your own virus checks before opening
any attachment.
>


This email, including any attachment, is a confidential communication
intended solely for the use of the individual or entity to whom it is
addressed. It contains information which is private and may be proprietary
or covered by legal professional privilege. If you have received this email
in error, please notify the sender upon receipt, and immediately delete it
from your system.

Anything contained in this email that is not connected with the businesses
of this company is neither endorsed by nor is the liability of this company.

Whilst we have taken reasonable precautions to ensure that any attachment to
this email has been swept for viruses, we cannot accept liability for any
damage sustained as a result of software viruses, and would advise that you
carry out your own virus checks before opening any attachment.

Re: [Openslp-users] OpenSLP windows problem

[Gerard v. d. B. <ge...@de...>]

Matthew,

Thanks for your reply, I have build the latest revision from the repository.
At first it wouldn't compile(VS express 2008) due to this:
..\..\slpd\slpd_process.c(204) : error C2220: warning treated as error - 
no 'object' file generated
  ..\..\slpd\slpd_process.c(204) : warning C4018: '>' : signed/unsigned 
mismatch

Fixed this error with a small change:
Index: slpd_process.c
===================================================================
--- slpd_process.c    (revision 1688)
+++ slpd_process.c    (working copy)
@@ -201,7 +201,7 @@
            size_t currentPosFromStart = (*sendbuf)->curpos - 
(*sendbuf)->start;

            /* check to make sure we're growing by at least the size of 
the tmp buffer */
-          *sendbuf = SLPBufferRealloc( (*sendbuf), 
((*sendbuf)->allocated + ((tmp->end - tmp->start) > grow_size?(tmp->end 
- tmp->start):grow_size)) );
+          *sendbuf = SLPBufferRealloc( (*sendbuf), 
((*sendbuf)->allocated + ((size_t)(tmp->end - tmp->start) > 
grow_size?(tmp->end - tmp->start):grow_size)) );
            if (*sendbuf == 0)
            {
               retVal = SLP_ERROR_INTERNAL_ERROR;

When I add a server manually now with the slptool tool it continues to 
exist, however registering my own application still fails.

Regards,
Gerard

On 12/21/2011 03:50 PM, Hird Matthew wrote:
> Gerard
>
> I'm not sure why your windows version doesn't work but if you don't mind
> compiling from source, I would step up to the latest revision (1688) for
> both from the repository if I was you -
> http://sourceforge.net/scm/?type=svn&group_id=1730
>
> The problem you are having with services disappearing is because there is a
> pid watch facility enabled on the daemon. As soon as the pid disappears from
> the process table, any services associated with it are removed. You can
> either switch it off via the slp.conf file or step up to the latest revision
> as I believe somebody has put a patch in to stop this happening from
> slptool.
>
> cheers
> Matt
>
>
> -----Original Message-----
> From: Gerard van den Bosch [mailto:ge...@de...]
> Sent: 21 December 2011 12:51
> To: ope...@li...
> Subject: [Openslp-users] OpenSLP windows problem
>
> Hello,
>
> I have made a server application in Qt, in order to automatically discover
> the server I've implemented code that talks with the OpenSLP API and
> registers the server. This code works fine on Linux but I am having troubles
> to get it running on Windows (XP).
>
> I have a small version difference, the version of SLPD on my Linux machine
> is 1.2.1 and the one on my Windows version is 2.0.0, I assumed the interface
> would stay the same so this wouldn't be a problem.
>
> On both OS's I compiled against SLP.h and on Linux linked with -lslp and
> with Windows I have linked against slp.dll.
>
> I have adapted the code from the openslp.org site, my code can be found
> here: http://pastebin.com/dak6YGnE
>
> The weird thing is also when I register a dummy service by hand with the
> slptool it disappears within a few seconds. I've also tried to run slpd.exe
> in debug mode but nothing showed up.
>
> Can anyone point me where this might be going wrong?
>
> Regards,
> Gerard
>
>
> ----------------------------------------------------------------------------
> --
> 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openslp-users
>
> This email, including any attachment, is a confidential communication
> intended solely for the use of the individual or entity to whom it is
> addressed. It contains information which is private and may be proprietary
> or covered by legal professional privilege. If you have received this email
> in error, please notify the sender upon receipt, and immediately delete it
> from your system.
>
> Anything contained in this email that is not connected with the businesses
> of this company is neither endorsed by nor is the liability of this company.
>
> Whilst we have taken reasonable precautions to ensure that any attachment to
> this email has been swept for viruses, we cannot accept liability for any
> damage sustained as a result of software viruses, and would advise that you
> carry out your own virus checks before opening any attachment.
>

Re: [Openslp-users] OpenSLP windows problem

[Hird M. <Mat...@uk...>]

Gerard

I'm not sure why your windows version doesn't work but if you don't mind
compiling from source, I would step up to the latest revision (1688) for
both from the repository if I was you -
http://sourceforge.net/scm/?type=svn&group_id=1730

The problem you are having with services disappearing is because there is a
pid watch facility enabled on the daemon. As soon as the pid disappears from
the process table, any services associated with it are removed. You can
either switch it off via the slp.conf file or step up to the latest revision
as I believe somebody has put a patch in to stop this happening from
slptool. 

cheers
Matt


-----Original Message-----
From: Gerard van den Bosch [mailto:ge...@de...] 
Sent: 21 December 2011 12:51
To: ope...@li...
Subject: [Openslp-users] OpenSLP windows problem

Hello,

I have made a server application in Qt, in order to automatically discover
the server I've implemented code that talks with the OpenSLP API and
registers the server. This code works fine on Linux but I am having troubles
to get it running on Windows (XP).

I have a small version difference, the version of SLPD on my Linux machine
is 1.2.1 and the one on my Windows version is 2.0.0, I assumed the interface
would stay the same so this wouldn't be a problem.

On both OS's I compiled against SLP.h and on Linux linked with -lslp and
with Windows I have linked against slp.dll.

I have adapted the code from the openslp.org site, my code can be found
here: http://pastebin.com/dak6YGnE

The weird thing is also when I register a dummy service by hand with the
slptool it disappears within a few seconds. I've also tried to run slpd.exe
in debug mode but nothing showed up.

Can anyone point me where this might be going wrong?

Regards,
Gerard


----------------------------------------------------------------------------
--
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
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openslp-users

This email, including any attachment, is a confidential communication
intended solely for the use of the individual or entity to whom it is
addressed. It contains information which is private and may be proprietary
or covered by legal professional privilege. If you have received this email
in error, please notify the sender upon receipt, and immediately delete it
from your system.

Anything contained in this email that is not connected with the businesses
of this company is neither endorsed by nor is the liability of this company.

Whilst we have taken reasonable precautions to ensure that any attachment to
this email has been swept for viruses, we cannot accept liability for any
damage sustained as a result of software viruses, and would advise that you
carry out your own virus checks before opening any attachment.

[Openslp-users] OpenSLP windows problem

[Gerard v. d. B. <ge...@de...>]

Hello,

I have made a server application in Qt, in order to automatically 
discover the server I've implemented code that talks with the OpenSLP 
API and registers the server. This code works fine on Linux but I am 
having troubles to get it running on Windows (XP).

I have a small version difference, the version of SLPD on my Linux 
machine is 1.2.1 and the one on my Windows version is 2.0.0, I assumed 
the interface would stay the same so this wouldn't be a problem.

On both OS's I compiled against SLP.h and on Linux linked with -lslp and 
with Windows I have linked against slp.dll.

I have adapted the code from the openslp.org site, my code can be found 
here: http://pastebin.com/dak6YGnE

The weird thing is also when I register a dummy service by hand with the 
slptool it disappears within a few seconds. I've also tried to run 
slpd.exe in debug mode but nothing showed up.

Can anyone point me where this might be going wrong?

Regards,
Gerard

Re: [Openslp-users] Attribute values with comma's treated differently between Java and C

[John C. <joh...@gm...>]

Hi all,

Just a quick announcement on this thread to let you know that I committed
Jim Marshall's changes to the Java client. These changes reflect the work he
did to remove message escaping code as discussed on this thread. They also
remove the dependency on log4j in favor of the Java internal logging
framework. Thanks Jim! The Java client is a better solution now, due to your
efforts.

John

> -----Original Message-----
> From: Jim Marshall [mailto:jim...@wb...]
> Sent: Tuesday, September 20, 2011 2:20 PM
> To: John Calcote
> Cc: ope...@li...
> Subject: Re: [Openslp-users] Attribute values with comma's treated
differently
> between Java and C
> 
> John Calcote wrote:
> >
> > That's exactly what I meant. In fact, there's no other way to do it
> > when using slptool, as it accepts full element lists on the command
> > line - if the user doesn't escape strings manually when passing the
> > list, how will any of the code know which commas are element separators
and
> which are embedded?
> Yes, your previous follow-up clarifying what you meant made that evident.
I
> agree with what you are saying here.
> >
> > ...
> >
> > The problem appears to be that the Java API takes more upon itself
> > than it should.
> Yes the Java API escapes all strings, see
ServiceLocationAttribute.escapeString.
> It seems the fix is to remove the calls to this function (and the
associated
> unEscape function) and just leave that function exposed for applications
to call
> themselves.
> 
> Jim
> >
> >>> On the other hand, receiving code must be careful to parse lists
> >>> into elements before decoding them so that the element list can be
> >>> parsed properly. If decoding is done first, then the receiver won't
> >>> know which commas are meant to separate elements, and which ones are
> >>> part of data strings.
> >> I think the cause of my concern is the following statement from
> >> section 5
> >>
> >> "The<attr-list>, if present, MUST be scanned prior to evaluation for
> >>      all occurrences of the escape character `\'.  Reserved characters
> >>      MUST be escaped (other characters MUST NOT be escaped).  All
escaped
> >>      characters must be restored to their value before attempting
string
> >>      matching."
> > Yes, this is a sore point and one of those places where the slp
> > designers probably disagreed and missed the lack of alignment in the
final
> analysis.
> > This paragraph is not even self-consistent. Consider: The subject is
> > "<attr-list>", which by definition contains characters that must not
> > be escaped, but which are reserved characters (e.g., the element
> > separator - comma). In other words, it must contain unescaped reserved
> > characters, but it also must be processed at this point to escape all
reserved
> characters.
> > The only reasonable way to manage this is to have<attr-list>  be fully
> > escaped before being processed at this level.
> >
> >> This seems to imply that the server and the client have to scan the
> >> list
> > and
> >> convert escaped/reserved characters, at least the '\' character, but
> >> I
> > think the
> >> second sentence indicates all reserved characters MUST be dealt with.
> >> It
> > doesn't
> >> appear OpenSLP is doing that.
> > A very literal interpretation that also works would have the caller
> > escaping only those characters that make the caller's intent unclear -
> > embedded list element separators. Then the slp UA would escape the
> > rest. That seems wrong in several ways (to me).
> >
> > I think we need to remove the internal escaping code from the Java API
> > and provide escaping functions in the public interface, like the C API
does.
> >
> > Regards,
> > John
> >
> >

Re: [Openslp-users] Attribute values with comma's treated differently between Java and C

[Jim M. <jim...@wb...>]

John Calcote wrote:
>
> That's exactly what I meant. In fact, there's no other way to do it when
> using slptool, as it accepts full element lists on the command line - if the
> user doesn't escape strings manually when passing the list, how will any of
> the code know which commas are element separators and which are embedded?
Yes, your previous follow-up clarifying what you meant made that 
evident. I agree with what you are saying here.
>
> ...
>
> The problem appears to be that the Java API takes more upon itself than it
> should.
Yes the Java API escapes all strings, see 
ServiceLocationAttribute.escapeString. It seems the fix is to remove the 
calls to this function (and the associated unEscape function) and just 
leave that function exposed for applications to call themselves.

Jim
>
>>> On the other hand, receiving code must be careful to parse lists into
>>> elements before decoding them so that the element list can be parsed
>>> properly. If decoding is done first, then the receiver won't know
>>> which commas are meant to separate elements, and which ones are part
>>> of data strings.
>> I think the cause of my concern is the following statement from section 5
>>
>> "The<attr-list>, if present, MUST be scanned prior to evaluation for
>>      all occurrences of the escape character `\'.  Reserved characters
>>      MUST be escaped (other characters MUST NOT be escaped).  All escaped
>>      characters must be restored to their value before attempting string
>>      matching."
> Yes, this is a sore point and one of those places where the slp designers
> probably disagreed and missed the lack of alignment in the final analysis.
> This paragraph is not even self-consistent. Consider: The subject is
> "<attr-list>", which by definition contains characters that must not be
> escaped, but which are reserved characters (e.g., the element separator -
> comma). In other words, it must contain unescaped reserved characters, but
> it also must be processed at this point to escape all reserved characters.
> The only reasonable way to manage this is to have<attr-list>  be fully
> escaped before being processed at this level.
>
>> This seems to imply that the server and the client have to scan the list
> and
>> convert escaped/reserved characters, at least the '\' character, but I
> think the
>> second sentence indicates all reserved characters MUST be dealt with. It
> doesn't
>> appear OpenSLP is doing that.
> A very literal interpretation that also works would have the caller escaping
> only those characters that make the caller's intent unclear - embedded list
> element separators. Then the slp UA would escape the rest. That seems wrong
> in several ways (to me).
>
> I think we need to remove the internal escaping code from the Java API and
> provide escaping functions in the public interface, like the C API does.
>
> Regards,
> John
>
>

Re: [Openslp-users] Attribute values with comma's treated differently between Java and C

[John C. <joh...@gm...>]

> -----Original Message-----
> From: Jim Marshall [mailto:jim...@wb...]
> Sent: Tuesday, September 20, 2011 1:27 PM
> To: John Calcote
> Cc: ope...@li...
> Subject: Re: [Openslp-users] Attribute values with comma's treated
differently
> between Java and C


> Seems that you are indicating that a client, using the OpenSLP API, must
> manually escape strings before sending it? For example something like
> 
> slptool register service:foo:http://foo.bar:1234 "(Description=This
> service\29 and any sub service\29 is a foo)"
> 
> Is that what you are indicating? I'm fine with that interpretation,
although it
> means that any client will need to know to deal with this.
> This seems to imply that the server/client API's don't do any escaping
tho, no?

That's exactly what I meant. In fact, there's no other way to do it when
using slptool, as it accepts full element lists on the command line - if the
user doesn't escape strings manually when passing the list, how will any of
the code know which commas are element separators and which are embedded?

In fact, the UA library calls accept complete element lists as arguments, so
it must be that either the authors of 2608 intended the callers of the UA
library to do all the escaping beforehand, or else they made a mistake in
the specification (not impossible). Regardless, when Caldera started the
project, it's pretty clear from the code that they interpreted the RFC to
mean that the user is intended to pre-escape strings before passing them in.

Of course, higher-level applications can manage this for the user when an
application is written to register strings with the OpenSLP UA. Again, the
intent is clear, from the existence of the SLPEscape and SLPUnescape
functions in the C API defined in RFC 2614, that the application is intended
to escape data strings on input, and unescape them on output.

The problem appears to be that the Java API takes more upon itself than it
should.

> >
> > On the other hand, receiving code must be careful to parse lists into
> > elements before decoding them so that the element list can be parsed
> > properly. If decoding is done first, then the receiver won't know
> > which commas are meant to separate elements, and which ones are part
> > of data strings.
> I think the cause of my concern is the following statement from section 5
> 
> "The <attr-list>, if present, MUST be scanned prior to evaluation for
>     all occurrences of the escape character `\'.  Reserved characters
>     MUST be escaped (other characters MUST NOT be escaped).  All escaped
>     characters must be restored to their value before attempting string
>     matching."

Yes, this is a sore point and one of those places where the slp designers
probably disagreed and missed the lack of alignment in the final analysis.
This paragraph is not even self-consistent. Consider: The subject is
"<attr-list>", which by definition contains characters that must not be
escaped, but which are reserved characters (e.g., the element separator -
comma). In other words, it must contain unescaped reserved characters, but
it also must be processed at this point to escape all reserved characters.
The only reasonable way to manage this is to have <attr-list> be fully
escaped before being processed at this level.

> 
> This seems to imply that the server and the client have to scan the list
and
> convert escaped/reserved characters, at least the '\' character, but I
think the
> second sentence indicates all reserved characters MUST be dealt with. It
doesn't
> appear OpenSLP is doing that.

A very literal interpretation that also works would have the caller escaping
only those characters that make the caller's intent unclear - embedded list
element separators. Then the slp UA would escape the rest. That seems wrong
in several ways (to me).

I think we need to remove the internal escaping code from the Java API and
provide escaping functions in the public interface, like the C API does.

Regards,
John