Gap is only retransmitted once

Gap is only retransmitted once

[Mingyuan Zhu]

Hi,



I have observed a problem while doing load testing on SCTP. The tested
equipment is an open suse linux box with 2.6.34 kernel. The
application of the equipment will send/receive messages through linux
kernel sctp. The peer is an equipment using Aricent sctp stack.

During the load testing, the peer equipment drops sctp chunks and
reports gaps through SACK to the tested equipment.

The tested equipment (Linux box) retransmitts the missing chunks. But
it always retransmit the same #TSN only once even it receives more
SACKs with the reporting gap.

From the ethereal captures:

- TSN 2254147468 is not received by the peer equipment, so it reports
the gap by SACK.

- Linux box retransmit TSN 2254147468.

- The peer still does not get it. It reports the gap by SACK again and again.

- Linux box never retransmit the missing chunk again.

- Finally, neither linux box nor the peer can send/receive any more chunks.



Could someone help to look at the problem? Any help would be highly appreciated!

Re: Gap is only retransmitted once

[Vasil Velichkov]

On 15.02.2011 15:58, Mingyuan Zhu wrote:
> Hi,
>
>
>
> I have observed a problem while doing load testing on SCTP. The tested
> equipment is an open suse linux box with 2.6.34 kernel. The
> application of the equipment will send/receive messages through linux
> kernel sctp. The peer is an equipment using Aricent sctp stack.
>
> During the load testing, the peer equipment drops sctp chunks and
> reports gaps through SACK to the tested equipment.
>
> The tested equipment (Linux box) retransmitts the missing chunks. But
> it always retransmit the same #TSN only once even it receives more
> SACKs with the reporting gap.
>
>  From the ethereal captures:
>
> - TSN 2254147468 is not received by the peer equipment, so it reports
> the gap by SACK.
>
> - Linux box retransmit TSN 2254147468.
>
> - The peer still does not get it. It reports the gap by SACK again and again.
>
> - Linux box never retransmit the missing chunk again.
>
> - Finally, neither linux box nor the peer can send/receive any more chunks.
>
>
>
> Could someone help to look at the problem? Any help would be highly appreciated!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>    
Hi Mingyuan Zhu,

On the Linux box, check whether net.sctp.path_max_retrans(MAX_PATH_RTX) 
or net.sctp.association_max_retrans(MAXRT) parameters are set to 1.

# cat /proc/net/sctp/assocs
  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE 
LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
f2876000 f35ee1c0 2   1   4  38050    1        0        0       0 
6429275 2975   2985  *127.0.0.1 <-> *127.0.0.1            5000    32    
32    5    0    0        0
f444c800 e8407c00 2   1   4  41620    2        0        0     500 
6429276 2985   2975  *127.0.0.1 <-> *127.0.0.1            5000    32    
32    5    0    0        0

# cat /proc/net/sctp/remaddr
ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
127.0.0.1  1 1 1000 5 0 0
127.0.0.1  2 1 1000 5 0 0

# sysctl -a | grep max_retrans
net.sctp.association_max_retrans = 10
net.sctp.path_max_retrans = 5

BR
Vasil Velichkov

Re: Gap is only retransmitted once

[Mingyuan Zhu]

I will rerun the test case to get the other two info:
# cat /proc/net/sctp/assocs
# cat /proc/net/sctp/remaddr


msw12:~ # sysctl -a | grep max_retrans
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.sctp.association_max_retrans = 10
net.sctp.path_max_retrans = 5


2011/2/16 Vasil Velichkov <vasil.velichkov@opencode.com>:
> On 15.02.2011 15:58, Mingyuan Zhu wrote:
>>
>> Hi,
>>
>>
>>
>> I have observed a problem while doing load testing on SCTP. The tested
>> equipment is an open suse linux box with 2.6.34 kernel. The
>> application of the equipment will send/receive messages through linux
>> kernel sctp. The peer is an equipment using Aricent sctp stack.
>>
>> During the load testing, the peer equipment drops sctp chunks and
>> reports gaps through SACK to the tested equipment.
>>
>> The tested equipment (Linux box) retransmitts the missing chunks. But
>> it always retransmit the same #TSN only once even it receives more
>> SACKs with the reporting gap.
>>
>>  From the ethereal captures:
>>
>> - TSN 2254147468 is not received by the peer equipment, so it reports
>> the gap by SACK.
>>
>> - Linux box retransmit TSN 2254147468.
>>
>> - The peer still does not get it. It reports the gap by SACK again and
>> again.
>>
>> - Linux box never retransmit the missing chunk again.
>>
>> - Finally, neither linux box nor the peer can send/receive any more
>> chunks.
>>
>>
>>
>> Could someone help to look at the problem? Any help would be highly
>> appreciated!
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>
> Hi Mingyuan Zhu,
>
> On the Linux box, check whether net.sctp.path_max_retrans(MAX_PATH_RTX) or
> net.sctp.association_max_retrans(MAXRT) parameters are set to 1.
>
> # cat /proc/net/sctp/assocs
>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT
> RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
> f2876000 f35ee1c0 2   1   4  38050    1        0        0       0 6429275
> 2975   2985  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>    0        0
> f444c800 e8407c00 2   1   4  41620    2        0        0     500 6429276
> 2985   2975  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>    0        0
>
> # cat /proc/net/sctp/remaddr
> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
> 127.0.0.1  1 1 1000 5 0 0
> 127.0.0.1  2 1 1000 5 0 0
>
> # sysctl -a | grep max_retrans
> net.sctp.association_max_retrans = 10
> net.sctp.path_max_retrans = 5
>
> BR
> Vasil Velichkov
>

Re: Gap is only retransmitted once

[Mingyuan Zhu]

Please see the result below. Can you give any suggestion from below information?

#cat /proc/net/sctp/assocs
 ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE
LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
ffff880206882000 ffff8801f36be0c0 2   1   4  37699    1     2710
 0       0 580897 2944   4944  *169.254.64.6 <-> *192.168.4.103
   2500     4     4   10    0    0        0

#cat /proc/net/sctp/remaddr
ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
192.168.4.103  1 1 750 5 0 0

#sysctl -a | grep max_retrans
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.sctp.association_max_retrans = 10
net.sctp.path_max_retrans = 5


2011/2/16 Mingyuan Zhu <liyha.zhu@gmail.com>:
> I will rerun the test case to get the other two info:
> # cat /proc/net/sctp/assocs
> # cat /proc/net/sctp/remaddr
>
>
> msw12:~ # sysctl -a | grep max_retrans
> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
> net.netfilter.nf_conntrack_tcp_max_retrans = 3
> net.sctp.association_max_retrans = 10
> net.sctp.path_max_retrans = 5
>
>
> 2011/2/16 Vasil Velichkov <vasil.velichkov@opencode.com>:
>> On 15.02.2011 15:58, Mingyuan Zhu wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> I have observed a problem while doing load testing on SCTP. The tested
>>> equipment is an open suse linux box with 2.6.34 kernel. The
>>> application of the equipment will send/receive messages through linux
>>> kernel sctp. The peer is an equipment using Aricent sctp stack.
>>>
>>> During the load testing, the peer equipment drops sctp chunks and
>>> reports gaps through SACK to the tested equipment.
>>>
>>> The tested equipment (Linux box) retransmitts the missing chunks. But
>>> it always retransmit the same #TSN only once even it receives more
>>> SACKs with the reporting gap.
>>>
>>>  From the ethereal captures:
>>>
>>> - TSN 2254147468 is not received by the peer equipment, so it reports
>>> the gap by SACK.
>>>
>>> - Linux box retransmit TSN 2254147468.
>>>
>>> - The peer still does not get it. It reports the gap by SACK again and
>>> again.
>>>
>>> - Linux box never retransmit the missing chunk again.
>>>
>>> - Finally, neither linux box nor the peer can send/receive any more
>>> chunks.
>>>
>>>
>>>
>>> Could someone help to look at the problem? Any help would be highly
>>> appreciated!
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>
>> Hi Mingyuan Zhu,
>>
>> On the Linux box, check whether net.sctp.path_max_retrans(MAX_PATH_RTX) or
>> net.sctp.association_max_retrans(MAXRT) parameters are set to 1.
>>
>> # cat /proc/net/sctp/assocs
>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT
>> RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>> f2876000 f35ee1c0 2   1   4  38050    1        0        0       0 6429275
>> 2975   2985  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>    0        0
>> f444c800 e8407c00 2   1   4  41620    2        0        0     500 6429276
>> 2985   2975  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>    0        0
>>
>> # cat /proc/net/sctp/remaddr
>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>> 127.0.0.1  1 1 1000 5 0 0
>> 127.0.0.1  2 1 1000 5 0 0
>>
>> # sysctl -a | grep max_retrans
>> net.sctp.association_max_retrans = 10
>> net.sctp.path_max_retrans = 5
>>
>> BR
>> Vasil Velichkov
>>
>

Re: Gap is only retransmitted once

[Mingyuan Zhu]

Is it probably a lksctp usage issue or kinda bug of lksctp?
I read some source code of lksctp-test and didn't find related test
cases. Did someone test this scenaria before?

Great appreciate if you could provide some information.

2011/2/17 Mingyuan Zhu <liyha.zhu@gmail.com>:
> Please see the result below. Can you give any suggestion from below information?
>
> #cat /proc/net/sctp/assocs
>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE
> LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
> ffff880206882000 ffff8801f36be0c0 2   1   4  37699    1     2710
>  0       0 580897 2944   4944  *169.254.64.6 <-> *192.168.4.103
>   2500     4     4   10    0    0        0
>
> #cat /proc/net/sctp/remaddr
> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
> 192.168.4.103  1 1 750 5 0 0
>
> #sysctl -a | grep max_retrans
> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
> net.netfilter.nf_conntrack_tcp_max_retrans = 3
> net.sctp.association_max_retrans = 10
> net.sctp.path_max_retrans = 5
>
>
> 2011/2/16 Mingyuan Zhu <liyha.zhu@gmail.com>:
>> I will rerun the test case to get the other two info:
>> # cat /proc/net/sctp/assocs
>> # cat /proc/net/sctp/remaddr
>>
>>
>> msw12:~ # sysctl -a | grep max_retrans
>> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
>> net.netfilter.nf_conntrack_tcp_max_retrans = 3
>> net.sctp.association_max_retrans = 10
>> net.sctp.path_max_retrans = 5
>>
>>
>> 2011/2/16 Vasil Velichkov <vasil.velichkov@opencode.com>:
>>> On 15.02.2011 15:58, Mingyuan Zhu wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> I have observed a problem while doing load testing on SCTP. The tested
>>>> equipment is an open suse linux box with 2.6.34 kernel. The
>>>> application of the equipment will send/receive messages through linux
>>>> kernel sctp. The peer is an equipment using Aricent sctp stack.
>>>>
>>>> During the load testing, the peer equipment drops sctp chunks and
>>>> reports gaps through SACK to the tested equipment.
>>>>
>>>> The tested equipment (Linux box) retransmitts the missing chunks. But
>>>> it always retransmit the same #TSN only once even it receives more
>>>> SACKs with the reporting gap.
>>>>
>>>>  From the ethereal captures:
>>>>
>>>> - TSN 2254147468 is not received by the peer equipment, so it reports
>>>> the gap by SACK.
>>>>
>>>> - Linux box retransmit TSN 2254147468.
>>>>
>>>> - The peer still does not get it. It reports the gap by SACK again and
>>>> again.
>>>>
>>>> - Linux box never retransmit the missing chunk again.
>>>>
>>>> - Finally, neither linux box nor the peer can send/receive any more
>>>> chunks.
>>>>
>>>>
>>>>
>>>> Could someone help to look at the problem? Any help would be highly
>>>> appreciated!
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>
>>> Hi Mingyuan Zhu,
>>>
>>> On the Linux box, check whether net.sctp.path_max_retrans(MAX_PATH_RTX) or
>>> net.sctp.association_max_retrans(MAXRT) parameters are set to 1.
>>>
>>> # cat /proc/net/sctp/assocs
>>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT
>>> RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>>> f2876000 f35ee1c0 2   1   4  38050    1        0        0       0 6429275
>>> 2975   2985  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>    0        0
>>> f444c800 e8407c00 2   1   4  41620    2        0        0     500 6429276
>>> 2985   2975  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>    0        0
>>>
>>> # cat /proc/net/sctp/remaddr
>>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>>> 127.0.0.1  1 1 1000 5 0 0
>>> 127.0.0.1  2 1 1000 5 0 0
>>>
>>> # sysctl -a | grep max_retrans
>>> net.sctp.association_max_retrans = 10
>>> net.sctp.path_max_retrans = 5
>>>
>>> BR
>>> Vasil Velichkov
>>>
>>
>

Re: Gap is only retransmitted once

[Mingyuan Zhu]

I read an email thread in lksctp archive mailing list. I think what's
happening on my test environment is the same as described in the email
thread. I put the link here.
http://sourceforge.net/mailarchive/forum.php?thread_nameL489B51.6060604%40hp.com&forum_name=lksctp-developers

In the email thread, Vlad Yasevich mentioned a patch which should have
fixed the issue.
Is there someone can let me know if the patch works? Or where can I
get the patch with this fix.

I do need the fix for my product testing. Thanks very much!


2011/2/18 Mingyuan Zhu <liyha.zhu@gmail.com>:
> Is it probably a lksctp usage issue or kinda bug of lksctp?
> I read some source code of lksctp-test and didn't find related test
> cases. Did someone test this scenaria before?
>
> Great appreciate if you could provide some information.
>
> 2011/2/17 Mingyuan Zhu <liyha.zhu@gmail.com>:
>> Please see the result below. Can you give any suggestion from below information?
>>
>> #cat /proc/net/sctp/assocs
>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE
>> LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>> ffff880206882000 ffff8801f36be0c0 2   1   4  37699    1     2710
>>  0       0 580897 2944   4944  *169.254.64.6 <-> *192.168.4.103
>>   2500     4     4   10    0    0        0
>>
>> #cat /proc/net/sctp/remaddr
>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>> 192.168.4.103  1 1 750 5 0 0
>>
>> #sysctl -a | grep max_retrans
>> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
>> net.netfilter.nf_conntrack_tcp_max_retrans = 3
>> net.sctp.association_max_retrans = 10
>> net.sctp.path_max_retrans = 5
>>
>>
>> 2011/2/16 Mingyuan Zhu <liyha.zhu@gmail.com>:
>>> I will rerun the test case to get the other two info:
>>> # cat /proc/net/sctp/assocs
>>> # cat /proc/net/sctp/remaddr
>>>
>>>
>>> msw12:~ # sysctl -a | grep max_retrans
>>> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
>>> net.netfilter.nf_conntrack_tcp_max_retrans = 3
>>> net.sctp.association_max_retrans = 10
>>> net.sctp.path_max_retrans = 5
>>>
>>>
>>> 2011/2/16 Vasil Velichkov <vasil.velichkov@opencode.com>:
>>>> On 15.02.2011 15:58, Mingyuan Zhu wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> I have observed a problem while doing load testing on SCTP. The tested
>>>>> equipment is an open suse linux box with 2.6.34 kernel. The
>>>>> application of the equipment will send/receive messages through linux
>>>>> kernel sctp. The peer is an equipment using Aricent sctp stack.
>>>>>
>>>>> During the load testing, the peer equipment drops sctp chunks and
>>>>> reports gaps through SACK to the tested equipment.
>>>>>
>>>>> The tested equipment (Linux box) retransmitts the missing chunks. But
>>>>> it always retransmit the same #TSN only once even it receives more
>>>>> SACKs with the reporting gap.
>>>>>
>>>>>  From the ethereal captures:
>>>>>
>>>>> - TSN 2254147468 is not received by the peer equipment, so it reports
>>>>> the gap by SACK.
>>>>>
>>>>> - Linux box retransmit TSN 2254147468.
>>>>>
>>>>> - The peer still does not get it. It reports the gap by SACK again and
>>>>> again.
>>>>>
>>>>> - Linux box never retransmit the missing chunk again.
>>>>>
>>>>> - Finally, neither linux box nor the peer can send/receive any more
>>>>> chunks.
>>>>>
>>>>>
>>>>>
>>>>> Could someone help to look at the problem? Any help would be highly
>>>>> appreciated!
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>
>>>> Hi Mingyuan Zhu,
>>>>
>>>> On the Linux box, check whether net.sctp.path_max_retrans(MAX_PATH_RTX) or
>>>> net.sctp.association_max_retrans(MAXRT) parameters are set to 1.
>>>>
>>>> # cat /proc/net/sctp/assocs
>>>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT
>>>> RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>>>> f2876000 f35ee1c0 2   1   4  38050    1        0        0       0 6429275
>>>> 2975   2985  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>>    0        0
>>>> f444c800 e8407c00 2   1   4  41620    2        0        0     500 6429276
>>>> 2985   2975  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>>    0        0
>>>>
>>>> # cat /proc/net/sctp/remaddr
>>>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>>>> 127.0.0.1  1 1 1000 5 0 0
>>>> 127.0.0.1  2 1 1000 5 0 0
>>>>
>>>> # sysctl -a | grep max_retrans
>>>> net.sctp.association_max_retrans = 10
>>>> net.sctp.path_max_retrans = 5
>>>>
>>>> BR
>>>> Vasil Velichkov
>>>>
>>>
>>
>

Re: Gap is only retransmitted once

[Shan Wei]

Mingyuan Zhu wrote, at 02/18/2011 10:04 PM:
> Is it probably a lksctp usage issue or kinda bug of lksctp?
> I read some source code of lksctp-test and didn't find related test
> cases. Did someone test this scenaria before?

I have just tested it like following:
H2 is the tested Linux with latest kernel 2.6.37.
and it can retransmit again and again.

H1                 H2(2.6.37kernel)
     
   <--------------- D1
   <--------------- D2
   <--------------- D3
   <--------------- D4

  SACK(ACKÑ,gap_start=2,gap_end=2)
  --------------->

  <--------------- D5
  
  SACK(ACKÑ,gap_start=2,gap_end=3)
  --------------->

  <--------------- D2(retransmitted!!)

  SACK(ACKÑ,gap_start=2,gap_end=4)
  --------------->

  <--------------- D2(retransmitted Again!)

  SACK(ACKÑ,gap_start=2,gap_end=4)
  --------------->

  <--------------- D2(retransmitted Again!!)


> 
> Great appreciate if you could provide some information.
> 
> 2011/2/17 Mingyuan Zhu <liyha.zhu@gmail.com>:
>> Please see the result below. Can you give any suggestion from below information?
>>
>> #cat /proc/net/sctp/assocs
>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE
>> LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>> ffff880206882000 ffff8801f36be0c0 2   1   4  37699    1     2710
>>  0       0 580897 2944   4944  *169.254.64.6 <-> *192.168.4.103
>>   2500     4     4   10    0    0        0
>>
>> #cat /proc/net/sctp/remaddr
>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>> 192.168.4.103  1 1 750 5 0 0
>>
>> #sysctl -a | grep max_retrans
>> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
>> net.netfilter.nf_conntrack_tcp_max_retrans = 3
>> net.sctp.association_max_retrans = 10
>> net.sctp.path_max_retrans = 5
>>
>>
>> 2011/2/16 Mingyuan Zhu <liyha.zhu@gmail.com>:
>>> I will rerun the test case to get the other two info:
>>> # cat /proc/net/sctp/assocs
>>> # cat /proc/net/sctp/remaddr
>>>
>>>
>>> msw12:~ # sysctl -a | grep max_retrans
>>> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
>>> net.netfilter.nf_conntrack_tcp_max_retrans = 3
>>> net.sctp.association_max_retrans = 10
>>> net.sctp.path_max_retrans = 5
>>>
>>>
>>> 2011/2/16 Vasil Velichkov <vasil.velichkov@opencode.com>:
>>>> On 15.02.2011 15:58, Mingyuan Zhu wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> I have observed a problem while doing load testing on SCTP. The tested
>>>>> equipment is an open suse linux box with 2.6.34 kernel. The
>>>>> application of the equipment will send/receive messages through linux
>>>>> kernel sctp. The peer is an equipment using Aricent sctp stack.
>>>>>
>>>>> During the load testing, the peer equipment drops sctp chunks and
>>>>> reports gaps through SACK to the tested equipment.
>>>>>
>>>>> The tested equipment (Linux box) retransmitts the missing chunks. But
>>>>> it always retransmit the same #TSN only once even it receives more
>>>>> SACKs with the reporting gap.
>>>>>
>>>>>  From the ethereal captures:
>>>>>
>>>>> - TSN 2254147468 is not received by the peer equipment, so it reports
>>>>> the gap by SACK.
>>>>>
>>>>> - Linux box retransmit TSN 2254147468.
>>>>>
>>>>> - The peer still does not get it. It reports the gap by SACK again and
>>>>> again.
>>>>>
>>>>> - Linux box never retransmit the missing chunk again.
>>>>>
>>>>> - Finally, neither linux box nor the peer can send/receive any more
>>>>> chunks.
>>>>>
>>>>>
>>>>>
>>>>> Could someone help to look at the problem? Any help would be highly
>>>>> appreciated!
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>
>>>> Hi Mingyuan Zhu,
>>>>
>>>> On the Linux box, check whether net.sctp.path_max_retrans(MAX_PATH_RTX) or
>>>> net.sctp.association_max_retrans(MAXRT) parameters are set to 1.
>>>>
>>>> # cat /proc/net/sctp/assocs
>>>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT
>>>> RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>>>> f2876000 f35ee1c0 2   1   4  38050    1        0        0       0 6429275
>>>> 2975   2985  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>>    0        0
>>>> f444c800 e8407c00 2   1   4  41620    2        0        0     500 6429276
>>>> 2985   2975  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>>    0        0
>>>>
>>>> # cat /proc/net/sctp/remaddr
>>>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>>>> 127.0.0.1  1 1 1000 5 0 0
>>>> 127.0.0.1  2 1 1000 5 0 0
>>>>
>>>> # sysctl -a | grep max_retrans
>>>> net.sctp.association_max_retrans = 10
>>>> net.sctp.path_max_retrans = 5
>>>>
>>>> BR
>>>> Vasil Velichkov
>>>>
>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 

Best Regards
-----
Shan Wei

Re: Gap is only retransmitted once

[Mingyuan Zhu]

What kind of test tool you used for the testing? I'm working on 2.6.34
Linux kernel. Can you have a test on 2.6.34?

Thanks very much!

2011/2/22 Shan Wei <shanwei@cn.fujitsu.com>:
> Mingyuan Zhu wrote, at 02/18/2011 10:04 PM:
>> Is it probably a lksctp usage issue or kinda bug of lksctp?
>> I read some source code of lksctp-test and didn't find related test
>> cases. Did someone test this scenaria before?
>
> I have just tested it like following:
> H2 is the tested Linux with latest kernel 2.6.37.
> and it can retransmit again and again.
>
> H1                 H2(2.6.37kernel)
>
>   <--------------- D1
>   <--------------- D2
>   <--------------- D3
>   <--------------- D4
>
>  SACK(ACKÑ,gap_start=2,gap_end=2)
>  --------------->
>
>  <--------------- D5
>
>  SACK(ACKÑ,gap_start=2,gap_end=3)
>  --------------->
>
>  <--------------- D2(retransmitted!!)
>
>  SACK(ACKÑ,gap_start=2,gap_end=4)
>  --------------->
>
>  <--------------- D2(retransmitted Again!)
>
>  SACK(ACKÑ,gap_start=2,gap_end=4)
>  --------------->
>
>  <--------------- D2(retransmitted Again!!)
>
>
>>
>> Great appreciate if you could provide some information.
>>
>> 2011/2/17 Mingyuan Zhu <liyha.zhu@gmail.com>:
>>> Please see the result below. Can you give any suggestion from below information?
>>>
>>> #cat /proc/net/sctp/assocs
>>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE
>>> LPORT RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>>> ffff880206882000 ffff8801f36be0c0 2   1   4  37699    1     2710
>>>  0       0 580897 2944   4944  *169.254.64.6 <-> *192.168.4.103
>>>   2500     4     4   10    0    0        0
>>>
>>> #cat /proc/net/sctp/remaddr
>>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>>> 192.168.4.103  1 1 750 5 0 0
>>>
>>> #sysctl -a | grep max_retrans
>>> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
>>> net.netfilter.nf_conntrack_tcp_max_retrans = 3
>>> net.sctp.association_max_retrans = 10
>>> net.sctp.path_max_retrans = 5
>>>
>>>
>>> 2011/2/16 Mingyuan Zhu <liyha.zhu@gmail.com>:
>>>> I will rerun the test case to get the other two info:
>>>> # cat /proc/net/sctp/assocs
>>>> # cat /proc/net/sctp/remaddr
>>>>
>>>>
>>>> msw12:~ # sysctl -a | grep max_retrans
>>>> net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
>>>> net.netfilter.nf_conntrack_tcp_max_retrans = 3
>>>> net.sctp.association_max_retrans = 10
>>>> net.sctp.path_max_retrans = 5
>>>>
>>>>
>>>> 2011/2/16 Vasil Velichkov <vasil.velichkov@opencode.com>:
>>>>> On 15.02.2011 15:58, Mingyuan Zhu wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I have observed a problem while doing load testing on SCTP. The tested
>>>>>> equipment is an open suse linux box with 2.6.34 kernel. The
>>>>>> application of the equipment will send/receive messages through linux
>>>>>> kernel sctp. The peer is an equipment using Aricent sctp stack.
>>>>>>
>>>>>> During the load testing, the peer equipment drops sctp chunks and
>>>>>> reports gaps through SACK to the tested equipment.
>>>>>>
>>>>>> The tested equipment (Linux box) retransmitts the missing chunks. But
>>>>>> it always retransmit the same #TSN only once even it receives more
>>>>>> SACKs with the reporting gap.
>>>>>>
>>>>>>  From the ethereal captures:
>>>>>>
>>>>>> - TSN 2254147468 is not received by the peer equipment, so it reports
>>>>>> the gap by SACK.
>>>>>>
>>>>>> - Linux box retransmit TSN 2254147468.
>>>>>>
>>>>>> - The peer still does not get it. It reports the gap by SACK again and
>>>>>> again.
>>>>>>
>>>>>> - Linux box never retransmit the missing chunk again.
>>>>>>
>>>>>> - Finally, neither linux box nor the peer can send/receive any more
>>>>>> chunks.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Could someone help to look at the problem? Any help would be highly
>>>>>> appreciated!
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>>
>>>>>
>>>>> Hi Mingyuan Zhu,
>>>>>
>>>>> On the Linux box, check whether net.sctp.path_max_retrans(MAX_PATH_RTX) or
>>>>> net.sctp.association_max_retrans(MAXRT) parameters are set to 1.
>>>>>
>>>>> # cat /proc/net/sctp/assocs
>>>>>  ASSOC     SOCK   STY SST ST HBKT ASSOC-ID TX_QUEUE RX_QUEUE UID INODE LPORT
>>>>> RPORT LADDRS <-> RADDRS HBINT INS OUTS MAXRT T1X T2X RTXC
>>>>> f2876000 f35ee1c0 2   1   4  38050    1        0        0       0 6429275
>>>>> 2975   2985  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>>>    0        0
>>>>> f444c800 e8407c00 2   1   4  41620    2        0        0     500 6429276
>>>>> 2985   2975  *127.0.0.1 <-> *127.0.0.1            5000    32    32    5    0
>>>>>    0        0
>>>>>
>>>>> # cat /proc/net/sctp/remaddr
>>>>> ADDR ASSOC_ID HB_ACT RTO MAX_PATH_RTX REM_ADDR_RTX  START
>>>>> 127.0.0.1  1 1 1000 5 0 0
>>>>> 127.0.0.1  2 1 1000 5 0 0
>>>>>
>>>>> # sysctl -a | grep max_retrans
>>>>> net.sctp.association_max_retrans = 10
>>>>> net.sctp.path_max_retrans = 5
>>>>>
>>>>> BR
>>>>> Vasil Velichkov
>>>>>
>>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
>
> --
>
> Best Regards
> -----
> Shan Wei
>

Re: Gap is only retransmitted once

[Shan Wei]

Mingyuan Zhu wrote, at 02/22/2011 09:14 PM:
> What kind of test tool you used for the testing? 

No test tool can directly test your case.
But SCTP Conformance Test Suite Project can help you.
See: http://networktest.sourceforge.net/

Your case is not in the tool, so you need to write your case by yourself.
data#22 has similar test procedure, see 
http://networktest.sourceforge.net/log/2.6.29-rc4/IPv4/data/22.html

-- 
Best Regards
-----
Shan Wei

Re: Gap is only retransmitted once

[Wei Yongjun]

Hi, Mingyuan Zhu

Can you send me the pcap file? This may help me to write test case.
If this problem is still exists in latest kernel, we will fix it ASAP.

> Mingyuan Zhu wrote, at 02/22/2011 09:14 PM:
>> What kind of test tool you used for the testing? 
> No test tool can directly test your case.
> But SCTP Conformance Test Suite Project can help you.
> See: http://networktest.sourceforge.net/
>
> Your case is not in the tool, so you need to write your case by yourself.
> data#22 has similar test procedure, see 
> http://networktest.sourceforge.net/log/2.6.29-rc4/IPv4/data/22.html
>

Re: Gap is only retransmitted once

[Wei Yongjun]

Did you using sinfo_timetolive when you send sctp message?
There is a bug when we handle sinfo_timetolive, I will fix this later.

> Mingyuan Zhu wrote, at 02/22/2011 09:14 PM:
>> What kind of test tool you used for the testing? 
> No test tool can directly test your case.
> But SCTP Conformance Test Suite Project can help you.
> See: http://networktest.sourceforge.net/
>
> Your case is not in the tool, so you need to write your case by yourself.
> data#22 has similar test procedure, see 
> http://networktest.sourceforge.net/log/2.6.29-rc4/IPv4/data/22.html
>

Re: Gap is only retransmitted once

[Mingyuan Zhu]

I searched the src code. We did not use sinfo_timetolive.

2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
> Did you using sinfo_timetolive when you send sctp message?
> There is a bug when we handle sinfo_timetolive, I will fix this later.
>
>> Mingyuan Zhu wrote, at 02/22/2011 09:14 PM:
>>> What kind of test tool you used for the testing?
>> No test tool can directly test your case.
>> But SCTP Conformance Test Suite Project can help you.
>> See: http://networktest.sourceforge.net/
>>
>> Your case is not in the tool, so you need to write your case by yourself.
>> data#22 has similar test procedure, see
>> http://networktest.sourceforge.net/log/2.6.29-rc4/IPv4/data/22.html
>>
>

Re: Gap is only retransmitted once

[Wei Yongjun]

> I searched the src code. We did not use sinfo_timetolive.

I guess there were some retransmit issues in 2.6.31 and
latest kernel hit the rwnd limit, I will try to reproduce it
and fix it. wait some time since I have other work to do now.

> 2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
>> Did you using sinfo_timetolive when you send sctp message?
>> There is a bug when we handle sinfo_timetolive, I will fix this later.
>>
>>> Mingyuan Zhu wrote, at 02/22/2011 09:14 PM:
>>>> What kind of test tool you used for the testing?
>>> No test tool can directly test your case.
>>> But SCTP Conformance Test Suite Project can help you.
>>> See: http://networktest.sourceforge.net/
>>>
>>> Your case is not in the tool, so you need to write your case by yourself.
>>> data#22 has similar test procedure, see
>>> http://networktest.sourceforge.net/log/2.6.29-rc4/IPv4/data/22.html
>>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: Gap is only retransmitted once

[Mingyuan Zhu]

My test is working on kernel 2.6.34-4.

2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
>
>> I searched the src code. We did not use sinfo_timetolive.
>
> I guess there were some retransmit issues in 2.6.31 and
> latest kernel hit the rwnd limit, I will try to reproduce it
> and fix it. wait some time since I have other work to do now.
>
>> 2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
>>> Did you using sinfo_timetolive when you send sctp message?
>>> There is a bug when we handle sinfo_timetolive, I will fix this later.
>>>
>>>> Mingyuan Zhu wrote, at 02/22/2011 09:14 PM:
>>>>> What kind of test tool you used for the testing?
>>>> No test tool can directly test your case.
>>>> But SCTP Conformance Test Suite Project can help you.
>>>> See: http://networktest.sourceforge.net/
>>>>
>>>> Your case is not in the tool, so you need to write your case by yourself.
>>>> data#22 has similar test procedure, see
>>>> http://networktest.sourceforge.net/log/2.6.29-rc4/IPv4/data/22.html
>>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>

Re: Gap is only retransmitted once

[Mingyuan Zhu]

More read about the ethreal captures.

The peer shutdown association 6 seconds after it missed the
retransmittion of sctp.data_tsn = 447375618. During the 6 seconds,
the peer sent a lot of SACKs but Linux did not retransmit the chunk.

Could someone look at it?

Great thanks!

2011/3/3 Mingyuan Zhu <liyha.zhu@gmail.com>:
> I attached more capture packets.
> From the ethreal file, I found some chunks are retransmitted the
> second time after 3 seconds. The peer does not shutdown the
> association. But sometimes the peer shutdown the association.
> For example:
> sctp.data_tsn = 447375491 or sctp.data_tsn = 447375492 are
> retransmitted 3 seconds after the first retransmittion.
>
> And sctp.data_tsn = 447375618, the peer shutdown association before
> the 2nd retransmittion.
>
> So comes the question, why doesn't sctp retransmit immediately when it
> receives SACK, instead it retransmit after 3 seconds?
>
> 2011/3/1 Mingyuan Zhu <liyha.zhu@gmail.com>:
>> My test is working on kernel 2.6.34-4.
>>
>> 2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
>>>
>>>> I searched the src code. We did not use sinfo_timetolive.
>>>
>>> I guess there were some retransmit issues in 2.6.31 and
>>> latest kernel hit the rwnd limit, I will try to reproduce it
>>> and fix it. wait some time since I have other work to do now.
>>>
>>>> 2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
>>>>> Did you using sinfo_timetolive when you send sctp message?
>>>>> There is a bug when we handle sinfo_timetolive, I will fix this later.
>>>>>
>>>>>> Mingyuan Zhu wrote, at 02/22/2011 09:14 PM:
>>>>>>> What kind of test tool you used for the testing?
>>>>>> No test tool can directly test your case.
>>>>>> But SCTP Conformance Test Suite Project can help you.
>>>>>> See: http://networktest.sourceforge.net/
>>>>>>
>>>>>> Your case is not in the tool, so you need to write your case by yourself.
>>>>>> data#22 has similar test procedure, see
>>>>>> http://networktest.sourceforge.net/log/2.6.29-rc4/IPv4/data/22.html
>>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>

Re: Gap is only retransmitted once

[Shan Wei]

Mingyuan Zhu wrote, at 03/03/2011 09:25 AM:
> So comes the question, why doesn't sctp retransmit immediately when it
> receives SACK, instead it retransmit after 3 seconds?

For this question, answer is that sctp implement it by design.
See rto_initial parameter.

rto_initial - INTEGER
	The initial round trip timeout value in milliseconds that will be used
	in calculating round trip times.  This is the initial time interval
	for retransmissions.

	Default: 3000

-- 
Best Regards
-----
Shan Wei

Re: Gap is only retransmitted once

[Wei Yongjun]

> More read about the ethreal captures.
>
> The peer shutdown association 6 seconds after it missed the
> retransmittion of sctp.data_tsn = 447375618. During the 6 seconds,
> the peer sent a lot of SACKs but Linux did not retransmit the chunk.
>
> Could someone look at it?

I will post a patch about this, can you try it and tell us whether
the patch can fix your problem?

> Great thanks!
>
> 2011/3/3 Mingyuan Zhu <liyha.zhu@gmail.com>:
>> I attached more capture packets.
>> From the ethreal file, I found some chunks are retransmitted the
>> second time after 3 seconds. The peer does not shutdown the
>> association. But sometimes the peer shutdown the association.
>> For example:
>> sctp.data_tsn = 447375491 or sctp.data_tsn = 447375492 are
>> retransmitted 3 seconds after the first retransmittion.
>>
>> And sctp.data_tsn = 447375618, the peer shutdown association before
>> the 2nd retransmittion.
>>
>> So comes the question, why doesn't sctp retransmit immediately when it
>> receives SACK, instead it retransmit after 3 seconds?
>>
>> 2011/3/1 Mingyuan Zhu <liyha.zhu@gmail.com>:
>>> My test is working on kernel 2.6.34-4.
>>>
>>> 2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
>>>>> I searched the src code. We did not use sinfo_timetolive.
>>>> I guess there were some retransmit issues in 2.6.31 and
>>>> latest kernel hit the rwnd limit, I will try to reproduce it
>>>> and fix it. wait some time since I have other work to do now.
>>>>
>>>>> 2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
>>>>>> Did you using sinfo_timetolive when you send sctp message?
>>>>>> There is a bug when we handle sinfo_timetolive, I will fix this later.
>>>>>>
>>>>>>> Mingyuan Zhu wrote, at 02/22/2011 09:14 PM:
>>>>>>>> What kind of test tool you used for the testing?
>>>>>>> No test tool can directly test your case.
>>>>>>> But SCTP Conformance Test Suite Project can help you.
>>>>>>> See: http://networktest.sourceforge.net/
>>>>>>>
>>>>>>> Your case is not in the tool, so you need to write your case by yourself.
>>>>>>> data#22 has similar test procedure, see
>>>>>>> http://networktest.sourceforge.net/log/2.6.29-rc4/IPv4/data/22.html
>>>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>

Re: Gap is only retransmitted once

[Mingyuan Zhu]

Great thanks!
Please let me know how to get the patch. I will get the patch on Linux
and try again.

2011/3/3 Wei Yongjun <yjwei@cn.fujitsu.com>:
>
>> More read about the ethreal captures.
>>
>> The peer shutdown association 6 seconds after it missed the
>> retransmittion of sctp.data_tsn = 447375618. During the 6 seconds,
>> the peer sent a lot of SACKs but Linux did not retransmit the chunk.
>>
>> Could someone look at it?
>
> I will post a patch about this, can you try it and tell us whether
> the patch can fix your problem?
>
>> Great thanks!
>>
>> 2011/3/3 Mingyuan Zhu <liyha.zhu@gmail.com>:
>>> I attached more capture packets.
>>> From the ethreal file, I found some chunks are retransmitted the
>>> second time after 3 seconds. The peer does not shutdown the
>>> association. But sometimes the peer shutdown the association.
>>> For example:
>>> sctp.data_tsn = 447375491 or sctp.data_tsn = 447375492 are
>>> retransmitted 3 seconds after the first retransmittion.
>>>
>>> And sctp.data_tsn = 447375618, the peer shutdown association before
>>> the 2nd retransmittion.
>>>
>>> So comes the question, why doesn't sctp retransmit immediately when it
>>> receives SACK, instead it retransmit after 3 seconds?
>>>
>>> 2011/3/1 Mingyuan Zhu <liyha.zhu@gmail.com>:
>>>> My test is working on kernel 2.6.34-4.
>>>>
>>>> 2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
>>>>>> I searched the src code. We did not use sinfo_timetolive.
>>>>> I guess there were some retransmit issues in 2.6.31 and
>>>>> latest kernel hit the rwnd limit, I will try to reproduce it
>>>>> and fix it. wait some time since I have other work to do now.
>>>>>
>>>>>> 2011/3/1 Wei Yongjun <yjwei@cn.fujitsu.com>:
>>>>>>> Did you using sinfo_timetolive when you send sctp message?
>>>>>>> There is a bug when we handle sinfo_timetolive, I will fix this later.
>>>>>>>
>>>>>>>> Mingyuan Zhu wrote, at 02/22/2011 09:14 PM:
>>>>>>>>> What kind of test tool you used for the testing?
>>>>>>>> No test tool can directly test your case.
>>>>>>>> But SCTP Conformance Test Suite Project can help you.
>>>>>>>> See: http://networktest.sourceforge.net/
>>>>>>>>
>>>>>>>> Your case is not in the tool, so you need to write your case by yourself.
>>>>>>>> data#22 has similar test procedure, see
>>>>>>>> http://networktest.sourceforge.net/log/2.6.29-rc4/IPv4/data/22.html
>>>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>
>