crash wtih esp-idf 5.x, or master #33
Comments
|
upstream issue: espressif/esp-idf#9643 |
|
this issue can be resolved by rewriting |
|
Can also confirm a similar crash exists for esp8266-rtos-sdk: Can be reproduced by launching the wireguard tunnel as per examples/demo but also starting an HTTP server and then closing it and afterwards trying to close wireguard. It causes the system to fail at the above. |
|
would you tell me which version or git tag of the SDK you are using? |
Not perfectly sure, I'm thinking it's v3.4. I'm pulling the latest revision of this docker image: https://hub.docker.com/r/mbenabda/esp8266-rtos-sdk (Because I couldn't get the SDK to work on NixOS itself) |
Also further discovery: If ANY accept() request is ran in-between of wireguard context being loaded and closed, a similar crash would occur. I hope that narrows the bug quite a bit. |
|
the issue you are seeing is not the one in this issue. would you open new issue? |
|
sure |
|
Is there any progression on the esp-idf v5.0 implementation ? |
|
I found out that the problem is from the parameters ip_info and ip_info_old, which has the value of 0 during the call of the function esp_netif_internal_dhcpc_cb(). However I don't know how to set those parameters correctly in the netif interface structure. |
none. you are on your own to fix it, or support us. |
|
I went a bit deeper to try to debug this issue, and found the following: The crash happens because this callback "esp_netif_internal_dhcpc_cb" gets called after the call to netif_add which is part of the initialization of esp_wireguard. The code for that callback resides inside of esp-idf-v5.0/components/esp_netif/lwip/esp_netif_lwip.c Here is the beginning: static void esp_netif_internal_dhcpc_cb(struct netif *netif)
{
esp_netif_t *esp_netif;
ESP_LOGD(TAG, "%s lwip-netif:%p", __func__, netif);
if (netif == NULL || (esp_netif = lwip_get_esp_netif(netif)) == NULL) {
// internal pointer hasn't been configured yet (probably in the interface init_fn())
return;
}
esp_netif_ip_info_t *ip_info = esp_netif->ip_info;
esp_netif_ip_info_t *ip_info_old = esp_netif->ip_info_old;The trick is that lwip_get_esp_netif(netif) should notice that this lwip netif struct does not have a corresponding esp_netif structure. But that doesn't happen because the check works like this: (From esp_netif_lwip.c) static inline esp_netif_t* lwip_get_esp_netif(struct netif *netif)
{
#if LWIP_ESP_NETIF_DATA
return (esp_netif_t*)netif_get_client_data(netif, lwip_netif_client_id);
#else
return (esp_netif_t*)netif->state;
#endif
}So here we see that in the normal case (LWIP_ESP_NETIF_DATA is 0) this function simply returns the content of netif->state. esp_wireguard stores its own pointer there to hold some configuration, so it is not empty. Because of that, in esp_netif_internal_dhcpc_cb it is assumed that it got a pointer to a esp_netif structure, and it tries to access the member data ip_info and ip_info_old, which is not there, and the program panics. There is a simple fix to get esp_wireguard working on ESP-IDF v5.0.2: The easiest is to see what sets LWIP_ESP_NETIF_DATA, which stops using netif->state to hold the pointer to the esp_netif associated structure to the lwip netif one, and instead uses netif_get_client_data and netif_set_client_data, which stores the info somewhere else. That variable is set here components/lwip/port/esp32/include/lwipopts.h #if defined(CONFIG_ESP_NETIF_BRIDGE_EN) || defined(CONFIG_LWIP_PPP_SUPPORT)
/*
* If special lwip interfaces (like bridge, ppp) enabled
* `netif->state` is used internally and we must store esp-netif ptr
* in `netif->client_data`
*/
#define LWIP_ESP_NETIF_DATA (1)
#else
#define LWIP_ESP_NETIF_DATA (0)
#endifSo if we activate CONFIG_ESP_NETIF_BRIDGE_EN or CONFIG_LWIP_PPP_SUPPORT in idf.py menuconfig, it will fix the problem. For a test, I tried activating "Enable PPP support (new/experimental)" (Name: LWIP_PPP_SUPPORT), and it works. So in short, activate CONFIG_LWIP_PPP_SUPPORT in your project configuration in ESP-IDF-v5, recompile your project, and the wireguard tunnel will work as intended. |
The text was updated successfully, but these errors were encountered: