Jon Shallow

So, I am therefore assuming that `/usr/lib/x86_64-linux-gnu/libssl.so.1.1` and `/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1` have just been rebuilt for Openssl 1.1.1 (have datestamp of just now) - correct ? What version of OpenSSL did you...

So, did you build with OpenSSL 3.0 (just recently released) - which has a `#define EVP_CIPHER_block_size EVP_CIPHER_get_block_size`, whereas OpenSSL 1.1.1 has `EVP_CIPHER_block_size()` as a function (which `src/coap_openssl.c` calls).

`PKG_CONFIG_PATH= ./configure .....` See `HOWTO.dual.openssl`

 It is all down to the supported_versions extension being the definitive answer.

You need to be more explicit here and provide some debug log where this is happening. You for instance, should only be calling coap_new_client_session_pki()/coap_new_client_session_psk2() once to set up the CoAP...

I assume that you are also calling coap_io_process() between the coap_send() calls to handle the responses coming back from the server. It would be good to see `-v9` verbose logs...

What this looks like to me in pseudo code terms ```` coap_new_client_session_pki() for i in 1 to 10 { coap_send() next data increment expected response } while waiting for outstanding...

Without seeing the changes you have made to coap-client.c, it is not possible to say, ```` Nov 17 19:46:17.808 DEBG ** 0.0.0.0:0 127.0.0.1:5684 TLS : mid=0x6206: delayed Nov 17 19:46:18.808...

libcoap handles all the necessary TLS setup work each time a call_io_process() is called. So, call_io_process() needs to be in the coap_send() loop. Yes, your local copy of examples/coap-client.c will...

Reading the debug logs will tell you why both line 22 and 24 were sent immediately adter each other - my suspicion is that your code is sending out 2...