0

Cumulative TSN in SACK (SCTP Server) is not incorrect after association created. It is always ('Initial TSN' - 1). Actually, Client sends messages to Server.

Just wondering whether it is the issue of LKSCTP ? Red Hat Enterprise Linux Server release 6.7 (Santiago) lksctp-tools-1.0.10-7.el6.x86_64

Such as 'Initial TSN' is 100 in INIT from SCTP client to SCTP server. After 4 messages handshake, client sends one message with TSN 100 to server. The Cumulative TSN in SACK from server is 99. Client sends more messages. The Cumulative TSN in SACK from server is still 99. Client retransmits messages. The Cumulative TSN in SACK from server is still 99. Late, Client sends Abort to Server.

After Abort, association is created again. Then it happens issues same with above descritpion.

enter image description here

Init

Init Ack

SACK

Abort

Zegang
  • 11
  • 3
  • Please provide a bit more information. In particular: 1. Initial TSN value reported by both sides (client and server) in INIT and INIT_ACK. 2. What was reported in SACK chunk. Were there any optional parameters like GAP ack blocks or duplicated TSN? 3. What was reported in ABORT chunk. Were there any "error cause" appended to the ABORT chunk? Just FYI, regardless of what value of initial TSN client side reported in INIT chunk, when it sends DATA chunk for the very first time it should be using initial TSN reported by the server side in INIT_ACK. – Alexander Zinovyev May 15 '18 at 18:56
  • 1. tsn obeys the specification; 2.No extra information in SACK chunk; 3.No cause code in Abort. Pls. check uploaded images. thanks. – Zegang May 16 '18 at 11:19

0 Answers0