<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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);
          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); color: rgb(0, 0, 0);"><br>
        </span></div>
      <div>
        <ol class="MailOutline">
          <li><font color="#000000"><span style="caret-color: rgb(0, 0,
                0);">wolfssh</span></font></li>
          <li><font color="#000000"><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"><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" 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>
      </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>