Whoops. I understand now. I haven't looked at the FAT filesystem that comes with FreeRTOS, but I'm looking now. It follows the pattern that Win32 uses for examining directories, not POSIX. You use ff_findfirst() and ff_findnext() to query the file system for entries in the directory table.

The directory functions are used to get directory listings. The functions that open files for reading or writing take the path string they are given and use that. I think SCP should work with NO_WOLFSSH_DIR. It isn't going affect SSH shells.

testwolverinebagel:

We don't have an example that uses epoll. Our example client is using select() in the function NonBlockSSH_connect(). Can you share with me the code you are using for your connect? You can send it to support@wolfssl.com if you don't want to post it here.

--John

I don't recommend following the example server source. The echoserver is the example that works.

The WOLFSSH object isn't reusable right now. I preferred to create a new WOLFSSH for each incoming connection and free it when done. Servers tend to allow multiple clients to connect simultaneously, so the echoserver can create a new object per incoming connection.

The echoserver is calling wolfSSH_shutdown. wolfSSH_stream_exit would be closing one data channel in a session, not the whole connection.

--John

I do not recommend doing that at all. ECC signatures use a random value and they are different every time you sign some data. It verifies after the fact. I'm assuming you are trying to do a known answer test for the ECC sign function. NIST recommends doing a sign-and-verify test.

If you really want to replace the random number generator that always returns 1, you can set the macro CUSTOM_RAND_GENERATE_BLOCK to a function that you provide that memset's the buffer with 0xFF. You can do that, but I don't recommend that at all. You don't want the code to get out and have the random number generator returning the same value constantly.

The API to look out for is wolfSSL_CTX_set_cipher_list(). You call this once on the WOLFSSL_CTX, and all WOLFSSL sessions made with that CTX will have the preset list. If you only want to use ECDSA-AES256-GCM-SHA384, call it

ret = wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-AES256-GCM-SHA384");

Only that suite will be requested by the client to the server.

I think the following defines in user_settings.h will get you TLSv1.3 with support for the above cipher suite.

#define WOLFSSL_TLS13
#define HAVE_TLS_EXTENSIONS
#define HAVE_SUPPORTED_CURVES
#define HAVE_HKDF
/* #define WC_RSA_PSS - not needed if only using ECC */
/* #define HAVE_FFDHE_2048 - not needed if only using ECC */

If TLSv1.3 is enabled, wolfSSLv23_client_method() will try to negotiate for TLSv1.3 and allow downgrades. (It looks like the manual needs an update.)

Which version of wolfSSL are you using and how are you configuring it?

Your PCAP file isn't showing much with the passive connection. The client sends a hello message and the server is reseting both connections two minutes later-ish. Can you attach a successful handshake with your other client?

You don't use wolfSSL_set_using_nonblock() with TLS sessions. It is only used in DTLS sessions. I originally named the function without the "dtls" part, and it confused some people. "Well, I set non-block and it didn't work." wolfSSL is agnostic to the behavior of the underlying TCP/IP stack, or lack of one, and how it behaves. The only exception is DTLS with non-blocking sockets. In POSIX TCP/IP stacks, the stack returns the same error code for "this socket will block" as the condition "the timeout on this socket expired".

Really, the DTLS usage in our example server and client should have a custom application level structure containing the peer's address, the socket fd, and the non-blocking setting, and that should get passed into the I/O callback function.

RFC 6066, section 4, defines the Max Fragment Length extension. 2^14 is not a value allowed by the extension, as that is the default maximum size of a TLS record. You indicate that size by not using the MFL extension. If the server accepts the MFL request, it shall reply with a MFL extension of its own with the same requested size tag.

We added options 5 and 6 for our own testing. They only work when wolfSSL is on either side.

There isn't an accessor for the MFL on a session. It is normally handled automatically inside the library. Nobody has requested an accessor for the value. The client application should already know what the value is, it set the value.

Note, RFC 8449, section5, obsoletes the MFL for TLSv1.3.

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.