I am sorry about not replying sooner.

config.h is generated by the configure script if when you are doing a autotools/GCC based build (for macOS, Linux, Cygwin, etc). It isn't used if you are using an IDE.

When you are using an IDE, you need to add a user_settings.h file. There is one in the ide/winvs directory that is used to set up wolfSSL, and it is loaded by the wolfSSH build as well. wolfCrypt, a subset of wolfSSL, is used by wolfSSH.

As far as not having a file system, wolfSSH is currently expecting one. I haven't looked into a callback system for creating virtual file systems for RTOSes without file systems. (The idea would be to associate file names with functions, and getting the file name calls the function which returns data of some kind.)

The files to look at for porting are wolfssh/port.h and src/port.c. You'll also have to port wolfCrypt to your target as well. Depending on the RTOS we may already have wolfCrypt ported. wolfSSH is still new and we don't have many turnkey ports provided yet.

--John

Addax:

Were you able to solve the issue you were having? Something that was never clear was which version of wolfSSL are you testing with? I'm running your code locally (without the wide character strings) and I'm not getting any data corruption.

--John

You should only need to add OPENSSL_EXTRA (--enable-opensslextra with configure) to get access to wolfSSL_X509_print().

We added SEP support for a company whose initials are "QL". SEP stands for Smart Energy Profile. The SEP consortium added a bunch of description detail extensions for devices into the X.509 certificates.

Federico:

Could you contact one of our sales managers by email at sales@wolfssl.com? We can provide more help for you.

--John

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.)