Jon,
I tried both the patch and the tarball with 2.5.29 last night and I
didn't see any problems. I ran a test overnight without any problems. Other
than the few version # changes needed in README as Sridhar has pointed out,
I don't see any other issues.
Thanks,
Daisy Chang
IBM Linux Technology Center
daisyc@...
Tel: (512)-838-4194 T/L: 678-4194
FAX: (512)-838-4663
jgrimm2@...@lists.sourceforge.net on 07/30/2002
04:10:36 PM
Sent by: lksctp-developers-admin@...
To: "lksctp-developers@..."
<lksctp-developers@...>
cc:
Subject: [Lksctp-developers] Please try out: lksctp-2_5_29-0_5_0 patch
and tarball
Hi folks,
I've uploaded the project tarball and the kernel only patch.
Please
give them a try as I want to send out an Announcement to the various
lists and to the network maintainers by tomorrow afternoon.
I'd love to hear of any acknowledgement of either success or
failure.
Here's a quick link to the downloads:
http://sourceforge.net/project/showfiles.php?group_id=26529
Thanks. I'm going to take the patch over to a test machine and make
sure I can lay down the patch, but wanted to get this note out to be
able to see if I can get a few more volunteers and still be able to
react to last minute gotchas.
This would be greatly appreciated,
Jon
-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
Lksctp-developers mailing list
Lksctp-developers@...
https://lists.sourceforge.net/lists/listinfo/lksctp-developers

A warning to anyone who hasn't already tried the 2.5.29 stock kernel..
there is a bug in the fs/partitions/Config.in that you'll have to fix
up to get 'make xconfig' to work.
I forgot to mention since I've already fixed it in my tree, but Daisy
reminded me that folks would probably hit this. Thanks.
See notes here for a workaround:
http://sourceforge.net/tracker/index.php?func=detail&aid=587986&group_id=26529&atid=387572
Best Regards,
jon
Jon Grimm wrote:
>
> Hi folks,
>
> I've uploaded the project tarball and the kernel only patch. Please
> give them a try as I want to send out an Announcement to the various
> lists and to the network maintainers by tomorrow afternoon.
>
> I'd love to hear of any acknowledgement of either success or failure.
>
> Here's a quick link to the downloads:
> http://sourceforge.net/project/showfiles.php?group_id=26529
>
> Thanks. I'm going to take the patch over to a test machine and make
> sure I can lay down the patch, but wanted to get this note out to be
> able to see if I can get a few more volunteers and still be able to
> react to last minute gotchas.
>
> This would be greatly appreciated,
> Jon
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@...
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers

Hi folks,
I've uploaded the project tarball and the kernel only patch. Please
give them a try as I want to send out an Announcement to the various
lists and to the network maintainers by tomorrow afternoon.
I'd love to hear of any acknowledgement of either success or failure.
Here's a quick link to the downloads:
http://sourceforge.net/project/showfiles.php?group_id=26529
Thanks. I'm going to take the patch over to a test machine and make
sure I can lay down the patch, but wanted to get this note out to be
able to see if I can get a few more volunteers and still be able to
react to last minute gotchas.
This would be greatly appreciated,
Jon

OK. Randy confirmed this can happen. Of course nothing prevents one
from having a guard timer against. If we wanted to we could have a sock
opt or some other method to specify the total amount of time one is
willing to wait on SHUTDOWN-PENDING before finally just aborting..
Paranoid as usual,
Jon
Jon Grimm wrote:
> Hi Sridhar,
>
> Sridhar Samudrala wrote:
>
> > Jon,
> >
> > I think that even in SHUTDOWN_PENDING state, the retransmission timer
> and the
> > overall error threshold will make sure that an association gets freed
> when
> > the receiver is not responding.
>
> Why? The receiver is still responding with SACKs, its just not allowing
> one to make progress by clamping/advertising an a_rwnd of 0. The zero
> window probes will go out every retransmission period, but the
> association will not error out.
>
> >
> > SO_LINGER does not provide a way to wait for a period of time and do
> an ABORT.
> >
>
> Yes, this is what I had realized. It only provides a way to
> immediately ABORT. Or else wait a period of time for shutdown immediately
>
> > We can either abort immediately or start the graceful shutdown
> process and
> > let it run until the overall error count reaches the threshold value.
> >
>
> Why will the error count reach the threshold? We are just doing zero
> window probes, which don't count as association errors.
>
> Let's pretend that there is an FTP/SCTP server, serving up lots of large
> files.
>
> It seems quite possible to create a resource attack at the server by
> requesting the file transfers, but not reading them out of the read
> buffer. Eventually the a_rwnd will go down to zero, where the server is
> only doing zero window probes. Now do this over and over again against
> the server. Even if AUTOCLOSE or an explicit close() were attempted
> the DATA could not make progress to finally send SHUTDOWN. Now we are
> nice to the application and disconnect the socket from the association,
> but those resources are now stranded and at the mercy of the peer to
> finally allow progress on the transmission and hopefully shutdown.
>
> Best Regards,
> Jon
>
> > Thanks
> > Sridhar
> >
> > On Mon, 29 Jul 2002, Jon Grimm wrote:
> >
> >
> >>I am less coherent than usual even. I meant:
> >>
> >>"no way to give up and finally ABORT".. if we have not completed
> >>shutdown if we've never yet sent our SHUTDOWN due to pending data.
> >>
> >>
> >>Sorry, jon
> >>
> >>Jon Grimm wrote:
> >>
> >>>I hate responding to my own notes..
> >>>
> >>>I'm not reading the SO_LINGER quite right.. even for TCP-style API,
> >>>there doesn't seem a way to only wait a certain time before an
> >>>association gives up and ABORTS. The only option is either to use
> >>>0... to indicate an immediate ABORT or else non-zero to block waiting
> >>>for the shutdown before returning (but the graceful shutdown still waits
> >>>indefinately).
> >>>
> >>>So may be there is something else still needed OR .... is this even a
> >>>real issue.
> >>>
> >>>jon
> >>>
> >>>Jon Grimm wrote:
> >>>
> >>>>So, I've noticed for some time a behavior in the UDP-style API as
> >>>>specified and we've implemented that seems a little troubling to me...
> >>>>
> >>>>Suppose a UDP-style socket is close()'d while its been flow controlled
> >>>>off by its peer, so that the sender has DATA pending that it can't
> >>>>send. The UDP-style close says that all the associations are to be
> >>>>gracefully shutdown. Since the sender has data pending it enters the
> >>>>SHUTDOWN-PENDING state and disallows new data. The sender stays in
> >>>>this state until the reciever finally decides to read all the data.
> >>>>This seems to let resources be captured indefinately.
> >>>>
> >>>>Now, the TCP style API has SO_LINGER defined to finally just go ahead
> >>>>and send an ABORT after some wait (may be an imediate abort even).
> >>>>I'm thinking that this could/should be implemented for UDP-style
> >>>>too. Otherwise, it would seem to allow someone to capture server
> >>>>resources at the peer indefinately. I can't see any reason that
> >>>>SO_LINGER wouldn't be definable and useful for a UDP-style
> >>>>application. We could treat it as a per socket variable.. if
> AUTOCLOSE
> >>>>or MSG_EOF were used to gracefult shutdown an association the current
> >>>>could be used.
> >>>>
> >>>>Am I reading this correct? I guess it really doesn't say we 'can't'
> >>>>implement SO_LINGER for the UDP-style sockets, but its odd that it is
> >>>>there for TCP-style, but not UDP-style.
> >>>>
> >>>>Best Regards,
> >>>>Jon
> >>>>
> >>>>-------------------------------------------------------
> >>>>This sf.net email is sponsored by: Dice - The leading online job board
> >>>>for high-tech professionals. Search and apply for tech jobs today!
> >>>>http://seeker.dice.com/seeker.epl?rel_code=31
> >>>>_______________________________________________
> >>>>Lksctp-developers mailing list
> >>>>Lksctp-developers@...
> >>>>https://lists.sourceforge.net/lists/listinfo/lksctp-developers
> >>>>
> >>>-------------------------------------------------------
> >>>This sf.net email is sponsored by: Dice - The leading online job board
> >>>for high-tech professionals. Search and apply for tech jobs today!
> >>>http://seeker.dice.com/seeker.epl?rel_code=31
> >>>_______________________________________________

Sent to wrong list.. yikes.
-------- Original Message --------
From: - Tue Jul 30 08:52:48 2002
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Message-ID: <3D469A2F.8090302@...>
Date: Tue, 30 Jul 2002 08:52:47 -0500
From: Jon Grimm <jgrimm2@...>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1)
Gecko/20020508 Netscape6/6.2.3
X-Accept-Language: en-us
MIME-Version: 1.0
To: Sridhar Samudrala <sri@...>, lksctp-developers-request@...
Subject: Re: [Lksctp-developers] UDP-style close().. any time this
century would be nice.
References: <Pine.LNX.4.33.0207301612580.1541-100000@...>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hi Sridhar,
Sridhar Samudrala wrote:
> Jon,
>
> I think that even in SHUTDOWN_PENDING state, the retransmission timer
and the
> overall error threshold will make sure that an association gets freed
when
> the receiver is not responding.
Why? The receiver is still responding with SACKs, its just not allowing
one to make progress by clamping/advertising an a_rwnd of 0. The zero
window probes will go out every retransmission period, but the
association will not error out.
>
> SO_LINGER does not provide a way to wait for a period of time and do
an ABORT.
>
Yes, this is what I had realized. It only provides a way to
immediately ABORT. Or else wait a period of time for shutdown immediately
> We can either abort immediately or start the graceful shutdown
process and
> let it run until the overall error count reaches the threshold value.
>
Why will the error count reach the threshold? We are just doing zero
window probes, which don't count as association errors.
Let's pretend that there is an FTP/SCTP server, serving up lots of large
files.
It seems quite possible to create a resource attack at the server by
requesting the file transfers, but not reading them out of the read
buffer. Eventually the a_rwnd will go down to zero, where the server is
only doing zero window probes. Now do this over and over again against
the server. Even if AUTOCLOSE or an explicit close() were attempted
the DATA could not make progress to finally send SHUTDOWN. Now we are
nice to the application and disconnect the socket from the association,
but those resources are now stranded and at the mercy of the peer to
finally allow progress on the transmission and hopefully shutdown.
Best Regards,
Jon
> Thanks
> Sridhar
>
> On Mon, 29 Jul 2002, Jon Grimm wrote:
>
>
>>I am less coherent than usual even. I meant:
>>
>>"no way to give up and finally ABORT".. if we have not completed
>>shutdown if we've never yet sent our SHUTDOWN due to pending data.
>>
>>
>>Sorry, jon
>>
>>Jon Grimm wrote:
>>
>>>I hate responding to my own notes..
>>>
>>>I'm not reading the SO_LINGER quite right.. even for TCP-style API,
>>>there doesn't seem a way to only wait a certain time before an
>>>association gives up and ABORTS. The only option is either to use
>>>0... to indicate an immediate ABORT or else non-zero to block waiting
>>>for the shutdown before returning (but the graceful shutdown still waits
>>>indefinately).
>>>
>>>So may be there is something else still needed OR .... is this even a
>>>real issue.
>>>
>>>jon
>>>
>>>Jon Grimm wrote:
>>>
>>>>So, I've noticed for some time a behavior in the UDP-style API as
>>>>specified and we've implemented that seems a little troubling to me...
>>>>
>>>>Suppose a UDP-style socket is close()'d while its been flow controlled
>>>>off by its peer, so that the sender has DATA pending that it can't
>>>>send. The UDP-style close says that all the associations are to be
>>>>gracefully shutdown. Since the sender has data pending it enters the
>>>>SHUTDOWN-PENDING state and disallows new data. The sender stays in
>>>>this state until the reciever finally decides to read all the data.
>>>>This seems to let resources be captured indefinately.
>>>>
>>>>Now, the TCP style API has SO_LINGER defined to finally just go ahead
>>>>and send an ABORT after some wait (may be an imediate abort even).
>>>>I'm thinking that this could/should be implemented for UDP-style
>>>>too. Otherwise, it would seem to allow someone to capture server
>>>>resources at the peer indefinately. I can't see any reason that
>>>>SO_LINGER wouldn't be definable and useful for a UDP-style
>>>>application. We could treat it as a per socket variable.. if
AUTOCLOSE
>>>>or MSG_EOF were used to gracefult shutdown an association the current
>>>>could be used.
>>>>
>>>>Am I reading this correct? I guess it really doesn't say we 'can't'
>>>>implement SO_LINGER for the UDP-style sockets, but its odd that it is
>>>>there for TCP-style, but not UDP-style.
>>>>
>>>>Best Regards,
>>>>Jon
>>>>
>>>>-------------------------------------------------------
>>>>This sf.net email is sponsored by: Dice - The leading online job board
>>>>for high-tech professionals. Search and apply for tech jobs today!
>>>>http://seeker.dice.com/seeker.epl?rel_code=31
>>>>_______________________________________________
>>>>Lksctp-developers mailing list
>>>>Lksctp-developers@...
>>>>https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>>>>
>>>-------------------------------------------------------
>>>This sf.net email is sponsored by: Dice - The leading online job board
>>>for high-tech professionals. Search and apply for tech jobs today!
>>>http://seeker.dice.com/seeker.epl?rel_code=31
>>>_______________________________________________
>>>Lksctp-developers mailing list
>>>Lksctp-developers@...
>>>https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: Dice - The leading online job board
>>for high-tech professionals. Search and apply for tech jobs today!
>>http://seeker.dice.com/seeker.epl?rel_code=31
>>_______________________________________________
>>Lksctp-developers mailing list
>>Lksctp-developers@...
>>https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>>
>>
>
>

Jon,
I think that even in SHUTDOWN_PENDING state, the retransmission timer and the
overall error threshold will make sure that an association gets freed when
the receiver is not responding.
SO_LINGER does not provide a way to wait for a period of time and do an ABORT.
We can either abort immediately or start the graceful shutdown process and
let it run until the overall error count reaches the threshold value.
Thanks
Sridhar
On Mon, 29 Jul 2002, Jon Grimm wrote:
> I am less coherent than usual even. I meant:
>
> "no way to give up and finally ABORT".. if we have not completed
> shutdown if we've never yet sent our SHUTDOWN due to pending data.
>
>
> Sorry, jon
>
> Jon Grimm wrote:
> >
> > I hate responding to my own notes..
> >
> > I'm not reading the SO_LINGER quite right.. even for TCP-style API,
> > there doesn't seem a way to only wait a certain time before an
> > association gives up and ABORTS. The only option is either to use
> > 0... to indicate an immediate ABORT or else non-zero to block waiting
> > for the shutdown before returning (but the graceful shutdown still waits
> > indefinately).
> >
> > So may be there is something else still needed OR .... is this even a
> > real issue.
> >
> > jon
> >
> > Jon Grimm wrote:
> > >
> > > So, I've noticed for some time a behavior in the UDP-style API as
> > > specified and we've implemented that seems a little troubling to me...
> > >
> > > Suppose a UDP-style socket is close()'d while its been flow controlled
> > > off by its peer, so that the sender has DATA pending that it can't
> > > send. The UDP-style close says that all the associations are to be
> > > gracefully shutdown. Since the sender has data pending it enters the
> > > SHUTDOWN-PENDING state and disallows new data. The sender stays in
> > > this state until the reciever finally decides to read all the data.
> > > This seems to let resources be captured indefinately.
> > >
> > > Now, the TCP style API has SO_LINGER defined to finally just go ahead
> > > and send an ABORT after some wait (may be an imediate abort even).
> > > I'm thinking that this could/should be implemented for UDP-style
> > > too. Otherwise, it would seem to allow someone to capture server
> > > resources at the peer indefinately. I can't see any reason that
> > > SO_LINGER wouldn't be definable and useful for a UDP-style
> > > application. We could treat it as a per socket variable.. if AUTOCLOSE
> > > or MSG_EOF were used to gracefult shutdown an association the current
> > > could be used.
> > >
> > > Am I reading this correct? I guess it really doesn't say we 'can't'
> > > implement SO_LINGER for the UDP-style sockets, but its odd that it is
> > > there for TCP-style, but not UDP-style.
> > >
> > > Best Regards,
> > > Jon
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: Dice - The leading online job board
> > > for high-tech professionals. Search and apply for tech jobs today!
> > > http://seeker.dice.com/seeker.epl?rel_code=31
> > > _______________________________________________
> > > Lksctp-developers mailing list
> > > Lksctp-developers@...
> > > https://lists.sourceforge.net/lists/listinfo/lksctp-developers
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Dice - The leading online job board
> > for high-tech professionals. Search and apply for tech jobs today!
> > http://seeker.dice.com/seeker.epl?rel_code=31
> > _______________________________________________
> > Lksctp-developers mailing list
> > Lksctp-developers@...
> > https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@...
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>

I am less coherent than usual even. I meant:
"no way to give up and finally ABORT".. if we have not completed
shutdown if we've never yet sent our SHUTDOWN due to pending data.
Sorry, jon
Jon Grimm wrote:
>
> I hate responding to my own notes..
>
> I'm not reading the SO_LINGER quite right.. even for TCP-style API,
> there doesn't seem a way to only wait a certain time before an
> association gives up and ABORTS. The only option is either to use
> 0... to indicate an immediate ABORT or else non-zero to block waiting
> for the shutdown before returning (but the graceful shutdown still waits
> indefinately).
>
> So may be there is something else still needed OR .... is this even a
> real issue.
>
> jon
>
> Jon Grimm wrote:
> >
> > So, I've noticed for some time a behavior in the UDP-style API as
> > specified and we've implemented that seems a little troubling to me...
> >
> > Suppose a UDP-style socket is close()'d while its been flow controlled
> > off by its peer, so that the sender has DATA pending that it can't
> > send. The UDP-style close says that all the associations are to be
> > gracefully shutdown. Since the sender has data pending it enters the
> > SHUTDOWN-PENDING state and disallows new data. The sender stays in
> > this state until the reciever finally decides to read all the data.
> > This seems to let resources be captured indefinately.
> >
> > Now, the TCP style API has SO_LINGER defined to finally just go ahead
> > and send an ABORT after some wait (may be an imediate abort even).
> > I'm thinking that this could/should be implemented for UDP-style
> > too. Otherwise, it would seem to allow someone to capture server
> > resources at the peer indefinately. I can't see any reason that
> > SO_LINGER wouldn't be definable and useful for a UDP-style
> > application. We could treat it as a per socket variable.. if AUTOCLOSE
> > or MSG_EOF were used to gracefult shutdown an association the current
> > could be used.
> >
> > Am I reading this correct? I guess it really doesn't say we 'can't'
> > implement SO_LINGER for the UDP-style sockets, but its odd that it is
> > there for TCP-style, but not UDP-style.
> >
> > Best Regards,
> > Jon
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Dice - The leading online job board
> > for high-tech professionals. Search and apply for tech jobs today!
> > http://seeker.dice.com/seeker.epl?rel_code=31
> > _______________________________________________
> > Lksctp-developers mailing list
> > Lksctp-developers@...
> > https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@...
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers

I hate responding to my own notes..
I'm not reading the SO_LINGER quite right.. even for TCP-style API,
there doesn't seem a way to only wait a certain time before an
association shutsdown gracefully. The only option is either to use
0... to indicate an immediate ABORT or else non-zero to block waiting
for the shutdown before returning (but the graceful shutdown still waits
indefinately).
So may be there is something else still needed OR .... is this even a
real issue.
jon
Jon Grimm wrote:
>
> So, I've noticed for some time a behavior in the UDP-style API as
> specified and we've implemented that seems a little troubling to me...
>
> Suppose a UDP-style socket is close()'d while its been flow controlled
> off by its peer, so that the sender has DATA pending that it can't
> send. The UDP-style close says that all the associations are to be
> gracefully shutdown. Since the sender has data pending it enters the
> SHUTDOWN-PENDING state and disallows new data. The sender stays in
> this state until the reciever finally decides to read all the data.
> This seems to let resources be captured indefinately.
>
> Now, the TCP style API has SO_LINGER defined to finally just go ahead
> and send an ABORT after some wait (may be an imediate abort even).
> I'm thinking that this could/should be implemented for UDP-style
> too. Otherwise, it would seem to allow someone to capture server
> resources at the peer indefinately. I can't see any reason that
> SO_LINGER wouldn't be definable and useful for a UDP-style
> application. We could treat it as a per socket variable.. if AUTOCLOSE
> or MSG_EOF were used to gracefult shutdown an association the current
> could be used.
>
> Am I reading this correct? I guess it really doesn't say we 'can't'
> implement SO_LINGER for the UDP-style sockets, but its odd that it is
> there for TCP-style, but not UDP-style.
>
> Best Regards,
> Jon
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@...
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers

So, I've noticed for some time a behavior in the UDP-style API as
specified and we've implemented that seems a little troubling to me...
Suppose a UDP-style socket is close()'d while its been flow controlled
off by its peer, so that the sender has DATA pending that it can't
send. The UDP-style close says that all the associations are to be
gracefully shutdown. Since the sender has data pending it enters the
SHUTDOWN-PENDING state and disallows new data. The sender stays in
this state until the reciever finally decides to read all the data.
This seems to let resources be captured indefinately.
Now, the TCP style API has SO_LINGER defined to finally just go ahead
and send an ABORT after some wait (may be an imediate abort even).
I'm thinking that this could/should be implemented for UDP-style
too. Otherwise, it would seem to allow someone to capture server
resources at the peer indefinately. I can't see any reason that
SO_LINGER wouldn't be definable and useful for a UDP-style
application. We could treat it as a per socket variable.. if AUTOCLOSE
or MSG_EOF were used to gracefult shutdown an association the current
could be used.
Am I reading this correct? I guess it really doesn't say we 'can't'
implement SO_LINGER for the UDP-style sockets, but its odd that it is
there for TCP-style, but not UDP-style.
Best Regards,
Jon

Jon, La Monte:
Upgrading the sctp_ulpevent.c file to version 1.3 fixed the problem!
I think the skb->end pointer was getting corrupted causing the
kernel hang.
We are very tightly tied to the 2.4.17 kernel due to a bunch of
other reasons. Therefore, I guess we need to backport all of
the bug fixes/enhancements from the latest release.
Thanks a lot for your suggestion!
Chandru
-----Original Message-----
From: Jon Grimm [mailto:jgrimm2@...]
Sent: Thursday, July 18, 2002 6:28 AM
To: Chandru Sargor
Cc: La Monte Henry Piggy Yarroll;
lksctp-developers@...
Subject: Re: [Lksctp-developers] Re: Problem building the test directory
with lksctp-2_4_17.0_4_4
Thanks La Monte and Welcome to Chandru!
La Monte is correct, the base has moved on quite significantly since
0.4.4 in features and bug fixes.
FWIW, I vaguely seeing this issue in the past. The following changes
_may_ have been a fix to this:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/lksctp/lksctp/sctp_cvs/net/sc
tp/sctp_ulpevent.c.diff?r1=1.2&r2=1.3
If possible, you really do need to move ahead on to the later releases,
as we are not planning to keep older development releases going. Even
if you find the bug that is hampering you at this point in time, there
will be something else you hit next.
How tied to 2.4.17 are you?
Best Regards,
Jon
La Monte Henry Piggy Yarroll wrote:
>
> I just noticed that your messages have been going to just a few
> developers, not the full mailing list. I've moved this to the
> developers' list. You'll get a LOT more help that way. In
> particular, you had omitted Jon Grimm, the fellow who runs the project
> now.
>
> The extra messages are notifications telling you that a new
> association came up and that it then went down. Look at the ancillary
> data. I thought that sctp_darn handled notifications properly...
>
> Memory management is something that's been cleaned up a LOT since this
> version of lksctp. Can you tell us more about WHY you have to use the
> older kernel?
>
> My short-term suggestion is that you just remove the free. You can do
> quite a lot of experimentation before you exhaust all of your memory.
>
> Longer term, you either need to move to the current kernel or do a
> backport. A backport of the current version should not be TOO
> painful...
>
> > Hi folks,
> >
> > I continued debugging the cause of the PPC hang and have narrowed it
> > down to an skb_free(). Basically, the hang happens when the skb
containing
> > the user data (typed at the send> prompt of sctp_darn) is freed via
> > a call to sctp_ulpevent_free() (which calls kfree_skb()).
> >
> > I have some questions:
> >
> > 1. From the x86 and ppc logs I see that even tho there is only one
> > data packet (7 bytes of user data = "hello") sent, on the
> > recv side 3 packets are read and passed into recvmsg():
> >
> > - the first is of length 20 bytes and contains binary data
> > - the second is the actual data sent (7 bytes long)
> > - the third is again 20 bytes long and contains binary data
> >
> > Why are these other data packets being read by recvmsg()? I
> > see them both on x86 and ppc machines. Even the user program
> > sctp_darn first prints out 20 bytes of garbage on ppc (and blank
> > text on x86) before printing the user data. Again, there is
> > the same 20 bytes printed when the connection is shutdown.
> >
> > 2. Do u have an idea as to what may be causing the kernel to hang
> > when the skbuff is freed?
> >
> > The first skb containing the 20 bytes of spurious data is freed
> > with no problem.
> >
> > The kernel hangs when trying to free the skbuff containing the
> > 7 bytes of user data ("hello").
> >
> > kfree_skb() calls skb_release_data() which calls
> > atomic_dec_and_test(&(skb_shinfo(skb)->dataref)). This is where
> > the kernel hangs.
> >
> >
> > Any tips/insights/suggestions would be greatly appreciated.
> >
> > Thanks,
>

Since I just tagged 0.4.12, I thought I'd throw out a note on our
continued progress.
One of the project goals has been to get ourselves integrated into the
Linux kernel... we refocused much of our energy since the start of the
year along these lines (putting together a core set of function that
would be worth putting into the kernel).
I think we are almost there. La Monte and I had a discussion last
January on the set of functionality/tasks that should minimally happen
before submission. We've completed that list (and then some!) As such,
I believe we should start submitting our code to the network
maintainers. We're not RFC complete yet and we do have a few warts here
and there, but overall I hope we offer a useful package that helps
propogate the SCTP protocol.
I have no idea if the networking maintainers will be interested in
bringing us into the 2.5 tree, nor what other requirements may be put
upon us, but we need to get our code directly in front of the
maintainers.
Why do I bring this up? Well, I want other folks to give me their
opinion on our readiness. Are we ready? If not, why not and is it
fixable? What are the showstoppers.
Consequently, I'd like to start settling down the base. By the end of
July I want to send a note out claiming we are Beta ready and want to be
considered for inclusion in the kernel. (FYI: Guillaume Boissiere was
willing to add us to his kernel 2.5 status page. See
http://www.kernelnewbies.org/status/Status-17-Jul-2002.html)
I do know that folks are wrapping up a few things.. Sridhar is working
on peeloff; Daisy is working on select/poll; and Dajiang and Hui are
working on overlapping Init. All of these pieces are very close to
being done (or done enough for inclusion). I still plan on integrating
these, but do not expect to integrate many others, instead focusing on
bug fixes and code cleanups.
I'm not sure what happens after that. We really have a short window of
opportunity (Linus has publicly stated that the feature freeze data is
October 31). We'll need to examine what we do next based on feedback we
get on our submission and decide how we get that work done. Keep in
mind, we'll probably need to submit several times before we get real
feedback. We may get told just to go away, but my hopes are that we
have something value.
Otherwise, I'm assuming that we will continue on our way toward 1.0
which will contain full RFC 2960, UDP-style API, and possibly the
TCP-style API. The more interesting features we do not have completed
are the Source Address Selection and PMTU discovery.
Thanks again to anyone who has helped out in any fashion.. whether it be
bug reporting, code submissions, or just a report that they had been
successful in downloading and running our testcases.
I'll sign off with the request I made earlier:
Are we ready? What else MUST be done before we think about submitting?
Best Regards,
Jon Grimm

On Fri, 12 Jul 2002 loretosa@... wrote:
> i've downloaded the last version of lksctp ... by CVS
>
> in this version there are two mistaken Makefile:
>
> 1) in the directory /linux_sctp/net
> 2) in the directory /linux_sctp/net/sctp
The CVS version of lksctp is based on linux kernel 2.5.24.
If you are using 2.5.24 kernel, there should not be any problem while building
the kernel.
Are you noticing any compiler errors while building the kernel? Which version
of kernel are you using?
Thanks
Sridhar
>
> i've changed this two files with the old Makefile
> then i completed the kernel compilation successfull
>
>
> Sal
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Gadgets, caffeine, t-shirts, fun stuff.
> http://thinkgeek.com/sf
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@...
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
>

i've downloaded the last version of lksctp ... by CVS
in this version there are two mistaken Makefile:
1) in the directory /linux_sctp/net
2) in the directory /linux_sctp/net/sctp
i've changed this two files with the old Makefile
then i completed the kernel compilation successfull
Sal

Hi all,
Is there any heartbreak in removing the md5 code from the source tree?
We have the SHA-1 code there too that we use anyway by default for our
HMAC of the state cookie. The code is compiled/linked even though we
don't use it. I'm guessing I'm the last person that even tested that it
still worked (back in February).
Since we have a fairly large codebase, I'm afraid we are going to scare
folks with sheer lines of code. (at least I've warned of this) and am
wanting to remove all but the essentials that we need. Both the SHA-1
and MD5 implementation code comes from RFCs, so the code can be
resurrected even if we weren't able to go back to CVS (which we can).
MD5 as a cryptographic hash has some weaknesses (IIRC, the weakness is
eliminated when used in HMAC), and as such you see it used less
frequently. The IBM crypto experts recommended against its use for
all cases when asked their opinion.
Is there anyone dependent on that MD5 code? Right now, I'm assuming
I'm the last person that even tried it, but didn't want to just blast it
away (like I usually do ;-) ) just in case.
BTW, there was a BOF at the kernel summit for a crypto library in the
kernel (similar to the CRC32 code being pulled in a 2.5 module). I was
unfortunately, the only person who was at that BOF besides the Free/SWAN
guys. In the long term, I'm assuming algorithm code like this will move
into a standalone module like CRC32 was just recently. Algorithms with
export issues will be a tough sell, but things like zlib compression (I
think used by PPP), crc32, md5, sha1 shouldn't be too controversial.
Who knows we may get asked to even start that process by moving our
SHA-1 code into the kernel lib. too.
Best Regards,
Jon