The error is due to the message triggered by the processing of the
message (Connect()->SendTls13Certificate/SendTls13CertificateVerify/SendTls13Verify). Consider
the message processed to avoid double processing.
- Modify all existing tests to return an int. This moves us in the direction of
being able to return error/success from a test rather than just calling abort
when something fails. Also, all tests now have the same signature, so they can
easily be members of an array of test cases.
- Wrap each test in a TEST_CASE struct, which just stores a pointer to the test
function and the name of the test, for now. In the future, other metadata can
be added (e.g. should this test be run/skipped) to TEST_CASE, if desired.
- Modify all tests to return 0 on success. Right now, this doesn't do us much
good because the failure mechanism isn't returning some value != 0, it's
abort.
- Add TestSetup and TestCleanup functions that run before and after each test,
respectively. The former does nothing right now, and the latter clears the
error queue, if the error queue is compiled in.
During post-handshake authentication async code mistakes connect() error code
with the error code of DoTls13CertificateRequest and wrongly rewinds the buffer.
The bug was never triggered because of side effects of ShrinkBuffer (removed in
40cb6e0853c6c2cdcef393fca905f40338b41506)
wolfSSL_ERR_get_error and wolfSSL_ERR_peek_error_line_data should return the
earliest error in the queue (i.e. the error at the front), but prior to this
commit, they returned the latest/most recent one instead.
In DoAlert, we were adding an error to the queue for all alerts. However, a
close_notify isn't really an error. This commit makes it so DoAlert only adds
errors to the queue for non-close_notify alerts. In ReceiveData, similarly, we
were adding an error to the queue when the peer sent a close_notify, as
determined by ssl->error == ZERO_RETURN. Now, we don't add an error in this
case.
Don't assume that the underlying medium of DTLS provides the full message in a
single operation. This is usually true for message-based socket (eg. using UDP)
and false for stream-based socket (eg. using TCP).
Commit changes:
- Do not error out if we don't have the full message while parsing the header.
- Do not assume that the record header is still in the buffer when decrypting
the message.
- Try to get more data if we didn't read the full DTLS header.
