esp32 UDP socket bind()/recvfrom(): incoming empty packet crashes the system
I'm using the following image:
MicroPython v1.20.0-206-g33b403dfb-kaki5 on 2023-07-11; ESP32 CAMERA w/SSL (KAKI5) with ESP32 on an AiThinker ESP32-CAM.
When listening for incoming UDP packets, if the packet has a payload, everything works normally. If the packet is empty, instead of blocking, the receive loop begins looping very fast, receiving a bogus empty packet every time, which locks up the system.
Un-/comment MESSAGE="" after properly setting TARGET_IP in pc-tester.py (which is run from PC), and setting SSID and PASSWORD in notifications.py (which should be uploaded to mpy) to see the difference (you may also want to comment the wifi.ifconfig(...) line if using dynamic IP.
Notice the timestamps in the picture. For wrong.png, the timestamps are way too close, even though pc-tester.py is only sending once per second. The top picture is the wrong case, the bottom one is the correct case, when the udp packet has the payload foo. In the wrong case, the IP and port are then also reported incorrectly.
Is this a bug, or am I not paying attention to some quirk?
ESP8266 v1.18 Unreliable UDP Receiving From Broadcast Address (ex 192.168.1.255)
Anyone else having issues receiving UDP packets? I can send 10-20 packets and only receive one packet. I send them with another esp or with my computer and can see the packets in Wireshark but hardly any are received with the 8266. It seems to be substantially worse when I send to the broadcast (ex 192.168.1.255) vs directly to the esp IP address. Should I be using a multicast address instead? Not sure what the differences are.
socket = socket(AF_INET, SOCK_DGRAM)
socket.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
socket.bind(('', 1011))
socket.setblocking(False)
while True:
try:
data, addr = self.socket.recvfrom(1024)
print('Recv Data From %s' % str(addr))
except OSError as err:
if err.args[0] != 11:
print(err)
This appears to be related to my discussion post. In my case the recvfrom worked as expected but the readinto exhibited the symptoms you reported. This was on a pico w.
readinto issue post
Curt