openslp-users Mailing List for OpenSLP
Brought to you by:
jcalcote
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: Turritopsis D. T. En M. <tdt...@gm...> - 2023-02-09 12:47:45
|
Subject: VMware ESXi servers are massively hacked worldwide due to heap-based buffer overflow in OpenSLP Good day from Singapore, I am sharing this article for more awareness. Article: Hackers are mass infecting servers worldwide by exploiting a patched hole Link: https://arstechnica.com/information-technology/2023/02/hackers-are-mass-infecting-servers-worldwide-by-exploiting-a-patched-hole/ [QUOTE] The vulnerability being exploited to infect the servers is CVE-2021-21974, which stems from a heap-based buffer overflow in OpenSLP, an open network-discovery standard that’s incorporated into ESXi. When VMware patched the vulnerability in February 2021, the company warned it could be exploited by a malicious actor with access to the same network segment over port 427. The vulnerability had a severity rating of 8.8 out of a possible 10. Proof-of-concept exploit code and instructions for using it became available a few months later. [/QUOTE] Thank you. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com |
From: Daniel S. <ds...@ma...> - 2019-12-17 15:59:51
|
HEllo, I hope that somebady is alive here :) I try to use slp to find our machines in a foreign network. To do this I configured the openslp server and statically registered a service with a unique name. For I while I can find all my machines with slptool. But then, after a while, the machines are not responding to my slptool calls. How can I fgure out the cause of this? I runned a "tcpdump igmp" and there are a lot of reports.... I configured "net.slp.isBroadcastOnly = true" on all machines, but it didn't help. What can I do to figure out the cause for this? Regards Daniel -- Daniel Spannbauer Systemadministration marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11 Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220 http://www.marco.de/ Email ds...@ma... Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München |
From: John C. <joh...@gm...> - 2019-09-13 21:46:40
|
*General Announcement* The OpenSLP project has moved to github Link: https://github.com/openslp-org/openslp I've migrated the entire project history from the existing sf.net mercurial repository to the new github.com git repository. The issue board has also officially moved to the github project site and I will be migrating top issues from SF.net to the github issue board over the coming weeks. Currently, the sf.net project has a redirect badge at the top of the summary page that redirects to the github project, along with a note in the summary text that indicates the move. Finally, the openslp git project exists (as you can see from the url above) under the openslp-org organization. I'm currently the only member of the organization. If anyone is interested in joining, please email me on the openslp-devel mailing list at ope...@li... (still hosted by sf.net at this time). I hope this move encourages contributors to open pull requests as this seems to be the modern way of submitting patches to open source projects. Thanks, John Calcote OpenSLP.org |
From: Samer V. <sba...@ya...> - 2015-12-09 13:59:56
|
Please find attached patch file that fixes this crash. Added developers to review and approve. From: Samer Vazdekis <sba...@ya...> To: "ope...@li..." <ope...@li...> Sent: Tuesday, December 8, 2015 8:58 PM Subject: Re: Nessus crashing slpd Found the bug and fixed it. Will post a .diff file very soon. From: Samer Vazdekis <sba...@ya...> To: "ope...@li..." <ope...@li...> Sent: Sunday, December 6, 2015 8:30 PM Subject: Nessus crashing slpd Hi there, Has anyone come across an issue where Nessus security scan software crashes the slpd service when running a scan? The crash is here, /** Free an SLPBuffer. * * This routine releases the memory for a previously allocated * @c SLPBuffer object. * * @param[in] buf The SLPBuffer to be freed. */ void SLPBufferFree(SLPBuffer buf) { xfree(buf); } It looks like an attempt to free an already freed buffer. was wondering if there is already a fix for this. Thanks,Sam. |
From: Samer V. <sba...@ya...> - 2015-12-09 02:01:23
|
Found the bug and fixed it. Will post a .diff file very soon. From: Samer Vazdekis <sba...@ya...> To: "ope...@li..." <ope...@li...> Sent: Sunday, December 6, 2015 8:30 PM Subject: Nessus crashing slpd Hi there, Has anyone come across an issue where Nessus security scan software crashes the slpd service when running a scan? The crash is here, /** Free an SLPBuffer. * * This routine releases the memory for a previously allocated * @c SLPBuffer object. * * @param[in] buf The SLPBuffer to be freed. */ void SLPBufferFree(SLPBuffer buf) { xfree(buf); } It looks like an attempt to free an already freed buffer. was wondering if there is already a fix for this. Thanks,Sam. |
From: Samer V. <sba...@ya...> - 2015-12-07 01:30:13
|
Hi there, Has anyone come across an issue where Nessus security scan software crashes the slpd service when running a scan? The crash is here, /** Free an SLPBuffer. * * This routine releases the memory for a previously allocated * @c SLPBuffer object. * * @param[in] buf The SLPBuffer to be freed. */ void SLPBufferFree(SLPBuffer buf) { xfree(buf); } It looks like an attempt to free an already freed buffer. was wondering if there is already a fix for this. Thanks,Sam. |
From: Remi C. <rem...@gm...> - 2015-08-14 23:35:14
|
Hi, I would like to know if there is a Javascript API for SLP discovery ? The goal is to display SLP registered services from an Internet browser. Thanks Remi |
From: Rick B. <ric...@ya...> - 2015-05-27 16:16:07
|
I'm trying to get 2 DA's to sync up their registration and it is not working and looking for suggestions net.spl.DASyncReg is set to true in the config and I have 2 DA addresses listed on the net.slp.DAAddresses line. On a third server (using as an SA) I register a service on DA1 and can see that service using SLPTool pointed to DA1 but the registration never seems to be available from DA2 even after a restart of slpd I'm a little unclear on some of the uses of the config items and maybe that is contributing to my problems: for net.slp.DAAddresses conf file says this line is for UA's and SA's to find DA's but is it also used by DAs to know where to send new registrations on a sync operation? for net.slp.DASyncReg, conf file says this makes the DA's sync on startup but what about for new registrations, do those sync as well and if so what type of communication should I expect to see in a trace for this sync operation? I'm not seeing syncronization even on a restart of the Daemon. |
From: Daniel F. <dan...@gm...> - 2015-04-09 21:03:45
|
I’ve built openslp on OS X 10 and it compiles without warning/errors. I’ve tested with the tools (slptool) and adding in the libspl.a and related headers and attempting to put some code together. The tool returns nothing from testing, however runs fine on linux. OSX: $ slptool findsrvs VMwareInfrastructure $ Linux: $ slptool findsrvs VMwareInfrastructure service:VMwareInfrastructure://esxi01.fnnrn.me <http://esxi01.fnnrn.me/>,65535 service:VMwareInfrastructure://esxi02.fnnrn.me <http://esxi02.fnnrn.me/>,65535 $ Both running version 2.0.0 The test code (http://www.openslp.org/doc/html/ProgrammersGuide/SLPFindSrvs.html <http://www.openslp.org/doc/html/ProgrammersGuide/SLPFindSrvs.html>) compiled without warnings/errors just returns service URL = NULL - Dan |
From: <Menny_Hamburger@Dell.com> - 2014-08-07 11:23:28
|
Hi, I already sent a mail regarding this a few months ago. There are two issues: 1) The following patch should be added to the kernel: http://patchwork.ozlabs.org/patch/353841/ 2) This is a kernel patch that introduced the need to supply a scope id in ipv6 multicast interface-scoped address: http://www.spinics.net/lists/netdev/msg226124.html openslp needs to be modified to supply the scope ID so that it binds correctly to the requested interface. Best Regards, Menny -----Original Message----- From: Alois Mahdal [mailto:am...@re...] Sent: Wednesday, August 06, 2014 4:46 PM To: ope...@li... Subject: [Openslp-users] `slptool findsrvs` does not work with some attributes Hi, I'm playing with SLP configuration with slptools and a slp.reg that I made up according to examples in documentation and in shipped file. My machine is RHEL7 where the versions are: openslp-2.0.0-5.el7.x86_64 openslp-server-2.0.0-5.el7.x86_64 So my slp.reg contains records like this (actually ~9 similar records): service:http://host_red_l,en,65535 color=red size=l service:http://host_yellow_l,en,65535 color=red,green size=l Now when I try one of these: slptool findsrv service:http slptool findsrv service:http '(color=red)' slptool findattrs service:http://host_yellow_l nothing is returned. * In first case I'd expect all records (since all are "service:http"), * in second case, all where "color=red" (or where "red" id part of the "color" list but I 'm not sure if it's right interpretation) and * in third case, I'd expect list of attributes. /var/log/slpd.log does not contain any useful information. What am I doing wrong? Is there any way to debug this further? Thanks, aL. -- Alois Mahdal <am...@re...> Platform QE, BaseOS Daemons #qa, #brno, #daemons ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Openslp-users mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openslp-users |
From: Alois M. <am...@re...> - 2014-08-06 13:45:59
|
Hi, I'm playing with SLP configuration with slptools and a slp.reg that I made up according to examples in documentation and in shipped file. My machine is RHEL7 where the versions are: openslp-2.0.0-5.el7.x86_64 openslp-server-2.0.0-5.el7.x86_64 So my slp.reg contains records like this (actually ~9 similar records): service:http://host_red_l,en,65535 color=red size=l service:http://host_yellow_l,en,65535 color=red,green size=l Now when I try one of these: slptool findsrv service:http slptool findsrv service:http '(color=red)' slptool findattrs service:http://host_yellow_l nothing is returned. * In first case I'd expect all records (since all are "service:http"), * in second case, all where "color=red" (or where "red" id part of the "color" list but I 'm not sure if it's right interpretation) and * in third case, I'd expect list of attributes. /var/log/slpd.log does not contain any useful information. What am I doing wrong? Is there any way to debug this further? Thanks, aL. -- Alois Mahdal <am...@re...> Platform QE, BaseOS Daemons #qa, #brno, #daemons |
From: Alois M. <am...@re...> - 2014-07-31 11:48:55
|
Hi, If I have slp.reg like this: service:http://host1en,en,65535 service:http://host1fr,fr,65535 service:http://host2en,en,65535 service:http://host2fr,fr,65535 and I call $ slptool -l fr findsrvs service:http service:http://host1en,65535 service:http://host1fr,65535 service:http://host2en,65535 service:http://host2fr,65535 $ Shouldn't it only return host1fr and host2fr? Is this a bug or I have got something wrong? The above is from openslp-2.0.0-5.el7.x86_64 openslp-server-2.0.0-5.el7.x86_64 There's nothing interesting in slp.log and I haven't yet found way to enable additional logging. Thanks, aL -- Alois Mahdal <am...@re...> Platform QE Engineer at Red Hat, Inc. #brno, #daemons, #openlmi |
From: John C. <joh...@gm...> - 2014-07-30 19:58:33
|
The user agent (advertising application) is responsible for doing a refresh. This feature exists so that if the service crashes the advertisement will disappear within a reasonable time. John Sent via the Samsung GALAXY S®4, an AT&T 4G LTE smartphone <div>-------- Original message --------</div><div>From: Alois Mahdal <am...@re...> </div><div>Date:07/30/2014 12:57 PM (GMT-07:00) </div><div>To: ope...@li... </div><div>Subject: [Openslp-users] How to use the lifetime parameter </div><div> </div>Hi, I've been wondering: what is the use case of the "lifetime" in SLP? RFC says: > Clients indicate that they want URLs to be automatically > refreshed by setting the usLifetime parameter in the SLPReg() > function call to SLP_LIFETIME_MAXIMUM. This will cause the API > implementation to refresh the URL before it times out. Say I have a SA that provides service x, and it dynamically registers for 300s. So far it seems this means that service is likely to disappear after 5 minutes. OK, but the spec speaks about refreshing: who will do the refreshing? Can a good soul shed some light on this? Another example, I have a static registration with this record in /etc/slp.reg: sevice:http://myservice/,en,10000 what does that mean? From what I've read I understand that setting this to 65535 will have the service registration last forever (until slpd exits). But why would I want to use anything else? Thanks, aL. -- Alois Mahdal <am...@re...> Platform QE Engineer at Red Hat, Inc. #brno, #daemons, #openlmi ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Openslp-users mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openslp-users |
From: Alois M. <am...@re...> - 2014-07-30 18:57:34
|
Hi, I've been wondering: what is the use case of the "lifetime" in SLP? RFC says: > Clients indicate that they want URLs to be automatically > refreshed by setting the usLifetime parameter in the SLPReg() > function call to SLP_LIFETIME_MAXIMUM. This will cause the API > implementation to refresh the URL before it times out. Say I have a SA that provides service x, and it dynamically registers for 300s. So far it seems this means that service is likely to disappear after 5 minutes. OK, but the spec speaks about refreshing: who will do the refreshing? Can a good soul shed some light on this? Another example, I have a static registration with this record in /etc/slp.reg: sevice:http://myservice/,en,10000 what does that mean? From what I've read I understand that setting this to 65535 will have the service registration last forever (until slpd exits). But why would I want to use anything else? Thanks, aL. -- Alois Mahdal <am...@re...> Platform QE Engineer at Red Hat, Inc. #brno, #daemons, #openlmi |
From: <Menny_Hamburger@Dell.com> - 2014-03-23 14:18:47
|
Hello, Has anyone encountered issues with SLP failing to detect a RHEL7-beta service in a VMware guest (IPV6)? We have a large number of EL5/EL6 VM guests connected to the switch - all contained services are detected by slptool running on a machine connected to that subnet, while the RHEL7 service is unavailable. If we have more than one RHEL7 guests and run slptool from within the RHEL7 guest - we do see all the RHEL7 contained services (on all the others RHEL7 guests). For EL6 we use openslp2.0-beta (that supports IPV6). In RHEL7 we use the openslp2.0 available in the distribution, although we did try using the beta with no success. There is no difference in configuration between the openslp running on the EL5/EL6 guests and the one running in the RHEL7-beta guest. Thanks, Menny |
From: Hein-Pieter v. B. <hp...@tm...> - 2014-02-10 14:46:10
|
Hi all, I have a set of DAs running and a subset of client is having an odd problem where the DA returns the IP address of the client as a response to a service:directory-agent request. The general situation appears to be: client: slptool findsrvs service:blah client > da : Service Request service:directory-agent da > client : Da Advertisement service:directory-agent://ip-of-client client -> client : Service Request service:blah <Connection refused> The DA runs on RHEL6 with 2.0.beta2 the client runs RHEL5 with 1.2.1 Not all clients have this problem, most seem to work just fine. Any guidance would be very much appreciated! - Hein-Pieter van Braam |
From: Gavin L. <ga...@co...> - 2013-11-20 21:16:50
|
Well, as I said there isn't anything too exciting in there: **************************************** Tue Aug 27 16:37:33 2013 SLPD daemon started **************************************** Command line = /usr/local/sbin/slpd Using configuration file = /etc/slp.conf Using registration file = /etc/slp.reg Listening on loopback TCP... Listening on loopback UDP... Listening on 10.200.196.77 ... Multicast (IPv4) socket on 10.200.196.77 ready Unicast socket on 10.200.196.77 ready Agent Interfaces = 10.200.196.77 Startup complete entering main run loop ... **************************************** Wed Nov 20 06:14:00 2013 SLPD daemon shutting down **************************************** **************************************** Wed Nov 20 06:14:00 2013 SLPD daemon shut down **************************************** **************************************** Wed Nov 20 06:14:01 2013 SLPD daemon started **************************************** Command line = /usr/local/sbin/slpd Using configuration file = /etc/slp.conf Using registration file = /etc/slp.reg Listening on loopback TCP... Listening on loopback UDP... Listening on 10.200.196.77 ... Multicast (IPv4) socket on 10.200.196.77 ready Unicast socket on 10.200.196.77 ready Agent Interfaces = 10.200.196.77 Startup complete entering main run loop ... **************************************** Wed Nov 20 17:35:04 2013 SLPD daemon shutting down **************************************** **************************************** Wed Nov 20 17:35:04 2013 SLPD daemon shut down **************************************** **************************************** Wed Nov 20 17:35:05 2013 SLPD daemon started **************************************** Command line = /usr/local/sbin/slpd Using configuration file = /etc/slp.conf Using registration file = /etc/slp.reg Listening on loopback TCP... Listening on loopback UDP... Listening on 10.200.196.77 ... Multicast (IPv4) socket on 10.200.196.77 ready Unicast socket on 10.200.196.77 ready Agent Interfaces = 10.200.196.77 Startup complete entering main run loop ... **************************************** Thu Nov 21 03:07:25 2013 SLPD daemon shutting down **************************************** **************************************** Thu Nov 21 03:07:25 2013 SLPD daemon shut down **************************************** **************************************** Thu Nov 21 03:07:26 2013 SLPD daemon started **************************************** Command line = /usr/local/sbin/slpd Using configuration file = /etc/slp.conf Using registration file = /etc/slp.reg Listening on loopback TCP... Listening on loopback UDP... Listening on 10.200.196.77 ... Multicast (IPv4) socket on 10.200.196.77 ready Unicast socket on 10.200.196.77 ready Agent Interfaces = 10.200.196.77 Startup complete entering main run loop ... From: John Calcote [mailto:joh...@gm...] Sent: Thursday, 21 November 2013 04:38 To: Gavin Lambert Cc: OpenSLP List Subject: Re: [Openslp-users] Registrations and server restarts Gavin, Can you send the log indicating shutdown and restart? John On Nov 19, 2013 11:15 PM, "Gavin Lambert" <ga...@co...> wrote: Hi all, I have a fairly simple test network setup at the moment with one Windows machine and four Linux machines running OpenSLP (all with the same code, which is one of the just-immediately-prior-to-release 2.0 betas); and there are no DAs. The four Linux machines all run the same app which is supposed to have a permanent SLP registration. Today I noticed while running an unrelated soak test (so everything had been running for several hours, in some cases days) that two of the four machines were no longer responding with the service info for that app. The app is still running, and slpd is still running. However logs show that (at different times) the slpd service on both of the affected machines shut down and was restarted one second later, for no readily apparent reason. (In particular, the slpd.log appears to show a normal shutdown / startup banner, but there's no other apparent cause for the restart.) The app normally makes a single call to SLPReg on startup with SLP_LIFETIME_MAXIMUM. On rare occasions it'll call SLPReg again to change one or more of its attributes. Only when the app exits does it SLPDereg and SLPClose. No errors were returned from these APIs. So, two points puzzle me: 1. why did slpd restart? 2. why, following the restart, didn't it reload the registration made previously? (For #2, I'm assuming the app shouldn't have to manually refresh the registration since AFAIK it has no way to tell whether slpd has restarted or not.) If the assumption in #2 isn't valid, is there something the app should be doing to keep this registration alive? (Preferably without spamming SLPReg or making it find itself.) |
From: John C. <joh...@gm...> - 2013-11-20 15:38:25
|
Gavin, Can you send the log indicating shutdown and restart? John On Nov 19, 2013 11:15 PM, "Gavin Lambert" <ga...@co...> wrote: > Hi all, > > I have a fairly simple test network setup at the moment with one Windows > machine and four Linux machines running OpenSLP (all with the same code, > which is one of the just-immediately-prior-to-release 2.0 betas); and there > are no DAs. The four Linux machines all run the same app which is supposed > to have a permanent SLP registration. > > Today I noticed while running an unrelated soak test (so everything had > been > running for several hours, in some cases days) that two of the four > machines > were no longer responding with the service info for that app. The app is > still running, and slpd is still running. However logs show that (at > different times) the slpd service on both of the affected machines shut > down > and was restarted one second later, for no readily apparent reason. (In > particular, the slpd.log appears to show a normal shutdown / startup > banner, > but there's no other apparent cause for the restart.) > > The app normally makes a single call to SLPReg on startup with > SLP_LIFETIME_MAXIMUM. On rare occasions it'll call SLPReg again to change > one or more of its attributes. Only when the app exits does it SLPDereg > and > SLPClose. No errors were returned from these APIs. > > So, two points puzzle me: > > 1. why did slpd restart? > 2. why, following the restart, didn't it reload the registration made > previously? > > (For #2, I'm assuming the app shouldn't have to manually refresh the > registration since AFAIK it has no way to tell whether slpd has restarted > or > not.) > > If the assumption in #2 isn't valid, is there something the app should be > doing to keep this registration alive? (Preferably without spamming SLPReg > or making it find itself.) > > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Openslp-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openslp-users > |
From: Gavin L. <ga...@co...> - 2013-11-20 06:14:13
|
Hi all, I have a fairly simple test network setup at the moment with one Windows machine and four Linux machines running OpenSLP (all with the same code, which is one of the just-immediately-prior-to-release 2.0 betas); and there are no DAs. The four Linux machines all run the same app which is supposed to have a permanent SLP registration. Today I noticed while running an unrelated soak test (so everything had been running for several hours, in some cases days) that two of the four machines were no longer responding with the service info for that app. The app is still running, and slpd is still running. However logs show that (at different times) the slpd service on both of the affected machines shut down and was restarted one second later, for no readily apparent reason. (In particular, the slpd.log appears to show a normal shutdown / startup banner, but there's no other apparent cause for the restart.) The app normally makes a single call to SLPReg on startup with SLP_LIFETIME_MAXIMUM. On rare occasions it'll call SLPReg again to change one or more of its attributes. Only when the app exits does it SLPDereg and SLPClose. No errors were returned from these APIs. So, two points puzzle me: 1. why did slpd restart? 2. why, following the restart, didn't it reload the registration made previously? (For #2, I'm assuming the app shouldn't have to manually refresh the registration since AFAIK it has no way to tell whether slpd has restarted or not.) If the assumption in #2 isn't valid, is there something the app should be doing to keep this registration alive? (Preferably without spamming SLPReg or making it find itself.) |
From: fiorentino, t. <ton...@em...> - 2013-09-24 01:11:14
|
Dear OpenSLP Team, We tried using the 64bit Windows v2.0.0 released version and we are experiencing an slpd server crash during registration. *** Where did we get the OpenSLP v2.0.0? http://sourceforge.net/projects/openslp/files/2.0.0/2.0.0%20Release/openslp_2.0.0_0_x64.msi/download *** How to reproduce? After downloading, change to the installation directory and run the slpd process: C:\Program Files\OpenSLP>slpd -debug Debugging Service Location Protocol. Then run the slptool register command two or three times, as shown below, and you will get the following error (-19): C:\Minidump\OpenSLP>slptool.exe register service:wbem:http://10.26.103.24:5988 "(template-type=wbem),(template-version=1.0),(template-description=This templatedescribes the attributes used for advertising WBEM Servers),(template-url-syntax=http://10.26.103.24:5988),(service-hi-name=EMC CIM Server),(service-hi-description=EMC CIM Server Version 9.9.0.0.0.0D-Bronze),(service-id=EMC:10.26.103.24),(CommunicationMechanism=cim-xml),(InteropSchemaNamespace=interop),(ProtocolVersion=1.0),(FunctionalProfilesSupported=Basic Read,Basic Write,Instance Manipulation,Association Traversal,Query Execution,Indications,Pulled Read,Pulled Read Count,Pulled Query Execution),(FunctionalProfileDescriptions=\"Basic Read\",\"Basic Write\",\"Instance Manipulation\",\"Association Traversal\",\"Query Execution\",\"Indications\",\"Pulled Read\",\"Pulled Read Count\",\"Pulled Query Execution\"),(MultipleOperationsSupported=true),(AuthenticationMechanismsSupported=Basic),(AuthenticationMechanismDescriptions=\"Basic\"),(Namespace=root/emc,root/qe5,root/emc/navisphere,root/emc/ecom,root/emc/vmware,interop),(RegisteredProfilesSupported=SNIA:Server)" C:\Minidump\OpenSLP>slptool.exe register service:wbem:http://10.26.103.24:5988 "(template-type=wbem),(template-version=1.0),(template-description=This templatedescribes the attributes used for advertising WBEM Servers),(template-url-syntax=http://10.26.103.24:5988),(service-hi-name=EMC CIM Server),(service-hi-description=EMC CIM Server Version 9.9.0.0.0.0D-Bronze),(service-id=EMC:10.26.103.24),(CommunicationMechanism=cim-xml),(InteropSchemaNamespace=interop),(ProtocolVersion=1.0),(FunctionalProfilesSupported=Basic Read,Basic Write,Instance Manipulation,Association Traversal,Query Execution,Indications,Pulled Read,Pulled Read Count,Pulled Query Execution),(FunctionalProfileDescriptions=\"Basic Read\",\"Basic Write\",\"Instance Manipulation\",\"Association Traversal\",\"Query Execution\",\"Indications\",\"Pulled Read\",\"Pulled Read Count\",\"Pulled Query Execution\"),(MultipleOperationsSupported=true),(AuthenticationMechanismsSupported=Basic),(AuthenticationMechanismDescriptions=\"Basic\"),(Namespace=root/emc,root/qe5,root/emc/navisphere,root/emc/ecom,root/emc/vmware,interop),(RegisteredProfilesSupported=SNIA:Server)" errorcode: -19 After we get the above error, if we wait a few seconds and go back to the window that is running the slpd process, we find that the process is no longer running because it has crashed. *** What is our hypothesis? We debugged the OpenSLP code, and the crash seems to be related to a memory alignment code located on file "openslp-2.0.0\libslpattr\libslpattr.c", which is causing a buffer overflow. There is a piece of code that allocates a chunk of memory that will be used to store aligned attribute data and will be populated some lines further down the code: /***** Allocate space for the values. *****/ block_size = (val_count * sizeof(value_t)) /* Size of each value */ + unescaped_len /* The size of the unescaped data. */ #if 1 /* Jim Meyer's byte allignment code */ + val_count * (sizeof(long) - 1); /* Padding */ #endif mem_block = (char *) malloc(block_size); At some point down on that same file, the code starts to store attribute data on this chunk of memory, and it uses the following routine to calculate the position that next attribute should be put respecting the alignment: #if 1 /* Jim Meyer's byte allignment code */ /****************************************************************************** * * Fix memory alignment * *****************************************************************************/ static char * fix_memory_alignment(char * p) { intptr_t address = (intptr_t)p; address = (address + sizeof(intptr_t) - 1) & ~(sizeof(intptr_t) - 1); return (char *)address; } #endif The problem is that this routine calculates the alignment based on type "intptr_t", which has a size of 8 bytes when building for 64 bits. However, the code that allocates the memory uses "long" (above), which has a size of 4 bytes, to calculate the number of bytes used for padding, and so the buffer overflow occurs and the process crashes. We did attempt to fix this by changing sizeof(long)to sizeof(intptr_t) on the above code. By making this change the crash is gone, but registration still doesn't work. Are there are more issues to be fixed in OpenSLP release 2.0.0 regarding 64bits? Note: for 32bits everything works fine. Please let us know if you need anything further. We appreciate any assistance you can provide. Sincerely, --Tony. |
From: HIRD M. <Mat...@uk...> - 2013-09-16 07:36:55
|
Dave In answer to your second question - the daemon treats SLP_LIFETIME_MAXIMUM as being registered for the life of the calling process. Assuming your using the pid watch functionality, this will cleanup if the process exits without deregistering. If not, you'd have 'stale' registrations in the daemon. cheers Matt From: mclellan, dave [mailto:dav...@em...] Sent: 11 September 2013 18:16 To: John Calcote; ope...@li... Subject: Re: [Openslp-users] How does an application know to re-register? Thank you very much John. A couple of notes inline below. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dav...@em...<mailto:dav...@em...> +-+-+-+-+-+-+-+-+- From: John Calcote [mailto:joh...@gm...] Sent: Wednesday, September 11, 2013 12:59 PM To: mclellan, dave; ope...@li...<mailto:ope...@li...> Subject: RE: [Openslp-users] How does an application know to re-register? Hi Dave, First of all, the application "handle" represents a network (domain socket, actually) connection to the SA. Any attempt to communicate using that handle while the SA is down will return a network-level error to the application. It can then do whatever failover is needed in a domain-specific manner. [Dave] this is what I expected, so I could use SLPFindScopes or some other passive call to see if the system is working. But then I read the next paragraph... Secondly, applications are responsible for re-registering their service with the SA on a regular interval defined by the application. The SLPReg call has a usLifetime argument that represents a number of seconds (less than or equal to SLP_LIFETIME_MAXIMUM). The registration expires in the SA after usLifetime seconds has passed since SLPReg was called. [Dave] we will use SLP_LIFETIME_MAXIMUM, but now I see that is 18 hours in slp.h. But I was confused by the assertion at http://www.openslp.org/doc/html/ProgrammersGuide/SLPReg.html that "If lifetime is set to SLP_LIFETIME_MAXIMUM<http://www.openslp.org/doc/html/ProgrammersGuide/SLPTypes.html#SLPURLLifetime>, it will remain registered for the life of the calling process." So this is not how it works, you are saying. Often, this number is something like 300 seconds, so about every 5 minutes the application should call SLPReg again. This means that a registration will never be down for more than 5 minutes. If the service is mission-critical, it would be prudent to specify a shorter lifetime value and re-register more often, but it would seem, in light of the nature of advertised network services, that once a minute is sufficient, even for mission-critical applications. Regards, John From: mclellan, dave [mailto:dav...@em...] Sent: Wednesday, September 11, 2013 7:17 AM To: ope...@li...<mailto:ope...@li...> Subject: [Openslp-users] How does an application know to re-register? Hi all. Novice question alert; we are fairly new to use of OpenSLP. Suppose an application has registered using SLPReg successfully in an environment without the Directory agent. If the local Service Agent fails for whatever reason and must be restarted, all registrations held by that Service Agent are lost. How does the application get notified, if at all, that it should close its handle, open a handle and register again? Is there any notification provided via the registration callback? I don't think so, from what I have read. My conclusion is that there isn't a way for a registered process to know if the openSLP infrastructure on which it depends fails and has been re-initialized. Such notification would have to be done by some other monitoring entity, presumably the same entity which notices the SLP infrastructure failure and recovers it. Are these correct assumptions? Thanks very much for any advice. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dav...@em...<mailto:dav...@em...> +-+-+-+-+-+-+-+-+- |
From: mclellan, d. <dav...@em...> - 2013-09-11 17:16:47
|
Thank you very much John. A couple of notes inline below. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dav...@em...<mailto:dav...@em...> +-+-+-+-+-+-+-+-+- From: John Calcote [mailto:joh...@gm...] Sent: Wednesday, September 11, 2013 12:59 PM To: mclellan, dave; ope...@li... Subject: RE: [Openslp-users] How does an application know to re-register? Hi Dave, First of all, the application "handle" represents a network (domain socket, actually) connection to the SA. Any attempt to communicate using that handle while the SA is down will return a network-level error to the application. It can then do whatever failover is needed in a domain-specific manner. [Dave] this is what I expected, so I could use SLPFindScopes or some other passive call to see if the system is working. But then I read the next paragraph... Secondly, applications are responsible for re-registering their service with the SA on a regular interval defined by the application. The SLPReg call has a usLifetime argument that represents a number of seconds (less than or equal to SLP_LIFETIME_MAXIMUM). The registration expires in the SA after usLifetime seconds has passed since SLPReg was called. [Dave] we will use SLP_LIFETIME_MAXIMUM, but now I see that is 18 hours in slp.h. But I was confused by the assertion at http://www.openslp.org/doc/html/ProgrammersGuide/SLPReg.html that "If lifetime is set to SLP_LIFETIME_MAXIMUM<http://www.openslp.org/doc/html/ProgrammersGuide/SLPTypes.html#SLPURLLifetime>, it will remain registered for the life of the calling process." So this is not how it works, you are saying. Often, this number is something like 300 seconds, so about every 5 minutes the application should call SLPReg again. This means that a registration will never be down for more than 5 minutes. If the service is mission-critical, it would be prudent to specify a shorter lifetime value and re-register more often, but it would seem, in light of the nature of advertised network services, that once a minute is sufficient, even for mission-critical applications. Regards, John From: mclellan, dave [mailto:dav...@em...] Sent: Wednesday, September 11, 2013 7:17 AM To: ope...@li...<mailto:ope...@li...> Subject: [Openslp-users] How does an application know to re-register? Hi all. Novice question alert; we are fairly new to use of OpenSLP. Suppose an application has registered using SLPReg successfully in an environment without the Directory agent. If the local Service Agent fails for whatever reason and must be restarted, all registrations held by that Service Agent are lost. How does the application get notified, if at all, that it should close its handle, open a handle and register again? Is there any notification provided via the registration callback? I don't think so, from what I have read. My conclusion is that there isn't a way for a registered process to know if the openSLP infrastructure on which it depends fails and has been re-initialized. Such notification would have to be done by some other monitoring entity, presumably the same entity which notices the SLP infrastructure failure and recovers it. Are these correct assumptions? Thanks very much for any advice. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dav...@em...<mailto:dav...@em...> +-+-+-+-+-+-+-+-+- |
From: John C. <joh...@gm...> - 2013-09-11 16:59:43
|
Hi Dave, First of all, the application "handle" represents a network (domain socket, actually) connection to the SA. Any attempt to communicate using that handle while the SA is down will return a network-level error to the application. It can then do whatever failover is needed in a domain-specific manner. Secondly, applications are responsible for re-registering their service with the SA on a regular interval defined by the application. The SLPReg call has a usLifetime argument that represents a number of seconds (less than or equal to SLP_LIFETIME_MAXIMUM). The registration expires in the SA after usLifetime seconds has passed since SLPReg was called. Often, this number is something like 300 seconds, so about every 5 minutes the application should call SLPReg again. This means that a registration will never be down for more than 5 minutes. If the service is mission-critical, it would be prudent to specify a shorter lifetime value and re-register more often, but it would seem, in light of the nature of advertised network services, that once a minute is sufficient, even for mission-critical applications. Regards, John From: mclellan, dave [mailto:dav...@em...] Sent: Wednesday, September 11, 2013 7:17 AM To: ope...@li... Subject: [Openslp-users] How does an application know to re-register? Hi all. Novice question alert; we are fairly new to use of OpenSLP. Suppose an application has registered using SLPReg successfully in an environment without the Directory agent. If the local Service Agent fails for whatever reason and must be restarted, all registrations held by that Service Agent are lost. How does the application get notified, if at all, that it should close its handle, open a handle and register again? Is there any notification provided via the registration callback? I don't think so, from what I have read. My conclusion is that there isn't a way for a registered process to know if the openSLP infrastructure on which it depends fails and has been re-initialized. Such notification would have to be done by some other monitoring entity, presumably the same entity which notices the SLP infrastructure failure and recovers it. Are these correct assumptions? Thanks very much for any advice. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dav...@em... +-+-+-+-+-+-+-+-+- |
From: mclellan, d. <dav...@em...> - 2013-09-11 13:44:54
|
Hi all. Novice question alert; we are fairly new to use of OpenSLP. Suppose an application has registered using SLPReg successfully in an environment without the Directory agent. If the local Service Agent fails for whatever reason and must be restarted, all registrations held by that Service Agent are lost. How does the application get notified, if at all, that it should close its handle, open a handle and register again? Is there any notification provided via the registration callback? I don't think so, from what I have read. My conclusion is that there isn't a way for a registered process to know if the openSLP infrastructure on which it depends fails and has been re-initialized. Such notification would have to be done by some other monitoring entity, presumably the same entity which notices the SLP infrastructure failure and recovers it. Are these correct assumptions? Thanks very much for any advice. +-+-+-+-+-+-+-+-+- Dave McLellan, VMAX Software Engineering, EMC Corporation, 176 South St. Mail Stop 176-V1 1/P-36, Hopkinton, MA 01749 Office: 508-249-1257, Mobile: 978-500-2546, dav...@em...<mailto:dav...@em...> +-+-+-+-+-+-+-+-+- |
From: Wang, R. <Ren...@nu...> - 2013-08-29 17:44:39
|
One issue we have now is the MTU limit - based on the document, OpenSLP has a TCP feature to transmit message if the UDP failed with package size more than MTU limit (default is 1400 bytes), but the system logged an error message -18 (SLP_BUFFER_OVERFLOW) and the messages never got transmitted. I wonder if this is a bug or we should turn on some configuration options? Regards, Ren |