SCTP SSN handling error

[ohcool9898]

I try to send a live streaming through webrtc data channel to browser, but the browser will fail to receive the streaming data 20 minutes later. In the sctp layer, the browser keeps sending ack indicating that it has received no more data. After close investigation, I find out that the problem results from the false variable declaration in function "sctp_queue_data_to_stream"(in usrsctplib/netinet/sctp_indata.c). Defined in rfc 4960, the field for Stream Sequence Number(SSN) is a 16-bit unsigned digit, but 32-bits here.

[tuexen]

That is intentional, since we need a 32-bit value when using the I-DATA extension. So the plan is that we are passing around 32-bit values, but do 16-bit arithmetic in case we are not using this extensions.
There might be bugs there... Can you tell me how to reproduce the problem? Just transferring 100000 messages doesn't produce the problem...

[ohcool9898]

I was trying to send a sequence of sctp messages, and each sctp messge is about 1000 bytes with itself a complete message(the b bit and e bit are set, ref: https://tools.ietf.org/html/rfc4960#section-3.3.1). After we send more than 65535 messages, the problem happens. (The statement
nxt_todel = strm->last_sequence_delivered + 1;`) will cause the problem.
(Ex: strm->last_sequence_delivered = 65535, then the value of nxt_todel will be 65536, but the value range of control->sinfo_ssn(SSN) is 0 ~ 65535. Therefore, the incoming messages afterwards will be queued in the buffer(by the function call "sctp_place_control_in_stream") till the buffer is over the preset limit.).
What I encounter is that as the buffer size is over "sctp_max_chunks_on_queue" then the incoming messages will all be dropped.

[tuexen]

I saw that and I think you are right. We need to detect if the comparison is needed to be based on uint16_t or uint32_t. I just want to reproduce the issue to be able to test the fix.
I can't reproduce this with the kernel stack. Since you are using the userland stack, are you using the callback API?

[tuexen]

OK. I can confirm that there is a bug, I was able to reproduce the problem. Will fix it...

[ohcool9898]

Thanks for your quick response.

[shiretu]

Was about to report the same issue.

[shiretu]

I have a full pcap file with the issue if that helps, but is ~320MB in size.

[tuexen]

@shiretu I can reproduce the issue locally, not tracefile needed. Thanks for offering!

[tuexen]

Please test this fix. I'm able to transfer several hundred GBs without any problem. This was failing before...

[shiretu]

@tuexen: thank you sir! Will do so!