Re: How long TCP state change from SYN_RECV to ESTABLISHED should take?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



But what about tcpdump -tttttv from receiver side?

Receiver got SYN:
 00:00:00.000000 IP (tos 0x28, ttl 49, id 280, offset 0, flags [DF], proto TCP (6), length 60)
    dst_host > src_host: Flags [S], cksum 0x46ae (correct), seq 4063608731, win 29200, options [mss 1460,sackOK,TS val 332512899 ecr 0,nop,wscale 6], length 0

Receiver sent SYN+ACK:
 00:00:00.000071 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    src_host > dst_host: Flags [S.], cksum 0x84c2 (incorrect -> 0x3c01), seq 1516815880, ack 4063608732, win 28960, options [mss 1460,sackOK,TS val 2341429130 ecr 332512899,nop,wscale 7], length 0

Receiver got ACK:
 00:00:00.079183 IP (tos 0x28, ttl 49, id 281, offset 0, flags [DF], proto TCP (6), length 52)
    dst_host > src_host: Flags [.], cksum 0xda11 (correct), ack 1, win 457, options [nop,nop,TS val 332512918 ecr 2341429130], length 0

such low numbers are between syn_recv and syn+ack send, but between syn_recv and established it should be 00:00:00.079183 (79.183 ms) ping between hosts ~83ms, so there couldn't be no RTT

handshake is working the same way for both sides and should take around 2 RTT

10.06.2019, 01:42, "zrm" <zrm@xxxxxxxxxxxxxxx>:
> On 6/9/19 16:56, iam@xxxxxxxxxxx wrote:
>>  When I tested on INITIATOR side, transition between SYN_SENT -> ESTABLISHED was near RTT, but on RECEIVER side it was very low, as i showed before, but it should be the same as on INITIATOR side. Is that right?
>>  I just want to understand where to look at, if it's not netfilter.. Maybe eBPF or Linux networking?
>
> The TCP handshake looks like this:
>
> initiator -> receiver SYN
> receiver -> initiator SYN+ACK
> initiator -> receiver ACK
>
> When conntrack sees the SYN packet the state becomes SYN_SENT. When it
> sees the SYN+ACK packet the state becomes ESTABLISHED.
>
> When conntrack is running at the initiator, it sees the SYN packet, then
> the packet goes over the internet, then the SYN+ACK packet comes back
> over the internet, and there is a RTT between seeing one and the other.
>
> When conntrack is running at the receiver, the SYN packet goes over the
> internet, then conntrack sees it, then conntrack sees the SYN+ACK
> packet, then the SYN+ACK packet goes back over the internet. The round
> trip happens before and after conntrack sees the two packets instead of
> between them, so there is no RTT there.



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux