I have developed an application which reads data over a high volume network (2 sensors, both 1khz).
The application reads the packets for a random time, and then crashes due to - what I believe to be - a native buffer overflow.
The following image depicts the exacts packet sequence each time the crash occurs - a large Dup ACK block followed by 2 RST flags.
Am I correct in thinking that this crash occurs due to the RWIN buffer being too small, and this in turn leads to the sending sockets shutting down. Any advice or suggestions is most appreiciated.
Edit - Updated with image of sequence pre DUP-ACK
asked 04 Sep '13, 04:40
edited 04 Sep '13, 05:20
Is that just an application on top of a standard OS or are those 'embedded devices' with a their own TCP/IP stack?
That many DUP-ACK looks more than strange. I don't think that any recent OS (Windows, Linux) would send that many DUP-ACK that fast. So, I guess these are either duplicate packets (possibly a routing loop) or another problem in the TCP/IP stack.
Can you please add the following information:
BTW: is it possible to post the capture file instead of a screenshot? You can post the capture file on google docs, dropbox or cloudshark.
To me it looks like the Win7 system (your application) is not able to process the data (fast enough). In both TCP streams, the TCP window size reported by Win7 drops constantly until it reaches 0 (see tcp.stream eq 1 - it shows it pretty nicely).
The embedded system keeps sending ACKs and the Win7 finally (after a long time) closes the connection with a RESET.
So, the key to your problem is: Why does the Win7 system lower its TCP window size, i.e. why is it incapable of handling the data (fast enough).
As that is your own application, the only way to understand that behavior is by debugging the application. Maybe the application does not receive the data it is expecting and your program logic waits for the correct data, until the TCP receive buffers are full.
answered 04 Sep '13, 06:14
Kurt Knochner ♦
edited 06 Sep '13, 02:49
I see only one RST; the others belong to a different connection (with the IP .108 instead of .106). But from that long long long list of Duplicate ACKs I can tell that something is going very wrong, and I guess your application has trouble with packet loss and recovery. There is no way to tell what stopped the sending process because it is not in the screenshot - the screenshot only tells the end of the story. It would be helpful to see how the Duplicate ACK series got started.
answered 04 Sep '13, 04:57