26 Reply by gojimmypi

(27 replies, posted in wolfSSL)

Hi Adam -

I'm so sorry to hear you are still struggling with the setup. I'll make the instructions more clean on GitHub.

I'll also check the setup script later today.

Can you tell me the exact error you are seeing?

In the meantime, I think the best method is to use the existing examples.

I suggest:

1) Remove the wolfSSL compoenent that was installed to the ESP-IDF with the script.

2) Copy the sample project component directory tree and all files to your `[project root]/components/` directory:

https://github.com/wolfSSL/wolfssl/tree … ts/wolfssl

3) Set an environment variable called WOLFSSL_ROOT (or edit the CMakeLists.txt variable of the same name) to point to the wolfssl source.

For example if you've git-cloned wolfssl from a d:\workspace directory and used the default repo name:

WOLFSSL_ROOT="d:\workspace\wolfssl"

Or see cmake examples:

https://github.com/wolfSSL/wolfssl/blob … ts.txt#L53

Your wolfSSL user_settings.h file would then be in your:

[project]/components/wolfssl/include

Like this one:

https://github.com/wolfSSL/wolfssl/tree … sl/include

Let me know how that goes.  If you still see errors, please post them here or open a GitHub issue.

Best Regards,

Jim

Go to forum: wolfSSL

27 Reply by gojimmypi

(27 replies, posted in wolfSSL)

Hi Adam -

Good to hear about your progress and continued interest!

At the moment, I don't yet have any good instructions for VS Code & PlatformIO. But I do have a major update in the works to publish an official wolfSSL to both Ardiuno and PlatformIO sites, along with improved Arduino examples. Stay tuned. smile

Would you happen to be using Windows? If so, I highly recommend the VisualGDB extension for Visual Studio. I've found it to be an incredibly productive development environment tool. Couple that with the Tigard JTAG board and there's an excellent ESP32 debugger for single step, breakpoints, variable inspection, memory & register peeking and more.

I gave a YouTube webinar last year on this topic that you may find helpful:

https://www.youtube.com/watch?v=CzwA3ZBZBZ8

Although the ESP Registry is awesome for getting started, it is not as robust as I want for ongoing development. I need to further develop the KConfig to make changes via the ESP-IDF menuconfig, as otherwise the user_settings.h file in a managed component cannot be edited.

There are some Espressif examples to help get started with the ESP-IDF here:

https://github.com/wolfSSL/wolfssl/tree … F/examples

Note in particular that wolfSSL does not need to be installed in the local project. See the CMakeLists.txt file in components/wolfssl directory.

The user_settings.h is then found in this directory:

[your project]/components/wolfssl/include

As you move forward, please note that wolfSSL offers special pre-sales support to help get your project kickstarted.

Cheers

Jim

Go to forum: wolfSSL

28 Reply by gojimmypi

(27 replies, posted in wolfSSL)

Hi Adam -

wolfSSL is that we can tailor the SSL/TLS requirements per geographic region or client base

Indeed! That's definitely an awesome feature of wolfSSL.

The odd build problems are not a surprise. The source on PlatformIO is not official, and I cannot even confirm it is genuine wolfSSL source. Without seeing your source code, it is hard to say for sure what's going on. I'd like to help.

I'm certain the hardware random number generator is implemented for all of the ESP32 devices. I suspect he problem you are encountering is related to the user_settings.h values.

Is there a serious and compelling reason to use the Arduino platform? I'd like to again emphasize the robustness of the Espressif ESP-IDF. I noticed at project creation time that PlatformIO will use either Arduino or ESP-IDF. If you use the ESP-IDF, we'd be able to help you much more. I'll be working on improving Arduino integration, that's admittedly not great at the moment.

I'd also like to invite you to open any issues on GitHub as appropriate, including one regarding your request for Arduino support:

https://github.com/wolfSSL/wolfssl/issues

Regarding your migration from OpenSSL: we have several engineers on staff that have a great amount of experience with that. Professional engineering and consulting services are available to help you with your implementation.

I'm glad you are making progress on your evaluation and look forward to learning more.

Best Regards

Jim

Go to forum: wolfSSL

29 Reply by gojimmypi

(27 replies, posted in wolfSSL)

Hi Adam -

How's your evaluation coming along? Will you have any customers in China? One of the things to consider is wolfSSL SM Chinese ShangMi support:

https://www.wolfssl.com/wolfssl-adds-sh … wolfcrypt/

I have that working for the ESP32, but the samples need just a little fine tuning with regards to the static sample certs.

Heads up I received approval to work on an official wolfssl repository for PlatformIO.

Status will be tracked at GitHub issue #85 for platformio/platformio-registry here:

https://github.com/platformio/platformi … /issues/85

I need to wrap up a few other items before I get started on that, but in the meantime please let me know if there's anything else I can do to help you.

Cheers

Go to forum: wolfSSL

30 Reply by gojimmypi

(27 replies, posted in wolfSSL)

AdamHeavens wrote:

Hi gojimmypi,

Are there any plans to have an official version published by wolfSSL in the PlatformIO registry?

I'd personally like to see an official version. So far, there's been relatively little demand, particularly considering how well documented and polished the ESP-IDF is these days. The best way is to voice the desire:  support@wolfssl.com

Cheers

Go to forum: wolfSSL

31 Reply by gojimmypi

(27 replies, posted in wolfSSL)

Hi Adam -

That's excellent you've made progress!

I have added the following to platformio.ini build flags

I suggest putting them in the `user_settings.h` instead:

#define SINGLE_THREADED
#define HAVE_ECC
#define WOLFSSL_SMALL_STACK
#define WOLFSSL_ESPIDF
#define WOLFSSL_ESP32
#define OPENSSL_EXTRA
#define OPENSSL_ALL
#define HAVE_TLS_EXTENSIONS
#define HAVE_SUPPORTED_CURVES

I've updated my sample `user_settings.h` here:

https://github.com/gojimmypi/wolfssl/bl … ings.h#L39

I get the following error when building
#error directive: "No encryption algorithm available for default ticket encryption."


The library for wolfSSL is highly tunable. See the documentation for details on the options available:

https://www.wolfssl.com/documentation/m … ave_aesgcm

One possible solution to the error you are seeing is to turn on AESGCM in `user_settings.h` like this:

#define HAVE_AESGCM

Please let me know if that works for you.

Cheers!

Go to forum: wolfSSL

32 Reply by gojimmypi

(27 replies, posted in wolfSSL)

Hi Adam -

I briefly took a look at using PlatformIO and the Arduino framework for an ESP32 wolfSSL project. It's an interesting environment.

The first thing that should be emphasized is that the 

lib_deps = 
    onelife/wolfssl@^5.5.4

... and located here: https://registry.platformio.org/librari … fe/wolfssl

...is *not* an official wolfSSL source code (and in fact rather stale), and is *not* maintained by wolfSSL staff.

Still, I understand there's no other alternative there... so I've taken a look at why it does not work. I was able to quickly reproduce your error. A variety of relatively minor changes are needed - mostly file deletions & a couple of edits. I've summarized what it took here:

https://github.com/gojimmypi/wolfssl/tr … PlatformIO

Here's the included README.md for future reference & I've attached the `user_settings.h` that I used:

This is a supplementary suggestion to [this forum question] regarding PlatformIO and the wolfSSL library.

Here are some tips to get it working:

Given a VS Code `[project]` directory, these changes are needed:

## Edit `[project]\.pio\libdeps\esp32dev\wolfssl\src\wolfcrypt\src`

delete all the `*.i` files

delete these files:
`sp_arm32.c`
`sp_arm64.c`
`sp_armthumb.c`
`sp_c32.c`
`sp_c64.c`
`sp_cortexm.c`
`sp_dsp32.c`
`sp_x86_64.c`
`sp_cortexm.c`

(do NOT delete `sp_int.c`)

## Edit `[project]\.pio\libdeps\esp32dev\wolfssl\src\wolfcrypt\src\port`

Delete all of the directories EXCEPT `Atmel` and `Espressif`


## Edit `[project]\.pio\libdeps\esp32dev\wolfssl\src\wolfcrypt\`

Delete `test` and `benchmark` directories


## Edit `[project]\.pio\libdeps\esp32dev\wolfssl\src\user_settings.h`

See the enclosed [user_settings.h](./user_settings.h) - copy it to:

`[project]\.pio\libdeps\esp32dev\wolfssl\src\user_settings.h`


## Edit `[project]\.pio\libdeps\esp32dev\wolfssl\src\wolfssl\wolfcrypt\wolf_crypt_settings.h`

Comment out the `#define FREERTOS` in the `#if defined(WOLFSSL_ESPIDF)` section, on or around line 333.

```c
#if defined(WOLFSSL_ESPIDF)
    /* #define FREERTOS */
```

Please give that a try and let me know how it goes.

Cheers

*edit: I've been unable to attach a file. Please see the one at the GitHub link, above.

Go to forum: wolfSSL

33 Reply by gojimmypi

(27 replies, posted in wolfSSL)

Hi Adam -

I'm not familiar with the PlatformIO method of building a project. I definitely recommend using the ESP-IDF if at all possible. There are wolfSSL examples here:

https://github.com/wolfSSL/wolfssl/tree … /Espressif

There's also the capability of using Managed Components from the ESP Registry:

https://www.wolfssl.com/wolfssl-now-ava … -registry/

That said, I do think the Arduino projects should at least work. If there's no mechanism for including or excluding files in PlatformIO, there's always the brute force method of simply deleting all the files you don't want to be included (e.g. all the assembly language suffix "*.s" files in wolfcrypt/src)

Additionally, it's really best to use a wolfssl `user_settings.h` file. It gets included by pretty much every wolfssl source file (via wolfcrypt/settings.h) & controls which features are compiled in - such as your missing wc_GenerateSeed().

I suppose it should in theory also work to add "-D" build flags. See the example template user_settings.h:

https://github.com/wolfSSL/wolfssl/blob … settings.h

In particular, you will at least need `-DWOLFSSL_ESPIDF` and `-DWOLFSSL_ESP32` defined project-wide.

If you choose to use the user_settings.h file, I'd probably drop it in place with settings.h in wolfssl/wolfcrypt. When using the ESP-IDF instead, the file belongs in the components/wolfssl/include directory.

If you choose to use the ESP-IDF (you can still edit with VS Code) - I'll be able to help you much more. I'd still like to get the PlatformIO working, but I'll need to spend some time on that. If you can point to your example online, or something similar, that would be helpful to get me started.

Cheers

Go to forum: wolfSSL

34 Reply by gojimmypi

(27 replies, posted in wolfSSL)

Hi Adam,

The first error: 

unknown register name 'r8' in 'asm'

is typically caused at compile time when *all* the files in wolfcrypt/src are attempted to be compiled. There are some assembly files there that are not appropriate on the Xtensa architecture of the ESP32-S3.  Either explicitly listing files, or list exclusions would likely resolve this. I've been working on an ESP8288 makefile that addresses this topic:

https://github.com/gojimmypi/wolfssl/bl … mponent.mk

There's also an example of CMake excluding files those files here:

https://github.com/wolfSSL/wolfssl/blob … s.txt#L210

The next error, possibly also related: 

#error "you need to write an os specific wc_GenerateSeed() here"

typically means the compiler does not "know" that the target CPU for wolfSSL code is for the ESP32. This is often a macro definition in the user_settings.h file.

I've been meaning to give more attention to the Arduino platform. Can you provide additional details on your makefiles and the user_settings.h that you are using?

There's a GitHub issue regarding Arduino support:

https://github.com/wolfSSL/wolfssl/issues/6360

Thanks for your interest! I look forward to learning more about your project.

Go to forum: wolfSSL