By default the DA detection is set to true using the following parameters in
/etc/slp.conf
net.slp.passiveDADetection
net.slp.passiveDADetection
You may want to try setting these to false to avoid automatic DA detection.
Regards
-KPRajesh
On Mon, Aug 8, 2011 at 10:13 AM, Varun Chandramohan <
var...@linux.vnet.ibm.com> wrote:
> While we are on the discussion, i noticed that my slpd daemon configured as
> SA is taking registrations from outside (there are DAs in the n/w). That
> sounds wrong! I think SA should not take registrations from DA's right?
>
> Regards,
> Varun
>
>
> On Wednesday, August 03, 2011 02:58:57 pm Hird Matthew wrote:
> > Varun
> >
> > How many nodes do you have in your system? also, how long are your scope
> > names? I've found a bug in slpd_process.c which is related to these areas
> > and causes the daemon to segfault. As soon as we hit 50 DAs, all the SLP
> > daemons seg faulted at the same time. I have a fix which I'll submit
> shortly
> > but you could just up that buffer to 8192 as a temporary test.
> >
> > What happens is that when a search is performed on a node, the slptool
> asks
> > the daemon for a list of it's known scopes via a 'backdoor'. the daemon
> > builds up a list of known DAs from it's database and returns them all in
> the
> > form of a DAAdvert. This will vary in size according to your scope name
> and
> > IP address but each advert is in the order of 70-100 bytes, assuming a
> scope
> > name of less than 10 chars. It puts it's own local loopback address in at
> > the start of the list and a terminating DAAdvert at the end so you're
> down
> > to ~3936 bytes straight off. Assuming a DAAdvert size of ~80 bytes, means
> > you can only fit 49/50 DAs in the list. Obviously, if you have a very
> scope
> > name, even less.
> >
> > could this be the problem you're seeing?
> >
> > Like I said, I'll fix the code to dynamically size the buffer to
> something
> > appropriate and submit the patch soon.
> >
> > cheers
> > Matt
> >
> >
> > _____
> >
> > From: Nick Wagner [mailto:ne...@wingedbeast.org]
> > Sent: 02 August 2011 03:29
> > To: Richard Morrell
> > Cc: openslp-devel@lists.sourceforge.net
> > Subject: Re: [Openslp-devel] Segfault Seen In Latest Openslp
> >
> >
> > Yes, I didn't spot what you were doing until after I sent the email.
> I've
> > never done that trick inside of a union -- I wouldn't think so, but is it
> > possible some compiler optimization is getting in the way? Varun, what
> kind
> > of compiler/environment are you using?
> >
> > --Nick
> >
> >
> > On Mon, Aug 1, 2011 at 1:51 PM, Richard Morrell <r.morr...@hotmail.com
> > <mailto:r.morr...@hotmail.com> > wrote:
> >
> >
> > This seems to be in the code I added while at Thales.
> >
> > I left there recently, and am just getting myself set back up to have
> access
> > to
> > the source and mailing lists from home rather than work.
> >
> > Any further information on this ?
> >
> >
> >
> > See comments below.
> >
> >
> >
> > >On 07/28/2011 03:40 AM, Varun Chandramohan wrote:
> > >> On Thursday, July 28, 2011 12:51:47 am Nick Wagner wrote:
> > >>> The SLPDPredicateTreeNode structure does seem to have a problem. If
> we
> > left
> >
> >
> > >>> the larger-sized array, guards should still be added to ensure that
> > neither
> > >>> strncpy will step off the end of the member 'storage'. Others may
> have
> > >>> differing opinions, but I'd change storage to be a char* and alloc it
> to
> > the
> >
> >
> > >>> right size (tag_len + value_len + terminating nulls), as long as we
> make
> > >>> sure that it's freed appropriately. We're allocating all the nodes
> in
> > the
> > >>> tree anyway.
> > >>>
> >
> >
> > >>> --Nick
> > >>>
> > >> I think we can do that. If all are ok with it, can we make this
> change?
> > >It seems that the extra space for the attributes is already taken care
> > >of in allocating the memory for ppNode (slpd_predicate:1645). So Nick's
> >
> >
> > >proposed change shouldn't be necessary. But we still need to find out
> > >why it doesn't work properly yet...
> > >
> > Agreed. The assumption was that "storage" was allocated as the last
> > structure
> >
> >
> > member at the end of the structure, and is initially two bytes long to
> allow
> > for
> > the trailing NUL characters at the end of each of the tag and value
> strings.
> > The
> > space allocated is increased by lhs_len+rhs_len to allow for the storage
> of
> > the
> >
> >
> > strings. This is so that you don't need to worry about separately
> allocating
> > and
> > de-allocating storage for the (usually short) tag and value strings.
> >
> > It works fine for me using the latest trunk source built on Linux Mint 7
> >
> >
> > x86_64. Can we get any more information from the failure ? How
> repeatable
> > is
> > it ? Can you generate a core file and get information like the values of
> > lhs_len
> > and rhs_len, operator, and *ppNode at the point of failure using gdb ?
> >
> >
> >
> > >Can we be certain that the 'storage' field is actually exactly at the
> > >end of the SLPPredicateTreeNode structure?
> > Even if it wasn't, it shouldn't cause a segmentation fault, although it
> > would
> >
> >
> > overwrite any structure members allocated following it.
> >
> >
> > >
> > >BR,
> > > Roel
> > >>
> > >> - Varun
> > >>
> > >>> On Wed, Jul 27, 2011 at 1:27 AM, Varun Chandramohan<
> >
> > >>> varunc@...> wrote:
> > >>>
> > >>>> **
> > >>>>
> > >>>> Hi Folks,
> > >>>>
> > >>>> The test team reported a bug. Iam pasting the bug analysis. They
> seem
> > to
> >
> >
> > >>>> have found the problem as well with a temporary fix. However i they
> > want our
> > >>>> opinion on the fix. Please advice.
> > >>>>
> > >>>> Using the following command:
> >
> >
> > >>>>
> > >>>> slptool findsrvs service:test$ID "(foo=value1)"
> > >>>>
> > >>>> this will generat the overflow in createPredicateParseTree doing
> an
> > strncpy -
> > >>>>
> >
> >
> > >>>> line 1656 slpd_predicate.c
> > >>>>
> > >>>> When reading the comments around "operator" it appears it is using
> > the operator
> > >>>>
> > >>>> 2 characters as a place to copy the attribute name. The attribute
> name
> > can be
> >
> >
> > >>>>
> > >>>> very large. This is the code:
> > >>>>
> > >>>> /* Finished with "operator" now - just use as temporary
> pointer
> > to assist
> > >>>>
> >
> >
> > >>>> with copying the
> > >>>>
> > >>>> * attribute name (lhs) and required value (rhs) into the
> node
> > >>>>
> > >>>> */
> > >>>>
> > >>>> operator = (*ppNode)->nodeBody.comparison.storage;
> >
> >
> > >>>>
> > >>>> strncpy(operator, lhs, lhs_len);
> > >>>>
> > >>>> operator[lhs_len] = '\0';
> > >>>>
> > >>>> operator is now the pointer of "storage" in:
> >
> >
> > >>>>
> > >>>> slpd_predicate.h
> > >>>>
> > >>>> typedef struct __SLPDPredicateTreeNode
> > >>>>
> > >>>> {
> > >>>>
> > >>>> SLPDPredicateTreeNodeType nodeType;
> >
> >
> > >>>>
> > >>>> struct __SLPDPredicateTreeNode *next; /* next node in a
> > combination */
> > >>>>
> > >>>> union {
> > >>>>
> > >>>> struct __SLPDPredicateLogicalBody
> >
> >
> > >>>>
> > >>>> {
> > >>>>
> > >>>> struct __SLPDPredicateTreeNode *first;
> > >>>>
> > >>>> } logical;
> > >>>>
> > >>>> struct __SLPDPredicateComparisonBody
> >
> >
> > >>>>
> > >>>> {
> > >>>>
> > >>>> size_t tag_len;
> > >>>>
> > >>>> char *tag_str;
> > >>>>
> > >>>> size_t value_len;
> >
> >
> > >>>>
> > >>>> char *value_str;
> > >>>>
> > >>>> char storage[2];
> > >>>>
> > >>>> } comparison;
> > >>>>
> > >>>> } nodeBody;
> >
> >
> > >>>>
> > >>>> } SLPDPredicateTreeNode;
> > >>>>
> > >>>> Copying of attributes onto 2char array fails though doesn't fail
> in
> > older
> > >>>>
> > >>>> builds so I am not sure if build options or strictness has changed.
> >
> >
> > >>>>
> > >>>> Since there were no cleanup routines if the pointer was malloced,
> I
> > just
> > >>>>
> > >>>> increased --> storage[200] and the testcase runs without fail and
> the
> > area will
> >
> >
> > >>>>
> > >>>> get freed with the structure.
> > >>>>
> > >>>> Is this the best way out?
> > >>>>
> > >>>> Regards,
> > >>>>
> >
> > >>>> Varun
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> >
> ----------------------------------------------------------------------------
> > --
> > >>>> Got Input? Slashdot Needs You.
> >
> >
> > >>>> Take our quick survey online. Come on, we don't ask for help often.
> > >>>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> > >>>> http://p.sf.net/sfu/slashdot-survey
> > <http://p.sf.net/sfu/slashdot-survey>
> >
> >
> > >>>> _______________________________________________
> > >>>> Openslp-devel mailing list
> > >>>> Openslp-devel@...
> >
> > >>>> https://lists.sourceforge.net/lists/listinfo/openslp-devel
> > <https://lists.sourceforge.net/lists/listinfo/openslp-devel>
> >
> >
> > >>>>
> > >>>>
> > >>
> >
> ----------------------------------------------------------------------------
> > --
> > >> Got Input? Slashdot Needs You.
> > >> Take our quick survey online. Come on, we don't ask for help often.
> >
> >
> > >> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> > >> http://p.sf.net/sfu/slashdot-survey <
> http://p.sf.net/sfu/slashdot-survey>
> >
> > >> _______________________________________________
> >
> >
> > >> Openslp-devel mailing list
> > >> Openslp-devel@...
> >
> > >> https://lists.sourceforge.net/lists/listinfo/openslp-devel
> > <https://lists.sourceforge.net/lists/listinfo/openslp-devel>
> >
> >
> >
> ----------------------------------------------------------------------------
> > --
> > BlackBerry(r) DevCon Americas, Oct. 18-20, San Francisco, CA
> > The must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1 <
> http://p.sf.net/sfu/rim-blackberry-1>
> > _______________________________________________
> > Openslp-devel mailing list
> > Openslp-devel@lists.sourceforge.net
> > <mailto:Openslp-devel@lists.sourceforge.net>
> > https://lists.sourceforge.net/lists/listinfo/openslp-devel
> > <https://lists.sourceforge.net/lists/listinfo/openslp-devel>
> >
> >
> >
> >
> >
> > 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.
> >
> >
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Openslp-devel mailing list
> Openslp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
>
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Openslp-devel mailing list
Openslp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-devel
