<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I suggest to merge into for-v3.3 and just include it in the testing for that.<div class=""><br class=""></div><div class="">I have a tag ‘pre’ setup on <a href="http://api.openvehicles.com" class="">api.openvehicles.com</a> server to allow that ‘preview’ from for-v3.3 branch to be OTA updated automatically (I ran out of good names after edge, eap, and main). I build it when worthwhile. This allows me to easily run it in my cars for live testing.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 12 Mar 2021, at 2:08 PM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Oh, you guys are not testing my mongoose-wolfssl branch, you are<br class="">testing master and/or for-v3.3 branch. I see that commit<br class="">c6911c91432cada337bef46f6a541af46304b5cf went into master on 2/11 but<br class="">commit 9607979e91da7a53da1cd0bd8325ab390abe18bb is only on my<br class="">mongoose-wolfssl branch.<br class=""><br class="">On master or for-v3.3 the SSH/SSL code is updated to 1.4.5/4.6.0 but<br class="">mongoose is still using MBEDTLS for TLS.<br class=""><br class="">So, Craig, you're not actually "building/booting this" where this was<br class="">referring to my wolfssl-based TLS. If you would like to do so, what<br class="">rebasing and or merging is needed? Should my new code be moved over<br class="">to a new branch from for-v3.3?<br class=""><br class="">Actually, I guess all of the changes to wolfssh and wolfssl components<br class="">could be merged. The control of whether TLS goes through MBEDTLS or<br class="">wolfssl is controlled by changes in mongoose.<br class=""><br class=""> -- Steve<br class=""><br class="">On Fri, 12 Mar 2021, Mark Webb-Johnson wrote:<br class=""><br class=""><blockquote type="cite" class="">The for-v3.3 branch should be up-to-date and merged from master. It should have everything that master has.<br class=""><br class="">I see it has this:<br class=""><br class="">commit 9607979e91da7a53da1cd0bd8325ab390abe18bb<br class="">Author: Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>><br class="">Date: Wed Feb 24 23:53:28 2021 -0800<br class=""><br class=""> SSH: Don't emit error message if wolfssl debugging is unconfigured<br class=""><br class="">diff --git a/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp b/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp<br class="">index 21549bad..6fa0e5e5 100644<br class="">--- a/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp<br class="">+++ b/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp<br class="">@@ -177,9 +177,8 @@ void OvmsSSH::NetManInit(std::string event, void* data)<br class=""> ESP_LOGI(tag, "Launching SSH Server");<br class=""> wolfSSH_SetLoggingCb(&wolfssh_logger);<br class=""> wolfSSH_Debugging_ON();<br class="">- if ((ret=wolfSSL_SetLoggingCb(&wolfssl_logger)) || (ret=wolfSSL_Debugging_ON()))<br class="">- ESP_LOGW(tag, "Couldn't initialize wolfSSL debugging, error %d: %s", ret,<br class="">- GetErrorString(ret));<br class="">+ wolfSSL_SetLoggingCb(&wolfssl_logger);<br class="">+ wolfSSL_Debugging_ON();<br class=""> ret = wolfSSH_Init();<br class=""> if (ret != WS_SUCCESS)<br class=""> {<br class=""><br class="">But current code in both master and for-v3.3 branches is:<br class=""><br class=""> ESP_LOGI(tag, "Launching SSH Server");<br class=""> wolfSSH_SetLoggingCb(&wolfssh_logger);<br class=""> wolfSSH_Debugging_ON();<br class=""> if ((ret=wolfSSL_SetLoggingCb(&wolfssl_logger)) || (ret=wolfSSL_Debugging_ON()))<br class=""> ESP_LOGW(tag, "Couldn't initialize wolfSSL debugging, error %d: %s", ret,<br class=""> GetErrorString(ret));<br class=""><br class="">Seems commit c6911c91432cada337bef46f6a541af46304b5cf seems to have brought back the old code?<br class=""><br class="">Mark<br class=""><br class=""><blockquote type="cite" class="">On 12 Mar 2021, at 11:34 AM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:<br class=""><br class="">Craig and Mark,<br class=""><br class="">I do have the OvmsSSH::NetManInit() function calling<br class="">wolfSSL_Debugging_ON() which would be expected to return -174 meaning<br class="">NOT_COMPILED_IN as Mark correctly found. At one point I had code to<br class="">print that error messge because I was having trouble getting the<br class="">wolfSSL debugging to work, but I took out that error message in<br class="">commit 9607979e91da7a53da1cd0bd8325ab390abe18bb so now the return<br class="">value is ignored. I'm baffled. I'll have to look deeper after<br class="">dinner.<br class=""><br class="">My mongoose-wolfssl branch is off of master on 2/17. I should<br class="">probably have rebased to the current master or perhaps merged it to<br class="">for-v3.3 as Mark recently requested. Have you guys done that merge<br class="">for what you are testing now?<br class=""><br class=""> -- Steve<br class=""><br class="">On Fri, 12 Mar 2021, Mark Webb-Johnson wrote:<br class=""><br class=""><blockquote type="cite" class="">P.S. Error code -174 seems to be 'NOT_COMPILED_IN’.<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 12 Mar 2021, at 9:56 AM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:<br class=""><br class="">Craig,<br class=""><br class="">I get the same (with for-v3.3):<br class=""><br class="">W (2940) ssh: Couldn't initialize wolfSSL debugging, error -174: Unknown error code<br class=""><br class="">I guess it is just a warning. Probably some debugging config setting.<br class=""><br class="">But wifi, web and others work ok for me. Only problems I have with for-v3.3 branch are (a) the web dashboard modem status, and (b) the TLS certificate verification against <a href="http://api.openvehicles.com" class="">api.openvehicles.com</a> <<a href="http://api.openvehicles.com/" class="">http://api.openvehicles.com/</a>>. I am working on both.<br class=""><br class="">Regards, Mark.<br class=""><br class=""><blockquote type="cite" class="">On 12 Mar 2021, at 9:46 AM, Craig Leres <<a href="mailto:leres@xse.com" class="">leres@xse.com</a> <<a href="mailto:leres@xse.com" class="">mailto:leres@xse.com</a>>> wrote:<br class=""><br class="">On 3/10/21 11:23 PM, Stephen Casner wrote:<br class=""><blockquote type="cite" class="">Michael and anyone else who's game:<br class="">I now have an updated mongoose-wolfssl branch ready to be tested. The<br class="">reason for the 90-second lockup mentioned in the previous post is a<br class="">whole lot of math for a prime-number validation that's part of the<br class="">Diffie-Hellman step. It was actually 87 seconds for Mark's server and<br class="">28 seconds for Michael's due to differences in certificates. That<br class="">prime-number validation is required for FIPS compliance, which WolfSSL<br class="">supports, but we don't need it. I spent quite a while digging into<br class="">this to find where the process was getting stuck. Finally I got help<br class="">from WolfSSL support suggesting a configuration option that avoids<br class="">this extra check.<br class="">So now I have an implementation using mongoose with wolfssl that<br class="">connects successfully to both servers with a 3-4 second delay. (I<br class="">don't recall what the delay was for the MBEDTLS-based implementation.)<br class="">I think the memory usage looks OK. I still have not taken any steps<br class="">to reduce any resources used by the MBEDTLS code as accessed for other<br class="">purposes.<br class="">Included in the debugging was another version update on the Wolf code<br class="">to wolfssh 1.4.6 and wolfssl 4.7.0.<br class=""></blockquote><br class="">I tried building/booting this on my dev module( 3.2.016-66-g93e0cf3e); but for some time now the for-v3.3 branch has been broken for me. When the module first boots the web gui works long enough for me to login and then it times out. From that point on I can't get the web gui or ssh to respond. It will return pings. The serial console is fine (and that's how I switch back to build based on master).<br class=""><br class="">I just did a fresh reboot and captured the serial console output and noticed this:<br class=""><br class=""> W (4484) ssh: Couldn't initialize wolfSSL debugging, error -174: Unknown error code<br class=""><br class="">I think it happened around the time I lost wifi connectivity.<br class=""><br class="">My sdkconfig is close to support/sdkconfig.default.hw31, I have CONFIG_SPIRAM_CACHE_WORKAROUND turned off along with a lot of vehicles.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>Craig<br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a> <<a href="mailto:OvmsDev@lists.openvehicles.com" class="">mailto:OvmsDev@lists.openvehicles.com</a>><br class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class=""></blockquote></blockquote></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</blockquote></blockquote>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>