Open nhorman opened 19 hours ago
the server (correctly) closes the connection,
It is not the server but the client that closes the connection. Also I believe this should not happen after the dropped retry packet as that should be handled the same way as a dropped initial packet from the server.
This really needs to be investigated ASAP as the CI on feature/quic-server branch is messed up by this.
I'm looking at it now, but its not always the client that closes the connection. Different events occur depending on exactly what is dropped and when. I'm reproducing it and investigating here: https://github.com/openssl/openssl/pull/26027
with the addition of server verification retry packets, I've noticed that the quicapi test is occasionally failing, specifically on the noisy_dgram test. It appears that, if the filter dgram packet filter bios decides to drop the retry frame or reinject a previous initial packet, the server (correctly) closes the connection, due to an unexpected ORIG_DCID, or simply a failed handshake, due to a missing token.
Not sure what the exact root cause is here, or what the right fix is (possibly the need to avoid mangling packets until the handshake is done, or simply accept stochastic failures in the test), but some investigation is needed