Thanks, I'll take a look at yours and thanks to Guy Harris for
reassuring me it would be fine to reuse the fields.
I had some troubles with the column info until I realized that I could
simply parse the entire packet and THEN set the INFO section by using a
temporary string variable. That is, append or insert all your stuff
onto the string variable and then at the end of the dissector, just set
the column INFO to that end result string.
Of course, you might say it would be waste to parse the entire packet
for the column info, but you could check if your dissector has a tree
(like in the README.developer) and then if it DOES NOT (which happens
when it loads the packet dump initially), you could just quickly parse
your multiple headers and set the column INFO at the end.
Caveat: This idea was formulated without having looked deeply at the
packet-sctp.c and may not fit in with the way things are programmed.
-Will Mulvihill
Michael Tuexen wrote:
Hi,
SCTP (packet-sctp.c) often has multiple uppler layer information
within one packet. I'm coding the upper layer in a way that the stuff
in the INFO columns is appended. However, the protocol column is a
problem. The entry shown corresponds to the highest layer of the
last DATA chunk. The point is that often one SCTP packet contains
multiple different upper layers. I have not found a good way yet to
deal with it.
Best regards
Michael
On Wednesday, Jan 22, 2003, at 15:55 Europe/Berlin, 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
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
