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)
