The disk space requirement is not really a problem. The stack size increase is not good, but probably manageable. Imho, IRAM is out biggest issue at the moment, and any reduction in that is welcome. Regards, Mark.
On 24 Jan 2021, at 2:38 PM, Stephen Casner <casner@acm.org> wrote:
After a pause of three years, I have finally gotten around to updating wolfssh and wolfssl to the current stable releases, 1.4.5 and 4.6.0 respectively. This includes the code to support SCP that I wrote and contributed back to them and was integrated into wolfssh 1.3.0. There were some API tweaks that I needed to work through, but the source files are now unmodified except for wolfcrypt/settings.h where I ran into a compilation conflict on the XREALLOC macro. As before, I need to supply my own malloc, free and realloc functions so we can control PSRAM usage and so we can emit a log message if memory allocation fails.
For starters, this update removes the restriction to use cipher aes128-cbc. In addition, the WolfSSL code now includes integration with the hardware crypto acceleration capabilities of the ESP32. I'm not sure how much that will affect performance as we see it because I think the biggest performance factor is how we need to use the APIs given our task structure. The public key handshake for initial connection may be faster.
I added the new code on a branch named update-wolfssh by copying in the source files as I did when creating the wolfssh and wolfssl components initially. I'm running the new code on OVMS in my car and have given it basic testing by connecting with the ssh client and transferring files with scp. I invite anyone else who is interested to test as well or to comment if there are any concerns about merging to the master branch. There are some memory considerations.
I've added the complete wolfssl source tree even though we only use the wolfcrypt subset of wolfssl. The update added a bunch of files and increased the required disk space from 18M to 43M. Similarly, wolfssh added code for scp, sftp, ssh agent server code and also ssh clients that we are not using; that increased disk space from 2.0M to 2.6M. I added our scp code before they implemented theirs and I have not examined their scp and sftp code to see if there would be any advantage in trying to adapt it to fit our non-blocking architecture.
I had to increase the size of the NetMan stack from 8K to 10K to avoid stack overflow. With current master code the max used on my OVMS was 5616 whereas after the update it is 9700.
With the current master code, the amount of memory added by NetMan when an ssh connection was established was 2557 D/IRAM and 6108 SPIRAM for 8665 total. With the update it was 1240 D/IRAM and 8768 SPIRAM for 10008 total.
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev