From: David Laight <David.Laight@ACULAB.COM>
To: linux-sctp@vger.kernel.org
Subject: sctp discarding received data chunks
Date: Thu, 08 Oct 2020 21:46:42 +0000 [thread overview]
Message-ID: <e377e7e2a87e4f078e7a6d82992cfda0@AcuMS.aculab.com> (raw)
One of my local tests (that I run quite often) failed in a 'new and exciting way'.
I sent 510 messages through an M3UA-MTP2-M3UA link and only got ~350 at the far end.
(This is part of my SS7+TCAP regression test - gets run a lot.)
Usually I can find 'lost' messages logged as discarded due to my own flow control.
In this case there is no sign of any error traces.
I expect to have each message traced 6 times (on each send and receive)
but the missing messages are only traced 5 times.
Now /proc/net/sctp/snmp has SctpInDataChunksDiscards set to 163,
this matches the number of messages I'm missing.
Any idea how I can find out why one (or more) the SCTP connections (which are still
connected - unless there is a power cut) has discarded a lot of receive packets?
Each M3UA link is actually 4 SCTP connections (TCP style 1-1).
All are loopback connected to 127.0.0.1 or ::1 (the assocs print is 'interesting').
The local port is 'random' the listening port 2905 or 2906.
I'd expect the data to loadshare evenly between them but I've not checked the actual
distribution.
The packet data contains a sequence number, I'm missing all the x1, x2, x9, xa
and half the x6 and xe packets - so I think at least one of the sctp connections
is just discarding the receive chunks.
(I'll sort out which one tomorrow.)
This is a 5.6.0-rc7 kernel.
I've not seen anything like this before - I've run this same test for
over 10 years, probably going back to at least 2.6.28.
Data chunks will have gone though all the connections when they were
initialised.
Is there anything anywhere that indicates why a data chunk was dropped?
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: "linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>
Subject: sctp discarding received data chunks
Date: Thu, 8 Oct 2020 21:46:42 +0000 [thread overview]
Message-ID: <e377e7e2a87e4f078e7a6d82992cfda0@AcuMS.aculab.com> (raw)
Message-ID: <20201008214642.jkZjVppsHXFThnWMP501qEsoWdC5i87XKFoCtOB_eVQ@z> (raw)
One of my local tests (that I run quite often) failed in a 'new and exciting way'.
I sent 510 messages through an M3UA-MTP2-M3UA link and only got ~350 at the far end.
(This is part of my SS7+TCAP regression test - gets run a lot.)
Usually I can find 'lost' messages logged as discarded due to my own flow control.
In this case there is no sign of any error traces.
I expect to have each message traced 6 times (on each send and receive)
but the missing messages are only traced 5 times.
Now /proc/net/sctp/snmp has SctpInDataChunksDiscards set to 163,
this matches the number of messages I'm missing.
Any idea how I can find out why one (or more) the SCTP connections (which are still
connected - unless there is a power cut) has discarded a lot of receive packets?
Each M3UA link is actually 4 SCTP connections (TCP style 1-1).
All are loopback connected to 127.0.0.1 or ::1 (the assocs print is 'interesting').
The local port is 'random' the listening port 2905 or 2906.
I'd expect the data to loadshare evenly between them but I've not checked the actual
distribution.
The packet data contains a sequence number, I'm missing all the x1, x2, x9, xa
and half the x6 and xe packets - so I think at least one of the sctp connections
is just discarding the receive chunks.
(I'll sort out which one tomorrow.)
This is a 5.6.0-rc7 kernel.
I've not seen anything like this before - I've run this same test for
over 10 years, probably going back to at least 2.6.28.
Data chunks will have gone though all the connections when they were
initialised.
Is there anything anywhere that indicates why a data chunk was dropped?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next reply other threads:[~2020-10-08 21:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 21:46 David Laight [this message]
2020-10-08 21:46 ` sctp discarding received data chunks 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
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=e377e7e2a87e4f078e7a6d82992cfda0@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).