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