Ethereal-dev: Re: [Ethereal-dev] Accessing low level protocol's info

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Wed, 28 Aug 2002 03:31:53 -0700
On Wed, Aug 28, 2002 at 09:44:27AM +0530, Sureshkumar Manimuthu wrote:
> 	I am new to ethereal.
> 	I am developing a protocol dissector which runs atop http.
> 	I need to get some information from the low level dissectors 
> 	( like sequence number from TCP layer )
> 	is there any function provided by the etherial framework or by
> 	the TCP dissector for getting these ?

There is no general framework to allow an arbitrary dissector to get
arbitrary information from arbitrary lower-level dissectors.

There is a mechanism by which a dissector for a protocol running
directly atop TCP can get, for the data supplied to that dissector (which
is *NOT* necessarily a single TCP segment, if TCP reassembly is
supported by that dissector and is enabled):

	the sequence number of the first byte of data;

	an indication of whether the data is just a TCP segment or is
	reassembled data;

	an indication of whether the urgent pointer is set and, if it
	is, the 16-bit value of the urgent pointer.

Dissectors are passed a pointer to a "packet_info" structure; in a
dissector called directly from TCP, the "private_data" member of that
structure points to a "struct tcpinfo", as declared in "packet-tcp.h".

The HTTP dissector could then be changed to use that sequence number and
compute the sequence number of the first byte of HTTP *payload* (which
is presumably what is being passed to your protocol dissector), and pass
that to sub-dissectors in *another* structure (which would be a local
variable in "dissect_http()") by setting "pinfo->private_data" to point
to *that* structure before calling "dissector_try_port()" and
"dissector_try_heuristic()".

You would have to modify the HTTP dissector to do that.

Note that there is no guarantee that the HTTP dissector won't, in the
future, set "pinfo->private_data" to point to its own structure, so
having your sub-dissector rely on "pinfo->private_data" pointing to the
TCP dissector's "struct tcpinfo" is not necessarily going to work.  It
also would mean that you would get the TCP sequence number of the first
byte of data handed to the HTTP dissector, which, in the first TCP
segment of a reply, be the first byte of the HTTP *reply header*, not
the first byte of the HTTP payload.