[Ovmsdev] Request For Comments - Wireguard VPN
Ludovic LANGE
ll-ovmsdev at lange.nom.fr
Tue May 2 04:30:31 HKT 2023
Hi Michael,
Thanks for your enthusiasm!
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 )
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 !
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).
All this being important for the ESP-IDFv5 port ; but, as you mention,
is also important feature-wise:
* Changelog for WolfSSH
<https://github.com/wolfSSL/wolfssh/blob/326a4bf004a6f4f19c8741ae10f24e1169e80f85/ChangeLog.md>
(we were at 1.4.6 - now at 1.4.10 - aiming 1.4.13)
* Changelog for WolfSSL
<https://github.com/wolfSSL/wolfssl/blob/877e026da4141cee916a2b2b4bee7139e2dc21db/ChangeLog.md>
(we are at 4.3.0 - aiming 5.6.0)
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.
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.
So you can enable it and check if Mongoose works with it, but I'm not
sure it's the preferred path forward.
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 changes are here
<https://github.com/cesanta/mongoose/releases>. I'll try to tackle this
when I have time :-)
Regards,
Le 01/05/2023 à 03:38, Michael Geddes a écrit :
> Hey Ludovic,
>
> 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:
>
> CONFIG_MG_SSL_IF_WOLFSSL=
> CONFIG_OVMS_SC_GPL_WOLF=y
>
> Do you know what I cain by using WOLFSSL config? I'm happy to try it.
>
> //.ichael
>
> On Mon, 1 May 2023 at 03:39, Ludovic LANGE <ll-ovmsdev at lange.nom.fr>
> wrote:
>
> Thanks Mark, it's perfect.
>
> I've just reapplied the original patches from Stephen here :
> https://github.com/openvehicles/wolfssl/pull/1
>
> 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).
>
> Thanks in advance !
>
> Regards,
>
>
> Le 30/04/2023 à 10:28, Mark Webb-Johnson a écrit :
>> I think this is done. Please try, and let me know if ok for you now.
>>
>> Regards, Mark.
>>
>>> On 29 Apr 2023, at 4:44 AM, Ludovic LANGE
>>> <ll-ovmsdev at lange.nom.fr> <mailto:ll-ovmsdev at lange.nom.fr> wrote:
>>>
>>> Hi Mark,
>>>
>>> Thanks for the 2 repos.
>>>
>>> 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).
>>>
>>> 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:
>>>
>>> * Baseline:
>>> o WolfSSH 1.4.6 :
>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/885
>>> o WolfSSL : (draft in-progress, it's missing 2 patches
>>> from our repo that are needed - at least one for
>>> compilation - with v4.7.0)
>>> * Upgrades:
>>> o WolfSSH up to 1.4.10 :
>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/886
>>> + I'll prepare an upgrade to the latest but some
>>> changes are needed that I need to test on all releases.
>>> o (For WolfSSL I'll prepare the upgrade later)
>>>
>>> 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.
>>>
>>>
>>> Please note: in the WolfSSL fork the tags are missing ; could
>>> you please fetch them and push them ? Thanks in advance.
>>>
>>> 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))
>>>
>>>
>>> Thanks in advance.
>>>
>>>
>>> Regards,
>>>
>>>
>>> PS: If you have some time, and want to review my other pendings
>>> PRs:
>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse
>>> I believe they can be reviewed / applied independently should
>>> you wish so.
>>>
>>> Le 28/04/2023 à 07:37, Mark Webb-Johnson a écrit :
>>>>
>>>> I’ve forked the two wolf repos:
>>>>
>>>> * https://github.com/openvehicles/wolfssl
>>>> * https://github.com/openvehicles/wolfssh
>>>>
>>>>
>>>> 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.
>>>> Our previous wolfSSH was v1.4.6 (February 3, 2021), and wolfSSL
>>>> Release 4.7.0 (February 16, 2021). From my understanding,
>>>> WolfSSH requires the crypt parts of WolfSSL to build.
>>>>
>>>> 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.
>>>>
>>>> Could you have a try and see if that is possible?
>>>>
>>>> Regards, Mark.
>>>>
>>>>> On 26 Apr 2023, at 2:26 PM, Ludovic LANGE
>>>>> <ll-ovmsdev at lange.nom.fr> <mailto:ll-ovmsdev at lange.nom.fr> wrote:
>>>>>
>>>>> Hi Mark,
>>>>>
>>>>> 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).
>>>>>
>>>>> For the "manual" commands I'll experiment with these. I like
>>>>> the idea of having a quick remote access for troubleshooting
>>>>> purposes.
>>>>>
>>>>>
>>>>> Regarding wolf*, yes, I do think that would be the best idea -
>>>>> to have these as submodules.
>>>>>
>>>>> I intend to "relocate" those modules as subfolders of the
>>>>> component in my patches:
>>>>> components/wolfssh
>>>>> ├── CMakeLists.txt
>>>>> ├── README.md
>>>>> ├── component.mk <http://component.mk>
>>>>> └── wolfssh
>>>>> ├── ChangeLog.md
>>>>> ├── LICENSING
>>>>> ├── Makefile.am
>>>>> ├── README
>>>>> ├── ....
>>>>> ...
>>>>>
>>>>> This way, we can manage our "glue" code ( CMakeLists.txt and
>>>>> component.mk <http://component.mk> ) 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.
>>>>> Especially given that some of these external components now
>>>>> have their own CMakeLists.txt - not easily re-usable for our
>>>>> build structure.
>>>>>
>>>>> If you're OK with that, you can either:
>>>>>
>>>>> * take this opportunity to add the submodule at the target
>>>>> place - only dealing with relocating component.mk
>>>>> <http://component.mk> (you can take inspiration from my
>>>>> tree : wolfssh
>>>>> <https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental-esp-idf-build-workflow/vehicle/OVMS.V3/components/wolfssh>
>>>>> (component.mk <http://component.mk> andREADME.md) and
>>>>> wolfssl
>>>>> <https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental-esp-idf-build-workflow/vehicle/OVMS.V3/components/wolfssl>
>>>>> (component.mk <http://component.mk> andREADME.md and port/
>>>>> 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.))
>>>>> * just replace as-is, and I'll do the relocation with a PR.
>>>>> * Or if you want I can also handle the (b) and (c) parts of
>>>>> your proposal myself with a PR
>>>>>
>>>>> Let me know.
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Le 26/04/2023 à 04:10, Mark Webb-Johnson a écrit :
>>>>>> I reviewed your config, and see the issue. Quite a lot of
>>>>>> parameters to set.
>>>>>>
>>>>>> Perhaps it is sufficient to have just:
>>>>>>
>>>>>> 1. One single wireguard tunnel in configuration, with an
>>>>>> associated auto setting to automatically start it.
>>>>>> 2. A wireguiard command to bring up/down other tunnels,
>>>>>> manually specified on the command line.
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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 Open-Vehicle-Monitoring-System-3? I think candidates for
>>>>>> this approach include:
>>>>>>
>>>>>> 1. wolfssh
>>>>>> 2. wolfssl
>>>>>>
>>>>>>
>>>>>> Regards, Mark
>>>>>>
>>>>>>> On 25 Apr 2023, at 3:28 PM, Ludovic LANGE
>>>>>>> <ll-ovmsdev at lange.nom.fr> <mailto:ll-ovmsdev at lange.nom.fr>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hello Mark,
>>>>>>>
>>>>>>> Thanks for the comments. I'll see how we can manage tunnels
>>>>>>> from the cli, should be doable.
>>>>>>>
>>>>>>> Regarding the PR, here is one PR with only WireGuard support
>>>>>>> :
>>>>>>> https://github.com/llange/Open-Vehicle-Monitoring-System-3/pull/1
>>>>>>> - it's just for review, as it is from my fork to itself.
>>>>>>>
>>>>>>> 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.
>>>>>>> They are here :
>>>>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse
>>>>>>>
>>>>>>> (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, ....)
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Le 25/04/2023 à 02:49, Mark Webb-Johnson a écrit :
>>>>>>>> Really glad to see this, and thanks for working on it.
>>>>>>>>
>>>>>>>> I do think it would be useful to have many wireguard
>>>>>>>> circuits configurable.
>>>>>>>>
>>>>>>>> For my own use case, I would like to be able to bring up a
>>>>>>>> wireguard 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.
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Regards, Mark.
>>>>>>>>
>>>>>>>>> On 24 Apr 2023, at 5:35 PM, Ludovic LANGE
>>>>>>>>> <ll-ovmsdev at lange.nom.fr> <mailto:ll-ovmsdev at lange.nom.fr>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Dear list,
>>>>>>>>>
>>>>>>>>> A few months ago I created
>>>>>>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752
>>>>>>>>> to explore WireGuard VPN support ; which leaded me to add
>>>>>>>>> ESP-IDFv5 support to OVMS.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> It's now ready for comments, you can now check:
>>>>>>>>>
>>>>>>>>> * a new branch here
>>>>>>>>> https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/752-wireguard
>>>>>>>>> * a DRAFT PR here
>>>>>>>>> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/882
>>>>>>>>>
>>>>>>>>> if you want to explore and test this VPN support for OVMS.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My own use case for this feature is :
>>>>>>>>>
>>>>>>>>> * Security : I would like my module to be unreachable
>>>>>>>>> from the public Internet. This is a first step.
>>>>>>>>> * 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
>>>>>>>>> * Roaming : The idea is to have a single point of
>>>>>>>>> contact even if the module changes network, changes IP
>>>>>>>>> address, etc...
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you can have a look and give feedback (either here, or
>>>>>>>>> on the PR), especially on:
>>>>>>>>>
>>>>>>>>> * The documentation : is it enough ? properly organized
>>>>>>>>> ? should it be split ? etc...
>>>>>>>>> * The command set
>>>>>>>>> * The configuration items : what's missing ? is the
>>>>>>>>> naming OK ?
>>>>>>>>> * Other features (should I introduced events ? metrics ?)
>>>>>>>>>
>>>>>>>>> Also if you have any feature request, please share.
>>>>>>>>>
>>>>>>>>> Limitations:
>>>>>>>>>
>>>>>>>>> * Currently limited to 1 tunnel, but should work with
>>>>>>>>> multiple - it's just a question of arranging the
>>>>>>>>> configuration to support multiple instances
>>>>>>>>> * Roaming not tested yet (will report)
>>>>>>>>> * Compatibility with mobile network not tested yet (will
>>>>>>>>> need help on this)
>>>>>>>>> * 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.
>>>>>>>>> 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.
>>>>>>>>> * 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.
>>>>>>>>>
>>>>>>>>> Current status:
>>>>>>>>>
>>>>>>>>> * Builds on GitHub actions (if you can to test,
>>>>>>>>> pre-compiled firmwares are available here for example:
>>>>>>>>> https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions/runs/4784405668
>>>>>>>>> - just download a Zip file (v5.0 or v5.0.1), and flash
>>>>>>>>> with a command-line like esptool.py --chip esp32
>>>>>>>>> --port /dev/xxxx --baud 921600 write_flash --compress
>>>>>>>>> --flash_mode "dio" --flash_freq "40m" --flash_size
>>>>>>>>> detect 0x10000 ovms3.bin )
>>>>>>>>> * 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)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks for your comments.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OvmsDev mailing list
>>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230501/06b4f8e7/attachment-0001.htm>
More information about the OvmsDev
mailing list