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).
Powered by MHonArc 2.6.10