Wireguard on ESP32-C3 with Tasmota 15.0.1: wgconnect fails #23877
Answered
by
s-hadinger
GEAG
asked this question in
Support request
|
Tasmota firmware 15.0.1 compiled with #define USE_WIREGUARD (and the appropriate MCU configured):
Seems to already have been confirmed in this discussion. Is this an issue with Arduino Core for ESP32-C3? |
Answered by
s-hadinger
Jan 18, 2026
Replies: 5 comments 7 replies
|
Here is an exception with its stack trace from an ESP32-C3, when trying to invoke wgconnect (the same code compiled for and run on an ESP32 does not produce such an exception): |
3 replies
|
To better analyze this issue, I traced the execution into the lwIP stack. The sequence starts with |
|
... and same behavior with an ESP32-C6. |
|
please try latest development. The sha Hardware routines have been refactored. |
|
No luck! What I did:
|
2 replies
|
I confirm the problem found by GEAG. |
|
SensorsIot has provided a workaround to avoid these exceptions with the ESP C series. Here is a possible integration into Tasmota's
|
|
Thanks a lot everybody, solution confirmed for release 15.0.1
I tried to apply the same workaround to rel. 15.1.0 and rel. 15.2.0 but it
doesn't work, in these cases the restart exception message is different:
16:57:00.700 RSL: INFO3 =
{"Info3":{"RestartReason":{"Exception":1,"Reason":"Instruction access
fault","EPC":"a5a5a5a4","EXCVADDR":"a5a5a5a4","CallChain":["420c7ac6","42234d45","41504922","41303a37","42234d45"]},"BootCount":82}}
As of now I'll stick to rel15.0.1, to me a working WG means a lot because I
can safely reach my tasmota devices when I'm out of my private network.
Thanks again.
Fabrizio
…On Mon, 29 Dec 2025 at 18:38, GEAG ***@***.***> wrote:
SensorsIot <https://github.com/SensorsIot> has provided a workaround
<trombik/esp_wireguard#59> to avoid these
exceptions with the ESP C series.
Here is a possible integration into Tasmota's
lib/lib_ssl/esp_wireguard-Tasmota/src/esp_wireguard.cpp of the above
solution:
#ifdef CONFIG_IDF_TARGET_ESP32C3 || CONFIG_IDF_TARGET_ESP32C6
// Create netif with zero IP to avoid crash
const ip_addr_t zero_ip = IPADDR4_INIT_BYTES(0, 0, 0, 0);
const ip_addr_t zero_mask = IPADDR4_INIT_BYTES(0, 0, 0, 0);
wg_netif = netif_add(
&wg_netif_struct,
ip_2_ip4(&zero_ip),
ip_2_ip4(&zero_mask),
ip_2_ip4(&gateway),
&wg, &wireguardif_init,
&ip_input);
// Set real IP via direct assignment (netif_set_addr also crashes)
ip4_addr_copy(wg_netif->ip_addr.u_addr.ip4, *ip_2_ip4(&config->address2));
ip4_addr_copy(wg_netif->netmask.u_addr.ip4, *ip_2_ip4(&config->netmask2));
ip4_addr_copy(wg_netif->gw.u_addr.ip4, *ip_2_ip4(&gateway));
#else // NOT ( CONFIG_IDF_TARGET_ESP32C3 || CONFIG_IDF_TARGET_ESP32C6)
wg_netif = netif_add(
&wg_netif_struct,
ip_2_ip4(&config->address2),
ip_2_ip4(&config->netmask2),
ip_2_ip4(&gateway),
&wg, &wireguardif_init,
&ip_input);
#endif
wgConnect didn't cash anymore on a ESP32C3 with Tasmota 15.0.1.
—
Reply to this email directly, view it on GitHub
<#23877 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BLFBPTAE54GSRY2FJ2APXJD4EFRHXAVCNFSM6AAAAACFZC7VY2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZWHEYDCNQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
0 replies
|
It is now fixed in #24356 |
2 replies
|
Thanks for the fix. But unfortunately, its operation is only free of blocking side-effecs, as long as the Wifi connection is rock-solid without any interruptions of service. Operations tested with Tasmota up to v15.5.0 On intermittent outages of the Wifi connection, unavailability of the Wifi Router for some time (or RSSI of < -80 dBm), a wireguard config with autostart=1 is, after a while of operation, able to provoke the following side-effects of the Tasmota device:
After a restart of Tasmota on the device (reset button or power cycle) , everything returns to normal operation. Since USB-CDC access on ESP32-C3 to the CLI has not been reliably during normal operation (without a reset or power cycle) no further information about Tasmota's internal state is available so far. With the wireguard.conf setting autostart=0 and after the execution of the wgstop command, the same device works flawlessly without any noticeable reconnection problems after temporary wifi AP unavailability or a weak RSSI. From this observation we might guess, that there is an issue with the wirguard implementation loosing dynamically memory for TCP descriptors during Wifi unavailability periods. With MQTT/TLS, we have remarked another potential issue for long (multiple hours) periods of Wifi unavailability, that might be the same source to the problem. An investigation through Claude (by Gerhard) came to the following conclusion:
|
Answer selected by
s-hadinger
|
A firmware update over a Wireguard connection and the Tasmota webUI has not been successful. The device didn't reconnect on the WG VPN. The reason seams to be, that WG VPN is not available in safeboot-mode (that's ok). But fortunately, the MQTT/TLS connection is still available, which makes the device recoverable by sending the "restart 3" command over MQTT to the device. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It is now fixed in #24356