UDP Crash with versions above 2.5.2 #6831
Comments
|
Do you "server" the UDP related code with regular intervals? |
|
@SvenSiwek the issue template you filled out requires an MCVE. Without that there isn't much we can do. |
devyte
added
the
waiting for feedback
|
Okay I found out what MCVE means. I ll provide one. It would be fine if you explain what OP means, which I have to edit. My English is not that good, and as I wrote I am new to this. |
|
Original Post |
Hmm that sounds like "lots of traffic" and "large packets". |
|
You are processing packets once per loop. You also have delay(100) in the loop. That effectively limits you to 10 packets per second. If you send faster than that, the esp will accumulate them, run out of mem, and crash. |
|
Also, you're reading at most 1024 bytes into the buffer. If the packet is bigger, there are remaining bytes unread. |
|
Why do you close this? This ist not an user error. You're really doing it very easy. If I send too many packets too fast, that's my problem. The nodemcu must therefore not crash. If she loses packages that's okay. I checked my MCVE against 2.5.2 which works as expected without any crash. So I will stick to that version. Thank you for taking my time. Sven |
|
I closed because I still don't see a core issue. That does not mean end of discussion. As for 2.5.1, it would intermittently lose incoming packets independently of receiving speed, and that was addressed. If you don't want to process all incoming, it is your responsibility to receive and discard unwanted packets, because there is no way to differentiate between your use case of unwanted packets and somebody else who wants to maximize reception. |
|
Hi, If you arent interested in finding the cause of that, than it is that way, For me its pretty easy. I generate an udp stream of packets on the server side. But this packet stream should not crash the device - under no circumstances. So, too much udp packets in a to short timerange crashes the device. That is core. Sven |
|
@SvenSiwek Please read his reply again. Maybe you can change the function in your code to read the entire packet (read until packet length is processed) and also not waiting for 100 msec every loop. |
|
Hi, the goal, at last for me was, to provide a MCVE, which I did. If a bug fix results in somewhat like a possible DoS it is not a good one. To the root of that : I have combined both in a sketch and it works fine - just up to version 2.5.2. Now there was the update to 2.6.1 and higher. The Visualization-Server sends UDP light instructions to the ESP. Always 4 bytes. The first byte Addresses the number of the LED. The other three bytes are RGB color values. The source code has remained pretty much the same. Translated with Google |
I debugged this more: It is not a memory problem visible to the sketch #include <ESP8266WiFi.h>
#include <WiFiUdp.h>
// Wi-Fi network to connect to (if not in AP mode)
char* ssid = "XXXXXXXXX";
char* password = "XX";
WiFiUDP port;
// Maximum number of packets to hold in the buffer.
#define BUFFER_LEN 2048
char packetBuffer[ BUFFER_LEN + 1];
IPAddress mc_groupIP = IPAddress(233, 233, 233, 233);
unsigned int mc_localUdpPort = 4711; // local port to listen on
int len;
void setup() {
WiFi.setSleepMode(WIFI_NONE_SLEEP);
Serial.begin(115200);
delay(100);
Serial.setDebugOutput(true);
WiFi.mode(WIFI_STA);
Serial.printf("Connecting to %s\n", ssid);
if (String(WiFi.SSID()) != String(ssid)) {
WiFi.begin(ssid, password);
}
while (WiFi.status() != WL_CONNECTED) {
Serial.print('.');
delay(500);
}
Serial.println("Listening UDP");
port.beginMulticast(WiFi.localIP(), mc_groupIP, mc_localUdpPort);
}
void loop() {
// put your main code here, to run repeatedly:
int packetSize = port.parsePacket();
// If packets have been received, interpret the command
if (packetSize) {
Serial.print("P");
Serial.println(packetSize);
// Read data over socket
len = port.read(packetBuffer, BUFFER_LEN);
Serial.print("L");
Serial.println(len);
}
}The only thing this sketch does is println... And here is the result: |
|
Your stack trace is personal, only you can decode it. Thanks, we need to reproduce the issue to fix it. Do you have any idea of the packet frequency ? |
d-a-v
added
component: network
type: troubleshooting
and removed
waiting for feedback
|
To explain I use that python mentioned above. I do have 150Led * 4 Byte * 60Hz. ~ 36.000Bytes/s max. I will test with lower Hz. 0x40204699: loop() at D:\Users\svens\Documents\Arduino\udp_kaputt/udp_kaputt.ino line 69 Line 69 int packetSize = port.parsePacket(); And a second one Decoding stack results |
|
To explain what I do. Playing a song on my PC with this python( It's always the same song to reproduce the error - Carol of The Bells by Tommee Profitt ). Tested with 30Hz sending. It almost made it, but: Decoding stack results |
|
Whoops: 25Hz: Decoding stack results And an other one: Decoding stack results |
|
There is a debug option called OOM while true; do echo hey; done | nc -u 10.0.1.225 8888I got on console the following (see below). I think we should have some sanity barrier for largest umm free chunk block to not be crossed by the core when possible (here we'd drop the incoming flooding packets) (so the FW does not fail like it is the case here according to the :oom messages not coming from us). The thing is it has a cost to (re)process the largest free block (or the total free heap). |
|
More interestingly, I replaced |
|
@SvenSiwek Now that is a good MCVE. It might even serve as a device test. Alright, we've been discussing internally, here's a summary. Possible Solutions:
|
|
|
Hi there :) If I wanted to be sure to receive all packets I have to use TCP/IP . So, please forgive me ... I do not understand the whole buffering concept here. If you still want buffering - make it transparent to the sketch: You can determine size of that buffer in the sketch and what should happen if the buffer is full. One single question: If I understood you right, an interal buffer was flooded. I never saw a value > 500 in the output of my MCVE have a nice weekend |
|
The buffer keeps multiple packets. So it is not a buffer issue for a single packet. |
the penny dropped |
The network stack receives data while your sketch is doing something else, so packet data need to be buffered until sketches ask for them.
It already is
I'm not sure this kind of setting is good on the arduino side. The same question was asked for serial data. What to do when the input buffer is full?, and the answer was not clear (currently new data are discarded when buffer is full).
Because you see the oldest first. |
|
By buffer I really mean a packet list. |
In the loop() call a lot is written to serial port. |
|
@d-a-v Sorry for the delay. I cannot see a low-cost way to do that. Any largest chunk of memory you have cached can shrink through having additional new allocations carved from it until it is smaller than one of the other free blocks that were not in your large free list cache. |
Basic Infos
Platform
Settings in IDE
Problem Description
I am pretty new to this all. So please be polite with me.
I do have a working sketch with version 2.5.2.
I updated to 2.6.1
The WEMOS does reboot after a certain time (10 to 15 seconds) with heavy ingoing udp traffic.
I downgraded to 2.6.0
The WEMOS does reboot after a certain time (10 to 15 seconds) with heavy ingoing udp traffic.
I downgraded to 2.5.2
The WEMOS does work as expected.
Since I am pretty new to this all (NodeEMU etc),
is there a "how to" to provide you with additional infos - if needed?
I am willing to help...
Sven
On Linux do
$ cat /dev/random | netcat -u 172.16.178.41 7777Result:
The text was updated successfully, but these errors were encountered: