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