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.
