<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Mark,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks for the 2 repos.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regarding the versions, I had success
with wolfssl until 5.3.0. After that version, source code
compatibility is still OK but I had crashes in SSH sessions (stack
overflow).<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">So I did some baseline PRs with the
same versions we had before (4.7.0/1.4.6) ; then other ones to
increase up to 5.3.0 / 1.4.13:</div>
<div class="moz-cite-prefix">
<ul>
<li>Baseline:</li>
<ul>
<li>WolfSSH 1.4.6 :
<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/885">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/885</a></li>
<li>WolfSSL : (draft in-progress, it's missing 2 patches from
our repo that are needed - at least one for compilation -
with v4.7.0)<br>
</li>
</ul>
<li>Upgrades:</li>
<ul>
<li>WolfSSH up to 1.4.10 :
<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/886">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/886</a></li>
<ul>
<li>I'll prepare an upgrade to the latest but some changes
are needed that I need to test on all releases.<br>
</li>
</ul>
<li>(For WolfSSL I'll prepare the upgrade later)<br>
</li>
</ul>
</ul>
</div>
<div class="moz-cite-prefix">That way we can revert the "upgrade"
commits without going back to the module / submodule commit + we
do not introduce doubts/regressions with the submodule operation.<br>
</div>
<p><br>
</p>
<p>Please note: in the WolfSSL fork the tags are missing ; could you
please fetch them and push them ? Thanks in advance.</p>
<p>Please also create - for WolfSSL still - a dedicated branch
`v4.7.0-stable-ovms` so that I can apply the missing patches
(mainly a workaround for a define SHA_CTX + some changes from
Stephen (WOLFSSL_SMALL_STACK))</p>
<p><br>
</p>
<p>Thanks in advance.</p>
<p><br>
</p>
<p>Regards,<br>
</p>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">PS: If you have some time, and want to
review my other pendings PRs: <a class="moz-txt-link-freetext"
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse</a></div>
<div class="moz-cite-prefix">I believe they can be reviewed /
applied independently should you wish so.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Le 28/04/2023 à 07:37, Mark
Webb-Johnson a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:E9D6087E-F8BD-4F7D-A755-00DB6B918F9B@webb-johnson.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<br style="font-family: ArialMT;">
<span style="font-family: ArialMT;">I’ve forked the two wolf
repos:</span>
<div style="font-family: ArialMT;"><br>
</div>
<div style="font-family: ArialMT;">
<ul class="MailOutline">
<li><a href="https://github.com/openvehicles/wolfssl"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openvehicles/wolfssl</a></li>
<li><a href="https://github.com/openvehicles/wolfssh"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openvehicles/wolfssh</a></li>
</ul>
<div><br>
</div>
<div>However, those are the latest versions (5.6.0 and 1.4.13
respectively) so I am not certain of compatibility with our
code base, or how hard it would be to integrate those. We can
always branch+tag earlier versions closer to ours if too
hard. <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0,
0);">Our previous wolfSSH was v1.4.6 (February 3, 2021),
and </span><font color="#000000">wolfSSL Release 4.7.0
(February 16, 2021). From my understanding, WolfSSH requires
the crypt parts of WolfSSL to build.</font></div>
<div><br>
</div>
<div>Doing it this way, and bringing these in as submodules to
our code, would be the best way to maintain compatibility with
upstream. If it is really too difficult (given the number of
changes Stephen made to get this to work), we can always just
roll back to committing the existing versions directly to
those GitHub repositories and making them submodules.</div>
<div><br>
</div>
<div>Could you have a try and see if that is possible?</div>
<div><br>
</div>
<div>Regards, Mark.</div>
</div>
<div><br>
<blockquote type="cite">
<div>On 26 Apr 2023, at 2:26 PM, Ludovic LANGE
<a class="moz-txt-link-rfc2396E" href="mailto:ll-ovmsdev@lange.nom.fr"><ll-ovmsdev@lange.nom.fr></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div>
<div class="moz-cite-prefix">Hi Mark,<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I'm going to add the missing
parts for the main tunnel (new config items to a)
auto-start + b) to register as a default route if
wanted).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">For the "manual" commands
I'll experiment with these. I like the idea of having a
quick remote access for troubleshooting purposes.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regarding <font
face="monospace">wolf*</font>, yes, I do think that
would be the best idea - to have these as submodules.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I intend to "relocate" those
modules as subfolders of the component in my patches:</div>
<div class="moz-cite-prefix"><font face="monospace">components/wolfssh</font></div>
<div class="moz-cite-prefix"><font face="monospace">├──
CMakeLists.txt<br>
├── README.md<br>
├── component.mk<br>
└── wolfssh<br>
├── ChangeLog.md<br>
├── LICENSING<br>
├── Makefile.am<br>
├── README</font></div>
<div class="moz-cite-prefix"><font face="monospace">
├── ....</font></div>
<div class="moz-cite-prefix"><font face="monospace">
...<br>
</font></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">This way, we can manage our
"glue" code ( <font face="monospace">CMakeLists.txt</font>
and <font face="monospace">component.mk</font> )
without interfering with the external component. I
believe that it keeps a proper separation between "our
code" and "upstream code", making it easy to upstream
patches and/or to rebase to a newer release.<br>
</div>
<div class="moz-cite-prefix">Especially given that some of
these external components now have their own <font
face="monospace">CMakeLists.txt</font> - not easily
re-usable for our build structure.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">If you're OK with that, you
can either:</div>
<div class="moz-cite-prefix">
<ul>
<li>take this opportunity to add the submodule at the
target place - only dealing with relocating <font
face="monospace">component.mk </font>(you can
take inspiration from my tree : <a
moz-do-not-send="true"
href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental-esp-idf-build-workflow/vehicle/OVMS.V3/components/wolfssh">wolfssh</a>
(<font face="monospace">component.mk </font>and<font
face="monospace"> README.md</font>) and <a
moz-do-not-send="true"
href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental-esp-idf-build-workflow/vehicle/OVMS.V3/components/wolfssl">wolfssl</a>
(<font face="monospace">component.mk </font>and<font
face="monospace"> README.md</font> and <font
face="monospace">port/</font> directory that you
need to move - careful, in my tree the
user_settings.h is already patched, you don't want
that for the moment.))</li>
<li>just replace as-is, and I'll do the relocation
with a PR.</li>
<li>Or if you want I can also handle the (b) and (c)
parts of your proposal myself with a PR<br>
</li>
</ul>
<p>Let me know.</p>
<p>Regards,<br>
</p>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Le 26/04/2023 à 04:10, Mark
Webb-Johnson a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CB2D7767-6967-4179-A92A-2F488F69D3E8@webb-johnson.net">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
I reviewed your config, and see the issue. Quite a lot
of parameters to set.
<div><br>
</div>
<div>Perhaps it is sufficient to have just:</div>
<div><br>
</div>
<div>
<ol class="MailOutline">
<li>One single wireguard tunnel in configuration,
with an associated auto setting to automatically
start it.</li>
<li>A wireguiard command to bring up/down other
tunnels, manually specified on the command line.</li>
</ol>
</div>
<div><br>
</div>
<div>That way, if the user really needs more than one
tunnel (or custom tunnels such as I suggest), he can
use command shell scripts, or remote commands to bring
them up/down.</div>
<div><br>
</div>
<div>Regarding wolfssh and other similar external
components, I think that they can/should be split off
and run as submodules sourced from a
GitHub.com/openvehicles repository. We’ve already done
that for mongoose, zlib, and libzip. Would you like me
to create empty repositories for those, and then you
can submit the PRs to (a) add the existing code to the
new repository, (b) remove the code from
Open-Vehicle-Monitoring-System-3, and (c) add the
submodule to <span style="caret-color: rgb(0, 0, 0);">Open-Vehicle-Monitoring-System-3?
I think candidates for this approach include:</span></div>
<div><span style="caret-color: rgb(0, 0, 0);"><br>
</span></div>
<div>
<ol class="MailOutline">
<li><font><span style="caret-color: rgb(0, 0, 0);">wolfssh</span></font></li>
<li><font><span style="caret-color: rgb(0, 0, 0);">wolfssl</span></font></li>
</ol>
</div>
<div><br>
</div>
<div>Regards, Mark<br>
<div><br>
<blockquote type="cite">
<div>On 25 Apr 2023, at 3:28 PM, Ludovic LANGE <a
class="moz-txt-link-rfc2396E"
href="mailto:ll-ovmsdev@lange.nom.fr"
moz-do-not-send="true"><ll-ovmsdev@lange.nom.fr></a>
wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div>
<div class="moz-cite-prefix">Hello Mark,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks for the
comments. I'll see how we can manage tunnels
from the cli, should be doable.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regarding the PR,
here is one PR with only WireGuard support :
<a class="moz-txt-link-freetext"
href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/pull/1"
moz-do-not-send="true">https://github.com/llange/Open-Vehicle-Monitoring-System-3/pull/1</a>
- it's just for review, as it is from my
fork to itself.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">For the WolfSSH /
WolfSSL, I have some pending PRs on master,
and I create new ones as soon as the
previous ones are merged, as to not increase
too much the burden on the reviewers. <br>
</div>
<div class="moz-cite-prefix">They are here : <a
class="moz-txt-link-freetext"
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse"
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse</a></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">(wolfssl will be
a new one, not created yet, I'm waiting for
the feedback on the wolfssh one - is a new
submodule acceptable or not, or is it better
to have a subtree, or a copy, ....)</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regards,<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Le 25/04/2023 à
02:49, Mark Webb-Johnson a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:2FD09875-747B-4C09-8956-FD4DA157E2B6@webb-johnson.net">
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
Really glad to see this, and thanks for
working on it.
<div><br>
</div>
<div>I do think it would be useful to have
many wireguard circuits configurable.</div>
<div><br>
</div>
<div>For my own use case, I would like to be
able to bring up a <span
style="caret-color: rgb(0, 0, 0);">wireguard
</span>circuit purely from the command
line (with no configuration set). This is
because I am frequently called in to help
with setup/configuration/diagnostic issues
remotely, and having a full VPN would be
extremely useful for that. If I could just
send a single command to start the vpn
back to me, then ssh into the module (or
get can bus data over tcp/ip, etc), it
would help tremendously.</div>
<div>
<div><br>
</div>
<div>Regarding the PR, can we split this
into (a) for wolfssh/wolfssl as a
module, and (b) for wireguard support.
At the moment, it is quite hard to
review with both in the same PR.</div>
<div><br>
</div>
<div>Regards, Mark.</div>
<div><br>
<blockquote type="cite">
<div>On 24 Apr 2023, at 5:35 PM,
Ludovic LANGE <a
class="moz-txt-link-rfc2396E"
href="mailto:ll-ovmsdev@lange.nom.fr"
moz-do-not-send="true"><ll-ovmsdev@lange.nom.fr></a>
wrote:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<div>
<p>Dear list,</p>
<p>A few months ago I created <a
class="moz-txt-link-freetext"
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752"
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752</a>
to explore WireGuard VPN support
; which leaded me to add
ESP-IDFv5 support to OVMS.</p>
<p>Now that this ESP-IDFv5 support
is added (in my branch, and it
is in the progress of getting
included in master - with the
help and the testing of
everybody here), I've resumed my
exploration of adding support
for WireGuard VPN to OVMS.</p>
<p>It's now ready for comments,
you can now check:</p>
<ul>
<li>a new branch here <a
class="moz-txt-link-freetext"
href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/752-wireguard"
moz-do-not-send="true">https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/752-wireguard</a></li>
<li>a DRAFT PR here <a
class="moz-txt-link-freetext"
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/882"
moz-do-not-send="true">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/882</a></li>
</ul>
<p>if you want to explore and test
this VPN support for OVMS.</p>
<p><br>
</p>
<p>My own use case for this
feature is :</p>
<ul>
<li>Security : I would like my
module to be unreachable from
the public Internet. This is a
first step.</li>
<li>Practicality : I can reach
my module with a single IP
address / name that is part of
my private network. SSH, Web,
SCP, ... all work as if my
module is local to my servers</li>
<li>Roaming : The idea is to
have a single point of contact
even if the module changes
network, changes IP address,
etc...</li>
</ul>
<p>Part of this feature set is
already available with a
combination of the OVMS Server
(v2, v3) and the Hologram.io
services, but I wanted to be
independent of the mobile
connexion provider, and also
file transfer is important for
my use case (SCP or other), as
I'm often wanting to sync the
content of the SD card over the
network.</p>
<p><br>
</p>
<p>If you can have a look and give
feedback (either here, or on the
PR), especially on:</p>
<ul>
<li>The documentation : is it
enough ? properly organized ?
should it be split ? etc...</li>
<li>The command set</li>
<li>The configuration items :
what's missing ? is the naming
OK ?</li>
<li>Other features (should I
introduced events ? metrics ?)</li>
</ul>
<p>Also if you have any feature
request, please share.</p>
<p>Limitations:</p>
<ul>
<li>Currently limited to 1
tunnel, but should work with
multiple - it's just a
question of arranging the
configuration to support
multiple instances</li>
<li>Roaming not tested yet (will
report)</li>
<li>Compatibility with mobile
network not tested yet (will
need help on this)</li>
<li>I'm not really happy with
the way I set the
configuration items. I'd like
to "hide" (write-only) the
important bits (private key,
shared key), but fear that it
would clutter the config
namespace - especially if I
introduce multiple tunnels.<br>
Maybe one solution would be to
have a rich configuration per
tunnel (like a JSON / YAML),
which would be a nightmare to
edit by hand and would need
support in the web interface.</li>
<li>Tunnel always active as soon
as the configuration is
correct. May be will need to
add an enabled/disabled flag
to the configuration, and/or
an auto-start flag.<br>
</li>
</ul>
<p>Current status:</p>
<ul>
<li>Builds on GitHub actions (if
you can to test, pre-compiled
firmwares are available here
for example: <a
class="moz-txt-link-freetext"
href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/4784405668"
moz-do-not-send="true">https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/4784405668</a>
- just download a Zip file
(v5.0 or v5.0.1), and flash
with a command-line like <font
face="monospace">esptool.py
--chip esp32 --port
/dev/xxxx --baud 921600
write_flash --compress
--flash_mode "dio"
--flash_freq "40m"
--flash_size detect 0x10000
ovms3.bin</font> )</li>
<li>Works on My Machine (tunnel
is UP, SSH is working OK, HTTP
is working OK, performances
look OK. Ping time (ICMP) is
comparable with or without
tunnel)<br>
</li>
</ul>
<p><br>
</p>
<p>Thanks for your comments.</p>
<p>Regards,<br>
</p>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a class="moz-txt-link-abbreviated
moz-txt-link-freetext"
href="mailto:OvmsDev@lists.openvehicles.com"
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a class="moz-txt-link-abbreviated
moz-txt-link-freetext"
href="mailto:OvmsDev@lists.openvehicles.com"
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br>
<a class="moz-txt-link-freetext"
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:OvmsDev@lists.openvehicles.com" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a><br>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<p><br>
</p>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>