From: David Laight <David.Laight@ACULAB.COM>
To: linux-sctp@vger.kernel.org
Subject: RE: sctp discarding received data chunks
Date: Fri, 09 Oct 2020 11:13:31 +0000 [thread overview]
Message-ID: <73434b87932e46a89dd1b5b5132b3196@AcuMS.aculab.com> (raw)
In-Reply-To: <e377e7e2a87e4f078e7a6d82992cfda0@AcuMS.aculab.com>
From: Andreas Fink
> Sent: 09 October 2020 08:25
>
> Can you see this issue with the 5.4 kernel too?
>
> I did yesterday some testing by upgrading kernel from 5.4 to 5.7 and I run into all sorts of links
> going off after a while so I had to revert back.
> 5.4 is stable for me. 5.7 is not. And I have lots of M2PA and M3UA connections like you
I've just spent hours digging through my traces.
It is only some messages through the connection that get lost!
Now SCTP_MIN_IN_DATA_CHUNK_DISCARDS is only incremented in two
adjacent places in sm_statefuncs.c.
Either for bad TSN (unlikely when everything is using "lo")
and bad STREAM.
I suspect it is the 'bad stream' case.
I've not double-checked but I bet the discarded packets
all have a large stream number.
So it is likely that the addition of 'sctp streams' broke
the negotiation of the maximum stream number, and the reporting
of that value back to the application in getsockopt().
I've probably recently changed my test to request 17 streams
(not 5). Since the default number of streams is 10 that may
be why it worked on this kernel before.
There was a similar bug that got fixed very recently.
Ah yes, I wrote this on 14th August:
At some point the negotiation of the number of SCTP streams
seems to have got broken.
I've definitely tested it in the past (probably 10 years ago!)
but on a 5.8.0 kernel getsockopt(SCTP_INFO) seems to be
returning the 'num_ostreams' set by setsockopt(SCTP_INIT)
rather than the smaller of that value and that configured
at the other end of the connection.
Although I though that stopped packets being set, not received.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andreas Fink' <afink@list.fink.org>,
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>,
'Neil Horman' <nhorman@tuxdriver.com>,
"'Xin Long'" <lucien.xin@gmail.com>
Cc: "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>
Subject: RE: sctp discarding received data chunks
Date: Fri, 9 Oct 2020 11:13:31 +0000 [thread overview]
Message-ID: <73434b87932e46a89dd1b5b5132b3196@AcuMS.aculab.com> (raw)
Message-ID: <20201009111331.XAzWNdbUYiC2MB3O46fVRyzVnmua6iF_RJsMP4dqisE@z> (raw)
In-Reply-To: <CC1FDC9B-F273-475A-98C5-000ADC395BB0@list.fink.org>
From: Andreas Fink
> Sent: 09 October 2020 08:25
>
> Can you see this issue with the 5.4 kernel too?
>
> I did yesterday some testing by upgrading kernel from 5.4 to 5.7 and I run into all sorts of links
> going off after a while so I had to revert back.
> 5.4 is stable for me. 5.7 is not. And I have lots of M2PA and M3UA connections like you
I've just spent hours digging through my traces.
It is only some messages through the connection that get lost!
Now SCTP_MIN_IN_DATA_CHUNK_DISCARDS is only incremented in two
adjacent places in sm_statefuncs.c.
Either for bad TSN (unlikely when everything is using "lo")
and bad STREAM.
I suspect it is the 'bad stream' case.
I've not double-checked but I bet the discarded packets
all have a large stream number.
So it is likely that the addition of 'sctp streams' broke
the negotiation of the maximum stream number, and the reporting
of that value back to the application in getsockopt().
I've probably recently changed my test to request 17 streams
(not 5). Since the default number of streams is 10 that may
be why it worked on this kernel before.
There was a similar bug that got fixed very recently.
Ah yes, I wrote this on 14th August:
At some point the negotiation of the number of SCTP streams
seems to have got broken.
I've definitely tested it in the past (probably 10 years ago!)
but on a 5.8.0 kernel getsockopt(SCTP_INFO) seems to be
returning the 'num_ostreams' set by setsockopt(SCTP_INIT)
rather than the smaller of that value and that configured
at the other end of the connection.
Although I though that stopped packets being set, not received.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2020-10-09 11:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 21:46 sctp discarding received data chunks David Laight
2020-10-08 21:46 ` David Laight
2020-10-09 7:24 ` Andreas Fink
2020-10-09 7:24 ` Andreas Fink
2020-10-09 7:57 ` David Laight
2020-10-09 7:57 ` David Laight
2020-10-09 11:13 ` David Laight [this message]
2020-10-09 11:13 ` David Laight
2020-10-09 13:03 ` David Laight
2020-10-09 13:03 ` David Laight
2020-10-10 2:35 ` Xin Long
2020-10-10 2:35 ` Xin Long
2020-10-10 15:10 ` David Laight
2020-10-10 15:10 ` David Laight
2020-10-11 8:33 ` Andreas Fink
2020-10-11 8:33 ` Andreas Fink
2020-10-11 15:28 ` David Laight
2020-10-11 15:28 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=73434b87932e46a89dd1b5b5132b3196@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=linux-sctp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).