I'm looking at event generated by inet_sock_set_state tracepoint (https://github.com/torvalds/linux/blob/9a76aba02a37718242d7cdc294f0a3901928aa57/include/trace/events/sock.h#L137-L201) I don't know if it's conntrack or direct TCP stack behaviour. 10.06.2019, 18:22, "zrm" <zrm@xxxxxxxxxxxxxxx>: > On 6/10/19 07:48, iam@xxxxxxxxxxx wrote: >> So if it doesn't do anything with network stack states, why I don't see RTT for my SYN_RECV -> ESTABLISHED state changes? > > You're looking at the netfilter/conntrack state (see conntrack(8)) > rather than the state of the endpoint TCP stack (see ss(8)/netstat(8)). > > Conntrack measures things differently because it observes from the > perspective of an intermediary to the connection rather than either of > the endpoints -- it commonly runs on a router somewhere in the path > between them. > > From the perspective of the initiator the state goes from SYN_SENT to > ESTABLISHED as soon as SYN+ACK is observed, and so it is for conntrack, > but because conntrack is in the middle of the path you see up to a RTT > between SYN+ACK and ACK which for the initiator was instantaneous, and > conversely no RTT between SYN and SYN+ACK when conntrack runs near the > receiver even though that would have been a RTT for the initiator. > > I imagine the actual receiver TCP stack code does what you're expecting, > but it maintains its own state and has its own commands and APIs > independent of the conntrack ones.
