The proto I'm decoding can be over UDP or TCP, and multiple msgs can be in a given UDP/TCP packet. I'm able to detect when my msg overflows into the next packet, and I can successfully manipulate the pinfo.desegment_len and pinfo.desegment_offset vars to have the decoding of the following packet start in the correct place. However, the dissector for the last msg (the fragmented one at the end of the packet) doesn't get called since I return out when I don't have enough bytes for a complete msg. Is it possible to 'bring' the remaining bytes from the next packet in and continue? Or should the beginning of the next packet try to reference the previous packet and start from there? I can see the decoded bytes are correctly appended in the reassembled TCP segments tree of the second packet. I feel like I am super close, but can't seal the deal. :( As a side question, how does one generally determine the desegment_offset? I have a hard-coded value of 66 set to account for the ip/tcp header info in the frame. However, that wouldn't work so well if this was a UDP packet. Is there a method to get the beginning of 'user data'? I'm doing this in Lua. asked 27 Feb '11, 13:00  TalleyHo |
One Answer:
Given that the messages in your protocol have a length field early in the message, the best way to handle your protocol over TCP is to have its dissector call tcp_dissect_pdus(); let tcp_dissect_pdus() manipulate desegment_len and desegment_offset for you. See the doc/README.developer file (or, if you're using Windows, docREADME.developer :-)) for details on using tcp_dissect_pdus(). tcp_dissect_pdus() also handles the case of multiple messages per TCP segment for you, so you don't have to do that, either. I suspect your protocol does not support messages that cross UDP packet boundaries, as UDP, unlike TCP, makes no guarantee of in-order delivery of packets, so you would need to have your own fragment sequence numbers (the "id" field is per-message, not per-fragment, so it won't suffice). When dissecting your messages over UDP, the dissector would have to handle the "multiple messages per UDP datagram" case itself. For this, you would probably want a routine to dissect a single message, pass that as the "dissect a PDU" routine to tcp_dissect_pdus() in the dissector for your-protocol-over-TCP, and call it in the loop in the dissector for your-protocol-over-UDP. answered 01 Mar '11, 05:14  Guy Harris ♦♦ Inside the data is a msgId header, so I can verify order of delivery. I've not seen any reference to the tcp_dissect_pdus() functions in the Lua API? Are those also available from Lua? It was my impression that was only from C. For the cost of easy portability, I can live w/ a few boundary issues like this one. But your answer makes sense to what I was thinking. I guess reading it a second time (also from the Readme) it sunk in further. (01 Mar '11, 06:04) TalleyHo You can verify order of delivery of messages, but not of parts of messages. If a message is split across UDP packet boundaries into parts that aren't separate messages, you won't even be able to recognize anything other than the first part as being a part of a message, much less verify order of delivery. (I'd give an example, but that'd take more than the limit on the number of characters in a comment; if you want to discuss that further, ask about it on the wireshark-dev mailing list.) (01 Mar '11, 14:21) Guy Harris ♦♦ I don't see any reference to tcp_dissect_pdus() in the source files in the epan/wslua directory, so it's probably not available from Lua. File a bug to request that. To do what you want to do, you would, for now, be best advised to duplicate in your Lua dissector all the stuff that tcp_dissect_pdus() does. (01 Mar '11, 14:24) Guy Harris ♦♦ |
For UDP:
Can a message for your protocol cross a UDP packet boundary, or is all of a message contained within one UDP packet?
For TCP:
What determines the message boundaries in your protocol? For example, do messages have a message length field in the beginning of the packet?
Guy, The message length is determined by the 2nd/3rd bytes of the message. So I have [id][len][data][checksum] ...
In the TCP trace that spans I have...
[id][len][data][checksum] [id][len][data][checksum] ... [id][len][da ...packet break... ta][checksum]
In the decode tree, all of the complete msgs are present in the first packet. The split packet is not decoded. It's like I need a higher layer dissector to accumulate the packet.
I've been told its possible that UDP can span packets, although I've yet to see it. All our msgs are relatively short, multiple msgs/packet are likely.