b2a86c3e01
It happens regularly in test runs that the server example application shuts down a connection, goes into waiting mode for a new connection, and then receives the encrypted ClosureAlert from the client. The only reason why this does currently not trigger the 'record from another epoch' message is that we handle ClientHello parsing outside of the main record stack because we want to be able to detect SSLv2 ClientHellos. However, this is likely to go away, and once it happens, we'll see the log message. Further, when record checking is used, every record, including the mentioned closure alert, is passed to the record checking API before being passed to the rest of the stack, which leads to the log message being printed. In summary, grepping for 'record from another epoch' is a fragile way of checking whether a reordered message has arrived. A more reliable way is to grep for 'Buffer record from epoch' which is printed when a record from a future epoch is actually buffered, and 'ssl_buffer_message' which is the function buffering a future handshake message. |
||
---|---|---|
.. | ||
.jenkins | ||
data_files | ||
docker/bionic | ||
git-scripts | ||
scripts | ||
suites | ||
.gitignore | ||
CMakeLists.txt | ||
compat-in-docker.sh | ||
compat.sh | ||
Descriptions.txt | ||
make-in-docker.sh | ||
Makefile | ||
ssl-opt-in-docker.sh | ||
ssl-opt.sh |