I’m using a port of the Wiznet ioLibrary driver (from here: https://github.com/Wiznet/ioLibrary_Driver), running on a Cypress PSoC.
When receiving a UDP packet (actually a DHCP packet) in the socket.c function recvfrom I’m encountering a scenario where the header is corrupt (or the RX pointer is pointing to something that is not the head of the message). In any case the result is that the pack_len is some random number depending on what point of the packet it happens to land. In my case that random number is very big, which of course is larger than the buffer I’m writing to and therefore destroys a bunch of memory and crashes the application.
One solution is to implement the packet length check that’s eluded to in the comment immediately before reading the RX buffer that says “//Need to packet length check” (or check if the IP and port in the header are valid) but that raises 2 questions:
If I run that test what do we do if we encounter and invalid value, there’s no way to flush the buffer and start over and if I read the entire buffer I risk never getting the pointer back to the head of the UDP message.
How could this be happening in the first place? This library is pretty old and presumably used by others so I’d be surprised if something like this had been missed if it happened frequently.
For what it’s worth this only happens when I’m running an application that handles a large number of TCP packets on a different socket and even then it only happens after a few minutes/hours of runtime, so it’s inconsistent. The DHCP packets only come in every minute or so, is it possible that something else is actually stomping on the RX pointer or RX buffer (in the W5500) for this socket?