ESP32 Forum

I checked both V4 and V3.3, the support is up to TLS V1.2. I don't know too much about these versions but I have a server that uses TLS V1.3 and I'm unable to connect to it. Servers using TLS V1.2 are fine.

I did some more research myself. It seems that mbed-tls has not provided TLS V 1.3 support yet. wolfssl has TLS V 1.3 but esp-wolfssl seems to have a binary version that doesn't support 1.3:

https://github.com/espressif/esp-wolfssl

Does anyone know a time line to support 1.3?

Hello @zliudr

- There is no official mbedTLS release that feature TLS 1.3 support yet. However they are planning to have one by Q2 next year. Once this release is available we can provide required support in ESP-IDF as well.
- (As you rightly pointed out) For wolfSSL case, we do not have required license for releasing TLS 1.3 support.

Some references:
https://tls.mbed.org/tech-updates/blog/ ... mbed-tls-3
https://github.com/ARMmbed/mbedtls/issu ... -601258457

Hope this helps.

Mahavir

ESP_Mahavir,

Thanks for clarifying. I'll be updating my ESP-IDF 3.3 to 4.0 to hopefully later next year get 1.3 support. I have questions regarding how to include files outside the main folder of a project, such as my own classes etc. Where should I look for such info? I posted a thread and didn't get any response. I think I can stuff my classes in the ESP-IDF folder under components but I want to keep mine separate in my own repo, and being shared among projects.

You can put it as submodule within `components` directory of your project/application.

For example: https://github.com/espressif/esp-idf/tr ... components

Thanks. I suppose that will work with ESP-IDF 3.3 and 4.x. But what if I want to share the files among different projects and where should they go? My goals:
1) the shared components must not reside with ESP-IDF folder so they can be included in a git repo. I have a number of machines myself and must maintain all changes via git.
2) the shared components must be accessible among different projects so any update on the components will benefit all projects

What you suggested only helps 1 but I'm looking for ways to achieve 2 as well. Keeping duplicate copies of the components among projects will make a hot mess when I unintentionally changed one copy without copy pasting into all other copies.

Reference pointer I had provided was actually component hosted in an independent repository and used as git submodule within main IDF repository.

Alternatively you may also use `EXTRA_COMPONENT_DIRS` to specify path to extra components and that way they can be easily shared among projects or applications. More information available at: https://docs.espressif.com/projects/esp ... le-project

Hope this helps.

Thanks. I'll take a look

Hi,

A have been wondering about the same problem and this is how I solved it.

1) First I create a repository for each project I make in a separate dir like '<my-project>'
In this dir I have my project files like:

main.cpp
...

2) I have all my own library classes in a separate repository in directory 'xxlibs', don't mind the name of this dir, it was choosen like that because the library classes are cross-platform classes (Windows/Linux/FreeRTOS). This dir contains C++ classes and subdirs with C++ classes so they are better organised, for example

xxlibs\csocket.hpp
xxlibs\clogger.hpp
xxlibs\mqttcd\cmqttcd.hpp
xxlibs\httpsd\chttpsd.hpp
...

3) In my project I use my library classes by including them:

main.cpp:
>>>
#include "../../xxlibs/csocket.hpp"

// now instantiate a variable of class CSocket
CSocket mySock;
<<<

4) I mostly write my library classes in *.hpp files, not in *.cpp files.

A .hpp file is actually a .h file with the class definition AND implementation in it. The reason why I use .hpp iso .h is to make it clear that the file contains code. But using .h is equal.

The reason for this approach is twofold: first .cpp files must be included in the makefile and second: when creating a new function you must not separate declare it in the .h file as you are writing in the .h(pp) file.

5) With this mehtod you don't make a copy of the library classes for each project and you don't risk diversion amongst them.

Downside is that changes are reflected in all projects but I prefer this since 'a' problem will be similar in each project and 'a' fix will equally be shared by each project and thus you have 1 up-to-date version of the library.

My 50 cents

Hi,
Couldn't you just use components?