Wireshark-dev: Re: [Wireshark-dev] Get follwing Packets in a protocol dissector
From: Jan-Niklas Meier <[email protected]>
Date: Mon, 15 Feb 2010 16:26:39 +0100
Thanks for your answer!
You are right. A message in my protocol looks like you showed below (except for the xml declaration which we do not use). There is a set of possible root elements (called envelopes) like for example <Req/> and <Rsp/>. They can contain higher elements like commands or data. I do not know how long the message will be or how much elements it contains. The only chance i have is to check if the XML is valid (all opened tags are closed).
An example could look like:

*** Packet 1 ***
<Rsp id="12">
    <Match url="">    <Match url="">    <Ma
*** Packet 2 ***
tch url="">   </List>

I read about the function tcp_dissect_pdus() you described but i don't quite get how this works. possibly my knowledge about TCP is a bit limited ;-). generally qeueing of packets and dissecting them in the end sounds like a good method but i can't see how to start with this. Do you know a protocol which is using this in a way i try to?
I also checked the xml dissector when i began with my project and found it not quite useful for me.

with kind regards
Jan-Niklas Meier

2010/2/15 Guy Harris <[email protected]>

On Feb 14, 2010, at 11:48 PM, Jan-Niklas Meier wrote:

> I am currently working on a protocol dissector for a protocol, which is based on XML. The protocol is spoken inside a TCP stream. I am using the libxml to parse single requests and responses. I choose libxml because i want to check, if the XML is valid and because i need to parse the protocol quite deep. this works very well for normal requests and responses which are usually only one packet long (so the XML is valid and i can parse it). if there is for example a very long request it is splitted into different packets and the xml in the first packet is invalid (because all the closing tags are missing). in the following packets i can't even regognize that this is my protocol because they don't start with my header.
> I searched the documentation and some other dissectors, if there is a mechanism to request the following packets of a tcp stream from wireshark to be able to parse the whole request. I was not able to find something on this topic (request/response tracking is not quite what i want) so i'd like to ask here now. I would be happy about some suggestions how i could solve this problem or shouldn't i do something like this?

There's no mechanism by which a dissector can request that following packets be delivered to it now - for one thing, there's no guarantee that those packets even exist, and, if you're doing a live capture, they might exist in the future, but you don't know when.

There *is*, however, a mechanism by which a dissector for a protocol running atop TCP (or SSL/TLS) can request that the data it's dissecting be combined with future data, if that becomes available, and that the accumulated data be handed to the dissector.  The underlying mechanism is a bit complicated to use, but

       1) if your protocol's packets are always at least N bytes long, and you can determine how long the packet is by looking at the first N bytes, you can use tcp_dissect_pdus() - that's used with a lot of protocols, which typically have a binary encoding, but *probably* won't work with your protocol as it's described;

       2) if not, there might be another protocol whose dissector you can use as an example.

Presumably, in your protocol, a "packet" looks something like

       <?xml version="1.0" encoding='UTF-8'?>

               assorted XML


If so, we can probably either find a dissector to use as an example, or indicate how to handle this.  There is an XML dissector, but it doesn't appear to include anything that would help in this case.
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:[email protected]?subject=unsubscribe