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 [email protected] Automated List Manager [EMAIL PROTECTED]
