netdev - rtt calculation when retransmissions occur during handshake

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Mon, 10 Jan 2011 18:52:58 -0800
From:	Josh Hunt <joshhunt00@...il.com>
To:	netdev@...r.kernel.org
Subject: rtt calculation when retransmissions occur during handshake

I was wondering if someone could explain the following behavior I'm
seeing on my web server. I've instrumented the kernel to look at the
RTT during TCP handshake. I am seeing the RTTs reported by the kernel
when my initial SYN/ACK is lost to be calculated based on the original
SYN/ACK. Is this behavior correct? Below I have two cases I've seen on
my system. The first shows the client replying to the retransmitted
SYN/ACK but giving an RTT of 900 instead of around 252. The second
shows the client replying to the original SYN/ACK and reports an RTT
of 913. I have tcp_no_metrics_save enabled so there should be no RTT
caching. This is on kernel 2.6.32.20.

(I've attached these trace snippets as it might be tough to read in a
mail client)
* Reported RTT: 900 - looks like RTT should be ~252:
1294443792.878373 IP 1.2.3.4.49174 > 5.6.7.8.80: Flags [S], seq
2495182093, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val
759815989 ecr 0,sackOK,eol], length 0
1294443792.878379 IP 5.6.7.8.80 > 1.2.3.4.49174: Flags [S.], seq
4249681570, ack 2495182094, win 5792, options [mss 1460,sackOK,TS val
760394055 ecr 759815989,nop,wscale 5], length 0
1294443793.656624 IP 5.6.7.8.80 > 1.2.3.4.49174: Flags [S.], seq
4249681570, ack 2495182094, win 5792, options [mss 1460,sackOK,TS val
760394834 ecr 759815989,nop,wscale 5], length 0
1294443793.908897 IP 1.2.3.4.49174 > 5.6.7.8.80: Flags [.], ack 1, win
65535, options [nop,nop,TS val 759816000 ecr 760394834], length 0

* Reported RTT: 913 - looks correct since it's replying to the original syn/ack:
1294443634.012920 IP 2.3.4.5.62987 > 5.6.7.8.80: Flags [S], seq
1397298575, win 65535, options [mss 1460,nop,wscale 1,nop,nop,TS val
576497055 ecr 0,sackOK,eol], length 0
1294443634.012931 IP 5.6.7.8.80 > 2.3.4.5.62987: Flags [S.], seq
1761430826, ack 1397298576, win 5792, options [mss 1460,sackOK,TS val
760235190 ecr 576497055,nop,wscale 5], length 0
1294443634.656625 IP 5.6.7.8.80 > 2.3.4.5.62987: Flags [S.], seq
1761430826, ack 1397298576, win 5792, options [mss 1460,sackOK,TS val
760235834 ecr 576497055,nop,wscale 5], length 0
1294443634.925970 IP 2.3.4.5.62987 > 5.6.7.8.80: Flags [.], ack 1, win
33304, options [nop,nop,TS val 576497064 ecr 760235190], length 0

>From what I can tell it appears that once the ACK to establish the
connection is received tcp_ack_update_rtt() is called from
tcp_rcv_state_process(). That will eventually compute the initial srtt
using tcp_time_stamp and the value in rcv_tsecr. Am I missing a
codepath because these are retransmissions?

Thanks for any help you can provide.

Josh

Download attachment "tcpdump-snippet" of type "application/octet-stream" (1484 bytes)