This (pair of) bug report(s) is for Datagram TLS (DTLS).

The line: "retransmit: message 5 non-existant"
is repeatedly [see p.s. [1] below] printed to stderr when using DTLS. It
occurs during handshaking. I'm guessing that this is not anticipated to
occur often if its being printed to stderr regardless of the application
that it is being used by (i.e. those using console applications must
compile their own OpenSSL to avoid it), and for me it occurs every
execution.

It occurs because a buffered (I believe handshaking) message cannot be
found in a priority queue. It turns out that the 5th message is being
inserted with priority 1<<16+5 and attempted to be retrieve as message 5
without luck. Specifically, the epoch number has been incremented, and
messages in the function: dtls1_buffer_message() are inserted with
priority: epoch<<16 | frag->msg_header.seq = 65546+5. I do not know why
the epoch is being incremented so soon, nor why the retrieval method
doesn't consider the epoch when attempting to find messages, so I present
the bug here.

Joel Reardon

p.s.
[1] It is being printed dozens of times because whatever timer
functionality used by DTLS to controls resends during handshaking does
not seem to work for any application that links to pthreads, which
results in handshaking messages being sent rapidly until
handshaking is finished. Handshaking is the only component that uses a
resend timer as DTLS is meant for UDP sockets and so only needs
reliability for handshaking. I suppose this also is a bug with DTLS as
network server applications tend to use multithreading rending the
handshaking timer for DTLS unusable in those contexts.

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org