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.