SOLVED: Udp.parsePacket() or Udp.endPacket() crashes?

Hi there!

I’ve attached a program I’m working on. I don’t know what device on my network is sending my microcontroller this message that causes it to crash, but when ever it happens my program always gets hung up in the same space. It says the packetsize is less than 0 and after that happens, my program screeches to a halt. It is like the act of even examining the packet causes the system to stop. I included the program and a copy of the output with debug lines showing exactly where it dies. If I try to stop it from doing the Udp.endPacket() by checking if the value of packetsize is less than zero, it instead crashes at Udp.parsePacket().

Does anyone have any ideas? I’d really love some help because I don’t know how to stop whatever device is sending me these messages and I want to filter them out.

Ethernet Network Starting…
This Device’s Address is: 135.126.1.55, Port: 1337
Microcontroller bootup complete!

handleInboundENET entered >
debug 1
debug 2
debug 3
debug 9
debug 10
< handleInboundENET exited <
handleInboundENET entered >
debug 1
debug 2
debug 3
debug 9
debug 10
< handleInboundENET exited <
handleInboundENET entered >
debug 1
debug 2
debug 3
debug 9
debug 10
< handleInboundENET exited <
handleInboundENET entered >
debug 1
debug 2
debug 3
debug 4
WARNING: MALFORMED PACKET ARRIVED, SIZE WAS < 0! CANCELING ANALYSIS
Size -1, Containing:
debug 5
debug 6
debug 7

experiment.ino (6.5 KB)

Can you get the ip address of the device sending the packet causing the problem? I have had a quick look into the code for parsePacket and below and can't easily work out what is happening.

It may be easier to detect what the remote machine is sending the packet and see if you determine anything from that.

It may get to the point where you want to try and determine what is in the packet being sent send by the remote machine using something like Wireshark.

countrypaul:
Can you get the ip address of the device sending the packet causing the problem?

Thanks so much for looking at this countrypaul!
Its weird! I got the system to do a serial print before it crashes and it reported the source address as 0.0.255.255?! I went ahead and disconnected all devices from the network other than my development machine and this microcontroller, and this event is still happening.
I also went ahead and got wireshark like you said and was monitoring the streams. Theres alot of weird data in here, but I don't see any UDP packets being sent to this microcontroller. I wanted to make sure I wasn't going crazy, so I plugged two microcontrollers into the network and was able to successfully send UDP and receive UDP messages from those without problems, but the microcontroller that is giving me issues was still crashing at "debug 7" while the others were talking just fine.

That to me suggests one of two obvious possibilities, either a hardware problem can you try different combinations of Arduino and Ethernet shield?, or a memory scribble where an array is being written on beyond its dimensions I can't see anything at present, however it is late and I've had a drink or 2!

Incidentally, these two lines are redundant since you have not filled packetbuffer:

    Serial.print(", Containing: ");
    Serial.println(packetBuffer);

countrypaul:
....or a memory scribble where an array is being written on beyond its dimensions

Is there a chance that an oversize message is arriving, filling up the buffer and exploding? I seta fixed size for the transmit and receive buffers. If this is what is happening, how can I keep messages that are too large, out? It is my understanding that the Udp.parsePacket() function is the one responsible for determining how big the arriving packet is, and if I can't run it to find out how big the packet is, how can I even keep large packets out? Other than just making the input buffer huge, I mean.

It depends on what buffer you are referring to.

The buffer you have in your code won't be populated until you use Udp.Read - which you don't do if the packet is too small.

I don't know how you have your arduino Ethernet shield connected or whether you read the section about physical connections in the Wireshark docs. If you have the Arduino connected to a switch and your PC connected to the same switch (the switch could be built into you router) then anything from a third party will not show up in Wireshark as the switch will optimise packet flow and only send it to the Arduino.

You say the other Micro controllers you tried did not crash. What type of micro controllers are you using, this may have an influence.

I would normally expect a UDP packet that is too large for the internal buffers to either be dropped completely or truncated. Not totally sure if that happens on the Arduino though.

Hey again countrypaul! Thanks again for looking at this, you've been super helpful :smiley:

countrypaul:
It depends on what buffer you are referring to.

The buffer you have in your code won't be populated until you use Udp.Read - which you don't do if the packet is too small.

The buffer I'm talking about is "packetBuffer" in regards to the program, a 32 character array; and you are right, the contents should not technically be analyzed (though we do attempt to read from packetBuffer and it comes up empty inside that if statement). Actually...thats a really good question...I made a ReplyBuffer variable because it was used in the demo code when this was initially set up. When I use "Udp.write" which buffer does it attempt to write to?? Could that be part of the problem? The program is exploding when it tries to do Udp.endPacket() right now, and prior to adding the catch code that checks to see if it has a negative message size, it looked like it was crashing when Udp.parsePacket() was called.

countrypaul:
You say the other Micro controllers you tried did not crash. What type of micro controllers are you using, this may have an influence.

I would normally expect a UDP packet that is too large for the internal buffers to either be dropped completely or truncated. Not totally sure if that happens on the Arduino though.

The other microcontrollers are all arduinos, running mirror copies of the UDP code you see here, but with different logic to run certain functions based on the commands it receives.

When you use Udp.write it will be using a buffer within the Udp library and not one that you have supplied.

If something has gone wrong when reading the Udp packet sent to your Arduino - and it is looking to me as though that is highly likely to be the case, then it is entirely possible that some data structure in the Udp library has been corrupted in which case Udp.endPacket, or Udp.read or virtually any Udp library function could cause the whole pack of cards to fold.

I think the question is becoming is there a hardware problem - one reason I asked about trying a different Arduino with this code, and ideally a different ethernet card. If a different Arduino with a different ethernet card shows the same issue we can probably rule out a hardware fault in your Arduino/Ethernet card combination.

We are then back to looking at whether the Udp library is failing due to a bad packet arriving - and this is where wireshark can help if you can set things up so that it sees all the packets into and out of your Arduino.

If using Wireshark is going to be too difficult, then isolating the Arduino with just the one other machine that is sending data to it would be worthwhile, in that case if there are no bad packets we can start considering a rogue source on your network. If the bad packets do come from the other machine, we can look at what possible generators on that machine could be causing the issue.

I am fairly sure the problem is not the code you have posted - but I could always be wrong.

SOLVED: The problem was a hardware failure

Countrypaul, it seems like your theory was correct! I was waiting in the mail for a replacement ethernet shield. It arrived this morning, and after quickly replacing the existing shield the errors disappeared without any code modifications. I had such great fears that it was a code problem because true hardware failures are the least likely point of failure.

The hardware that failed was a sunfounder ethernet shield that had been working for about a year. If the other shields start failing, I'll come back to the forum and inform folks, but it looks like this one just had one bad component that must have died.

Thanks again for all your help and ensuring that I could keep a grasp on my programming sanity :smiley:

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.