Menu
▾
▴
Re: [Lksctp-developers] SACK after SCTP restart before 1st data frame
|
From: Michael T. <Mic...@lu...> - 2011-05-25 10:38:41
|
On May 23, 2011, at 4:32 PM, Martin Mc Donald wrote: > Hi, > > We found an unexpected behavior of the lksctp. > > 1. An existing SCTP connection with Data transmission. Last frame is a data frame > 2. The SCTP is restarted. INIT, INIT_ACK, COOKIE, COOKIE_ECHO > 3. Very seldom the lksctp sends a SACK after that before receiving any data frames. - This seems to be wrong. From looking at the trace it looks like the last DATA chunk resulted in starting a 200 ms delayed SACK timer. And the SACK is send after that timeout. However, this is wrong IMHO, since a restart should stop the timer. > 4. Another strict SCTP implementation aborts the SCTP connection. Not sure why... There is no reason to send the SACK, but it is completely acceptable. The ABORT seems wrong to me, too. Best regards Michael > > No. Time Source Destination Protocol Info Initiate tag Verification tag Initial TSN Cumulative TSN ACK Advertised receiver window credit (a_rwnd) > 1 08:32:55.742460 20.10.10.47 21.10.10.7 SCTP DATA 0x7783bddb > 2 08:32:55.939333 21.10.10.7 20.10.10.47 SCTP SACK 0x7ef51d24 458201590 62420 > 3 08:32:56.023417 20.10.10.47 21.10.10.7 SCTP DATA 0x7783bddb > 4 08:32:56.181983 20.10.10.47 21.10.10.7 SCTP INIT 0x00000000 1396301102 100000 > 5 08:32:56.182021 21.10.10.7 20.10.10.47 SCTP INIT_ACK 0x8ac4cb40 0x757e6004 62464 > 6 08:32:56.202607 20.10.10.47 21.10.10.7 SCTP COOKIE_ECHO 0x8ac4cb40 > 7 08:32:56.202637 21.10.10.7 20.10.10.47 SCTP COOKIE_ACK 0x757e6004 > 8 08:32:56.218595 21.10.10.7 20.10.10.47 SCTP SACK 0x757e6004 1396301101 62420 > 9 08:32:56.221773 20.10.10.47 21.10.10.7 SCTP ABORT 0x8ac4cb40 > > Frame 8: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) > Ethernet II, Src: IntelCor_7d:a2:08 (00:1b:21:7d:a2:08), Dst: Cisco_a8:f8:4f (00:1c:b0:a8:f8:4f) > Internet Protocol, Src: 21.10.10.7 (21.10.10.7), Dst: 20.10.10.47 (20.10.10.47) > Stream Control Transmission Protocol, Src Port: m3ua (2905), Dst Port: m3ua (2905) > Source port: 2905 > Destination port: 2905 > Verification tag: 0x757e6004 > Checksum: 0x00000000 [incorrect CRC32C, should be 0xa4e91d79] > SACK chunk (Cumulative TSN: 1396301101, a_rwnd: 62420, gaps: 0, duplicate TSNs: 0) > Chunk type: SACK (3) > Chunk flags: 0x00 > Chunk length: 16 > Cumulative TSN ACK: 1396301101 > Advertised receiver window credit (a_rwnd): 62420 > Number of gap acknowledgement blocks: 0 > Number of duplicated TSNs: 0 > > > Questions are: > > 1. Is this SACK allowed? > 2. Why is this SACK send - it does not confirm anything. > 3. If the SACK is ok - is Initial TSN -1 a valid Cumulative TSN ACK value > RFC 4960 > 11.4. Protection of Non-SCTP-Capable Hosts > > An SCTP implementation SHOULD abort the association if it receives a > SACK acknowledging a TSN that has not been sent. > > > Best regards, > Martin Mc Donald > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Lksctp-developers mailing list > Lks...@li... > https://lists.sourceforge.net/lists/listinfo/lksctp-developers > |