Ethereal-dev: Re: [Ethereal-dev] help with broken-up messages running atop TCP?

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Thu, 1 May 2003 15:51:46 -0700
On Thu, May 01, 2003 at 12:00:15PM -0400, nak26 wrote:
> I wrote a dissector for messages running atop TCP.
> Some messages are quite large so they get broken up and sent in subsequent 
> packets. So when my dissector encounters these subsequent packets (meaning the 
> remaining handoff-ed from the tcp dissector data) it is clueless about the 
> data.
> 
> Is there something that I could do to handle these situations
> properly?

Possibly, depending on how the size of your messages are specified.

Many binary protocols running atop TCP have a header, early in the
message, that specifies the size of the message (it might include the
size of everything including the header, it might include the size of
everything after the header, it might give a message type from which the
header size can be inferred, etc.).

For those protocols, you can usually use the "tcp_dissect_pdus()"
routine, which takes, as arguments:

	the tvbuff for the TCP segment being dissected;

	the pinfo value for the packet;

	the protocol tree pointer for the packet;

	a Boolean value that's TRUE if packets split between TCP
	segments should be reassembled and FALSE if they shouldn't be
	reassembled (this is typically a user-configurable preference
	variable);

	the number of bytes of header needed in order to get the data
	that tells you how big the message is;

	a pointer to a routine that's handed a tvbuff pointer and an
	offset in that tvbuff, where the offset is the offset of the
	beginning of a header, and returns the total size of the packet
	based on the data in the header (total size *including* the
	header!);

	a pointer to a routine to dissect a single message for your
	protocol, which gets handed the usual arguments for a dissector
	function - the tvbuff starts at the beginning of the message.

See, for example, "packet-dns.c".