Hi Matt,

             Thanks for posting these changes. I have already submitted the 
same changes earlier but you have consolidated it. Here are the list of patches 
submitted by me that are already part of your patch. So these bugs can be 
closed.
http://sourceforge.net/tracker/?func=detail&aid=3003847&group_id=1730&atid=101730
http://sourceforge.net/tracker/?func=detail&aid=2983072&group_id=1730&atid=101730

Richard,
              When you apply the earlier discussed patch, here are few more 
patches that i think must go in to fix all issues. Please take a look.
Matts Patch: 
https://sourceforge.net/tracker/?func=detail&aid=3026763&group_id=1730&atid=101730
Minor Compile Issues: 
http://sourceforge.net/tracker/?func=detail&aid=2983069&group_id=1730&atid=101730
Proper Dynamic Registration Support: 
http://sourceforge.net/tracker/?func=detail&aid=3001030&group_id=1730&atid=101730

As of now i feel all these 3 patches must go in. I have yet to review Matts 
other patches. I will comment on that later. Let me know what you think.

Regards,
Varun

On Thursday, July 08, 2010 07:14:26 pm Matthew Pendlebury wrote:
> Hi Varun, Richard,
> 
> Just to add to your debate, we've been doing some testing with IPv6 operation 
> recently and the results of our findings are in a patch, contained in bug 
> 3026763 
> (https://sourceforge.net/tracker/?func=detail&aid=3026763&group_id=1730&atid=101730).
>    With those changes we've achieved what seems to be reasonable ipv6 
> operation and dual ipv4/6 operation.  We started with Anthony Tong's 
> suggestions from 14 July 2008, 
> http://www.mail-archive.com/openslp-devel@lists.sourceforge.net/msg00043.html 
> and added a few other corrections most of which have been identified 
> independently recently.
> 
> The only other significant issue we ran into was one of permission to open 
> ipv6 multicast sockets, once daemonised the process doesn't have permission 
> to open multicast sockets and silently fails to do anything involving 
> multicast.  Our inelegant solution to this was to stop the change of user 
> from 'root' to 'daemon' in the daemonising process, there is invariably a 
> better way though.
> 
> Cheers
> 
> Matt
> 
> 
> Matthew Pendlebury
> Senior Software Engineer
> Thales UK
> Jupiter House, Station Road, Cambridge, CB12JD, United Kingdom 
> http://www.thalesgroup/iss
> Tel: +44 (0) 1223 723600
> e-mail: matthew.pendleb...@thales-esecurity.com
> 
> 
> > -----Original Message-----
> > From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com]
> > Sent: 07 July 2010 21:04
> > To: Morrell Richard (external)
> > Cc: 'openslp-devel@lists.sourceforge.net'
> > Subject: Re: [Openslp-devel] Add IPv6 Fix Support!
> >
> > On Wednesday, July 07, 2010 07:07:42 pm Morrell Richard (external)
> > wrote:
> > > Hi Varun,
> > >
> > > According to the forum post, the reason the socket removal code was
> > > commented out in the first place was that, prior to this call, the
> > slp.reg
> > > file had been processed, which, for IPv6, created multicast sockets
> > for each
> > > of the static registrations.  They were then deleted by this code.
> > >
> > > Do you have any static registrations in your slp.reg file ?  If not,
> > then
> > > you won't have seen this problem.
> > >
> > Yes i dont have static registrations. I understand the reason now.
> > > My original concern regarding running the code as a result of SIGHUP
> > was
> > > theoretical, in that I hadn't had the time to investigate it myself.
> > > Searching the latest trunk code for calls to SLPDIncomingInit, I can
> > only
> > > find one call in slpd_main.c and one in slpd_win32.c.
> > >
> > > The call in slpd_main.c is only made once, on startup, so there
> > > would
> > be no
> > > detrimental effect in commenting out the socket removal code in this
> > case,
> > > as the socket list is statically initialised to empty.
> > >
> > > The call in slpd_win32.c is made from the ServiceStart() function,
> > and,
> > > although I don't know that much about Windows services, it looks
> > > like
> > the
> > > sockets will be removed after a ServiceStop call, so there should be
> > no need
> > > to clean up the list on the next ServiceStart call, even if sockets
> > were
> > > persistent between ServiceStop and ServiceStart calls.
> > >
> > > In other words, it now looks to me that we should apply the patch as
> > it
> > > stands (given that you have been testing with both IPv4 and IPv6
> > enabled
> > > with no problems), including commenting out the socket removal code.
> > Did
> > > your investigations find anything that invalidates my analysis above
> > ?
> > >
> > I agree with your investigations. Please go ahead and apply the change.
> > Lets see if anyone here has any issue.
> > > Regards,
> > >
> > > Richard
> > >
> > > NB. I have copied this to the openslp-devel mailing list in case
> > anyone
> > > there has any comments or insights.
> > >
> > > -----Original Message-----
> > > From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com]
> > > Sent: 06 July 2010 10:08
> > > To: Morrell Richard (external)
> > > Subject: Re: Add IPv6 Fix Support!
> > >
> > >
> > > Hi Morrell,
> > >
> > >            I was busy fixing some major ipv6 issues for openslp that
> > i could
> > > not look at this for sometime. Iam sorry. As far the first question
> > is
> > > concerned you are right, it must not be commented. I will fix that.
> > >
> > > Iam not sure what the intention was, but i have been running with
> > both ipv4
> > > and ipv6 for about 4 months now. I have run slpd as SA and never
> > faced an
> > > issue. As DA i ran for a while, but not very extensively tested.
> > > From
> > my
> > > code reading, it seems that code can handle both ipv4 and ipv6
> > > simultaneously.
> > >
> > > I have tons of fixes that i need to submit, but for that this patch
> > has to
> > > go in. As i have already told you iam not allowed to modify this
> > patch due
> > > to company rules, i will have a patch made on top of latest svn with
> > the
> > > comment change. That patch you can apply or change it yourself. Is
> > that ok
> > > with you?
> > >
> > > Regards,
> > > Varun
> > >
> > >
> > > On Thursday, June 03, 2010 12:37:58 pm you wrote:
> > > > Sorry, Varun, I've been a bit busy recently.
> > > >
> > > > The patch looks relatively straightforward in itself, but I have
> > some
> > > > concerns.
> > > >
> > > > Regarding the commenting out of the removal of sockets, the code
> > > > is
> > run at
> > > > initialisation, in which case it would seem to be completely
> > redundant, as
> > > > the structure it is apparently clearing is statically initialised
> > to empty
> > > > anyway.  If the code could be run at some time other than
> > initialisation,
> > > > however, eg. after a SIGHUP to re-interpret the configuration
> > files, then
> > > we
> > > > may not clear down sockets that we should be clearing down.  How
> > sure are
> > > > you that the code is not run at other than first initialisation ?
> > > >
> > > > Secondly, the patch makes it so that IPv4 and IPv6 operation can
> > > > be
> > > enabled
> > > > independently, whereas the original behaviour was to have one or
> > the
> > > other.
> > > > There may be assumptions in the code that rely on this eg.
> > interpreting
> > > the
> > > > format of IP addresses depending on whether IPv4 is enabled.  How
> > much
> > > > testing have you done to make sure that IPv4 operation is not
> > affected
> > > when
> > > > IPv6 operation is enabled ?
> > > >
> > > > -----Original Message-----
> > > > From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com]
> > > > Sent: 02 June 2010 07:05
> > > > To: Morrell Richard (external)
> > > > Subject: Re: Add IPv6 Fix Support!
> > > >
> > > >
> > > > Hi,
> > > >
> > > >    Any update on this? Did you get a chance to look?
> > > >
> > > > On Wednesday, May 19, 2010 08:53:53 pm you wrote:
> > > > > Hi Varun,
> > > > >
> > > > > I'm not that familiar with the IPv6 support, but I'll take a
> > > > > look
> > at the
> > > > > patch.
> > > > >
> > > > > Regards,
> > > > > Richard
> > > > >
> > > > > -----Original Message-----
> > > > > From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com]
> > > > > Sent: 19 May 2010 06:27
> > > > > To: Morrell Richard (external)
> > > > > Cc: openslp-devel@lists.sourceforge.net
> > > > > Subject: Add IPv6 Fix Support!
> > > > >
> > > > >
> > > > > Hi Morrell,
> > > > >
> > > > >                  I have extensively tested the ipv6 fixes
> > submitted long
> > > > > time
> > > > > ago. I found them to be working fine except  a few bugs. For
> > those bugs
> > > i
> > > > > already have bug fixes submitted. The patch iam talking about is
> > > > >
> > > >
> > >
> > https://sourceforge.net/mailarchive/forum.php?thread_name=487B7A7B.707
> > 0
> > 308%4
> > > > > 0TrustedCS.com&forum_name=openslp-
> > > > > devel
> > > > >
> > > > > As part of my company policy iam not allowed to commit patches
> > that are
> > > > not
> > > > > mine. If its possible can you review the patch and commit patch?
> > If done
> > > i
> > > > > can
> > > > > work on further fixes. Let me know if this can be worked out?
> > > > >
> > > > > Regards,
> > > > > Varun
> > > > >
> > > > > This email, including any attachment, is a confidential
> > communication
> > > > > intended solely for the use of the individual or entity to whom
> > it is
> > > > > addressed. It contains information which is private and may be
> > > proprietary
> > > > > or covered by legal professional privilege. If you have received
> > this
> > > > email
> > > > > in error, please notify the sender upon receipt, and immediately
> > delete
> > > it
> > > > > from your system.
> > > > >
> > > > > Anything contained in this email that is not connected with the
> > > businesses
> > > > > of this company is neither endorsed by nor is the liability of
> > this
> > > > company.
> > > > >
> > > > > Whilst we have taken reasonable precautions to ensure that any
> > > attachment
> > > > to
> > > > > this email has been swept for viruses, we cannot accept
> > > > > liability
> > for
> > > any
> > > > > damage sustained as a result of software viruses, and would
> > advise that
> > > > you
> > > > > carry out your own virus checks before opening any attachment.
> > > > >
> > > > >
> > > >
> > > > This email, including any attachment, is a confidential
> > communication
> > > > intended solely for the use of the individual or entity to whom it
> > is
> > > > addressed. It contains information which is private and may be
> > proprietary
> > > > or covered by legal professional privilege. If you have received
> > this
> > > email
> > > > in error, please notify the sender upon receipt, and immediately
> > delete it
> > > > from your system.
> > > >
> > > > Anything contained in this email that is not connected with the
> > businesses
> > > > of this company is neither endorsed by nor is the liability of
> > > > this
> > > company.
> > > >
> > > > Whilst we have taken reasonable precautions to ensure that any
> > attachment
> > > to
> > > > this email has been swept for viruses, we cannot accept liability
> > for any
> > > > damage sustained as a result of software viruses, and would advise
> > that
> > > you
> > > > carry out your own virus checks before opening any attachment.
> > > >
> > > >
> > >
> > > This email, including any attachment, is a confidential
> > > communication intended solely for the use of the individual or
> > > entity to whom it is addressed. It contains information which is
> > > private and may be
> > proprietary
> > > or covered by legal professional privilege. If you have received
> > > this
> > email
> > > in error, please notify the sender upon receipt, and immediately
> > delete it
> > > from your system.
> > >
> > > Anything contained in this email that is not connected with the
> > businesses
> > > of this company is neither endorsed by nor is the liability of this
> > company.
> > >
> > > Whilst we have taken reasonable precautions to ensure that any
> > attachment to
> > > this email has been swept for viruses, we cannot accept liability
> > > for
> > any
> > > damage sustained as a result of software viruses, and would advise
> > that you
> > > carry out your own virus checks before opening any attachment.
> > >
> > >
> >
> > ----------------------------------------------------------------------
> > -
> > -------
> > This SF.net email is sponsored by Sprint What will you do first with
> > EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________
> > Openslp-devel mailing list
> > Openslp-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openslp-devel
> 
> Consider the environment before printing this mail.
> 
> Thales e-Security Limited is incorporated in England and Wales with company 
> registration number 2518805. Its registered office is located at 2 Dashwood 
> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15 
> 2NX.
> 
> The information contained in this e-mail is confidential. It may also be 
> privileged. It is intended only for the stated addressee(s) and access to it 
> by any other person is unauthorised. If you are not an addressee or the 
> intended addressee, you must not disclose, copy, circulate or in any other 
> way use or rely on the information contained in this e-mail. Such 
> unauthorised use may be unlawful. If you have received this e-mail in error, 
> please inform us immediately on +44 (0)1223 723600 and delete it and all 
> copies from your system.  Commercial matters detailed or referred to in this 
> e-mail are subject to a written contract signed for and on behalf of Thales 
> e-Security Limited.
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Openslp-devel mailing list
> Openslp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
> 

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Openslp-devel mailing list
Openslp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-devel

Reply via email to