Hi Vlad/Marcelo,
Thank you for the response.
I am using kernel 3.10.0-123.20.1.el7.x86_64.
I should give bit more details about my setup. My hosts H1 and H2 use
special ethernet adapters which run openvswitch. Due to this, i
believe there is initially bit more latency when connection is being
established. I checked the packets and packets are delivered to other
side without any errors.
i am new to sctp, so i am not exactly sure how kernel part of sctp works.
While testing case 1 mentioned in my previous mail.
In Server side i see following:
=====================
[root@localhost tmp]# sctp_test -h 5.5.5.8 -p 24241 -H 5.5.5.5 -P 24240 -l
remote:addr=5.5.5.8, port=24241, family=2
local:addr=5.5.5.5, port=24240, family=2
seed = 1441868236
Starting tests...
socket(SOCK_SEQPACKET, IPPROTO_SCTP) -> sk=3
bind(sk=3, [a:5.5.5.5,p:24240]) -- attempt 1/10
listen(sk=3,backlog=100)
Server: Receiving packets.
recvmsg(sk=3)
Notification: SCTP_ASSOC_CHANGE(COMMUNICATION_UP)
(assoc_change: state=0, error=0, instr=10 outstr=10)
recvmsg(sk=3) Data 1 bytes. First 1 bytes: <empty> text[0]=0
recvmsg(sk=3) Notification: SCTP_ASSOC_CHANGE(COMMUNICATION_LOST)
(assoc_change: state=1, error=0, instr=0 outstr=0)
recvmsg(sk=3)
TCPDUMP on Server side
-------------------------------------
[root@localhost tmp]# tcpdump -i oct0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on oct0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:33:57.134221 IP 5.5.5.8.24241 > 5.5.5.5.24240: sctp (1) [INIT]
[init tag: 3460584308] [rwnd: 106496] [OS: 10] [MIS: 65535] [init TSN:
2697986036]
12:33:57.135112 IP 5.5.5.5.24240 > 5.5.5.8.24241: sctp (1) [INIT ACK]
[init tag: 3286358519] [rwnd: 106496] [OS: 10] [MIS: 10] [init TSN:
942498333]
12:33:57.135702 IP 5.5.5.8.24241 > 5.5.5.5.24240: sctp (1) [COOKIE
ECHO] , (2) [DATA] (U)(B)(E) [TSN: 2697986036] [SID: 0] [SSEQ 0] [PPID
0x122c861b]
12:33:57.136079 IP 5.5.5.5.24240 > 5.5.5.8.24241: sctp (1) [COOKIE
ACK] , (2) [SACK] [cum ack 2697986036] [a_rwnd 106495] [#gap acks 0]
[#dup tsns 0]
12:33:57.136415 IP 5.5.5.8.24241 > 5.5.5.5.24240: sctp (1) [ABORT]
I am assuming below is the sequence in Client side.
=====================================
when using "sctp_test -h 5.5.5.8 -p 24241 -H 5.5.5.5 -P 24240 -l"
1. sctp_test calls sendmsg.
2. Kernel initiates a handshake.
3. sctp_test sends all the packets and closes the socket before
handshake is complete.
4. Kernel sends a abort packet due to socket close without completing
the transfer of packets.
Just to confirm if above theory is correct, i increased the number of
packets to be sent by sctp_test using following command.
"sctp_test -H 5.5.5.8 -P 24241 -h 5.5.5.5 -p 24240 -s -x 30"
I assume in this case, since sctp_test takes more time to send all the
packets, kernel has enough time to complete the handshake.
This test passed always.
so is the theory that sctp_test is closing socket too fast correct?
if so, shouldn't the kernel complete the connection initiation,
transfer packet before closing the connection even when socket close
is called too fast.
Thanks,
Prashanth
On Thu, Sep 10, 2015 at 2:49 AM, Vlad Yasevich <vyasevich@xxxxxxxxx> wrote:
> On 09/09/2015 04:13 AM, kunapaneni prashanth wrote:
>> Hi,
>> in our setup, i am trying out sctp tests using lksctp tools between
>> two hosts connected back to back.
>>
>> H1(5.5.5.8) -------------- H2 (5.5.5.5)
>>
>>
>> following are the commands i used.
>>
>> Case 1:
>> =========
>> client:
>> sctp_test -H 5.5.5.8 -P 24241 -h 5.5.5.5 -p 24240 -s
>>
>> server:
>> sctp_test -h 5.5.5.8 -p 24241 -H 5.5.5.5 -P 24240 -l
>>
>>
>> This test case fails, with client sending a abort after INIT/INIT-ACK.
>>
>> If i run same test case with "-T" option, it is successful.
>
> The test runs fine in my environment. Which kernel are you using?
>
>>
>> i,e
>> Case 2:
>> ========
>> client:
>> sctp_test -H 5.5.5.8 -P 24241 -h 5.5.5.5 -p 24240 -s -T
>>
>> server:
>> sctp_test -h 5.5.5.8 -p 24241 -H 5.5.5.5 -P 24240 -l
>>
>>
>>
>>
>> i observed that in case 1, sctp_test never calls "connect", why is it
>> so? shouldnt a connect be called.
>>
>
> No, the connect is not required when using SOCK_SEQPACKET sockets and
> that is what the test tries to do. Forcing it to always connect isn't
> the right thing. You need to figure our why you are getting an ABORT.
>
> -vlad
>
>>
>>
>> I modified the code as follows to make sure a connect is issued. After
>> this everything works fine.
>>
>> Please confirm.
>>
>> 1386c1386
>> < if (socket_type == SOCK_STREAM || connectx_count == 0)
>> ---
>>> if (socket_type == SOCK_STREAM && connectx_count == 0)
>>
>>
>
>
>> Thank you,
>> Prashanth
>> --
>> 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
>>
>
--
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
