The old esp32 -factory stuff along with the lws support doesn't have a
future in its old form. It has users but the ratio of effort to
contribution is really especially bad. I haven't updated it for more
than a year since esp-idf changes broke the original stuff.
Freertos plat is alive and well and getting a lot of new use, ESP-32 is
supported both there and by modern lws_drivers pieces, including in CI
on real hardware, any further effort will be invested in that direction
instead of more vendor api-specific code (outside of wrapper
implementation).
lws_drivers wraps any SDK apis in generic lws apis such that your code
just uses those, enabling it to become SDK / SoC / vendor independent.
Its first implementation is on esp-idf, the low and mid-level features
that were in the old -factory are already available using that and
new technologies like lws_struct and Secure Streams.
There's a good pattern that's encouraged by using lws_struct pieces, that
we have an lws_dll2 owner with an array of objects listed in it that exist
in an lwsac. And because it came from JSON, there is tending to be a
logical name for the objects.
This adds a typed helper and wrapper to scan the owner list looking for
a specific name (of a specified length, not NUL terminated) in a specific
member of the listed objects, which must be a NUL-terminated const char *.
Again this is a good pattern that's encouraged by use of lws_tokenize
to recover the name we're looking for.
So it leads to the helper that can cleanly search for a listed object of the
right name from an owner, and return the typed object pointer or NULL, from a
length-specified string.
Mbedtls mbedtls_x509_crt_parse() returns 0 for success which is good.
But it has a complicated idea about what to return on fail... if it
couldn't make even one cert from the data, then it returns a negative
return indicating the parsing problem and there is nothing to free.
If it managed to parse at least one cert, instead it retuns a positive
number indicating the number of certs it didn't parse successfully,
and there is something to free.
Adapt the code to understand this quirk.
Callbacks can ask the caller to, eg, destroy the ss handle now. But some
callback returns are handled and produced inside other helper apis, eg
lws_ss_backoff() may have to had fulfilled the callback request to destroy
the ss... therefore it has to signal to its caller, and its callers have
to check and exit their flow accordingly.
FreeRTOS only supports nonmonotonic time, when we correct it by, eg,
ntpclient, we offset all the existing sul timeouts. This adds an
internal helper function to correct existing sul timeouts by the
step amount, and call it in lws ntpclient implementation when
adjusting the gettimeofday() time.
This gives a valgrind result for lws-minimal-http-server-event-lib-foreign
that's clean for lws pieces, although glib is always dirty wrt thread local
storage and hashtable.
Add lws_display and minimal example support for esp32-wrover to match wsp32-heltec-wb32
Since no usable buttons that don't affect something else on wrover kit, assumes
a button to 0V on GPIO14.
This differentiates between client connections for retry / writeable requests
and explicit lws_ss_client_connect() api calls. The former effectively uses
retry / backoff, and the latter resets the retry / backoff.
If you receive ALL_RETRIES_FAILED due to the retry policy, you can do whatever
you need to do there and call lws_ss_client_connect() to try to connect again
with a fresh, reset retry / backoff state.
If the client connection attempt fails early, we report it will a NULL
return from the client connection api. If it fails later, perhaps after
more times around the event loop, we report it as a CONNECTION_ERROR.
This patch makes sure we don't do CONNECTION_ERROR flow if in fact we
are still in the client_connect_via_info() and in a position to report
the failure by returning NULL from there, without it under some
conditions we will do both a CONNECTION_ERROR and return NULL.
- Add low level system message distibution framework
- Add support for local Secure Streams to participate using _lws_smd streamtype
- Add apit test and minimal example
- Add SS proxy support for _lws_smd
See minimal-secure-streams-smd README.md
Now there's an abstract button class regardless of the underlying
connection, we can add more sophicsticated analysis on top of it
for processing its usually noisy events and classifying them into
smd-ready click, long-click or double-click events.
A "regime" defines the timing limits for different press recognition
and can be specified per-button, if not given a default regime is
applied.
String helpers for scanning non-NUL-delimited strings safely,
and very cheap simple string match based JSON parse for cases
that make sense for it... for more complex cases, do a full
JSON parse.
Allow usage of ${metadata} string substitution in more policy elements
for MQTT:
- associated subscription topic in policy
- associated publish topic in policy
- associated will topic in policy
- associated will message in policy
Tested against lws-minimal-mqtt-client-multi / mosquitto
Sometimes we need to find out the substituted length before we can
allocate and actually store it. Teach strexp that if we set the
output buffer to NULL (and the output length to something big) we
are asking for the substituted length and to not produce output.
The low level apis for HMAC (including those only introduced at 1.1.0...)
are all deprecated in OpenSSL v3.
Let's bite the bullet and migrate to EVP, it's already existing in modern
OpenSSL and we already use it for genhash.
EVP needs a PKEY, sort that out and keep it around until the hmac is
destroyed.
Make a start on generic peripheral and bus drivers to provide
meta-functionality regardless of platform.
On the one hand this simply provides...
- bitbang i2c on top of esp-idf gpio apis
- ssd1306 oled chip driver as found on Heltec WB32
- modifications to the minimal example test for esp32 to use that
... on the other hand, those capabilities are provided by creating:
- an abstract i2c class object
- an abstract gpio class object
- i2c class implementation using the abstract gpio for bitbang
- an abstract display class object
- an abstract display state (brightness, animated change,
on/off/init tracking, autodim after inactive, auto-off /
blanking after inactive)
... with the intention, eg, you only have to add a platform
implementation for the gpio to be able to use the i2c-based
display drivers and state handling, and i2c bitbang, without
any other modifications.
Currently for ipv6, we look up the scope assuming we were given an interface ip for
binding. But with ipv4, we also support giving an interface name.
Check it against an interface name first and return that if valid.
https://github.com/warmcat/libwebsockets/issues/1944
