-
-
Notifications
You must be signed in to change notification settings - Fork 415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
key_update_reordered is flaky #1695
Comments
The assertion in question:
If it doesn't reproduce consistently then it's probably due to the randomized packet number skipping. I don't think packet loss should be a consequence, so there may be an issue here, but I'll need to investigate closely to be sure. |
Initial notes from the logs: failed case has the server skipping pn 4, which shouldn't matter, as the key update happens on client packet 11. The server fails to decrypt packet 11, then oddly detects a key update on both packets 10 and 12... and then continues communication, even though that's too many updates. Failed:
Succeeded:
|
Saw this again on stable in FreeBSD at https://github.com/quinn-rs/quinn/actions/runs/7535071853/job/20510448889. This time there doesn't seem to have been any PN skipping at all, so I guess that was a red herring. Complete logs
|
Another failure on Ubuntu beta: https://github.com/quinn-rs/quinn/actions/runs/7535119285/job/20510576738?pr=1740 Logs
|
Again: https://github.com/quinn-rs/quinn/actions/runs/10185475414/job/28175129233 Logs
|
Observed in Tokio test suite: tokio-rs/tokio#7121 |
This looks... weird?
https://github.com/quinn-rs/quinn/actions/runs/6611503872/job/17955509790
The text was updated successfully, but these errors were encountered: