netif can block on sendto()
Posted: Fri Mar 20, 2020 12:43 pm
Using wired Ethernet with DHCPS capabilities:
Connect to PC via a switch. Switch the switch off.
Boot the ESP and start the netif stack in the usual way.
Next use sendto() to send some messages (I have attached to the ESP_LOG vprintf() and broadcast to UDP and so sendto() the boot log).
The sendto() call will quickly hang the calling 'main' task.
I also created a couple of timer tasks. One timer task attempts to restart DHCPS:
This timer task hangs on esp_netif_dhcps_stop() call once sendto() has hung.
The second timer task just regularly printf() to prove that the ESP32 was still running.
Powering the switch on does not clear.
Note that I have not seen this behaviour with DHCPC. The behaviour seems exclusively to be connected to DHCPS and possibly AUTOUP.
This is a major use/case but I cannot find a way of detecting and/or recovering. Wired Ethernet is optional in my system and so I cannot just reboot if sending fails.
EDIT: v4.1-dev-2079-g5dbabae9d
Code: Select all
.flags = ESP_NETIF_DHCP_SERVER | ESP_NETIF_FLAG_AUTOUP,
Boot the ESP and start the netif stack in the usual way.
Next use sendto() to send some messages (I have attached to the ESP_LOG vprintf() and broadcast to UDP and so sendto() the boot log).
The sendto() call will quickly hang the calling 'main' task.
I also created a couple of timer tasks. One timer task attempts to restart DHCPS:
Code: Select all
esp_netif_dhcps_stop()
esp_netif_set_ip_info()
esp_netif_dhcps_start()
The second timer task just regularly printf() to prove that the ESP32 was still running.
Powering the switch on does not clear.
Note that I have not seen this behaviour with DHCPC. The behaviour seems exclusively to be connected to DHCPS and possibly AUTOUP.
This is a major use/case but I cannot find a way of detecting and/or recovering. Wired Ethernet is optional in my system and so I cannot just reboot if sending fails.
EDIT: v4.1-dev-2079-g5dbabae9d