That's good to hear you figured it out.

KamKon:

The set-non-blocking function is a do-nothing for TLS sessions, it is meant to be used for DTLS. (We have recently renamed it to reflect this.) For TLS connections, you just need to set the socket to be non-blocking. If the socket would block, wolfSSL_read() will return a WANT_READ error.

--John

/* serialNumber Attribute*/
    NameAttrib* n;

        n = &myCertName.name[0];
        n->id   = ASN_SERIAL_NUMBER;
        n->type = CTC_PRINTABLE;
        n->sz   = sizeof("1801908070");
        XMEMCPY(n->value, "1801908070", sizeof("1801908070"));
/* serialNumber Attribute*/

Change both sizeof to strlen. sizeof a string includes the null terminator. The null terminator on the string is getting included in your name's serial number attribute. The name building function uses memcpy() not strcpy().

David is correct that CSRs do not have a Serial Number and they are added by the CA, there is a "serialnumber" name attribute for your use.

And the "sn" attribute is the surname of the owner of the certificate, I believe it is used when you have a certificate for email signing purposes.

We do have some pre-made support for MQX 4. The memory and network abstraction layers exist.

You add the CA certs and keys to the WOLFSSL_CTX you create. All WOLFSSL sessions created with that CTX will have access to the CA certs and keys.

What are you using to build the project? Are you using an IDE or just building from the command line using configure to set up the build?

Yes. You set up the wolfSSL context and it acts like a factory for making the wolfSSL session objects. If your device is being a client or server, you first establish the TCP connection with the peer, then assign your socket to the session. The I/O callback functions will use the socket to send and receive data. Depending on the RTOS, this may be a little more complicated than using the UNIX-style socket interface. We do have some code showing how to do an I/O callback in ThreadX/NetX. Then you'll need to monitor multiple sockets and call wolfSSL_read() if there is data waiting and wolfSSL_write() to send data.

Which RTOS are you using on your embedded device?

--John

Martin:

I do think that the external cache is what you are looking for. It allocates the space needed to store the WOLFSSL_SESSION, copies the session information from the SSL session in process, not the old cache copy that might get written over. And then calls your own new_sess_cb with a pointer to the SESSION to put the pointer wherever you want. That data will not be overwritten by any new connections.

If you pass the pointer to the WOLFSSL_SESSION record from the external cache callback to wolfSSL_i2d_SSL_SESSION() there won't be a race condition issue.

--John

I was able to recreate some of your symptoms locally. We discovered some bugs in setting up the I/O callbacks in our example server and client.

The symptom I recreated was with the error -308 happening in the wolfSSL JNI client. The I/O callback sets the timeout on socket reads, initially, to 1 second. After the handshake finishes, the client is sending "Hello wolfssl" to the server. If you have the OpenSSL server running, it should display that string. When you finally get around to typing the response to the client, the client has timed out. On a timeout, you end up with the socket error you are seeing. (Internally the handshake is complete, so the read isn't retried.)

From what I could find about the socket library, you don't actually get non-blocking sockets in Java. You can set the timeout to a very small value.

In the MyRecvCallback (or what you are using), if the Timeout exception is caught, try returning WolfSSL.WOLFSSL_CBIO_ERR_WANT_READ. Then the read should return a WANT_READ error, which will let you try the read again until something is read.

And to expand on non-blocking sockets, our example client and server know how to deal with them. For DTLS, we use blocking sockets with timeouts, or optionally non-blocking sockets with some additional work. For the handshake in DTLS, you have to do timing for waiting for the peer to reply and to trigger retries. With blocking sockets the library takes care of that automatically. With non-blocking sockets, it is fairly application specific. So, if the functions wolfSSL_negotiate(), wolfSSL_accept(), wolfSSL_connect(), wolfSSL_read(), or wolfSSL_write() return and error, you need to check it with wolfSSL_get_error(). If it is WANT_READ or WANT_WRITE, you need to call the function again, and again, until it is successful or you get a different error. Those two are special error codes meaning the socket would block normally. You also need to tell the DTLS session it is non-blocking because the usual network stacks treat a WANT_READ the same way as a timeout; wolfSSL needs a hint as to what the socket error code meant.

What I think your JNI application is doing is sending client hello, and then waits on the socket, which is non-blocking, and you get a WANT_READ immediately. Since you didn't tell the wolfSSL session it was non-blocking, it immediately retried the client hello, and the WANT_READ error code was returned.

(David isn't working on this issue, I am. Don't wait for him.)

Remove "--enable-sniffer" from your configure and this command line test should work. (Also remove "--enable-sctp", it is only needed if you are using DTLS over SCTP.) The sniffer allows you to build an application that provides packet decoding in a fashion similar to Wireshark. It only works if you are using RSA key exchange.

There is an issue with time on platforms without 64-bit values. We added the guard TIME_T_NOT_LONG to work around that. On the configure command line add CPPFLAGS=-DTIME_T_NOT_LONG or #define it in your settings file.

Olle:

Which version of wolfSSL are you using? Is it v3.13.0?

Digging into your capture files a couple things catch my interest. In dump.pcap, you have two client hello messages. The second one isn't a retransmission. It is the second client hello. It should only come in response to a hello verify request from the server, which your server doesn't send, and should be longer than the initial hello. I'd like to know why the client is doing that. I'm going to look at that some more. But, I'm not quite seeing that behavior here. My second client hello comes through as expected.

In your case, the client should NOT send a second hello message as your server isn't sending the hello verify request message. The server alert is due to it receiving two separate client hello messages with separate handshake message sequence numbers, and not expecting the second one because it didn't send the hello verify request.

Do you know why the server isn't sending the hello verify request? Is that an option you disabled? I'm going to try to hack my server so it doesn't send the hello verify request message. The client should be able to handle not getting it. (The client is required to respond to the message, but the server is not required to send it.)

--John

It looks like your server is sending data to the client and never stopping to receive messages from the client. You need to call wolfSSH_stream_read() once in a while as it processes the background bookkeeping messages like Channel Adjust Window.