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="1"/>
<Match url="2"/>
<Ma
*** Packet 2 ***
tch url="3"/>
</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 <[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'?>
> <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 <[email protected]>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:[email protected]?subject=unsubscribe
>
___________________________________________________________________________
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
