Do you have an expected timeline for that feature?
Is it a matter of days, weeks or longer?

Even without the 'timeouts' feature, is there a way to force
wolfSSL embedded SSL to resend last handshake packet(s)? Because without
that loosing even a single handshake packet will block
the whole handshake procedure...

I also had some other issues:
- WOLFSSL_USER_IO doesn't really work with DTLS, because there is no
   way to provide alternative to EmbedGenerateCookie function.
- The '-b' option of the 'server' example doesn't work with DTLS

These issues are minor and easy to change - do you accept patches?

Finally, OpenSSL provides an additional 'DTLS listen' function,
which is supposed to respond to 'client hello' messages that don't contain a cookie.
For these requests there is no need to generate a new SSL object
and allocate memory - this is supposed to help with DOS attacks.

Is there anything similar in wolfSSL? It looks like the first cookie-less
'hello' message changes the internal state of the SSL object,
so it cannot be used for responding to another cookie-less hello message.

This most likely will have to be changed anyway to support the 'timeout' feature,
but I am wondering if that feature is considered?

Thanks!