On 11/08/2022 22:23, Graeme Coates via Exim-users wrote:
No problem - here's a link to the pcap file filtered down by port 44884.https://www.chromosphere.co.uk/wp-content/blogs.dir/1/files/2022/08/tfo.zip
Attached is the time-sequence plot for that. I agree with Viktor: this is a problem in the (you said Debian, so probably all Linux) kernel TCP implementation. Assuming the capture was taken on the initiating host, not a hypervisor or out on a router. The red "R" packets are these retries being sent by the client side of the connection. But they are for a region of sequence space already ACK'd - see the green line - so there is no good reason for the retry. The server end, Google, certainly thinks it saw that data before; it responds with a DSACK (purple "DS") each time. The client keeps on retrying until it times out and resets the connection. The lineup with the initial value of the window advertised by the server (yellow, at the "WS 8" end) is intruiging and might hint at the location of the bug. It doesn't line up exactly, but it *is* at the start of the first (transmit-offloaded) 44 KB segment just after the initial window edge sequence value. -- Cheers, Jeremy (yes, I do this sort of thing for $work...)
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
