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@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
