[Ovmsdev] Request For Comments - Wireguard VPN
Ludovic LANGE
ll-ovmsdev at lange.nom.fr
Sat Apr 29 04:44:38 HKT 2023
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>
>> 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
>> └── wolfssh
>> ├── ChangeLog.md
>> ├── LICENSING
>> ├── Makefile.am
>> ├── README
>> ├── ....
>> ...
>>
>> This way, we can manage our "glue" code ( CMakeLists.txt and
>> 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 (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 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 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>
>>>> 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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230428/c4d36d17/attachment-0001.htm>
More information about the OvmsDev
mailing list