[Ovmsdev] openssh 6.7 cipher aes128-cbc

[Mark Webb-Johnson]

… or have it depend on “Include the GPL licensed WOLFSSH and WOLFSSL” and come up as an option under there when enabled.

Regards, Mark.

> On 27 Apr 2018, at 1:27 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
>>> It would be good to have a menu config option to define DEBUG_WOLFSSH.
>> 
>> I think the only penalty for enabling it always is an increase in code
>> size, ssuming the "_impure_ptr" is fixed in some way.  I asked Mark if
>> that would be reasonable to enable always.
> 
> I guess it depends on how much bigger. Debugging the internals of wolfssh is seemingly a rare occurence? Perhaps a menuconfig option (in Components / OVMS / Developer Options) would make sense?
> 
> Regards, Mark.
> 
>> On 27 Apr 2018, at 1:16 PM, Stephen Casner <casner at acm.org <mailto:casner at acm.org>> wrote:
>> 
>> On Thu, 26 Apr 2018, Robin O'Leary wrote:
>> 
>>> On Fri, Apr 20, 2018 at 11:39:18PM -0700, Stephen Casner wrote:
>>>> On Fri, 20 Apr 2018, Robin O'Leary wrote:
>>>>> OK, so that started me on quite an adventure in to compiler errors
>>>>> and git submodules,
>>>> Sorry, did my commit of an update to mongoose trip you up?
>>> 
>>> That was just one of several things, but one of the easily resolved ones!
>>> Much more annoying was a mysterious error about an undefined reference to
>>> "_impure_ptr", since that appears nowhere in the code.  I tracked it
>>> down to the fprintf in wolfssh/src/log.c; I still don't understand why,
>>> but I just commented it out, as ovms uses logFunction instead.
>> 
>> Oh, I do remember hitting that one myself and having to use Google for
>> help.  I think I hit that when I tried to add a printf statement of my
>> own, so maybe if I saw it when enabling DEBUG_WOLFSSH I used the same
>> workaround that you did.  I had not remembered that problem when
>> suggesting that you try DEBUG_WOLFSSH.  Sorry.
>> 
>>>> Perhaps I
>>>> should configure in the debug code for wolfssh and wolfssl by default
>>>> so the extra logging can be enabled whenever it is needed.
>>> 
>>> Adding more calls to GetErrorString() in ssh.c is probably more helpful.
>> 
>> That is done, but there is only one error code that is returned for
>> any cipher, MAC or key mismatch, so DEBUG_WOLFSSH is still required to
>> figure out which one.
>> 
>>> It would be good to have a menu config option to define DEBUG_WOLFSSH.
>> 
>> I think the only penalty for enabling it always is an increase in code
>> size, ssuming the "_impure_ptr" is fixed in some way.  I asked Mark if
>> that would be reasonable to enable always.
>> 
>>>> WolfSSH also supports aes128-ctr and aes128-gcm, but I was warned that
>>>> the latter is much more expensive in speed and memory, so I excluded
>>>> it from the configuration for compilation.
>>> 
>>> I think there is full support for aes128-ctr in wolfssl/wolfcrypt, but
>>> the places where it needs to be in wolfssh seem to be mostly missing.
>>> I had a go at adding it, but I haven't got it working.  It does connect,
>>> but auth always fails.  I haven't had chance to figure out why yet.
>> 
>> wolfssh/src/internal.c does reference AES128_CTR in a few places, but
>> I'm not sure what actions are required.
>> 
>> I started with WolfSSH 1.1.0 when doing the integration into OVMS.
>> There is a 1.2.0 release out now (on github at wolfSSL/wolfssh), and a
>> 1.3.0 release pending that will include Wolf's integration of my SCP
>> additions back into their code base.
>> 
>>                                                        -- Steve
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180427/5c0bf615/attachment.htm>