SSL_read() on DTLS sockets behaves much like on a stream-oriented socket - if you pass it a buffer that is too small to contain the whole data from a single datagram, it will buffer the rest and it will be returned at next call.

This is not what you'd expect when working with datagram-oriented protocols - for example, raw UDP sockets normally truncate the packet and discard leftover data, possibly indicating some warning flag (such as MSG_TRUNC used by recvmsg()). But it's not catastrophic in itself - in OpenSSL 1.0, you could use SSL_pending() to check if there is any leftover data and either process or discard it.

However, in OpenSSL 1.1, SSL_pending() always returns 0 when using DTLS. This is because ssl3_pending() iterates over pipelines, but numrpipes is actually always 0 for DTLS because it does not support pipelining.

I believe this is a bug that greatly complicates detecting truncated messages when using DTLS. Or am I missing something and there is some other "canonical" way of doing this?