Reassembly and broken fragments
- My protocol consists of small variable-length structures (which I'll call "commands"). Each command contains a field indicating its length. Frequently, commands are sent individually, so one TCP packet contains one command. Sometimes, however, numerous commands may be sent in a single TCP packet, and sometimes one command can be split over two TCP packets, so I see something like this:PKT 1:len1 data1 len2 data2 len3 (part of data3)PKT 2:(rest of data3)My original parser just described one command, so PKT 1 is shown as containing a single command (the rest is marked as TCP.UnhandledTCPData), and PKT 2 is shown as being corrupt. Then I added a "while [FrameOffset < FrameLength]" loop around the whole thing - now PKT 1 has 3 commands, though part of the third one is missing, but PKT 2 is still corrupt.I believe I have to use the reassembly facility to deal with this, and I found some videos here but the video on reassembly seemed to imply that this was used when one fragment was broken up into multiple TCP packets, and my problem is kind of the other way around.How can my parser deal with this?
All Replies
My guess here is that TCP is streaming your protocol and abritrarily deciding where to break the traffic. Our parsers are limited in these cases and dependent on the TCP stack to set the push bit when a completed payload occurs. However, TCP is a streaming protocol so this is only a heuristic we use reassemble data. If you push the Reassembly button in the UI, and all the packets you are interested in are instered in a complete PayloadHeader frame, then your While loop approach should consume all the data.
However, I'm thinking you probably already tried this. And when you did, the data was still separated into multiple PayloadHeader frames. This being the case, you are limited as we can't handle streamed protocols when the TCP heuristic doesn't work.
The only way around this is to use the NMAPI to manually put together the streamed fragments and then reparse that data to show you the entire frames. You could alternatively process the information and save it back out to a .cap file if you wanted to.
Paul
