Wireshark · Wireshark-dev: Re: [Wireshark-dev] Get follwing Packets in a protocol dissector

[Jan-Niklas Meier <dschanoeh@xxxxxxxxxxxxxx>]

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">
  <List>
    <Match url="">    <Match url="">    <Ma
*** Packet 2 ***
tch url="">
  </List>
</Rsp>

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 <guy@xxxxxxxxxxxx>

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'?>
       <openingtag>

               assorted XML

       </openingtag>

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 <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe