* [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
[not found] <18087.57737.908842.337891@zeus.sw.starentnetworks.com>
@ 2007-07-31 4:44 ` Wei Yongjun
2007-07-31 11:37 ` [Lksctp-developers] " Neil Horman
0 siblings, 1 reply; 11+ messages in thread
From: Wei Yongjun @ 2007-07-31 4:44 UTC (permalink / raw)
To: lksctp-developers, netdev
If SCTP data sender received a SACK which contains Cumulative TSN Ack is
not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
Ack is not used by the data sender, SCTP data sender still accept this
SACK , and next SACK which send correctly to DATA sender be dropped,
because it is less than the new Cumulative TSN Ack Point.
After received this SACK, data will be retrans again and again even if
correct SACK is received.
So I think this SACK must be dropped to let data transmit correctly.
Following is the tcpdump of my test. And patch in this mail can avoid
this problem.
02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS: 10] [MIS: 65535] [init TSN: 217114040]
02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100] [MIS: 65535] [init TSN: 100]
02:19:39.798583 sctp (1) [COOKIE ECHO]
02:19:40.082125 sctp (1) [COOKIE ACK]
02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0] [PPID 0xf192090b]
02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1] [PPID 0x3e467007]
02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2] [PPID 0x11b12a0a]
02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3] [PPID 0x30e7d979]
02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4] [PPID 0x251ff86f]
02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5] [PPID 0xe5d5da5d]
02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7] [PPID 0xca47e645]
02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8] [PPID 0x6c0ea150]
02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9] [PPID 0x9cc1994f]
02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10] [PPID 0xb1df4129]
02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
--- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.000000000 -0400
+++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.000000000 -0400
@@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
return SCTP_DISPOSITION_DISCARD;
}
+ /* If Cumulative TSN Ack is not less than the Cumulative TSN
+ * Ack which will be send in the next data, drop the SACK.
+ */
+ if (!TSN_lt(ctsn, asoc->next_tsn)) {
+ SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
+ SCTP_DEBUG_PRINTK("next_tsn %x\n", asoc->next_tsn);
+ return SCTP_DISPOSITION_DISCARD;
+ }
+
/* Return this SACK for further processing. */
sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH(sackh));
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-07-31 4:44 ` [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc Wei Yongjun
@ 2007-07-31 11:37 ` Neil Horman
2007-07-31 17:28 ` Sridhar Samudrala
0 siblings, 1 reply; 11+ messages in thread
From: Neil Horman @ 2007-07-31 11:37 UTC (permalink / raw)
To: Wei Yongjun; +Cc: lksctp-developers, netdev
On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
> If SCTP data sender received a SACK which contains Cumulative TSN Ack is
> not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
> Ack is not used by the data sender, SCTP data sender still accept this
> SACK , and next SACK which send correctly to DATA sender be dropped,
> because it is less than the new Cumulative TSN Ack Point.
> After received this SACK, data will be retrans again and again even if
> correct SACK is received.
> So I think this SACK must be dropped to let data transmit correctly.
>
> Following is the tcpdump of my test. And patch in this mail can avoid
> this problem.
>
> 02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS: 10] [MIS: 65535] [init TSN: 217114040]
> 02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100] [MIS: 65535] [init TSN: 100]
> 02:19:39.798583 sctp (1) [COOKIE ECHO]
> 02:19:40.082125 sctp (1) [COOKIE ACK]
> 02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0] [PPID 0xf192090b]
> 02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1] [PPID 0x3e467007]
> 02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2] [PPID 0x11b12a0a]
> 02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3] [PPID 0x30e7d979]
> 02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4] [PPID 0x251ff86f]
> 02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5] [PPID 0xe5d5da5d]
> 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> 02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7] [PPID 0xca47e645]
> 02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8] [PPID 0x6c0ea150]
> 02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9] [PPID 0x9cc1994f]
> 02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10] [PPID 0xb1df4129]
> 02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> 02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> 02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> 02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> 02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> 02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> 02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
> --- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.000000000 -0400
> +++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.000000000 -0400
> @@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
> return SCTP_DISPOSITION_DISCARD;
> }
>
> + /* If Cumulative TSN Ack is not less than the Cumulative TSN
> + * Ack which will be send in the next data, drop the SACK.
> + */
> + if (!TSN_lt(ctsn, asoc->next_tsn)) {
> + SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
> + SCTP_DEBUG_PRINTK("next_tsn %x\n", asoc->next_tsn);
> + return SCTP_DISPOSITION_DISCARD;
> + }
> +
> /* Return this SACK for further processing. */
> sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH(sackh));
>
>
>
Whats the behavior on this in the event that a sack is received in which the
ctsn falls within a a missing space in a stream of gap acks? I.e. what if the
sack being sent falls into a hole between the ack point and the first gap ack
range? Does this patch impact that at all?
Also, what is this:
02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] ....
That ack value seems rather out of range for the rest of the trace. Was that
part of your test? If so, what caused it?
Thanks & Regards
Neil
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@tuxdriver.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-07-31 11:37 ` [Lksctp-developers] " Neil Horman
@ 2007-07-31 17:28 ` Sridhar Samudrala
2007-08-01 1:06 ` Wei Yongjun
0 siblings, 1 reply; 11+ messages in thread
From: Sridhar Samudrala @ 2007-07-31 17:28 UTC (permalink / raw)
To: Neil Horman; +Cc: Wei Yongjun, netdev, lksctp-developers
On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
> On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
> > If SCTP data sender received a SACK which contains Cumulative TSN Ack is
> > not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
> > Ack is not used by the data sender, SCTP data sender still accept this
> > SACK , and next SACK which send correctly to DATA sender be dropped,
> > because it is less than the new Cumulative TSN Ack Point.
> > After received this SACK, data will be retrans again and again even if
> > correct SACK is received.
> > So I think this SACK must be dropped to let data transmit correctly.
> >
> > Following is the tcpdump of my test. And patch in this mail can avoid
> > this problem.
> >
> > 02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS: 10] [MIS: 65535] [init TSN: 217114040]
> > 02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100] [MIS: 65535] [init TSN: 100]
> > 02:19:39.798583 sctp (1) [COOKIE ECHO]
> > 02:19:40.082125 sctp (1) [COOKIE ACK]
> > 02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0] [PPID 0xf192090b]
> > 02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1] [PPID 0x3e467007]
> > 02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2] [PPID 0x11b12a0a]
> > 02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3] [PPID 0x30e7d979]
> > 02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4] [PPID 0x251ff86f]
> > 02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5] [PPID 0xe5d5da5d]
> > 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> > 02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7] [PPID 0xca47e645]
> > 02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8] [PPID 0x6c0ea150]
> > 02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9] [PPID 0x9cc1994f]
> > 02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10] [PPID 0xb1df4129]
> > 02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> > 02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> > 02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> > 02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> > 02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> > 02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
> > 02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
> >
> >
> > Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
> >
> > --- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.000000000 -0400
> > +++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.000000000 -0400
> > @@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
> > return SCTP_DISPOSITION_DISCARD;
> > }
> >
> > + /* If Cumulative TSN Ack is not less than the Cumulative TSN
> > + * Ack which will be send in the next data, drop the SACK.
> > + */
> > + if (!TSN_lt(ctsn, asoc->next_tsn)) {
> > + SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
> > + SCTP_DEBUG_PRINTK("next_tsn %x\n", asoc->next_tsn);
> > + return SCTP_DISPOSITION_DISCARD;
> > + }
> > +
> > /* Return this SACK for further processing. */
> > sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH(sackh));
> >
> >
> >
> Whats the behavior on this in the event that a sack is received in which the
> ctsn falls within a a missing space in a stream of gap acks? I.e. what if the
> sack being sent falls into a hole between the ack point and the first gap ack
> range? Does this patch impact that at all?
>
> Also, what is this:
> 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] ....
>
> That ack value seems rather out of range for the rest of the trace. Was that
> part of your test? If so, what caused it?
Yes. This SACK seems to be totally out of range and may be causing the problem.
I would expect the following check in sctp_sf_eat_sack_6_2() to drop any SACKs
with CTSN value lower than the earlier SACKs.
/* i) If Cumulative TSN Ack is less than the Cumulative TSN
* Ack Point, then drop the SACK. Since Cumulative TSN
* Ack is monotonically increasing, a SACK whose
* Cumulative TSN Ack is less than the Cumulative TSN Ack
* Point indicates an out-of-order SACK.
*/
if (TSN_lt(ctsn, asoc->ctsn_ack_point)) {
SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
SCTP_DEBUG_PRINTK("ctsn_ack_point %x\n", asoc->ctsn_ack_point);
return SCTP_DISPOSITION_DISCARD;
}
Thanks
Sridhar
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-07-31 17:28 ` Sridhar Samudrala
@ 2007-08-01 1:06 ` Wei Yongjun
2007-08-01 3:15 ` [Lksctp-developers] " Vlad Yasevich
2007-08-01 9:01 ` [Lksctp-developers] " Michael Tuexen
0 siblings, 2 replies; 11+ messages in thread
From: Wei Yongjun @ 2007-08-01 1:06 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: Neil Horman, netdev, lksctp-developers
> On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
>
>> On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
>>
>>> If SCTP data sender received a SACK which contains Cumulative TSN Ack is
>>> not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
>>> Ack is not used by the data sender, SCTP data sender still accept this
>>> SACK , and next SACK which send correctly to DATA sender be dropped,
>>> because it is less than the new Cumulative TSN Ack Point.
>>> After received this SACK, data will be retrans again and again even if
>>> correct SACK is received.
>>> So I think this SACK must be dropped to let data transmit correctly.
>>>
>>> Following is the tcpdump of my test. And patch in this mail can avoid
>>> this problem.
>>>
>>> 02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS: 10] [MIS: 65535] [init TSN: 217114040]
>>> 02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100] [MIS: 65535] [init TSN: 100]
>>> 02:19:39.798583 sctp (1) [COOKIE ECHO]
>>> 02:19:40.082125 sctp (1) [COOKIE ACK]
>>> 02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0] [PPID 0xf192090b]
>>> 02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1] [PPID 0x3e467007]
>>> 02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2] [PPID 0x11b12a0a]
>>> 02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3] [PPID 0x30e7d979]
>>> 02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4] [PPID 0x251ff86f]
>>> 02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5] [PPID 0xe5d5da5d]
>>> 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>> 02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7] [PPID 0xca47e645]
>>> 02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8] [PPID 0x6c0ea150]
>>> 02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9] [PPID 0x9cc1994f]
>>> 02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10] [PPID 0xb1df4129]
>>> 02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>> 02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>> 02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>> 02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>> 02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>> 02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>> 02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>
>>>
>>> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>>>
>>> --- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.000000000 -0400
>>> +++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.000000000 -0400
>>> @@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
>>> return SCTP_DISPOSITION_DISCARD;
>>> }
>>>
>>> + /* If Cumulative TSN Ack is not less than the Cumulative TSN
>>> + * Ack which will be send in the next data, drop the SACK.
>>> + */
>>> + if (!TSN_lt(ctsn, asoc->next_tsn)) {
>>> + SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
>>> + SCTP_DEBUG_PRINTK("next_tsn %x\n", asoc->next_tsn);
>>> + return SCTP_DISPOSITION_DISCARD;
>>> + }
>>> +
>>> /* Return this SACK for further processing. */
>>> sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH(sackh));
>>>
>>>
>>>
>>>
>> Whats the behavior on this in the event that a sack is received in which the
>> ctsn falls within a a missing space in a stream of gap acks? I.e. what if the
>> sack being sent falls into a hole between the ack point and the first gap ack
>> range? Does this patch impact that at all?
>>
>> Also, what is this:
>> 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] ....
>>
>> That ack value seems rather out of range for the rest of the trace. Was that
>> part of your test? If so, what caused it?
>>
>
> Yes. This SACK seems to be totally out of range and may be causing the problem.
>
> I would expect the following check in sctp_sf_eat_sack_6_2() to drop any SACKs
> with CTSN value lower than the earlier SACKs.
>
> /* i) If Cumulative TSN Ack is less than the Cumulative TSN
> * Ack Point, then drop the SACK. Since Cumulative TSN
> * Ack is monotonically increasing, a SACK whose
> * Cumulative TSN Ack is less than the Cumulative TSN Ack
> * Point indicates an out-of-order SACK.
> */
> if (TSN_lt(ctsn, asoc->ctsn_ack_point)) {
> SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
> SCTP_DEBUG_PRINTK("ctsn_ack_point %x\n", asoc->ctsn_ack_point);
> return SCTP_DISPOSITION_DISCARD;
> }
>
This place SACK with CTSN value *higher than* the earlier SACKs, So it
can not be dropped.
In my test I send a dup SACK with future CTSN to attack a SCTP assoc,
and it cause data transmit incorrectly. My test procedure is like this:
Endpoint A Endpoint B
<--------------- DATA (TSN=1)
SACK(TSN=1) ---------------> (*1)
<--------------- DATA (TSN=2)
<--------------- DATA (TSN=3)
<--------------- DATA (TSN=4)
<--------------- DATA (TSN=5)
SACK(TSN=5) --------------->(*2)
SACK(TSN=1000) --------------->(*3)
<--------------- DATA (TSN=6)
<--------------- DATA (TSN=7)
<--------------- DATA (TSN=8)
<--------------- DATA (TSN=9)
SACK(TSN=6) --------------->(*4)
<--------------- DATA (TSN=6)(retrans)
(*1) At this point ctsn_ack_point=0,next_tsn=2, ctsn=1, SACK is accept.
After accept SACK, ctsn_ack_point=1.
(*2) At this point ctsn_ack_point=1,next_tsn=6, ctsn=5,TSN_lt(ctsn,
ctsn_ack_point) is ture, so accept SACK, and then ctsn_ack_point=5
(*3) At this point SACK is a dup SACK, ctsn_ack_point=5,next_tsn=6,
ctsn=1000,TSN_lt(ctsn, ctsn_ack_point) is ture, so accept SACK, and then
ctsn_ack_point=1000
(*4) At this point ctsn_ack_point=1000, next_tsn=10,ctsn=6, TSN_lt(ctsn,
ctsn_ack_point) is false, so SACK is dropped.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-08-01 1:06 ` Wei Yongjun
@ 2007-08-01 3:15 ` Vlad Yasevich
2007-08-01 10:21 ` Wei Yongjun
2007-08-01 9:01 ` [Lksctp-developers] " Michael Tuexen
1 sibling, 1 reply; 11+ messages in thread
From: Vlad Yasevich @ 2007-08-01 3:15 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Sridhar Samudrala, netdev, lksctp-developers, Neil Horman
Sorry, coming in late due to list issues...
Wei Yongjun wrote:
>> On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
>>
>>> On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
>>>
>>>> If SCTP data sender received a SACK which contains Cumulative TSN Ack is
>>>> not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
>>>> Ack is not used by the data sender, SCTP data sender still accept this
>>>> SACK , and next SACK which send correctly to DATA sender be dropped,
>>>> because it is less than the new Cumulative TSN Ack Point.
>>>> After received this SACK, data will be retrans again and again even if
>>>> correct SACK is received.
>>>> So I think this SACK must be dropped to let data transmit correctly.
>>>>
>>>> Following is the tcpdump of my test. And patch in this mail can avoid
>>>> this problem.
>>>>
>>>> 02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS: 10] [MIS: 65535] [init TSN: 217114040]
>>>> 02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100] [MIS: 65535] [init TSN: 100]
>>>> 02:19:39.798583 sctp (1) [COOKIE ECHO]
>>>> 02:19:40.082125 sctp (1) [COOKIE ACK]
>>>> 02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0] [PPID 0xf192090b]
>>>> 02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1] [PPID 0x3e467007]
>>>> 02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2] [PPID 0x11b12a0a]
>>>> 02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3] [PPID 0x30e7d979]
>>>> 02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4] [PPID 0x251ff86f]
>>>> 02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5] [PPID 0xe5d5da5d]
>>>> 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7] [PPID 0xca47e645]
>>>> 02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8] [PPID 0x6c0ea150]
>>>> 02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9] [PPID 0x9cc1994f]
>>>> 02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10] [PPID 0xb1df4129]
>>>> 02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>
>>>>
>>>> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>>>>
>>>> --- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.000000000 -0400
>>>> +++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.000000000 -0400
>>>> @@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
>>>> return SCTP_DISPOSITION_DISCARD;
>>>> }
>>>>
>>>> + /* If Cumulative TSN Ack is not less than the Cumulative TSN
>>>> + * Ack which will be send in the next data, drop the SACK.
>>>> + */
>>>> + if (!TSN_lt(ctsn, asoc->next_tsn)) {
>>>> + SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
>>>> + SCTP_DEBUG_PRINTK("next_tsn %x\n", asoc->next_tsn);
>>>> + return SCTP_DISPOSITION_DISCARD;
>>>> + }
>>>> +
>>>> /* Return this SACK for further processing. */
>>>> sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH(sackh));
>>>>
This is an interesting case, but I am not sure that simply discarding
the SACK is the right thing.
The peer in this case is violating the protocol whereby he is trying to
advance the cumulative tsn ack to a point beyond the max tsn currently
sent. I would vote for terminating the association in this case since
either the peer is a mis-behaved implementation, or the association is
under attack.
-vlad
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-08-01 1:06 ` Wei Yongjun
2007-08-01 3:15 ` [Lksctp-developers] " Vlad Yasevich
@ 2007-08-01 9:01 ` Michael Tuexen
2007-08-01 11:19 ` Neil Horman
1 sibling, 1 reply; 11+ messages in thread
From: Michael Tuexen @ 2007-08-01 9:01 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Sridhar Samudrala, netdev, lksctp-developers, Neil Horman
Hi Wei,
see my comments in-line.
Best regards
Michael
On Aug 1, 2007, at 3:06 AM, Wei Yongjun wrote:
>
>> On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
>>
>>> On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
>>>
>>>> If SCTP data sender received a SACK which contains Cumulative
>>>> TSN Ack is
>>>> not less than the Cumulative TSN Ack Point, and if this
>>>> Cumulative TSN
>>>> Ack is not used by the data sender, SCTP data sender still
>>>> accept this
>>>> SACK , and next SACK which send correctly to DATA sender be
>>>> dropped,
>>>> because it is less than the new Cumulative TSN Ack Point.
>>>> After received this SACK, data will be retrans again and again
>>>> even if
>>>> correct SACK is received.
>>>> So I think this SACK must be dropped to let data transmit
>>>> correctly.
>>>>
>>>> Following is the tcpdump of my test. And patch in this mail can
>>>> avoid
>>>> this problem.
>>>>
>>>> 02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd:
>>>> 54784] [OS: 10] [MIS: 65535] [init TSN: 217114040]
>>>> 02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784]
>>>> [OS: 100] [MIS: 65535] [init TSN: 100]
>>>> 02:19:39.798583 sctp (1) [COOKIE ECHO]
>>>> 02:19:40.082125 sctp (1) [COOKIE ACK]
>>>> 02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0]
>>>> [SSEQ 0] [PPID 0xf192090b]
>>>> 02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0]
>>>> [SSEQ 1] [PPID 0x3e467007]
>>>> 02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0]
>>>> [SSEQ 2] [PPID 0x11b12a0a]
>>>> 02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0]
>>>> [SSEQ 3] [PPID 0x30e7d979]
>>>> 02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0]
>>>> [SSEQ 4] [PPID 0x251ff86f]
>>>> 02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0]
>>>> [SSEQ 5] [PPID 0xe5d5da5d]
>>>> 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
>>>> [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0]
>>>> [SSEQ 7] [PPID 0xca47e645]
>>>> 02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0]
>>>> [SSEQ 8] [PPID 0x6c0ea150]
>>>> 02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0]
>>>> [SSEQ 9] [PPID 0x9cc1994f]
>>>> 02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0]
>>>> [SSEQ 10] [PPID 0xb1df4129]
>>>> 02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
>>>> [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
>>>> [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
>>>> [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
>>>> [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>> 02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0]
>>>> [SSEQ 6] [PPID 0x87d8b423]
>>>> 02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd
>>>> 54784] [#gap acks 0] [#dup tsns 0]
>>>>
>>>>
>>>> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>>>>
>>>> --- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.000000000
>>>> -0400
>>>> +++ net/sctp/sm_statefuns.c 2007-07-29 18:14:49.000000000 -0400
>>>> @@ -2880,6 +2880,15 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
>>>> return SCTP_DISPOSITION_DISCARD;
>>>> }
>>>>
>>>> + /* If Cumulative TSN Ack is not less than the Cumulative TSN
>>>> + * Ack which will be send in the next data, drop the SACK.
>>>> + */
>>>> + if (!TSN_lt(ctsn, asoc->next_tsn)) {
>>>> + SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
>>>> + SCTP_DEBUG_PRINTK("next_tsn %x\n", asoc->next_tsn);
>>>> + return SCTP_DISPOSITION_DISCARD;
>>>> + }
>>>> +
>>>> /* Return this SACK for further processing. */
>>>> sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH
>>>> (sackh));
>>>>
>>>>
>>>>
>>>>
>>> Whats the behavior on this in the event that a sack is received
>>> in which the
>>> ctsn falls within a a missing space in a stream of gap acks?
>>> I.e. what if the
>>> sack being sent falls into a hole between the ack point and the
>>> first gap ack
>>> range? Does this patch impact that at all?
>>>
>>> Also, what is this:
>>> 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] ....
>>>
>>> That ack value seems rather out of range for the rest of the
>>> trace. Was that
>>> part of your test? If so, what caused it?
>>>
>>
>> Yes. This SACK seems to be totally out of range and may be causing
>> the problem.
>>
>> I would expect the following check in sctp_sf_eat_sack_6_2() to
>> drop any SACKs
>> with CTSN value lower than the earlier SACKs.
>>
>> /* i) If Cumulative TSN Ack is less than the Cumulative TSN
>> * Ack Point, then drop the SACK. Since Cumulative TSN
>> * Ack is monotonically increasing, a SACK whose
>> * Cumulative TSN Ack is less than the Cumulative TSN Ack
>> * Point indicates an out-of-order SACK.
>> */
>> if (TSN_lt(ctsn, asoc->ctsn_ack_point)) {
>> SCTP_DEBUG_PRINTK("ctsn %x\n", ctsn);
>> SCTP_DEBUG_PRINTK("ctsn_ack_point %x\n", asoc-
>> >ctsn_ack_point);
>> return SCTP_DISPOSITION_DISCARD;
>> }
>>
> This place SACK with CTSN value *higher than* the earlier SACKs, So it
> can not be dropped.
> In my test I send a dup SACK with future CTSN to attack a SCTP assoc,
> and it cause data transmit incorrectly. My test procedure is like
> this:
>
> Endpoint A Endpoint B
> <--------------- DATA (TSN=1)
> SACK(TSN=1) ---------------> (*1)
> <--------------- DATA (TSN=2)
> <--------------- DATA (TSN=3)
> <--------------- DATA (TSN=4)
> <--------------- DATA (TSN=5)
> SACK(TSN=5) --------------->(*2)
> SACK(TSN=1000) --------------->(*3)
> <--------------- DATA (TSN=6)
> <--------------- DATA (TSN=7)
> <--------------- DATA (TSN=8)
> <--------------- DATA (TSN=9)
> SACK(TSN=6) --------------->(*4)
> <--------------- DATA (TSN=6)(retrans)
>
>
> (*1) At this point ctsn_ack_point=0,next_tsn=2, ctsn=1, SACK is
> accept.
> After accept SACK, ctsn_ack_point=1.
> (*2) At this point ctsn_ack_point=1,next_tsn=6, ctsn=5,TSN_lt(ctsn,
> ctsn_ack_point) is ture, so accept SACK, and then ctsn_ack_point=5
> (*3) At this point SACK is a dup SACK, ctsn_ack_point=5,next_tsn=6,
> ctsn=1000,TSN_lt(ctsn, ctsn_ack_point) is ture, so accept SACK, and
> then
> ctsn_ack_point=1000
I would not consider it a duplicate SACK. RFC 4460, section 2.37.2 says
that an implementation SHOULD abort the association when receiving a
SACK acknowledging unsent data. So I would suggest to send an ABORT
chunk.
> (*4) At this point ctsn_ack_point=1000, next_tsn=10,ctsn=6, TSN_lt
> (ctsn,
> ctsn_ack_point) is false, so SACK is dropped.
>
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Lksctp-developers mailing list
> Lksctp-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/lksctp-developers
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-08-01 3:15 ` [Lksctp-developers] " Vlad Yasevich
@ 2007-08-01 10:21 ` Wei Yongjun
2007-08-01 13:06 ` [Lksctp-developers] " Vlad Yasevich
0 siblings, 1 reply; 11+ messages in thread
From: Wei Yongjun @ 2007-08-01 10:21 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Sridhar Samudrala, netdev, lksctp-developers, Neil Horman
> Sorry, coming in late due to list issues...
>
> Wei Yongjun wrote:
>
>>> On Tue, 2007-07-31 at 07:37 -0400, Neil Horman wrote:
>>>
>>>
>>>> On Tue, Jul 31, 2007 at 12:44:27PM +0800, Wei Yongjun wrote:
>>>>
>>>>
>>>>> If SCTP data sender received a SACK which contains Cumulative TSN Ack is
>>>>> not less than the Cumulative TSN Ack Point, and if this Cumulative TSN
>>>>> Ack is not used by the data sender, SCTP data sender still accept this
>>>>> SACK , and next SACK which send correctly to DATA sender be dropped,
>>>>> because it is less than the new Cumulative TSN Ack Point.
>>>>> After received this SACK, data will be retrans again and again even if
>>>>> correct SACK is received.
>>>>> So I think this SACK must be dropped to let data transmit correctly.
>>>>>
>>>>> Following is the tcpdump of my test. And patch in this mail can avoid
>>>>> this problem.
>>>>>
>>>>> 02:19:38.233278 sctp (1) [INIT] [init tag: 1250461886] [rwnd: 54784] [OS: 10] [MIS: 65535] [init TSN: 217114040]
>>>>> 02:19:39.782160 sctp (1) [INIT ACK] [init tag: 1] [rwnd: 54784] [OS: 100] [MIS: 65535] [init TSN: 100]
>>>>> 02:19:39.798583 sctp (1) [COOKIE ECHO]
>>>>> 02:19:40.082125 sctp (1) [COOKIE ACK]
>>>>> 02:19:40.097859 sctp (1) [DATA] (B)(E) [TSN: 217114040] [SID: 0] [SSEQ 0] [PPID 0xf192090b]
>>>>> 02:19:40.100162 sctp (1) [DATA] (B)(E) [TSN: 217114041] [SID: 0] [SSEQ 1] [PPID 0x3e467007]
>>>>> 02:19:40.100779 sctp (1) [DATA] (B)(E) [TSN: 217114042] [SID: 0] [SSEQ 2] [PPID 0x11b12a0a]
>>>>> 02:19:40.101200 sctp (1) [DATA] (B)(E) [TSN: 217114043] [SID: 0] [SSEQ 3] [PPID 0x30e7d979]
>>>>> 02:19:40.561147 sctp (1) [SACK] [cum ack 217114040] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:40.568498 sctp (1) [DATA] (B)(E) [TSN: 217114044] [SID: 0] [SSEQ 4] [PPID 0x251ff86f]
>>>>> 02:19:40.569308 sctp (1) [DATA] (B)(E) [TSN: 217114045] [SID: 0] [SSEQ 5] [PPID 0xe5d5da5d]
>>>>> 02:19:40.700584 sctp (1) [SACK] [cum ack 290855864] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:40.701562 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>>> 02:19:40.701567 sctp (1) [DATA] (B)(E) [TSN: 217114047] [SID: 0] [SSEQ 7] [PPID 0xca47e645]
>>>>> 02:19:40.701569 sctp (1) [DATA] (B)(E) [TSN: 217114048] [SID: 0] [SSEQ 8] [PPID 0x6c0ea150]
>>>>> 02:19:40.701576 sctp (1) [DATA] (B)(E) [TSN: 217114049] [SID: 0] [SSEQ 9] [PPID 0x9cc1994f]
>>>>> 02:19:40.701585 sctp (1) [DATA] (B)(E) [TSN: 217114050] [SID: 0] [SSEQ 10] [PPID 0xb1df4129]
>>>>> 02:19:41.098201 sctp (1) [SACK] [cum ack 217114041] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:41.283257 sctp (1) [SACK] [cum ack 217114042] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:41.457217 sctp (1) [SACK] [cum ack 217114043] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:41.691528 sctp (1) [SACK] [cum ack 217114044] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:41.849636 sctp (1) [SACK] [cum ack 217114045] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:41.975473 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>>> 02:19:42.021229 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:42.196495 sctp (1) [SACK] [cum ack 217114047] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:42.424319 sctp (1) [SACK] [cum ack 217114048] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:42.586924 sctp (1) [SACK] [cum ack 217114049] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:42.744810 sctp (1) [SACK] [cum ack 217114050] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:42.965536 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:43.106385 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>>> 02:19:43.218969 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:45.374101 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>>> 02:19:45.489258 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:49.830116 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>>> 02:19:49.984577 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>> 02:19:58.760300 sctp (1) [DATA] (B)(E) [TSN: 217114046] [SID: 0] [SSEQ 6] [PPID 0x87d8b423]
>>>>> 02:19:58.931690 sctp (1) [SACK] [cum ack 217114046] [a_rwnd 54784] [#gap acks 0] [#dup tsns 0]
>>>>>
>
>
> This is an interesting case, but I am not sure that simply discarding
> the SACK is the right thing.
>
> The peer in this case is violating the protocol whereby he is trying to
> advance the cumulative tsn ack to a point beyond the max tsn currently
> sent. I would vote for terminating the association in this case since
> either the peer is a mis-behaved implementation, or the association is
> under attack.
I have modify the patch to abort the association with protocol violation
error cause, and new patch is come on. May be this patch is correct.^_^
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
--- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.000000000 -0400
+++ net/sctp/sm_statefuns.c 2007-07-31 00:29:16.000000000 -0400
@@ -104,6 +104,13 @@ static sctp_disposition_t sctp_sf_violat
void *arg,
sctp_cmd_seq_t *commands);
+static sctp_disposition_t sctp_sf_violation_ctsn(
+ const struct sctp_endpoint *ep,
+ const struct sctp_association *asoc,
+ const sctp_subtype_t type,
+ void *arg,
+ sctp_cmd_seq_t *commands);
+
/* Small helper function that checks if the chunk length
* is of the appropriate length. The 'required_length' argument
* is set to be the size of a specific chunk we are testing.
@@ -2880,6 +2887,13 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
return SCTP_DISPOSITION_DISCARD;
}
+ /* If Cumulative TSN Ack beyond the max tsn currently
+ * send, terminating the association and respond to the
+ * sender with an ABORT.
+ */
+ if (!TSN_lt(ctsn, asoc->next_tsn))
+ return sctp_sf_violation_ctsn(ep, asoc, type, arg, commands);
+
/* Return this SACK for further processing. */
sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH(sackh));
@@ -3756,6 +3770,68 @@ nomem:
return SCTP_DISPOSITION_NOMEM;
}
+/*
+ * Handle a protocol violation when the peer trying to advance the
+ * cumulative tsn ack to a point beyond the max tsn currently sent.
+ *
+ * We inform the other end by sending an ABORT with a Protocol Violation
+ * error code.
+ *
+ * Section: Not specified
+ * Verification Tag: Nothing to do
+ * Inputs
+ * (endpoint, asoc, chunk)
+ *
+ * Outputs
+ * (reply_msg, msg_up, counters)
+ *
+ * Generate an ABORT chunk and terminate the association.
+ */
+static sctp_disposition_t sctp_sf_violation_ctsn(
+ const struct sctp_endpoint *ep,
+ const struct sctp_association *asoc,
+ const sctp_subtype_t type,
+ void *arg,
+ sctp_cmd_seq_t *commands)
+{
+ struct sctp_chunk *chunk = arg;
+ struct sctp_chunk *abort = NULL;
+ char err_str[] = "The cumulative tsn ack beyond the max tsn currently sent:";
+
+ /* Make the abort chunk. */
+ abort = sctp_make_abort_violation(asoc, chunk, err_str,
+ sizeof(err_str));
+ if (!abort)
+ goto nomem;
+
+ sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
+ SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
+
+ if (asoc->state <= SCTP_STATE_COOKIE_ECHOED) {
+ sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_STOP,
+ SCTP_TO(SCTP_EVENT_TIMEOUT_T1_INIT));
+ sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
+ SCTP_ERROR(ECONNREFUSED));
+ sctp_add_cmd_sf(commands, SCTP_CMD_INIT_FAILED,
+ SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
+ } else {
+ sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
+ SCTP_ERROR(ECONNABORTED));
+ sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
+ SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
+ SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
+ }
+
+ sctp_add_cmd_sf(commands, SCTP_CMD_DISCARD_PACKET, SCTP_NULL());
+
+ SCTP_INC_STATS(SCTP_MIB_ABORTEDS);
+
+ return SCTP_DISPOSITION_ABORT;
+
+nomem:
+ return SCTP_DISPOSITION_NOMEM;
+}
+
/***************************************************************************
* These are the state functions for handling primitive (Section 10) events.
***************************************************************************/
--
A new email address of FJWAN is launched from Apr.1 2007.
The updated address is: yjwei@cn.fujitsu.com
--------------------------------------------------
Wei Yongjun
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630523-858
COINS: 79955-858
FAX: +86+25-83317685
MAIL: yjwei@cn.fujitsu.com
--------------------------------------------------
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-08-01 9:01 ` [Lksctp-developers] " Michael Tuexen
@ 2007-08-01 11:19 ` Neil Horman
0 siblings, 0 replies; 11+ messages in thread
From: Neil Horman @ 2007-08-01 11:19 UTC (permalink / raw)
To: Michael Tuexen; +Cc: Wei Yongjun, Sridhar Samudrala, netdev, lksctp-developers
On Wed, Aug 01, 2007 at 11:01:21AM +0200, Michael Tuexen wrote:
> Hi Wei,
>
> see my comments in-line.
>
> Best regards
> Michael
>
><snip >
> >(*1) At this point ctsn_ack_point=0,next_tsn=2, ctsn=1, SACK is
> >accept.
> >After accept SACK, ctsn_ack_point=1.
> >(*2) At this point ctsn_ack_point=1,next_tsn=6, ctsn=5,TSN_lt(ctsn,
> >ctsn_ack_point) is ture, so accept SACK, and then ctsn_ack_point=5
> >(*3) At this point SACK is a dup SACK, ctsn_ack_point=5,next_tsn=6,
> >ctsn=1000,TSN_lt(ctsn, ctsn_ack_point) is ture, so accept SACK, and
> >then
> >ctsn_ack_point=1000
> I would not consider it a duplicate SACK. RFC 4460, section 2.37.2 says
> that an implementation SHOULD abort the association when receiving a
> SACK acknowledging unsent data. So I would suggest to send an ABORT
> chunk.
+1. I didn't notice the ctsn value before. We can't safely accept that a peer
pre-acks data we haven't sent. Too many security holes.
Neil
--
/***************************************************
*Neil Horman
*Software Engineer
*Red Hat, Inc.
*nhorman@tuxdriver.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Lksctp-developers] [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-08-01 10:21 ` Wei Yongjun
@ 2007-08-01 13:06 ` Vlad Yasevich
2007-08-02 8:57 ` Wei Yongjun
0 siblings, 1 reply; 11+ messages in thread
From: Vlad Yasevich @ 2007-08-01 13:06 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev, Neil Horman, lksctp-developers, Sridhar Samudrala
This is a little better.
One suggestion. The new function you create is almost exactly like
sctp_sf_violation_chunklen() with the exception of the error string.
Can you extract the common parts into a single function so that
we don't have duplication of code.
Thanks
-vlad
Wei Yongjun wrote:
>>
>> This is an interesting case, but I am not sure that simply discarding
>> the SACK is the right thing.
>>
>> The peer in this case is violating the protocol whereby he is trying to
>> advance the cumulative tsn ack to a point beyond the max tsn currently
>> sent. I would vote for terminating the association in this case since
>> either the peer is a mis-behaved implementation, or the association is
>> under attack.
> I have modify the patch to abort the association with protocol violation
> error cause, and new patch is come on. May be this patch is correct.^_^
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
> --- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.000000000 -0400
> +++ net/sctp/sm_statefuns.c 2007-07-31 00:29:16.000000000 -0400
> @@ -104,6 +104,13 @@ static sctp_disposition_t sctp_sf_violat
> void *arg,
> sctp_cmd_seq_t *commands);
>
> +static sctp_disposition_t sctp_sf_violation_ctsn(
> + const struct sctp_endpoint *ep,
> + const struct sctp_association *asoc,
> + const sctp_subtype_t type,
> + void *arg,
> + sctp_cmd_seq_t *commands);
> +
> /* Small helper function that checks if the chunk length
> * is of the appropriate length. The 'required_length' argument
> * is set to be the size of a specific chunk we are testing.
> @@ -2880,6 +2887,13 @@ sctp_disposition_t sctp_sf_eat_sack_6_2(
> return SCTP_DISPOSITION_DISCARD;
> }
>
> + /* If Cumulative TSN Ack beyond the max tsn currently
> + * send, terminating the association and respond to the
> + * sender with an ABORT.
> + */
> + if (!TSN_lt(ctsn, asoc->next_tsn))
> + return sctp_sf_violation_ctsn(ep, asoc, type, arg, commands);
> +
> /* Return this SACK for further processing. */
> sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH(sackh));
>
> @@ -3756,6 +3770,68 @@ nomem:
> return SCTP_DISPOSITION_NOMEM;
> }
>
> +/*
> + * Handle a protocol violation when the peer trying to advance the
> + * cumulative tsn ack to a point beyond the max tsn currently sent.
> + *
> + * We inform the other end by sending an ABORT with a Protocol Violation
> + * error code.
> + *
> + * Section: Not specified
> + * Verification Tag: Nothing to do
> + * Inputs
> + * (endpoint, asoc, chunk)
> + *
> + * Outputs
> + * (reply_msg, msg_up, counters)
> + *
> + * Generate an ABORT chunk and terminate the association.
> + */
> +static sctp_disposition_t sctp_sf_violation_ctsn(
> + const struct sctp_endpoint *ep,
> + const struct sctp_association *asoc,
> + const sctp_subtype_t type,
> + void *arg,
> + sctp_cmd_seq_t *commands)
> +{
> + struct sctp_chunk *chunk = arg;
> + struct sctp_chunk *abort = NULL;
> + char err_str[] = "The cumulative tsn ack beyond the max tsn currently sent:";
> +
> + /* Make the abort chunk. */
> + abort = sctp_make_abort_violation(asoc, chunk, err_str,
> + sizeof(err_str));
> + if (!abort)
> + goto nomem;
> +
> + sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
> + SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
> +
> + if (asoc->state <= SCTP_STATE_COOKIE_ECHOED) {
> + sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_STOP,
> + SCTP_TO(SCTP_EVENT_TIMEOUT_T1_INIT));
> + sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> + SCTP_ERROR(ECONNREFUSED));
> + sctp_add_cmd_sf(commands, SCTP_CMD_INIT_FAILED,
> + SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
> + } else {
> + sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
> + SCTP_ERROR(ECONNABORTED));
> + sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
> + SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
> + SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
> + }
> +
> + sctp_add_cmd_sf(commands, SCTP_CMD_DISCARD_PACKET, SCTP_NULL());
> +
> + SCTP_INC_STATS(SCTP_MIB_ABORTEDS);
> +
> + return SCTP_DISPOSITION_ABORT;
> +
> +nomem:
> + return SCTP_DISPOSITION_NOMEM;
> +}
> +
> /***************************************************************************
> * These are the state functions for handling primitive (Section 10) events.
> ***************************************************************************/
>
>
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-08-01 13:06 ` [Lksctp-developers] " Vlad Yasevich
@ 2007-08-02 8:57 ` Wei Yongjun
2007-08-02 14:40 ` Vlad Yasevich
0 siblings, 1 reply; 11+ messages in thread
From: Wei Yongjun @ 2007-08-02 8:57 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, Neil Horman, lksctp-developers, Sridhar Samudrala
Vlad Yasevich wrote:
> This is a little better.
>
> One suggestion. The new function you create is almost exactly like
> sctp_sf_violation_chunklen() with the exception of the error string.
> Can you extract the common parts into a single function so that
> we don't have duplication of code.
>
> Thanks
> -vlad
>
>
>
>>>
>>> This is an interesting case, but I am not sure that simply discarding
>>> the SACK is the right thing.
>>>
>>> The peer in this case is violating the protocol whereby he is trying to
>>> advance the cumulative tsn ack to a point beyond the max tsn currently
>>> sent. I would vote for terminating the association in this case since
>>> either the peer is a mis-behaved implementation, or the association is
>>> under attack.
>>>
Patch has been modified base on comment.
Thanks.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
--- net/sctp/sm_statefuns.c.orig 2007-07-29 18:11:01.000000000 -0400
+++ net/sctp/sm_statefuns.c 2007-07-31 17:49:22.000000000 -0400
@@ -97,6 +97,13 @@
const struct sctp_association *asoc,
struct sctp_transport *transport);
+static sctp_disposition_t sctp_sf_abort_violation(
+ const struct sctp_association *asoc,
+ void *arg,
+ sctp_cmd_seq_t *commands,
+ const __u8 *payload,
+ const size_t paylen);
+
static sctp_disposition_t sctp_sf_violation_chunklen(
const struct sctp_endpoint *ep,
const struct sctp_association *asoc,
@@ -104,6 +111,13 @@
void *arg,
sctp_cmd_seq_t *commands);
+static sctp_disposition_t sctp_sf_violation_ctsn(
+ const struct sctp_endpoint *ep,
+ const struct sctp_association *asoc,
+ const sctp_subtype_t type,
+ void *arg,
+ sctp_cmd_seq_t *commands);
+
/* Small helper function that checks if the chunk length
* is of the appropriate length. The 'required_length' argument
* is set to be the size of a specific chunk we are testing.
@@ -2880,6 +2894,13 @@
return SCTP_DISPOSITION_DISCARD;
}
+ /* If Cumulative TSN Ack beyond the max tsn currently
+ * send, terminating the association and respond to the
+ * sender with an ABORT.
+ */
+ if (!TSN_lt(ctsn, asoc->next_tsn))
+ return sctp_sf_violation_ctsn(ep, asoc, type, arg, commands);
+
/* Return this SACK for further processing. */
sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_SACKH(sackh));
@@ -3691,40 +3712,21 @@
return SCTP_DISPOSITION_VIOLATION;
}
-
/*
- * Handle a protocol violation when the chunk length is invalid.
- * "Invalid" length is identified as smaller then the minimal length a
- * given chunk can be. For example, a SACK chunk has invalid length
- * if it's length is set to be smaller then the size of sctp_sack_chunk_t.
- *
- * We inform the other end by sending an ABORT with a Protocol Violation
- * error code.
- *
- * Section: Not specified
- * Verification Tag: Nothing to do
- * Inputs
- * (endpoint, asoc, chunk)
- *
- * Outputs
- * (reply_msg, msg_up, counters)
- *
- * Generate an ABORT chunk and terminate the association.
+ * Common function to handle a protocol violation.
*/
-static sctp_disposition_t sctp_sf_violation_chunklen(
- const struct sctp_endpoint *ep,
+static sctp_disposition_t sctp_sf_abort_violation(
const struct sctp_association *asoc,
- const sctp_subtype_t type,
void *arg,
- sctp_cmd_seq_t *commands)
+ sctp_cmd_seq_t *commands,
+ const __u8 *payload,
+ const size_t paylen)
{
struct sctp_chunk *chunk = arg;
struct sctp_chunk *abort = NULL;
- char err_str[]="The following chunk had invalid length:";
/* Make the abort chunk. */
- abort = sctp_make_abort_violation(asoc, chunk, err_str,
- sizeof(err_str));
+ abort = sctp_make_abort_violation(asoc, chunk, payload, paylen);
if (!abort)
goto nomem;
@@ -3756,6 +3758,57 @@
return SCTP_DISPOSITION_NOMEM;
}
+/*
+ * Handle a protocol violation when the chunk length is invalid.
+ * "Invalid" length is identified as smaller then the minimal length a
+ * given chunk can be. For example, a SACK chunk has invalid length
+ * if it's length is set to be smaller then the size of sctp_sack_chunk_t.
+ *
+ * We inform the other end by sending an ABORT with a Protocol Violation
+ * error code.
+ *
+ * Section: Not specified
+ * Verification Tag: Nothing to do
+ * Inputs
+ * (endpoint, asoc, chunk)
+ *
+ * Outputs
+ * (reply_msg, msg_up, counters)
+ *
+ * Generate an ABORT chunk and terminate the association.
+ */
+static sctp_disposition_t sctp_sf_violation_chunklen(
+ const struct sctp_endpoint *ep,
+ const struct sctp_association *asoc,
+ const sctp_subtype_t type,
+ void *arg,
+ sctp_cmd_seq_t *commands)
+{
+ char err_str[]="The following chunk had invalid length:";
+
+ return sctp_sf_abort_violation(asoc, arg, commands, err_str,
+ sizeof(err_str));
+}
+
+/* Handle a protocol violation when the peer trying to advance the
+ * cumulative tsn ack to a point beyond the max tsn currently sent.
+ *
+ * We inform the other end by sending an ABORT with a Protocol Violation
+ * error code.
+ */
+static sctp_disposition_t sctp_sf_violation_ctsn(
+ const struct sctp_endpoint *ep,
+ const struct sctp_association *asoc,
+ const sctp_subtype_t type,
+ void *arg,
+ sctp_cmd_seq_t *commands)
+{
+ char err_str[]="The cumulative tsn ack beyond the max tsn currently sent:";
+
+ return sctp_sf_abort_violation(asoc, arg, commands, err_str,
+ sizeof(err_str));
+}
+
/***************************************************************************
* These are the state functions for handling primitive (Section 10) events.
***************************************************************************/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc
2007-08-02 8:57 ` Wei Yongjun
@ 2007-08-02 14:40 ` Vlad Yasevich
0 siblings, 0 replies; 11+ messages in thread
From: Vlad Yasevich @ 2007-08-02 14:40 UTC (permalink / raw)
To: Wei Yongjun; +Cc: netdev, Neil Horman, lksctp-developers, Sridhar Samudrala
Wei Yongjun wrote:
> Patch has been modified base on comment.
> Thanks.
>
> Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
>
Ok, I've applied this patch, but in the future, please
generate patches so that they can be applied
with a -p1 flag.
Please see Documentation/SubmittingPatches for proper
format.
Thanks
-vlad
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-08-02 14:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <18087.57737.908842.337891@zeus.sw.starentnetworks.com>
2007-07-31 4:44 ` [PATCH] SCTP: drop SACK if ctsn is not less than the next tsn of assoc Wei Yongjun
2007-07-31 11:37 ` [Lksctp-developers] " Neil Horman
2007-07-31 17:28 ` Sridhar Samudrala
2007-08-01 1:06 ` Wei Yongjun
2007-08-01 3:15 ` [Lksctp-developers] " Vlad Yasevich
2007-08-01 10:21 ` Wei Yongjun
2007-08-01 13:06 ` [Lksctp-developers] " Vlad Yasevich
2007-08-02 8:57 ` Wei Yongjun
2007-08-02 14:40 ` Vlad Yasevich
2007-08-01 9:01 ` [Lksctp-developers] " Michael Tuexen
2007-08-01 11:19 ` Neil Horman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).