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
[Linux OMAP]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]
