Looks like the same issue that I encountered in dc0be72.

Looks like the same issue that I encountered in dc0be72.

https://go-review.googlesource.com/c/go/+/147419 trybot failure https://storage.googleapis.com/go-build-log/47c24d6c/windows-amd64-2016_c500855c.log has sligtly different error message:

handshake_client_test.go:479: TLSv13-X25519-ECDHE #4: read tcp 127.0.0.1:49697->127.0.0.1:49703: wsarecv: An established connection was aborted by the software in your host machine.

This error message must be WSAECONNABORTED according to https://docs.microsoft.com/en-us/windows/desktop/debug/system-error-codes--9000-11999-

And original issue message is WSAECONNRESET.

I suspect both messages indicate that there is some not-read data on connection, and the connection is closed. This is from my past experience, I did not debug this.

Alex

Another one in https://storage.googleapis.com/go-build-log/8413fe9f/windows-386-2008_bacc8b63.log.

wsarecv: An existing connection was forcibly closed by the remote host.

Another one in https://storage.googleapis.com/go-build-log/8413fe9f/windows-386-2008_bacc8b63.log.

It is happening pretty regularly. I took a snapshot of all windows builders at this moment

all reds, except windows/arm, are because of this issue.

Alex

I still find it incredible that there is no way to tell the kernel "finish sending and THEN close the connection, pretty please", but here we control both sides when not recording traces, so I can probably fix this without increasing time.Sleeps. Sending a CL now.

(Just this week I noticed a similar issue in Tor: https://lists.torproject.org/pipermail/tor-dev/2018-November/013556.html)

@FiloSottile Likely I misunderstand, but by default when closing a socket the kernel (Unix or Windows) will continue sending the data in the background. You can control this using https://golang.org/pkg/net/#TCPConn.SetLinger .

Upon re-reading https://go-review.googlesource.com/c/net/+/71372/ it's more nuanced than I understood it: the issue seems to be that if there is data in the receive buffer when Close is called, a RST is generated, which cuts short the send as it gets priority. Still annoying, but not as incredible.

Ok, this makes sense: when the client closes the connection immediately after the handshake without reading anything from the server, the session tickets are sitting unread on the wire, causing the client to send a RST. I guess it's flaky instead of breaking every time because then the RST and the closeVerify race to the server.

I don't want the session tickets in there anyway, but there is no way to tell openssl not to send them. openssl/openssl#7727

The better fix would be not to record stuff we ignored by recording on the client side instead of the server side, I suppose, but I don't want to risk ignoring a server alert letting us know something went wrong.

The quick patch would be to do a read on the client side to drain the tickets, but since they don't show up on the application side, it would have to be a blind read with a timeout, either flaky or slow.

So I guess I'm patching OpenSSL until they upstream a fix.

Turns out by reading the code that there is an undocumented -num_tickets 0 option for TLS 1.3.

CL incoming.

Change https://golang.org/cl/151659 mentions this issue: crypto/tls: prevent the test server from sending session ticket

I still find it incredible that there is no way to tell the kernel "finish sending and THEN close the connection, pretty please",

I think you want net.(*TCPConn).CloseWrite combined together with reading from connection until io.EOF arrives.

I could be wrong, but the idea of TCP was connection between two parties where data "does not get lost". So you cannot just "ignore" some data without the system gets errors somewhere. If you want to ignore some data, you still have to read it from the connection.

Alex

@alexbrainman yes, I was missing the part where the RST is caused by data in the receive buffer, not the send buffer, which is much more reasonable.