Hello,
Check out packet-aim.c. In particular, look at the differences between
1.21 and 1.20. I had what I believe to have been the same problem, and
Guy Harris corrected it with the patch found in 1.21. The code change
he made allows dissection of multiple payloads within a single TCP
packet.
http://www.ethereal.com/cgi-bin/viewcvs.cgi/ethereal/packet-aim.c?sortby=date
-Devin
On Wed, 2003-01-22 at 09:55, William Mulvihill wrote:
> Hi,
> First off, I'm extremely happy with the power and simplicity of making
> dissectors and plugins with Ethereal. It has been very simple to get
> into the API and work with it. A big thanks to all the developers.
>
> My question is this. I've got a protocol where each packets payload
> (after IP headers, UDP headers, and the protocols headers) can contain
> any of 86 different packet types. On top of that, each payload can
> contain multiple instances of different packet types. So you've got:
>
> Internet Headers (Ethernet, IP, UDP, etc) ->
> Protocol Headers ->
> payload ->
> packet type #34
> packet type #56
> etc. etc.
>
> Now due to the ease of the Ethereal API, I've been able to easily
> interpret all these packets in the protocol and display the packet types
> in the Column INFO. That is nice, but it would be lovely if I could
> have every single packet within the packet interpreted fully (like down
> in the middle pane in the tree). Now each packet type has its own
> fields, as many as 70-80 per packet type (a lot of tedious work, but
> worth it). So I've got a growing list of hf_proto_fieldname declarations.
>
> What I humbly ask this community is how do I interpret each one of those
> packet types inside the packet without having a list of
> hf_proto_fieldname1, hf_proto_fieldname2 going up to the maximum number
> of packets in the packet. I'm already leaning towards having a tree for
> every packet (so like Packet 1, Packet 2, etc are each their own tree
> that have their own fully interpreted packets). But if I reuse the
> hf_proto_fieldnames for each tree (each packet within the packet),
> aren't I going to get in trouble somewhere down the road?
>
> I have a half-formed idea about arrays or something like that, but I'm
> not sure that would help. Has anyone done anything similar? You could
> point me to a packet-xxx.c for an example of how someone dealt with
> that. Thank you very much.
>
> -Will Mulvihill
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc
