On Tue, Mar 26, 2002 at 11:21:32AM +0000, Phil Williams wrote:
> In order to achieve this, I need to check every packet in the capture,
> to see if it is TCP, if so, then I would like to collect some
> statistics, initially:
> The header length of the TCP header
> The length of the TCP payload
> The TCP sequence number
> The TCP acknowledgement number
>
>
> As you tell me that this is all stored within a tree structure, I need to
> get some understanding of this. I am not sure where I should be looking
> in the code, as it is quite vast.
>
> > > - does pfd within the frame_data struct tell me what protocol a packet is
> >
> > No.
> What does this point to? Is it the protocol data tree?
No. It points to a list of data items that particular dissectors may
have associated with a frame, so that the frame can be correctly
dissected the next time it's looked at. As
1) some dissectors may have to maintain state during the
first-pass scan through all the packets;
2) those dissectors may require the value of that state when the
packet was dissected in order to dissect it correctly;
3) if you click on a packet in the packet list, there is no
guarantee that you have clicked on all previous packets, in
sequence, so there is no guarantee that the state will be
correct if kept as a global variable or a per-conversation
variable;
those dissectors would need to attach the frame a data structure holding
enough state to dissect the packet correctly.
Those data items contain
1) the protocol ID number of the protocol that added them;
2) a pointer to data that's specific to the dissector for that
protocol, and known only to the dissector of that protocol.
It is not anything you would need.
If your statistics-computing code were similar to the current
statistics-computing code, it would have code with a loop similar to the
one in "ph_stats_new()" in "proto_hier_stats.c".
The "process_frame()" routine in that file is the routine to process a
single frame. It calls "process_tree()" to get statistical information
from the protocol tree, the root node of which is pointed to by
"edt->tree", where "edt" is a pointer to the "epan_dissect_t" structure
allocated by "epan_dissect_new()" and filled in with dissected_packet
information by "epan_dissect_run()".
"process_tree()" looks at all the top-level children of the root node;
those are the nodes for the items that are displayed as the topmost
items when you click on a packet, and correspond to the protocols in the
frame.
You would want to have similar code, except that the equivalent of
"process_node()" would check whether the node handed to it was for the
TCP protocol and, if so, scan its children looking for the fields with
the information in question, and extract their values.
Unfortunately, there's currently no way to look for a "header_field_info"
structure by field name, so you can't just look up "tcp" (for the TCP
protocol) to get a pointer to compare with "finfo->hfinfo" in your
routine, nor can you look up:
"tcp.hdr_len" header length of the TCP header
"tcp.seq" TCP sequence number
"tcp.ack" TCP acknowledgment number
"tcp.flags.ack" TRUE if ACK is set, FALSE otherwise
nor could you look up "ip" for the IP protocol, "ip.hdr_len" to get the
IP header length, or "ip.len" to get the IP total length - there is
nothing in the TCP tree to give the length of the TCP payload, so you'd
have to look for the IP header as well, and compute the TCP payload
length from the IP header and total length and the TCP header length.
Note also that there may be more than one layer of IP, due to various
forms of tunneling, so you'd have to get the IP header right *before*
the TCP header to get the right IP header.
We could probably introduce routines to do by-name lookups (and probably
should, to make it possible to do things such as this); they probably
won't be in the next Ethereal release, however (as that will be coming
out soon), so you'd have to use the CVS version of Ethereal once those
routines are checked in (there's no official timeline for this, nor is
there an official commitment to add them), or wait for the release in
which they appear (see previous parenthetical note), or be the person to
introduce those routines (which might well speed up their arrival).
