Has anyone experienced a similar issue with the "heap" identifier in WolfSSH v1.4.13? If so, how was it resolved?

We did when we added Zephyr support. We set it to the correct value. That particular case you indicated should be ctx->heap. If you aren't using a custom heap with your own memory allocator functions, you could use NULL for the heap.

Could this error be related to specific configurations or dependencies required for integrating WolfSSH with FreeRTOS and lwIP (e.g., WolfSSL/WolfCrypt)?

It's happening in builds that aren't using the default memory allocators. For Linux/macOS/Windows, the WMALLOC() macro is ignoring the heap parameter. That's why I missed it.

Are there any particular user settings that should be verified or adjusted to resolve this issue?


Would upgrading or downgrading WolfSSH potentially solve this problem, or are there known workarounds for this version?

This issue is fixed and will be available in the v1.4.15 release in the next few days.


Which version of wolfSSH are you using? The current master branch in GitHub repo?

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.

I have been working with a project that is using FreeRTOS and FatFS, and we are using the functions f_opendir(), f_readdir(), and f_closedir() found in the file ff.c. I believe that project is using release R0.14 of FatFS.

Setting the flag NO_WOLFSSH_DIR will disable the SFTP commands used to open directories and get listings. You should be able to get and put, but I don't think ls will work.


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.



(5 replies, posted in wolfSSH)

The callback is written for the API you are using. wolfSSH doesn't care about the filesystem you are using. By default, the callback uses POSIX file I/O (fopen(), fread(), fwrite()) or the Win32 file I/O.

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.



(2 replies, posted in wolfSSH)

How are you configuring wolfSSH? Which version are you trying to build? The function ssh_worker() should be called by the server_worker() thread entry point.

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.


(2 replies, posted in wolfSSL)

We have an abstraction layer for mutexes in wolfcrypt/src/wc_port.c. With SINGLE_THREADED this abstraction just returns success when requesting the mutex. It can be replaced with RTOS specific mechanisms and for TIRTOS we are using a semaphore.

The worst thing that'll happen is two server sessions overwriting the same entry in the session cache. (Or the ECC look up table, or the CRL and OCSP response lists, etc.) If you disable the session cache, and don't enable FP_ECC and CRL, I think you're fine with SINGLE_THREADED.

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


(5 replies, posted in wolfSSL)

Thank you.

I don't see any reason for the server to not respond to the client in the Wireshark logs. The client sends pretty much the same hello message in both connections. As far as I can see, just the random is different, which is expected. Neither are trying to resume the session. Same cipher suites requested.

The server picked the same cipher for FireZilla as it used on the first wolfSSL connection (ECDSA-RSA-AES256-SHA384), so the request was acceptable. The server would send an alert if there wasn't a suite match.

Really, TLS is just a decorator on your application's data. We try to keep the library transport agnostic for portability because many TCP/IP library APIs are radically different than the BSD style.

Does the server report any problems in its logs?


(5 replies, posted in wolfSSL)

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?

wolfSSL does not currently support RFC 7250 raw public keys.

If your server can use a self-signed certificate, you could load the server's certificate as a root CA. You can disable certificate verification in the client. It won't check the server's certificate signature, but it would still use the public key in the handshake.

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 5746, section 3.3, describes this phantom cipher suite. It is used in conjunction with secure renegotiation.


(3 replies, posted in wolfSSL)

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.

At this time, no. We can always port it to your platform as part of a consulting project. I shall have one of our sales managers reach out to you.

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.



(5 replies, posted in wolfCrypt)


I do apologize for the delay in responding to you. It is also unfortunate you had to resort to the solution you did. I can keep trying to help you with wolfSSL if you would like.

Addax wrote:

Is this mean that compilation with "wide character strings" expected to have corruption?

No. The HMAC routines treat the input as a string of octets. I was building your example on macOS which doesn't normally use wchar_t. I did rebuild using wchar_t strings and didn't get the same corruption you saw outside the digest.

I also just built and ran the HMAC example using both wolfSSL and OpenSSL and both gave the same output:

digest 0
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
digest 1
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
72 a6 6c 85 9c 3f 1c 37 92 18 05 01 18 44 d2 79
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa

I am getting a different digest than you are, but it is consistent between libraries.



(5 replies, posted in wolfCrypt)


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.


What do you mean that you reduced the size of the OU by 1?

As an example, you change your root CA's Subject Name's OU field from "OU=EngineeringX" to "OU=Engineering", and the CA certificate is still properly formed and signed. If your endpoint certificate's Issuer Name still has the old OU field, "OU=EngineeringX", then that's a different Name, and you should get an error -188.


(2 replies, posted in wolfSSL)

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.

What are your configure options?

I used the default configuration for wolfSSL and I get the following when I connect to a CloudFlare hosted site.

$ ./examples/client/client -h REDACTED.com -p 443 -d -g
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
SSL connect ok, sending GET...
HTTP/1.1 403 Forbidden
Server: cloudflare
Date: Fri, 12 Oct 2018 17:46:43 GMT

Are you enabling the TLS server name indication in the wolfSSL build? Usually when connecting to a CDN, you need to specify the SNI.

$ ./examples/client/client -h REDACTED.com -p 443 -d -g -S REDACTED.com


(5 replies, posted in wolfSSL)


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