<div dir="ltr">Hey Ludovic,<br><div><br></div><div>I noticed this change come through, and it's exciting to see all these libraries being updated to the latest! I also noticed I have the following config:</div><div><br></div><div>CONFIG_MG_SSL_IF_WOLFSSL=<br>CONFIG_OVMS_SC_GPL_WOLF=y<br></div><div><br></div><div>Do you know what I cain by using WOLFSSL config? I'm happy to try it.</div><div><br></div><div>//.ichael</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 1 May 2023 at 03:39, Ludovic LANGE <<a href="mailto:ll-ovmsdev@lange.nom.fr">ll-ovmsdev@lange.nom.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>Thanks Mark, it's perfect.</div>
<div><br>
</div>
<div>I've just reapplied the original
patches from Stephen here :
<a href="https://github.com/openvehicles/wolfssl/pull/1" target="_blank">https://github.com/openvehicles/wolfssl/pull/1</a></div>
<div><br>
</div>
<div>Once those are reviewed and merged,
I'll upgrade the baseline PR for WolfSSL migration to submodule
(and convert it from draft to final PR).</div>
<div><br>
</div>
<div>Thanks in advance !</div>
<div><br>
</div>
<div>Regards,</div>
<div><br>
</div>
<div><br>
</div>
<div>Le 30/04/2023 à 10:28, Mark
Webb-Johnson a écrit :<br>
</div>
<blockquote type="cite">
I think this is done. Please try, and let me know if ok for you
now.
<div><br>
</div>
<div>Regards, Mark.<br>
<div>
<div><br>
<blockquote type="cite">
<div>On 29 Apr 2023, at 4:44 AM, Ludovic LANGE
<a href="mailto:ll-ovmsdev@lange.nom.fr" target="_blank"><ll-ovmsdev@lange.nom.fr></a> wrote:</div>
<br>
<div>
<div>
<div>Hi Mark,</div>
<div><br>
</div>
<div>Thanks for the 2 repos.<br>
</div>
<div><br>
</div>
<div>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><br>
</div>
<div>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>
<ul>
<li>Baseline:</li>
<ul>
<li>WolfSSH 1.4.6 :
<a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/885" target="_blank">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 href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/886" target="_blank">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>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><br>
</div>
<div>PS: If you have some
time, and want to review my other pendings PRs: <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse" target="_blank">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse</a></div>
<div>I believe they can be
reviewed / applied independently should you wish so.<br>
</div>
<div><br>
</div>
<div>Le 28/04/2023 à 07:37,
Mark Webb-Johnson a écrit :<br>
</div>
<blockquote type="cite">
<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>
<li><a href="https://github.com/openvehicles/wolfssl" target="_blank">https://github.com/openvehicles/wolfssl</a></li>
<li><a href="https://github.com/openvehicles/wolfssh" target="_blank">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>Our previous wolfSSH was v1.4.6 (February
3, 2021), and </span><font>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 href="mailto:ll-ovmsdev@lange.nom.fr" target="_blank"><ll-ovmsdev@lange.nom.fr></a>
wrote:</div>
<br>
<div>
<div>
<div>Hi Mark,<br>
</div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div><br>
</div>
<div>Regarding <font face="monospace">wolf*</font>, yes, I do
think that would be the best idea - to
have these as submodules.<br>
</div>
<div><br>
</div>
<div>I intend to
"relocate" those modules as subfolders of
the component in my patches:</div>
<div><font face="monospace">components/wolfssh</font></div>
<div><font face="monospace">├── CMakeLists.txt<br>
├── README.md<br>
├── <a href="http://component.mk" target="_blank">component.mk</a><br>
└── wolfssh<br>
├── ChangeLog.md<br>
├── LICENSING<br>
├── Makefile.am<br>
├── README</font></div>
<div><font face="monospace"> ├── ....</font></div>
<div><font face="monospace"> ...<br>
</font></div>
<div><br>
</div>
<div>This way, we
can manage our "glue" code ( <font face="monospace">CMakeLists.txt</font>
and <font face="monospace"><a href="http://component.mk" target="_blank">component.mk</a></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>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><br>
</div>
<div>If you're OK
with that, you can either:</div>
<div>
<ul>
<li>take this opportunity to add the
submodule at the target place - only
dealing with relocating <font face="monospace"><a href="http://component.mk" target="_blank">component.mk</a> </font>(you
can take inspiration from my tree : <a href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental-esp-idf-build-workflow/vehicle/OVMS.V3/components/wolfssh" target="_blank">wolfssh</a>
(<font face="monospace"><a href="http://component.mk" target="_blank">component.mk</a> </font>and<font face="monospace"> README.md</font>)
and <a href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental-esp-idf-build-workflow/vehicle/OVMS.V3/components/wolfssl" target="_blank">wolfssl</a>
(<font face="monospace"><a href="http://component.mk" target="_blank">component.mk</a> </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><br>
</div>
<div>Le 26/04/2023 à
04:10, Mark Webb-Johnson a écrit :<br>
</div>
<blockquote type="cite">
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>
<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>Open-Vehicle-Monitoring-System-3?
I think candidates for this approach
include:</span></div>
<div><span><br>
</span></div>
<div>
<ol>
<li><font><span>wolfssh</span></font></li>
<li><font><span>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 href="mailto:ll-ovmsdev@lange.nom.fr" target="_blank"><ll-ovmsdev@lange.nom.fr></a>
wrote:</div>
<br>
<div>
<div>
<div>Hello
Mark,</div>
<div><br>
</div>
<div>Thanks
for the comments. I'll see how
we can manage tunnels from the
cli, should be doable.</div>
<div><br>
</div>
<div>Regarding
the PR, here is one PR with
only WireGuard support : <a href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/pull/1" target="_blank">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><br>
</div>
<div>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>They
are here : <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse" target="_blank">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse</a></div>
<div><br>
</div>
<div>(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><br>
</div>
<div>Regards,<br>
</div>
<div><br>
</div>
<div>Le
25/04/2023 à 02:49, Mark
Webb-Johnson a écrit :<br>
</div>
<blockquote type="cite">
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>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 href="mailto:ll-ovmsdev@lange.nom.fr" target="_blank"><ll-ovmsdev@lange.nom.fr></a>
wrote:</div>
<br>
<div>
<div>
<p>Dear list,</p>
<p>A few months ago
I created <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752" target="_blank">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 href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/752-wireguard" target="_blank">https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/752-wireguard</a></li>
<li>a DRAFT PR
here <a href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/882" target="_blank">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 href="https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/4784405668" target="_blank">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 href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<p><br>
</p>
<div id="m_-6827661376210907007grammalecte_menu_main_button_shadow_host" style="width:0px;height:0px"></div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div>