<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Michael,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks for your enthusiasm!</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The library are converted to submodules
in a first step (did occur for WolfSSH first with d2ac3278), then
upgraded (for WolfSSH to a recent - not latest - v1.4.10 with
d13514ac )</div>
<div class="moz-cite-prefix">I'm in the process of trying to update
WolfSSH to latest (which would be v1.4.13) -but it depends on a
more recent version of WolfSSL - stay tuned !</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regarding WolfSSL then, it is in the
process of being converted to submodule first (in the same v4.3.0
as now), then upgraded to a more recent version).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">All this being important for the
ESP-IDFv5 port ; but, as you mention, is also important
feature-wise:</div>
<div class="moz-cite-prefix">
<ul>
<li><a moz-do-not-send="true"
href="https://github.com/wolfSSL/wolfssh/blob/326a4bf004a6f4f19c8741ae10f24e1169e80f85/ChangeLog.md">Changelog
for WolfSSH</a> (we were at 1.4.6 - now at 1.4.10 - aiming
1.4.13)</li>
<li><a moz-do-not-send="true"
href="https://github.com/wolfSSL/wolfssl/blob/877e026da4141cee916a2b2b4bee7139e2dc21db/ChangeLog.md">Changelog
for WolfSSL</a> (we are at 4.3.0 - aiming 5.6.0)<br>
</li>
</ul>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">These 2 libraries are mainly used, to
my knowledge, for the SSH console support. Also understood that we
would prefer to keep, or reduce, our dependency on these libraries
- not increase them.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Wolfssl can be (not 100% sure if it
still works) enabled for SSL support in Mongoose - but it's not
the default - with the config item CONFIG_MG_SSL_IF_WOLFSSL you
mentioned.</div>
<div class="moz-cite-prefix">So you can enable it and check if
Mongoose works with it, but I'm not sure it's the preferred path
forward.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">By the way... Mongoose itself could
benefit of some upgrades in the future, but the API seems to have
changed. Our version is 6.11; latest is 7.9, and the <a
moz-do-not-send="true"
href="https://github.com/cesanta/mongoose/releases">changes are
here</a>. I'll try to tackle this when I have time :-)</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 01/05/2023 à 03:38, Michael Geddes a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAH0p7u+B7U=++u-Y=qsG8Ry+yM8eXp=-gveAqUMgaM1BiAYKqg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"><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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">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"
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"
target="_blank"
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>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"
moz-do-not-send="true"><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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">wolfssh</a>
(<font face="monospace"><a
href="http://component.mk"
target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">wolfssl</a>
(<font face="monospace"><a
href="http://component.mk"
target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true"><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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true"><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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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"
moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true"
class="moz-txt-link-freetext">OvmsDev@lists.openvehicles.com</a><br>
<a
href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev"
rel="noreferrer" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
<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>