I tried to write some simple code to send just one UDP packet after connecting to a WiFi AP and waiting for the IP addess being assigned, following example code. But I noticed that the first ‘sendto’, while giving no error but the full length of the packet as a result, produced no packet at all at the listening machine in the local network.

I checked this with netcat and socat as listeners on a host in the local network and, of course, first with a netcat / socat client to verify the listener is running and working well. I also fetched all local network traffic as a wireshark trace directly from my router, to be sure.

Of course, I assumed a mistake on my side first. So I got the ESP-IDF 5.4 UDP client example code and configured it for my WiFi AP and the destination host. This example is a bit cumbersome to analyze the problem, but from the first try it was obvious that the first UDP packet was not being sent by this example code neither (without any way to detect the failure from the code).

To provide an easy way to reproduce this, I minimized the code to opening a UDP socket, sending a couple of packets, closing the socket, and repeat that procedure endlessly. I renamed the ‘udp_client.c’ to ‘udpclient.cpp’ to safely and easily construct the packet data from a string. I formatted the packet content to contain an incrementing counter that starts at ‘0’ after socker creation. The first packet received on the listener side is always ‘1’, though. After the first shutting down and re-creating the socket, we also see the ‘0’ packet and none is lost anymore.

When I just start the listener and send a UDP packet using netcat / socat from a linux machine, this very first UDP packet is immediatly received.

Also, I can add some code for name resolution before opening the UDP socket the first time and that succeeds without problem, though it doesn't change the fact that the first packet sent via UDP is actually not sent.

On the listener side, I ran

socat STDIO UDP4-LISTEN:7801,reuseaddr,fork

To give some context: I am planning to send a simple NTP message and receiving the answer, to set the system clock to some roughly correct time after cold boot. I tried to use the ESP-IDF SNTP library, but that one always takes 30 seconds to synchronize, with no rational explanation and despite removing that ‘random initial wait’ option. On any Linux machine I can use a CLI command to query time from an NTP server (from pool.ntp.org..) and it gives an answer immediately. So, maybe this unreasonable long SNTP delay is actually related to this UDP bug, where the first NTP message is never really sent and so the library waits until some timeout and even increases the retry interval for the next attempt, according to the NTP protocol.