<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">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 <ll-ovmsdev@lange.nom.fr> 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,</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);">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 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>
  </div>

_______________________________________________<br>OvmsDev mailing list<br>OvmsDev@lists.openvehicles.com<br>http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br></div></blockquote></div><br></div></div></body></html>