[Ovmsdev] TLS CA question

[Stephen Casner]

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 at 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 at xse.com <mailto:leres at 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 at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev