openslp-users Mailing List for OpenSLP (Page 5)
Brought to you by:
jcalcote
Menu
▾
▴
openslp-users — user issues and questions
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(10) |
Jun
(5) |
Jul
(2) |
Aug
(3) |
Sep
(7) |
Oct
(10) |
Nov
(3) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(6) |
Mar
(1) |
Apr
(1) |
May
(5) |
Jun
(7) |
Jul
(5) |
Aug
(10) |
Sep
(6) |
Oct
(26) |
Nov
(3) |
Dec
(1) |
| 2002 |
Jan
(9) |
Feb
(8) |
Mar
(5) |
Apr
(1) |
May
(12) |
Jun
(6) |
Jul
(8) |
Aug
(9) |
Sep
(12) |
Oct
(3) |
Nov
(2) |
Dec
(1) |
| 2003 |
Jan
(8) |
Feb
(13) |
Mar
(17) |
Apr
(7) |
May
|
Jun
(7) |
Jul
(2) |
Aug
(9) |
Sep
(4) |
Oct
(9) |
Nov
|
Dec
(2) |
| 2004 |
Jan
(5) |
Feb
(3) |
Mar
(3) |
Apr
(4) |
May
(7) |
Jun
(2) |
Jul
(2) |
Aug
(6) |
Sep
(9) |
Oct
(5) |
Nov
(7) |
Dec
(10) |
| 2005 |
Jan
(3) |
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(4) |
Jun
(9) |
Jul
(10) |
Aug
(6) |
Sep
(9) |
Oct
(4) |
Nov
(5) |
Dec
(1) |
| 2006 |
Jan
(3) |
Feb
(1) |
Mar
(33) |
Apr
|
May
(1) |
Jun
(13) |
Jul
(14) |
Aug
(10) |
Sep
(13) |
Oct
(19) |
Nov
(17) |
Dec
(13) |
| 2007 |
Jan
(12) |
Feb
(34) |
Mar
|
Apr
|
May
(3) |
Jun
(5) |
Jul
(7) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
(5) |
Feb
(6) |
Mar
|
Apr
(3) |
May
(16) |
Jun
|
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(8) |
Jul
(9) |
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
| 2010 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
(20) |
Aug
(10) |
Sep
(31) |
Oct
|
Nov
|
Dec
(8) |
| 2012 |
Jan
(7) |
Feb
|
Mar
(4) |
Apr
(11) |
May
(5) |
Jun
|
Jul
|
Aug
(6) |
Sep
(4) |
Oct
(33) |
Nov
(5) |
Dec
(1) |
| 2013 |
Jan
(19) |
Feb
(6) |
Mar
(1) |
Apr
(1) |
May
(11) |
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
(5) |
Oct
|
Nov
(3) |
Dec
|
| 2014 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Wang, R. <Ren...@nu...> - 2012-10-15 19:46:22
|
May I know if there any references for OpenSLP, I wonder how many enterprises or government agencies are using OpenSLP in production environment. Regards, Ren |
|
From: Nick W. <ne...@wi...> - 2012-10-15 14:51:57
|
If you try some other port, does SLP hijack that too? We're nearing release on version 2.0, would you like to try that and see if if you have a similar problem? I don't believe we're doing anything in the current code that would cause that side effect, and 1.2.1 was a long time ago. --Nick On Fri, Oct 12, 2012 at 3:35 AM, Robert Hegner <rh...@hs...> wrote: > I recently ported my application from Windows to Linux and now I'm > experiencing some strange problem when running it under Debian together > with OpenSLP 1.2.1-9 (this is the version that comes out of the box with > Debian). > > The problem is that slpd seems to occupy the port I'm using for my > application. Let me explain... > > Before I start my application, "lsof -i" lists the following spld related > entries: > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > slpd 2786 daemon 4u IPv4 6415 0t0 TCP > localhost:svrloc (LISTEN) > slpd 2786 daemon 5u IPv4 6416 0t0 TCP > DebianWheezy.local:svrloc (LISTEN) > slpd 2786 daemon 6u IPv4 6417 0t0 UDP > 239.255.255.253:svrloc > slpd 2786 daemon 7u IPv4 6418 0t0 UDP > DebianWheezy.local:svrloc > slpd 2786 daemon 8u IPv4 6419 0t0 TCP > 3724G-21104-2.hsr.ch:svrloc (LISTEN) > slpd 2786 daemon 9u IPv4 6420 0t0 UDP > 239.255.255.253:svrloc > slpd 2786 daemon 10u IPv4 6421 0t0 UDP > 3724G-21104-2.hsr.ch:svrloc > > Then I start my application which registers the following two services > with SLP: > service:TrackingNode.ADEC:CP:// > 10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea > service:TrackingNode.ADEC:CP:// > 192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea > > Of course my application opens a socket to listen to port 1234. Now comes > the part that surprised me: slpd also begins to listen to port 1234 > (why??). "lsof -i" shows this: > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > *TrackingN 4795 root 6u IPv4 12170 0t0 TCP *:1234 > (LISTEN)* > TrackingN 4795 root 7u IPv4 12186 0t0 TCP > localhost:45272->localhost:svrloc (ESTABLISHED) > slpd 4805 daemon 0u IPv4 12189 0t0 TCP > localhost:svrloc->localhost:45272 (ESTABLISHED) > slpd 4805 daemon 1u IPv4 12204 0t0 UDP *:37734 > slpd 4805 daemon 2u IPv4 12199 0t0 UDP *:49554 > slpd 4805 daemon 4u IPv4 12176 0t0 TCP > localhost:svrloc (LISTEN) > slpd 4805 daemon 5u IPv4 12177 0t0 TCP > DebianWheezy.local:svrloc (LISTEN) > *slpd 4805 daemon 6u IPv4 12170 0t0 TCP *:1234 > (LISTEN)* > slpd 4805 daemon 7u IPv4 12178 0t0 UDP > 239.255.255.253:svrloc > slpd 4805 daemon 8u IPv4 12179 0t0 UDP > DebianWheezy.local:svrloc > slpd 4805 daemon 9u IPv4 12180 0t0 TCP > 3724G-21104-2.hsr.ch:svrloc (LISTEN) > slpd 4805 daemon 10u IPv4 12181 0t0 UDP > 239.255.255.253:svrloc > slpd 4805 daemon 11u IPv4 12182 0t0 UDP > 3724G-21104-2.hsr.ch:svrloc > > And then, when I quit my application, slpd keeps listening on port 1234: > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > slpd 4816 daemon 4u IPv4 12317 0t0 TCP > localhost:svrloc (LISTEN) > slpd 4816 daemon 5u IPv4 12318 0t0 TCP > DebianWheezy.local:svrloc (LISTEN) > *slpd 4816 daemon 6u IPv4 12170 0t0 TCP *:1234 > (LISTEN)* > slpd 4816 daemon 7u IPv4 12319 0t0 UDP > 239.255.255.253:svrloc > slpd 4816 daemon 8u IPv4 12320 0t0 UDP > DebianWheezy.local:svrloc > slpd 4816 daemon 9u IPv4 12321 0t0 TCP > 3724G-21104-2.hsr.ch:svrloc (LISTEN) > slpd 4816 daemon 10u IPv4 12322 0t0 UDP > 239.255.255.253:svrloc > slpd 4816 daemon 11u IPv4 12323 0t0 UDP > 3724G-21104-2.hsr.ch:svrloc > slpd 4816 daemon 13u IPv4 12326 0t0 UDP *:47496 > > Now when I restart my application and it tries to open a socket to listen > to port 1234 again, I get an "Address already in use" error, since slpd > still occupies that port. > > Can anyone explain what's happening here? Why does slpd hijack my port? > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Openslp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openslp-users > > |
|
From: Nick W. <ne...@wi...> - 2012-10-15 14:49:34
|
You can periodically see what directory agents are online by looking for the "service:directory-agent" service on slp. Theoretically, you could also look for service agents with "service:service-agent", although I haven't tried that in quite a while. --Nick On Mon, Oct 15, 2012 at 9:32 AM, Wang, Ren <Ren...@nu...> wrote: > I would like know what’s the good way/tool to monitor DAs and SAs in a > productions environment.**** > > ** ** > > Regards,**** > > ** ** > > Ren**** > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Openslp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openslp-users > > |
|
From: Wang, R. <Ren...@nu...> - 2012-10-15 14:32:27
|
I would like know what's the good way/tool to monitor DAs and SAs in a productions environment. Regards, Ren |
|
From: Robert H. <rh...@hs...> - 2012-10-12 08:38:06
|
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I recently ported my application from Windows to Linux and now I'm
experiencing some strange problem when running it under Debian
together with OpenSLP 1.2.1-9 (this is the version that comes out of
the box with Debian).<br>
<br>
The problem is that slpd seems to occupy the port I'm using for my
application. Let me explain...<br>
<br>
Before I start my application, "<tt>lsof -i</tt>" lists the
following spld related entries:<br>
<br>
<tt>COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME</tt><tt><br>
</tt><tt>slpd 2786 daemon 4u IPv4 6415 0t0 TCP
localhost:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 2786 daemon 5u IPv4 6416 0t0 TCP
DebianWheezy.local:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 2786 daemon 6u IPv4 6417 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 2786 daemon 7u IPv4 6418 0t0 UDP
DebianWheezy.local:svrloc </tt><tt><br>
</tt><tt>slpd 2786 daemon 8u IPv4 6419 0t0 TCP
3724G-21104-2.hsr.ch:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 2786 daemon 9u IPv4 6420 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 2786 daemon 10u IPv4 6421 0t0 UDP
3724G-21104-2.hsr.ch:svrloc </tt><br>
<br>
Then I start my application which registers the following two
services with SLP:<br>
<tt>service:TrackingNode.ADEC:CP://10.0.2.15:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea</tt><tt><br>
</tt><tt>service:TrackingNode.ADEC:CP://192.168.0.24:1234/1c736ed2-e8b7-545c-998a-2ce095e600ea</tt><br>
<br>
Of course my application opens a socket to listen to port 1234. Now
comes the part that surprised me: slpd also begins to listen to port
1234 (why??). "<tt>lsof -i</tt>" shows this:<br>
<br>
<tt>COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME</tt><tt><br>
</tt><tt><b>TrackingN 4795 root 6u IPv4 12170 0t0
TCP *:1234 (LISTEN)</b></tt><tt><br>
</tt><tt>TrackingN 4795 root 7u IPv4 12186 0t0 TCP
localhost:45272->localhost:svrloc (ESTABLISHED)</tt><tt><br>
</tt><tt>slpd 4805 daemon 0u IPv4 12189 0t0 TCP
localhost:svrloc->localhost:45272 (ESTABLISHED)</tt><tt><br>
</tt><tt>slpd 4805 daemon 1u IPv4 12204 0t0 UDP
*:37734 </tt><tt><br>
</tt><tt>slpd 4805 daemon 2u IPv4 12199 0t0 UDP
*:49554 </tt><tt><br>
</tt><tt>slpd 4805 daemon 4u IPv4 12176 0t0 TCP
localhost:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 4805 daemon 5u IPv4 12177 0t0 TCP
DebianWheezy.local:svrloc (LISTEN)</tt><tt><br>
</tt><tt><b>slpd 4805 daemon 6u IPv4 12170 0t0
TCP *:1234 (LISTEN)</b></tt><tt><br>
</tt><tt>slpd 4805 daemon 7u IPv4 12178 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 4805 daemon 8u IPv4 12179 0t0 UDP
DebianWheezy.local:svrloc </tt><tt><br>
</tt><tt>slpd 4805 daemon 9u IPv4 12180 0t0 TCP
3724G-21104-2.hsr.ch:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 4805 daemon 10u IPv4 12181 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 4805 daemon 11u IPv4 12182 0t0 UDP
3724G-21104-2.hsr.ch:svrloc </tt><br>
<br>
And then, when I quit my application, slpd keeps listening on port
1234:<br>
<br>
<tt>COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME</tt><tt><br>
</tt><tt>slpd 4816 daemon 4u IPv4 12317 0t0 TCP
localhost:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 4816 daemon 5u IPv4 12318 0t0 TCP
DebianWheezy.local:svrloc (LISTEN)</tt><tt><br>
</tt><b><tt>slpd 4816 daemon 6u IPv4 12170 0t0
TCP *:1234 (LISTEN)</tt></b><tt><br>
</tt><tt>slpd 4816 daemon 7u IPv4 12319 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 4816 daemon 8u IPv4 12320 0t0 UDP
DebianWheezy.local:svrloc </tt><tt><br>
</tt><tt>slpd 4816 daemon 9u IPv4 12321 0t0 TCP
3724G-21104-2.hsr.ch:svrloc (LISTEN)</tt><tt><br>
</tt><tt>slpd 4816 daemon 10u IPv4 12322 0t0 UDP
239.255.255.253:svrloc </tt><tt><br>
</tt><tt>slpd 4816 daemon 11u IPv4 12323 0t0 UDP
3724G-21104-2.hsr.ch:svrloc </tt><tt><br>
</tt><tt>slpd 4816 daemon 13u IPv4 12326 0t0 UDP
*:47496 </tt><br>
<br>
Now when I restart my application and it tries to open a socket to
listen to port 1234 again, I get an "Address already in use" error,
since slpd still occupies that port.<br>
<br>
Can anyone explain what's happening here? Why does slpd hijack my
port?<br>
</body>
</html>
|
|
From: Nick W. <ne...@wi...> - 2012-09-14 18:06:18
|
I suspect this may be a bug in openslp, but I haven't tried to recreate this myself. Whenever I've needed to filter based on attribute, it was always a single attribute. --Nick On Mon, Sep 10, 2012 at 9:02 AM, Wang, Ren <Ren...@nu...> wrote: > I wonder how to use the SLPFindSrvs API with a filter. **** > > ** ** > > I registered a service with the following sample code:**** > > ** ** > > SLPReg( hslp, "service:drc://10.16.4.157:2921", SLP_LIFETIME_MAXIMUM, 0, * > *** > > "(userID=user1),(appID=2222222)", SLP_TRUE, **** > > slpRegCallback, &callback_err );**** > > ** ** > > ** ** > > When I try to use the same filter with two attributes, > "(userID=user1),(appID=2222222)", to search the service, it will fail. *** > * > > ** ** > > ** ** > > SLPFindSrvs ( hslp, "service:drc", "default", > "(userID=user1),(appID=2222222)",**** > > slpSrvURLCallback, &callback_err );**** > > ** ** > > ** ** > > ** ** > > But, when I only specify a single attribute, it works, E.g. **** > > ** ** > > SLPFindSrvs ( hslp, "service:drc", "default", "(userID=user1)",**** > > slpSrvURLCallback, &callback_err );**** > > ** ** > > Or**** > > ** ** > > SLPFindSrvs ( hslp, "service:drc", "default", "(appID=2222222)",**** > > slpSrvURLCallback, &callback_err );**** > > ** ** > > ** ** > > I would like know if it is code error or it is the limitation of the > OpenSLP?**** > > ** ** > > Regards,**** > > ** ** > > Ren**** > > ** ** > > ** ** > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openslp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openslp-users > > |
|
From: Wang, R. <Ren...@nu...> - 2012-09-10 14:02:54
|
I wonder how to use the SLPFindSrvs API with a filter.
I registered a service with the following sample code:
SLPReg( hslp, "service:drc://10.16.4.157:2921", SLP_LIFETIME_MAXIMUM, 0,
"(userID=user1),(appID=2222222)", SLP_TRUE,
slpRegCallback, &callback_err );
When I try to use the same filter with two attributes, "(userID=user1),(appID=2222222)", to search the service, it will fail.
SLPFindSrvs ( hslp, "service:drc", "default", "(userID=user1),(appID=2222222)",
slpSrvURLCallback, &callback_err );
But, when I only specify a single attribute, it works, E.g.
SLPFindSrvs ( hslp, "service:drc", "default", "(userID=user1)",
slpSrvURLCallback, &callback_err );
Or
SLPFindSrvs ( hslp, "service:drc", "default", "(appID=2222222)",
slpSrvURLCallback, &callback_err );
I would like know if it is code error or it is the limitation of the OpenSLP?
Regards,
Ren
|
|
From: Nick W. <ne...@wi...> - 2012-09-07 19:45:56
|
My answers below: On Fri, Sep 7, 2012 at 9:12 AM, Wang, Ren <Ren...@nu...> wrote: > [..] > > **1) **Based on the RFC 2608, the user agent may conduct SrvRqst by > sending a Unicast message to Directory Agent. I am assuming the API would > be SLPFindSrvs API to do it. Where can I assign the DA IP/Hostname for > Unicast message? > I don't know if there's a way to force this through the api or slp.conf. I couldn't find it, offhand. The library looks for Directory agents via multicast, and will unicast to the DAs found. Barring discovery of a DA, the library will multicast the queries. > **** > > **2) **Does slpd process has to be installed one very machine in > order to make Service Registration and Service Request? If not, how to > specific the IP address for remote SA/DA to register service and service > request? > Yes, the slpd process needs to be installed on every machine. The library connects to the process via loopback to do all Service Registrations. slpd is not needed for Service Requests. One reason slpd needs to be running is because the slp protocol requires listening on well-known IP ports (e.g. 427) which may not be shared between processes. So the processes need the central service to handle slp. > **** > > **3) **If the process calling the SLPReg terminated, does service > registration will be cleared from the SA/DA? > This can be turned on for local registrations with the net.slp.watchRegistrationPID setting in slp.conf. For remote registrations, the timeouts are the only guarantee the service will be cleared. --Nick > ** > |
|
From: Wang, R. <Ren...@nu...> - 2012-09-07 14:12:53
|
Hello, I am doing some testing on OpenSLP now and have following questions: 1) Based on the RFC 2608, the user agent may conduct SrvRqst by sending a Unicast message to Directory Agent. I am assuming the API would be SLPFindSrvs API to do it. Where can I assign the DA IP/Hostname for Unicast message? 2) Does slpd process has to be installed one very machine in order to make Service Registration and Service Request? If not, how to specific the IP address for remote SA/DA to register service and service request? 3) If the process calling the SLPReg terminated, does service registration will be cleared from the SA/DA? Regards, Ren |
|
From: Nick W. <ne...@wi...> - 2012-08-24 16:22:25
|
I've never run any automated tests. For me, basic functionality with and without directory agents is enough, making sure you can get component attributes, a couple of sanity sniffs of the network, etc. --Nick |
|
From: Jim M. <jim...@wb...> - 2012-08-22 14:34:59
|
Is there list of what needs to be done? We may have some spare cycles to work on them. Jim Nick Wagner wrote: > I'm not sure right now. There appears to be one or two outstanding > items on this mailing list, and everyone seems to be busy. I brought > the same issue up a couple of weeks ago, and then my priorities were > shifted at work, so I let it drop. > > --Nick > > On Mon, Aug 20, 2012 at 10:40 AM, Jim Marshall > <jim...@wb... > <mailto:jim...@wb...>> wrote: > > Hi, > We're in the midst of planning our next major release and would > like to have OpenSLP 2.0 as part of that product. We would prefer > to have a 2.0 release rather then a BETA or snapshot, what needs > to be done to make that happen? > > Jim > -- > Jim Marshall > > Sr. Software Engineer > WS <http://ws-inc.com/> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. > Discussions > will include endpoint security, mobile security and the latest in > malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openslp-users mailing list > Ope...@li... > <mailto:Ope...@li...> > https://lists.sourceforge.net/lists/listinfo/openslp-users > > -- mail Jim Marshall Sr. Software Engineer WS <http://ws-inc.com/> |
|
From: Nick W. <ne...@wi...> - 2012-08-21 19:47:38
|
I'm not sure right now. There appears to be one or two outstanding items on this mailing list, and everyone seems to be busy. I brought the same issue up a couple of weeks ago, and then my priorities were shifted at work, so I let it drop. --Nick On Mon, Aug 20, 2012 at 10:40 AM, Jim Marshall < jim...@wb...> wrote: > Hi, > We're in the midst of planning our next major release and would like to > have OpenSLP 2.0 as part of that product. We would prefer to have a 2.0 > release rather then a BETA or snapshot, what needs to be done to make that > happen? > > Jim > -- > Jim Marshall Sr. Software Engineer > [image: WS] <http://ws-inc.com/> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openslp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openslp-users > > |
|
From: Jim M. <jim...@wb...> - 2012-08-20 15:56:27
|
Hi, We're in the midst of planning our next major release and would like to have OpenSLP 2.0 as part of that product. We would prefer to have a 2.0 release rather then a BETA or snapshot, what needs to be done to make that happen? Jim -- mail Jim Marshall Sr. Software Engineer WS <http://ws-inc.com/> |
|
From: Hird M. <Mat...@uk...> - 2012-05-15 15:27:41
|
I'm not sure what you're asking here Ryan? If your core problem is your /etc/resolv.conf file, isn't it best to fix it? Can you post your slp.conf file? cheers Matt -----Original Message----- From: Ryan Raasch [mailto:rya...@gm...] Sent: 15 May 2012 08:56 To: ope...@li... Subject: [Openslp-users] DHCP DA Discovery Hello, The slpd is being restarted because the interface ip's change (i have now grasped the IGMP stuff :). However, we have noticed that when the daemon starts, the daemon attempts to contact a DHCP server to obtain the DA, which our box is not. But within the networks we run the server, there will be no DA machines. The core problem with this is that /etc/resolv.conf has entries which no longer reflect the system's network settings. That is to say, rather, during startup of the daemon, this DA disovery takes place and causes the daemonize of the deamon to be delayed. In our system, we had an issue of the hostname was not located in /etc/hosts, so the DA Discovery did a nslookup of the hostname from a dns server which was not available of the system (we fixed this). However, the underlying issue of disabling DA discovery completely would be nice. /Ryan ---------------------------------------------------------------------------- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ 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. |
|
From: Ryan R. <rya...@gm...> - 2012-05-15 07:56:30
|
Hello, The slpd is being restarted because the interface ip's change (i have now grasped the IGMP stuff :). However, we have noticed that when the daemon starts, the daemon attempts to contact a DHCP server to obtain the DA, which our box is not. But within the networks we run the server, there will be no DA machines. The core problem with this is that /etc/resolv.conf has entries which no longer reflect the system's network settings. That is to say, rather, during startup of the daemon, this DA disovery takes place and causes the daemonize of the deamon to be delayed. In our system, we had an issue of the hostname was not located in /etc/hosts, so the DA Discovery did a nslookup of the hostname from a dns server which was not available of the system (we fixed this). However, the underlying issue of disabling DA discovery completely would be nice. /Ryan |
|
From: Jim M. <jim...@wb...> - 2012-05-10 19:35:31
|
John Calcote wrote: > Hi Jim, > > What platform? I noted that you stated "slptool crashes (stops responding on > windows)" Does this mean slptool crashes on various linux/unix platforms, > and the way it manifests on windows to not to actually crash, but to simply > hang? There is one interesting thing we can do on windows. Have the user go > into task manager and right click on the slptool process and choose the > "Create dump file" option. Then send along the dump file that gets created. > It may be possible to pull that dump file into visual studio debugger and > see what the call stack for each thread looks like. Hi John, Yes it crashes on Linux and they get the "program has stopped responding, do you want to terminate the process" on Windows. I'll have them generate the dump file, hadn't thought of that. > > On linux/unix systems, you can enable core dumps (ulimit -c unlimited). Then > examine the core file in gdb the same way. > > John > > >> -----Original Message----- >> From: Jim Marshall [mailto:jim...@wb...] >> Sent: Thursday, May 10, 2012 11:08 AM >> To: ope...@li... >> Subject: [Openslp-users] slptool crashing, need thoughts >> >> Hi, >> We have a customer who is using various SLP agents on a decent sized >> network. They are seeing a problem when they do a 'slptool findsrvs ...' >> they get about 23 responses and then slptool crashes (stops responding on >> windows). We can not duplicate this issue, and have tested up to >> 1,000 registrations. I had them use WireShark to get the packets, below is > the >> last packet that is received before slptool dies. Can anyone take a look > at this >> and see if there is something malformed? >> >> Is there a way to have slptool output debug info? >> >> Can anyone think of some ideas on how to resolve this issue? >> >> Customer is using SLP 1.0.9a. >> >> Thank you >> >> >> >> 0000 01 00 5e 7f ff fd 00 1b ed 0f bc 00 08 00 45 00 ..^...........E. >> 0010 00 4d 00 00 40 00 fe 11 63 0e 0a 18 1f 7c ef ff .M..@...c....|.. >> 0020 ff fd 01 ab 01 ab 00 39 a2 e8 02 01 00 00 31 20 .......9......1 >> 0030 00 00 00 00 94 d0 00 02 65 6e 00 00 00 17 73 65 ........en....se >> 0040 72 76 69 63 65 3a 64 69 72 65 63 74 6f 72 79 2d rvice:directory- >> 0050 61 67 65 6e 74 00 00 00 00 00 00 agent...... >> >> >> > ---------------------------------------------------------------------------- > -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and threat >> landscape has changed and how IT managers can respond. Discussions will >> include endpoint security, mobile security and the latest in malware > threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Openslp-users mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openslp-users > -- Jim Marshall Sr. Software Engineer WS <http://ws-inc.com/> |
|
From: John C. <joh...@gm...> - 2012-05-10 17:41:13
|
Hi Jim, What platform? I noted that you stated "slptool crashes (stops responding on windows)" Does this mean slptool crashes on various linux/unix platforms, and the way it manifests on windows to not to actually crash, but to simply hang? There is one interesting thing we can do on windows. Have the user go into task manager and right click on the slptool process and choose the "Create dump file" option. Then send along the dump file that gets created. It may be possible to pull that dump file into visual studio debugger and see what the call stack for each thread looks like. On linux/unix systems, you can enable core dumps (ulimit -c unlimited). Then examine the core file in gdb the same way. John > -----Original Message----- > From: Jim Marshall [mailto:jim...@wb...] > Sent: Thursday, May 10, 2012 11:08 AM > To: ope...@li... > Subject: [Openslp-users] slptool crashing, need thoughts > > Hi, > We have a customer who is using various SLP agents on a decent sized > network. They are seeing a problem when they do a 'slptool findsrvs ...' > they get about 23 responses and then slptool crashes (stops responding on > windows). We can not duplicate this issue, and have tested up to > 1,000 registrations. I had them use WireShark to get the packets, below is the > last packet that is received before slptool dies. Can anyone take a look at this > and see if there is something malformed? > > Is there a way to have slptool output debug info? > > Can anyone think of some ideas on how to resolve this issue? > > Customer is using SLP 1.0.9a. > > Thank you > > > > 0000 01 00 5e 7f ff fd 00 1b ed 0f bc 00 08 00 45 00 ..^...........E. > 0010 00 4d 00 00 40 00 fe 11 63 0e 0a 18 1f 7c ef ff .M..@...c....|.. > 0020 ff fd 01 ab 01 ab 00 39 a2 e8 02 01 00 00 31 20 .......9......1 > 0030 00 00 00 00 94 d0 00 02 65 6e 00 00 00 17 73 65 ........en....se > 0040 72 76 69 63 65 3a 64 69 72 65 63 74 6f 72 79 2d rvice:directory- > 0050 61 67 65 6e 74 00 00 00 00 00 00 agent...... > > > ---------------------------------------------------------------------------- -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Openslp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openslp-users |
|
From: Jim M. <jim...@wb...> - 2012-05-10 17:35:09
|
Hi, We have a customer who is using various SLP agents on a decent sized network. They are seeing a problem when they do a 'slptool findsrvs ...' they get about 23 responses and then slptool crashes (stops responding on windows). We can not duplicate this issue, and have tested up to 1,000 registrations. I had them use WireShark to get the packets, below is the last packet that is received before slptool dies. Can anyone take a look at this and see if there is something malformed? Is there a way to have slptool output debug info? Can anyone think of some ideas on how to resolve this issue? Customer is using SLP 1.0.9a. Thank you 0000 01 00 5e 7f ff fd 00 1b ed 0f bc 00 08 00 45 00 ..^...........E. 0010 00 4d 00 00 40 00 fe 11 63 0e 0a 18 1f 7c ef ff .M..@...c....|.. 0020 ff fd 01 ab 01 ab 00 39 a2 e8 02 01 00 00 31 20 .......9......1 0030 00 00 00 00 94 d0 00 02 65 6e 00 00 00 17 73 65 ........en....se 0040 72 76 69 63 65 3a 64 69 72 65 63 74 6f 72 79 2d rvice:directory- 0050 61 67 65 6e 74 00 00 00 00 00 00 agent...... |
|
From: Jim M. <jim...@wb...> - 2012-04-23 19:34:49
|
Hird Matthew wrote: > I've never come across that problem Jim. I'm not aware of any > interoperability issues either but do you know what svn revision 1.0.9a > corresponds to? Hi Matthew, Thank you for taking the time to reply. I believe the 1.0.9a release predates SVN (it is *really* old), but the tarball is on the openslp site. We got a little more info from our client. If they filter the slptool results so that it only returns information from our server (using OpenSLP) it works fine. So we now are trying to get them to figure out what server might be causing the problem, which is slow going. Thank you > > > > -----Original Message----- > From: Jim Marshall [mailto:jim...@wb...] > Sent: 19 April 2012 15:45 > To: ope...@li... > Subject: [Openslp-users] slptool lists 25 entries and crashes? > > Hello, > We have a situation where a client is utilizing slptool (1.0.9a - client > is not able to upgrade to 1.1 or 2.0) on Windows and Linux to do a findsrvs > operation. When doing this they say the first 25 servers are listed and then > slptool seg faults. Has anyone heard of this happening or have thoughts on > what we can do to diagnose the issue - we can not reproduce this in our > environment. > > Are there any known incompatibility with slptool and other SLP DA's (we're > checking with the client to see what types of DA's they have)? > > > Thank you > > ---------------------------------------------------------------------------- > -- > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > 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. > > -- Jim Marshall Sr. Software Engineer WS <http://ws-inc.com/> |
|
From: Hird M. <Mat...@uk...> - 2012-04-23 10:36:55
|
I've never come across that problem Jim. I'm not aware of any interoperability issues either but do you know what svn revision 1.0.9a corresponds to? -----Original Message----- From: Jim Marshall [mailto:jim...@wb...] Sent: 19 April 2012 15:45 To: ope...@li... Subject: [Openslp-users] slptool lists 25 entries and crashes? Hello, We have a situation where a client is utilizing slptool (1.0.9a - client is not able to upgrade to 1.1 or 2.0) on Windows and Linux to do a findsrvs operation. When doing this they say the first 25 servers are listed and then slptool seg faults. Has anyone heard of this happening or have thoughts on what we can do to diagnose the issue - we can not reproduce this in our environment. Are there any known incompatibility with slptool and other SLP DA's (we're checking with the client to see what types of DA's they have)? Thank you ---------------------------------------------------------------------------- -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ 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. |
|
From: Jim M. <jim...@wb...> - 2012-04-19 15:37:30
|
Hello, We have a situation where a client is utilizing slptool (1.0.9a - client is not able to upgrade to 1.1 or 2.0) on Windows and Linux to do a findsrvs operation. When doing this they say the first 25 servers are listed and then slptool seg faults. Has anyone heard of this happening or have thoughts on what we can do to diagnose the issue - we can not reproduce this in our environment. Are there any known incompatibility with slptool and other SLP DA's (we're checking with the client to see what types of DA's they have)? Thank you |
|
From: Devchandra L. <del...@in...> - 2012-04-18 07:24:52
|
Hi All is the IPv6 support in openslp understands zone-id in link-local address? I am unable to register url like [fe80::221:ccff:fe62:9346%eth0]:5988 but it handles [fe80::221:ccff:fe62:9346]:5988 Warm Regards D>L> Meetei IBM India System and Technology Lab EGL -D,Bangalore, India |
|
From: Ryan R. <rya...@gm...> - 2012-04-04 08:44:54
|
On 3 April 2012 12:50, Hird Matthew <Mat...@uk...> wrote: > Ryan > > Is there any reason why listing all the interfaces you want to use in the > slp.net.interfaces property wouldn't work? The problem or drawback of that is the daemon needs to be restarted to re-enumerate the network device(s). And the the other issue is that the property refers to the actual ip address, not a network interface. Everything is peachy if you have a static network system. But when hot-plugging interfaces into different networks etc., then the daemon restart is not so attractive. If the property actually referred to eth0,eth1, etc., that would be really cool. Then could listen for changes to ip addresses on these interfaces, and change/join accordingly (netlink would be a nice way to monitor this). /Ryan > > cheers > Matt > > -----Original Message----- > From: Ryan Raasch [mailto:rya...@gm...] > Sent: 03 April 2012 09:33 > To: Nick Wagner > Cc: ope...@li... > Subject: Re: [Openslp-users] attach to device failed > > On 3 April 2012 03:37, Nick Wagner <ne...@wi...> wrote: >> 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. > Big thanks for the feedback! > > I think I have somewhat wrapped my head around the problem. The delayed > started is not really the issue. I think it was my misunderstanding of the > IGMP join stuff. > 0.0.0.0 in the multicast context means default route. So, each of the > interfaces need to be enumerated and used. Our implementation uses the b), > and will suffice. > > However, what have been the proposed solutions to dynamically loading the > changed interfaces? I made a quick hack with the code, but it wasn't an hour > job to just call the functions terminate signal invokes. > > Where there any discussion regarding some type of SLPGetInterfaces() > SLPScanInterfaces() > etc. over the socket interface? Or where they more on the lines of signal > handlers? > I would be nice for any application to know which interfaces the daemon is > registered on. > > > /Ryan > >> >> --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 >> >> > > ---------------------------------------------------------------------------- > -- > Better than sec? Nothing is better than sec when it comes to monitoring Big > Data applications. Try Boundary one-second resolution app monitoring today. > Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > 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. > |
|
From: Hird M. <Mat...@uk...> - 2012-04-03 10:50:47
|
Ryan Is there any reason why listing all the interfaces you want to use in the slp.net.interfaces property wouldn't work? cheers Matt -----Original Message----- From: Ryan Raasch [mailto:rya...@gm...] Sent: 03 April 2012 09:33 To: Nick Wagner Cc: ope...@li... Subject: Re: [Openslp-users] attach to device failed On 3 April 2012 03:37, Nick Wagner <ne...@wi...> wrote: > 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. Big thanks for the feedback! I think I have somewhat wrapped my head around the problem. The delayed started is not really the issue. I think it was my misunderstanding of the IGMP join stuff. 0.0.0.0 in the multicast context means default route. So, each of the interfaces need to be enumerated and used. Our implementation uses the b), and will suffice. However, what have been the proposed solutions to dynamically loading the changed interfaces? I made a quick hack with the code, but it wasn't an hour job to just call the functions terminate signal invokes. Where there any discussion regarding some type of SLPGetInterfaces() SLPScanInterfaces() etc. over the socket interface? Or where they more on the lines of signal handlers? I would be nice for any application to know which interfaces the daemon is registered on. /Ryan > > --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 > > ---------------------------------------------------------------------------- -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ 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. |
|
From: Ryan R. <rya...@gm...> - 2012-04-03 08:33:31
|
On 3 April 2012 03:37, Nick Wagner <ne...@wi...> wrote: > 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. Big thanks for the feedback! I think I have somewhat wrapped my head around the problem. The delayed started is not really the issue. I think it was my misunderstanding of the IGMP join stuff. 0.0.0.0 in the multicast context means default route. So, each of the interfaces need to be enumerated and used. Our implementation uses the b), and will suffice. However, what have been the proposed solutions to dynamically loading the changed interfaces? I made a quick hack with the code, but it wasn't an hour job to just call the functions terminate signal invokes. Where there any discussion regarding some type of SLPGetInterfaces() SLPScanInterfaces() etc. over the socket interface? Or where they more on the lines of signal handlers? I would be nice for any application to know which interfaces the daemon is registered on. /Ryan > > --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 > > |
62 messages has been excluded from this view by a project administrator.
