netif can block on sendto()

[PeterR]

Using wired Ethernet with DHCPS capabilities:

Code: Select all

        .flags = ESP_NETIF_DHCP_SERVER | ESP_NETIF_FLAG_AUTOUP,   

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:

Code: Select all

esp_netif_dhcps_stop()
esp_netif_set_ip_info()
esp_netif_dhcps_start()

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

[ESP_Sprite]

Sounds like something undesireable indeed.. can I ask you to create an issue on our Github page for this so we can track this better?

[PeterR]

Sure, yes. I am looking for some comfort here (have schedules) can you confirm? Its easy to replicate and seems to be strongly linked to AUTOUP and possibly PHY/MAC initialisation.
I don't want to dig that deep on a stack & especially as also DHCPS seems broke on assumption of one DHCP per product, can I not have a DHCP per each interface? If not then netif seems a bit of a solo hand movement. Why not just use Lwip applications? I digress.
I hacked user level a bit and think maybe I can mask the issue if I dont log (UDP sendto()) whilst/during/before DHCPS allocates. After allocation life seems cool but maybe there are collisions to be found.
Unfortunatey I now have other client MMI diversions so may be a week+ before I am back on this.
If you can make this happen/register/review then awesume!
PS Taking a meta view, where do you guys publish story/feature objectives? Seems certain that 3.x was/is mostly client (e.g. AWIS) based. I need servers. How do I tune into that enhancement schedule & progress? I understand that 4.x is not 'production' but take's a whole product. Take a finer grained view. Otherwuise it all or nothing & we all oose faith!

[ESP_Sprite]

In general, it gets decided on what our customers want, our internal decisions to pro-actively fortify some bits of our product, as well as things we hear in the community. That's one of the reasons I asked you to create a Github issue; it also indicates to us people are using the device in the way you do, giving us a better picture on what we need to do to keep everyone happy.