Oh, then i'm tottaly bad with self investigation and didn't find the right part of code yet.. But the question still there... why eBPF tracing of TCP states shows so low number for state transition from SYN_RECV to ESTABLISHED And if it's not related to netfilter, where should i ask about it? 09.06.2019, 22:24, "Jozsef Kadlecsik" <kadlec@xxxxxxxxxxxxxxxxx>: > On Sun, 9 Jun 2019, iam@xxxxxxxxxxx wrote: > >> While playing with eBPF i tried tcpstates.py >> (https://github.com/iovisor/bcc/blob/master/tools/tcpstates.py) and >> noticed very low time for TCP state transition SYN_RECV -> ESTABLISHED >> >> My numbers from tests: >> >> SYN_RECV -> ESTABLISHED 0.015 >> SYN_RECV -> ESTABLISHED 0.017 >> SYN_RECV -> ESTABLISHED 0.051 >> >> From handshake >> diagram(https://user-images.githubusercontent.com/1006307/58944706-0ffdb580-878b-11e9-95d3-8e7a4f85d8b0.png) >> it looks like that transition time from SYN_RECV to ESTABLISHED should >> be near RTT between hosts? >> >> TCP Fast Open turned off on host. >> >> OS: Ubuntu 18.10 (GNU/Linux 4.18.0-21-generic x86_64) >> >> tcpdump -tttttv >> >> 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 >> 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 >> 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 >> 00:00:00.093311 IP (tos 0x0, ttl 64, id 60333, offset 0, flags [DF], proto TCP (6), length 93) >> src_host > dst_host: Flags [P.], cksum 0x84e3 (incorrect -> 0xb341), seq 1:42, ack 1, win 227, options [nop,nop,TS val 2341429223 ecr 332512918], length 41 >> such low numbers are between syn_recv and syn+ack send, but between >> syn_recv and established it should be 00:00:00.079183 >> >> ping between hosts in this tcpdump is around 83ms >> >> Looks like nf_conntrack is doing this: >> >> https://github.com/torvalds/linux/blob/80f232121b69cc69a31ccb2b38c1665d770b0710/net/netfilter/nf_conntrack_proto_tcp.c#L1033-L1037 >> >> Is it bug or i'm wrong? > > That part deals with simultaneous open. Please explain what do you mean? > > Conntrack must deal with slow/long delay network connections, therefore > the internal timeouts are conservative. > > Best regards, > Jozsef > - > E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx > PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt > Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences > H-1525 Budapest 114, POB. 49, Hungary
