Panic in AsyncTCP due to sudden WiFi disconnection

[hosseinaghaie]

IDE / Tooling

Arduino (IDE/CLI)

What happened?

Description
I'm encountering a panic in AsyncTCP (version 3.3.5) when the WiFi connection is suddenly lost during an active TCP session. The issue seems related to the tcp_sent function in lwIP and occurs intermittently when the connection is dropped unexpectedly.

I've used AsyncTCP in multiple functions across my project (including both HTTP requests and MQTT connections). Eventually, I was forced to replace those functions with esp-idf esp_http_client to prevent the panic. After switching to esp-idf's native client, the panic no longer occurred.

The environment is extremely noisy, and the network connection frequently drops due to interference. It feels like the DNS resolution fails or becomes unresponsive at times, but regardless of the cause, the device panics and resets.

Even though I check WiFi status (WiFi.status()) and use flags (onEvent SYSTEM_EVENT_STA_GOT_IP) to ensure the connection is stable before sending data, the panic still happens occasionally during the transmission process when the connection drops unexpectedly.

Additional Information:
The environment is noisy, and the network connection is highly unstable.
DNS resolution seems to fail or become unresponsive at times, which might contribute to the issue.
I tested the WiFi connection status (WiFi.status()) before sending data and used event handlers (onEvent SYSTEM_EVENT_STA_GOT_IP) to set flags for connection status.
Despite these checks, the panic still occurs intermittently during data transmission if the connection is lost mid-process.
After replacing AsyncTCP with esp_http_client from esp-idf, the problem disappeared completely.
This happens with both AsyncTCP and AsyncMqttClient.

this code work in other device (other location)) but in thsi location painic ocuure 4-5 times a day!

System Information
Board: ESP32-S3
ESP32 Arduino Core: 2.3.4
AsyncTCP Version: 3.3.5
ESP-IDF Version: 3.1.2

Stack Trace

PC: 0x40376711 0x4037670E 0x4037E0CD 0x40384D59 0x420629E7 0x42020C6E 0x42020CA4 0x42020FEE 0x42021023 0x4037EE16
0x00000000: ?? ??:0
0x40376711: panic_abort at esp_system/panic.c:463
0x4037670e: panic_abort at esp_system/panic.c:463
0x4037e0cd: esp_system_abort at esp_system_chip.c:92
0x40384d59: __assert_func at assert.c:80
0x420629e7: tcp_sent at lwip/src/core/tcp.c:2076 (discriminator 1)
0x42020c6e: AsyncClient::_error(signed char) at AsyncTCP.cpp:1055
0x42020ca4: AsyncClient::_s_error(void*, signed char) at AsyncTCP.cpp:1503
0x42020fee: _handle_async_event(lwip_tcp_event_packet_t*) at AsyncTCP.cpp:271
0x42021023: _async_service_task(void*) at AsyncTCP.cpp:294
0x4037ee16: vPortTaskWrapper at port.c:139

Minimal Reproductible Example (MRE)

test.txt

I confirm that:

• I have read the documentation.
• I have searched for similar discussions.
• I have searched for similar issues.
• I have looked at the examples.
• I have upgraded to the lasted version of AsyncTCP.

[mathieucarbou]

@me-no-dev @vortigont : the failure happens in:

void AsyncClient::_error(int8_t err) {
  if (_pcb) {
    TCP_MUTEX_LOCK();
    tcp_arg(_pcb, NULL);
    if (_pcb->state == LISTEN) {
      tcp_sent(_pcb, NULL);
      tcp_recv(_pcb, NULL);
      tcp_err(_pcb, NULL);
      tcp_poll(_pcb, NULL, 0);
    }
    TCP_MUTEX_UNLOCK();
    _free_closed_slot();
    _pcb = NULL;
  }
  if (_error_cb) {
    _error_cb(_error_cb_arg, this, err);
  }
  if (_discard_cb) {
    _discard_cb(_discard_cb_arg, this);
  }
}

when tcp_sent(_pcb, NULL); is called.

the problem is that the lwip layer crashes so we have no way to act on that.
If we went there, then pcb was non null and also in listen state.
plus, we are in the lock.

edit:

lwip source code:

https://github.com/espressif/esp-lwip/blob/392707e5c3a5d8e2531461db77843b9759cd5a43/src/core/tcp.c#L2076

[mathieucarbou]

@hosseinaghaie : could you please test this branch ?

https://github.com/ESP32Async/AsyncTCP/tree/issue-30

I have sent a PR for a (maybe) fix at #31

Thanks!

[hosseinaghaie]

@mathieucarbou

I appreciate your efforts in addressing this issue. Unfortunately, due to recurring panics in high-interference environments, I was forced to migrate my code to use ESP-IDF's native functions for both MQTT and HTTP POST.

MQTT → Migrated to esp-mqtt (esp_mqtt_client_init(), esp_mqtt_client_start())
HTTP POST → Migrated to esp_http_client (esp_http_client_init(), esp_http_client_perform())
However, I will test your proposed changes and provide feedback. Since only one of our devices consistently encounters severe connection issues, I will compare the behavior of both your fix and ESP-IDF's libraries under the same conditions.

I'll share my results soon. Thanks again for your work!

Best regards,

[hosseinaghaie]

Oops! I accidentally closed this issue. 😅

I didn't mean to close it—I appreciate the fix and will test it soon.
If needed, I can reopen the issue after testing to provide feedback.

Thanks again for your support!