[Ovmsdev] Time for release 3.2.016?

[Stephen Casner]

Michael,

> Well, if the vehicle developers don't react, we can only release the test to
> the edge users and see if complaints come in or crash counts increase
> significantly... IOW, yes.

Thanks.

> > switching mongoose to use wolfSSL would require increasing that
> > set.  I'd be happy to try that.
>
> That would be great.
>
> Mongoose has an SSL library abstraction layer, but there certainly will be
> dragons...

The Espressif reference you cited included a step of switching the
ESP-TLS configuration parameter from mbedtls to wolfssl.  If Mongoose
was going to mbedtls through ESP-TLS, then that configuration might
take care of it.  But if not, ...

> Do we still need the larger stack if wolfSSL can run in internal RAM
> completely?

I think you are asking about an option to still keep the small stack
configuration for wolfSSL but change its heap allocations to come from
internal RAM instead of PSRAM (which is straightforward since the heap
allocations are funneled through our own allocation function in
console_ssh.cpp).  There is still the problem that the SSH connect
would execute more than 30K malloc calls, which was a contributing
factor in the slowness.  And if internal RAM was running low, the
connection would fail.  We check for that and avoid a crash, but the
remnants of the connection attempt are not cleaned up properly.  We'd
have to back off to PSRAM instead.  And that still might leave
internal RAM depleted when we might need it for something else like
creating a task.

> > I would think that we don't have mongoose SSL processing and wolfSSL
> > processing happening at the same time.  If that's true, then the
> > switch would not help stack usage.  Do you know?
>
> If an ssh/scp channel is used while the module performs https requests (e.g.
> for scripts or OTA update checks) or has a connection to a V2/V3 server using
> TLS, both libs will be in use simultaneously.

In the case of SSH, I think all the processing is done contiguously
upon receipt of a packet.  Because of our non-blocking design that
keeps all of the SSH processing in the one NetMan task it is not
possible to keep state from one packet to the next on the stack.  As
you noted, the HTTPS processing is blocked for the whole time that the
SSH crypto processing is underway.  I think the operations are all
forced to be processed sequentially.

                                                        -- Steve