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?
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
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 settingTARGET_IP
inpc-tester.py
(which is run from PC), and settingSSID
andPASSWORD
innotifications.py
(which should be uploaded to mpy) to see the difference (you may also want to comment thewifi.ifconfig(...)
line if using dynamic IP.Notice the timestamps in the picture. For
wrong.png
, the timestamps are way too close, even thoughpc-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 payloadfoo
. 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?