Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] Help: Question

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

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Sun, 4 Mar 2001 11:47:53 -0800
On Sun, Mar 04, 2001 at 05:23:17PM +0100, Guillaume Le Malet wrote:
> I've got a little question:
> Is it possible to go from a TCP data field to the next one (in an
> other datagram) in the same function of a packet dissector.
> 
> (hope my sentence is understandable).

Unfortunately, I'm not certain what you're asking.  For example, I'm not
sure what you mean by "TCP data field" or "the next one".

Currently, Ethereal does not assemble multiple frames into higher-level
packets, and doesn't provide any help (other than composite tvbuffs) for
dissectors that would do that.

The "TCP data fields", in the sense of fields in the TCP header, for a
given TCP segment would almost certainly all be in the same frame - I
would be extremely surprised if a TCP implementation sent out a TCP
segment in a fragmented datagram with the fragments so small that the
TCP header wouldn't fit entirely in the first fragment.

So, whilst Ethereal's IP dissector doesn't currently reassemble
fragmented IP datagrams, that shouldn't matter for dissecting the TCP
header, so, if "TCP data field" means "field in the TCP header" and "the
next one" means "the next field in a TCP header after a given field in
the TCP header", then the answer to the question is "no, but there
shouldn't be a need to do that".

If by "TCP data field" you're referring to a field in *another* protocol
that runs atop TCP, then there's still no convenient way to do it -
dissectors are given one frame at a time.  A dissector would have to
somehow, on the first pass through a capture, remember which frames make
up higher-level packets, and reassemble them itself, in order to go from
one field to "the next one" (in the sense of "the next field in the
protocol running *above* TCP) in another datagram (in the sense of "the
next TCP segment").