On Tue, Jan 17, 2017 at 9:13 PM, Julian Cordes <julian.cordes@xxxxxxxxx> wrote: > When fragmented ordered user messages are sent to the linux kernel user > messages with inconsistent stream sequence numbers are accepted and > delivered to the application. Take for example an look at the following test case: > https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/error-cases/packet-loss/ordered/ordered-packet-loss-2.pkt > > Here I first inject two DATA-Chunks with sid/ssn 1/1, 2/1 into the > kernel with packetdrill: > line 67: +0.0 < sctp: DATA[flgs=E, len=1016, tsn=2, sid=1, ssn=1, > ppid=0] > line 69: +0.1 < sctp: DATA[flgs=E, len=1016, tsn=4, sid=2, ssn=1, > ppid=0] > > After 0.1 seconds i then inject an FORWARD-TSN with cum_tsn=2 bundled > with an DATA-Chunk that looks like this: > DATA[flgs=B, len=1016, tsn=3, sid=2, ssn=0, ppid=0] > > This "looks" like the first segment of the user message where already a > fragment (tsn=4) was received. But the ssn-values are not consistent. > The DATA-Chunk with tsn=3 has ssn=0 and the ssn=1 therefore they should > be ignored by the IUT and not be delivered to the userland application when > calling sctp_recvmsg. Unfortunatly the linux kernel implementation does > currently deliver these inconsistent user messages. sorry, I may misunderstand you. after FORWARD-TSN, "DATA[flgs=E, len=1016, tsn=2, sid=1, ssn=1" should be received, then only "sctp: DATA[flgs=E, len=1016, tsn=4, sid=2, ssn=1" is in the queue, then "DATA[flgs=B, len=1016, tsn=3, sid=2, ssn=0, ppid=0]" is processed, these two chunks (tsn=3 and tsn=4) should be recvmsg, as their sid are the same and ssn are consistent (ssn=0 and ssn=1). and your sctp_recvmsg is after above, so it should be right. did I miss something? > > There are many test-cases that all reproduce this > issue. Just take a look at the README at > https://github.com/nplab/PR_SCTP_Testsuite/tree/master/forward-tsn/error-cases/packet-loss/ordered. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
