Arduino Exosite library rxdata buffer overflow


Hi all
It seems to me that the Exosite library writeRead() function for the Arduino is weak with rxdata buffer overflow issues. I am no software developer whiz so haven’t worked out the best way to robustly fix the problem yet. I think the while loop that transfers characters from the client to the rxdata buffer needs another AND condition to stop the loop when stringPos reaches the end of the rxdata buffer. I have observed situations simultaneously with Wireshark and the Atmel Studio IDE debugger where the rxdata buffer overflows with normal chaos ensuing because other variables get overwritten. With the usual TCP packet loss and retransmissions, sometimes Exosite responses to the Arduino device get retransmitted such that more than one respone arrives at the Arduino device immediately one after the other and flood the rxdata buffer. It quite happliy overwites stuff including critical things like the Arduino millis() counter until the sketch crashes completely.



Hello Keith,

Thanks for bringing this up. It looks like you’re totally right, there aren’t any checks for buffer length there. I’m probably not going to have time to properly test and publish this for a couple weeks, but I made some updates in a branch called ‘bufferoverflowissue’ that I think should at least prevent it from crashing and just result in an error message. You’re welcome to try it out, but just know that I have done literally no testing on those changes other than checking that it compiles.

That actually sounds like a bug in the TCP client/stack. (In addition to the bug in our library.) The TCP level stuff should take care of all deduplication and reordering before handing the data over to the application layer. What network device and TCP Client library are you using?


Hi Patrick
Network device is a Freetronics Ethermega 2560 v3.0 (Arduino Mega2560 clone with onboard Wiznet Ethernet controller).
TCP/IP library is from Arduino IDE v1.6.5. Every now and again among the responses were 400 and 409 responses which puzzled me because I never saw any out going traffic from my device that should have caused these. (That’s not to say my device didn’t send a bad request - just that I didn’t spot any.) In a perfect world there would have only been 204 responses.


Hi Patrick
Thanks for the library updates. I have installed these in one of two identical devices so will let them run side by side and see how it behaves.

After running these two identical devices side by side for almost 24 hours the traffic condition that caused the buffer overflow has occured once. The device with the updated library code kept running correctly but the device with the old code showed symptoms of the buffer overflow.