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...)
