networking: add support for WireGuard VPN #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
llange
force-pushed
the
752-wireguard
branch
2 times, most recently
from
502b69a
to
f3f4801
Compare
…efault Vehicle - Fix up default generation of dashboard configuration
Ioniq5 Fixes v0.0.5
…-5-mbdetls-3.3.0 ESP-IDFv5.0.1+ - deprecated function in Mbed-TLS 3.3.0+
…wolfssh compatibility with WolfSSH >= 1.4.12
Upgrade wolfssh 1.4.13
…ade-wolfssh-1.4.13 Revert "Upgrade wolfssh 1.4.13"
…atibility-recent-wolfssh Revert "compatibility with WolfSSH >= 1.4.12"
Some warnings were raised during documentation build and have been fixed. Signed-off-by: Ludovic LANGE <[email protected]>
fix a few documentation issues
First argument is <host[:port]>. If port omitted, it is set to `3000`. Signed-off-by: Ludovic LANGE <[email protected]>
wolfssl has been forked (https://github.com/openvehicles/wolfssl) and the subdirectory converted to a Git submodule. Additionally, it has been put one directory level below (in vehicle/OVMS.V3/components/wolfssl/wolfssl) to better separate the upstream code from our build glue (component.mk, CMakeLists.txt and configuration files) This way it's easier to track any changes made to the module, upgrade when upstram changes, or propose patches to upstream. We kept the existing version (v4.7.0-stable) - it will be upgraded later Signed-off-by: Ludovic LANGE <[email protected]>
…dule convert wolfssl to a git submodule
In ESP-IDF 3.3.x builds of OVMS, we're using a fork of ESP-IDF. In this fork, FreeRTOS has been patched with openvehicles/esp-idf@95e43fc to add a `uxMutexesHeld` field in `TaskStatus_t`. However, in the ESP-IDF >= 4 build we're using mainstream ESP-IDF (for the moment), which does not include this field. So we adapt the display to handle both cases. Signed-off-by: Ludovic LANGE <[email protected]>
…uxmutexesheld ESP-IDF v4+: we do not have uxMutexesHeld any more
`xt_set_error_handler_callback` is only available in our ESP-IDF 3.3.4 fork. For ESP-IDF >= 4, we implement it a little bit differently by using the linker wrap feature, which let us execute our handler before `esp_panic_handler()`. Signed-off-by: Ludovic LANGE <[email protected]>
`esp_task_wdt_get_trigger_tasknames()` was a custom patch of our ESP-IDF 3.3.4 fork. It is used to list the names of the task(s) responsible for triggering the WDT, and this information is saved in the (persistent) boot_data structure for post-crash analysis. Unfortunately it's not available on upstream ESP-IDF 4+. For the moment we remove the feature, until we find a way to implement it without patching ESP-IDF 4+. Signed-off-by: Ludovic LANGE <[email protected]>
…ata.crash_data` XTensa and RISC V have differences, and `boot_data.crash_data` being low-level is exposed to these differences. We try to handle the CPU registers dump for both architectures. However backtrace is not handled (yet) for RISC V. Signed-off-by: Ludovic LANGE <[email protected]>
ESP-IDF4+ : crash handler and boot status
When converting to CMake builds, we had difficulties in finding a way to properly set (define) some constants at build time (defines that are setting the modification time of embedded files). Commit 7657068 was a partial solution, which was working but had a few shortcomings: * It was modifying the standard build (ESP-IDF 3.3.4) * It triggered at each build a full cmake reconfigure, which was very annoying * It introduced a new header file, and a new helper script. With more experience, we finally found a way to make it work 'the cmake way', so we can now revert our previous approach - and put back the previous build system as it was before (with CPPFLAGS defines) Signed-off-by: Ludovic LANGE <[email protected]>
Trip consumption
replace StartStopChargeT26 charge with SetChargeCurrent where appropriate improve init values fix updating profile0 values on boot add wakeup_success fix abort wakeup on running profile0 command fix wakeup failing due to missing heartbeat reduce semaphore wait times safeguard against workaround current lingering only start/stop profile0_timer (don't create/delete) check for plugstate on charge start and climate control on battery, add notifications test 100ms blocking time in timer stop & delete
fix resetting current limit when ConfigChanged is called w/o climit value changed fix prevent timeout after retries have exceeded add drive mode lever position prevent climatecontrol when lever not in "P" clean up checks before charge/climate commands
Small updates to Nissan Leaf Documentation
VWEUP: rework climate contol, add charge control
fix cell voltage offset
Fasttech is not a distributor of OVMS any more since a longer time but still listed here.
add options to set custom poll times for Cell Voltage
….3 (openvehicles#987) * Update README.md - update description to represent hardware version 3.3
VWUP: changes.txt & bugfix
Signed-off-by: Ludovic LANGE <[email protected]>
Signed-off-by: Ludovic LANGE <[email protected]>
This VPN allows your OVMS module to "connect" itself to your own private network, make it visible and reachable, whatever the connexion it is using (WiFi, Mobile, ...) (Note: 3G untested at the moment) It should also (unverified) be able to roam from one connexion to the other, or even among different WiFi networks, without any specific setting to do. A documentation has been added. (Note: The schematics, drawn with [draw.io](https://get.diagrams.net/) is embedded in the resulting PNG file, so you can open the PNG file with the editor to edit the diagram. Please keep it that way (by checking the 'Include a copy of my diagram' check box)) Support for wireguard on ESP provided by https://github.com/trombik/esp_wireguard , cf https://github.com/trombik/esp_wireguard/blob/main/LICENSE Cf openvehicles#752 Signed-off-by: Ludovic LANGE <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This VPN allows your OVMS module to "connect" itself to your own private network, make it visible and reachable, whatever the connexion it is using (WiFi, Mobile, ...)
(Note: 3G untested at the moment)
It should also (unverified) be able to roam from one connexion to the other, or even among different WiFi networks, without any specific setting to do.
A documentation has been added. (Note: The schematics, drawn with draw.io is embedded in the resulting PNG file, so you can open the PNG file with the editor to edit the diagram. Please keep it that way (by checking the 'Include a copy of my diagram' check box))
Support for wireguard on ESP provided by https://github.com/trombik/esp_wireguard, cf https://github.com/trombik/esp_wireguard/blob/main/LICENSE
Cf openvehicles#752