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@xxxxxxxxxxxxxx>: > 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=D1,gap_start=2,gap_end=2) > ---------------> > > <--------------- D5 > > SACK(ACK=D1,gap_start=2,gap_end=3) > ---------------> > > <--------------- D2(retransmitted!!) > > SACK(ACK=D1,gap_start=2,gap_end=4) > ---------------> > > <--------------- D2(retransmitted Again!) > > SACK(ACK=D1,gap_start=2,gap_end=4) > ---------------> > > <--------------- D2(retransmitted Again!!) > > >> >> Great appreciate if you could provide some information. >> >> 2011/2/17 Mingyuan Zhu <liyha.zhu@xxxxxxxxx>: >>> 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@xxxxxxxxx>: >>>> 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@xxxxxxxxxxxx>: >>>>> 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@xxxxxxxxxxxxxxx >>>>>> 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@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > > -- > > Best Regards > ----- > Shan Wei > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
