Future network support - LWIP and SSL

[mikee47]

LWIP versions

LWIP support is indicated by the ENABLE_CUSTOM_LWIP option:

0: Version provided with Esp8266 SDK
1: esp-open-lwip, sdk-1.5.0, 2015-12-30, last update 2016-05-26)
2: LWIP open version 2 (STABLE-2_0_2_RELEASE_VER, 2017-03-13, last update 2019-05-03)

At present the Host Emulator supports only LWIP2 (version 2.1, 2019-06-03).

ESP32-IDF uses version based on LWIP 2.0.3 (2017-09-15)

With the Esp8266 I've only really used the default, version 1, and not clear on the relative merits of the versions. Is there any reason we cannot standardise on the most recent LWIP 2 version ?

SSL support

This is provided for the Esp8266 via AxTLS. I've started work adding this to the emulator, but a couple of issues have come to light:

1. The Arduino Esp2866 project supports both AxTLS and BearSSL, whilst ESP32 uses MBED TLS and the ESP8266 RTOS includes support for Wolf SSL.

I am not familiar with the relative merits of the various SSL/TLS implementations, however it seems clear that what is appropriate for the Esp8266 is perhaps rather limiting for the Esp32. That means moving any implementation-specific defintions or code into the related Component.

2. At present the framework has to be recompiled entirely to add SSL support, however only the modules in Core/Network are affected (plus the user application).

One solution to this would be to separate all the SSL stuff out into a separate library, so we wouldn't need a separate libsmingssl.a, just the regular libsming.a. All the SSL stuff would be in libaxtls.a.

[slaff]

One solution to this would be to separate all the SSL stuff out into a separate library, so we wouldn't need a separate libsmingssl.a, just the regular libsming.a. All the SSL stuff would be in libaxtls.a.

Great, that's exactly what we should have for the SSL part.

That means moving any implementation-specific defintions or code into the related Component.

Again true.

[slaff]

Is there any reason we cannot standardise on the most recent LWIP 2 version ?

That is probably the best way to go in terms of maintenance effort. We have to check how stable and fast it is and what is the memory footprint.
For the moment we haven't done this for the Esp8266 architecture due to mDNS and SmartConfig being only part of the espconn_* stuff. If there is mDNS support in latest LWIP 2 then I guess we should rewrite the UdpServer_mDNS sample and use only the most recent stable LWIP 2 version. And we have to test if SmartConfig works with our LWIP of choice.

[slaff]

With the merge of PR #1724 Sming is now dependant on md5sum. It would be better to provide our own minimal md5sum tool based on axtls.

[mikee47]

I only used md5sum as it was handy and available on both Linux and MinGW. Something simpler like a CRC16 would do just as well. Python is another option?

[mikee47]

md5sum seems pretty safe, it's part of GNU coreutils. And CMake has this sort of stuff baked in anyway.

[slaff]

@mikee47 How about starting the refactoring of the SSL stuff ? ;)

[slaff]

Making available axTLS also to other architectures worked quite nicely. Thanks a lot @mikee47 for doing this.

The next step should be to create a layer that abstracts the actual SSL/TLS implementation that is used. There should be

• null implementation (which is just dummy implementation and can be used during link time to compile in projects that don't want to have SSL enabled)
• axTLS implementation

Once we have this abstraction further implementations based on WolfSSL, BearSSL or MBed SSL can be added and used.

@mikee47 Do you want to try adding this layer? I could have done it myself but you have much better coding and design skills than me :)

[mikee47]

@slaff I'll add this to my todo list, probably won't be ready for this release though.

[icodk]

may be to think Ethernet as well ? esp32 has Ethernet hardware support and it could be a nice addition to the esp8266 using SPI. Ethernet has some security advantages and can also facilitate PoE

Just an idea ...