I am writing a dissector for a UDP protocol with the following (rather unfortunate) features:
In practice, this means that some assembly must be done before it is even possible to determine how much assembly will be needed to complete a PDU.
I have approached this by using the various tools in reassemble.h. However, I am getting stuck in a few places, and am looking for suggestions.
My dissector essentially looks like this (pseudocode):
Mostly, I am hung up on how to add fragments properly. I would like to be able to read part of a packet, add any portion of that from a fragmented PDU into the table, and continue looping through. As I read more PDUs out of that packet, I add fragments, marked complete, for those into the table. The last PDU would likely be incomplete, and added as well.
It appears that the fragment table is expecting a single add operation per packet. Is there a correct way to keep track of fragments when there may be multiple per packet?
asked 11 Aug '11, 12:27
From the looks of it your protocol is screwed up. UDP is an unreliable datagram protocol, hence does not guarantee delivery, nor sequence. Once an inconsistency occurs your dissector (and any receiver for that matter) will get out of sync.
Maybe the RTP dissector can be of help, it also runs over UDP, and contains reassembly code. Although I think it has the benefit of sequence numbers.
answered 12 Aug '11, 01:38
OK, so let's look at the protocol's (mis-)features:
That means you need to have some way of knowing when the PDU ends, i.e. when you're done with reassembly.
That means you need to have some way of knowing when the header ends.
Again, you need to know when the PDU ends, even if the entire PDU is within one UDP datagram.
OK, that presumably means the length tells you when the PDU ends. If the delimiter is variable-length, there has to be some way of knowing when the delimiter ends; what is that?
Which, as Jaap noted, means that the receiver has to assume that the packets are delivered in order, and, if they're not, it won't work correctly, so, if Wireshark doesn't reassemble the packets "correctly" in that case, it's actually correct in the sense that it'll show you what a receiver that got the UDP packets in the same order will think it got, even if that's not what the sender intended it to see.
That's similar to many protocols running atop TCP, so that's not inherently insoluble. You might have to implement something similar to