Ethereal-dev: Re: [ethereal-dev] SMB decoding and generating decoders

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

From: Gilbert Ramirez <gram@xxxxxxxxxx>
Date: Mon, 17 May 1999 21:48:03 -0500
On Sun, May 16, 1999 at 05:58:11AM -0500, Richard Sharpe wrote:
> 
> One of the big problems I have at the moment, however, is handling SMBs
> that are longer than a single segment ...
> 
> What you get is:
> 
>      Segment 1: TCP Header, NEtBIOS Header, SMB Header
>      Segment 2: TCP Header, continuation ...
>      Segment 3: TCP Header, continuation ...
>        ....
>      Segment n: TCP Header, Last part ...
>      Segment n+1: TCP Header, NeBIOS header etc

What if Ethereal has 2 view modes, "physical packet" versus "logical
transmission". Before I had described this as a 'coalesced' mode in
which multiple TCP packets are grouped together and translated
together. The user could switch between the two modes dynamically.

"Physical packet" mode is the way ethereal works currently; each
packet is dissected one by one.

In "logical transmission" mode, the multiple packets of a single
transmission are grouped together. In "logical transmission" mode,
some packets are still a single tranmission (like a BOOTP broadcast). In
the table of packets, these packets would maintain their datalink
types (DLT_FDDI, WTAP_ETHERNET, whatever). But the packets that have
been grouped together get a different 'datalink' type, say LOG_TCP,
LOG_SPX, LOG_IP, or whatever the layer at which the packets are
grouped together is.

Then the data from the group of packets, which might included the
header from the first packet to give us information like TCP port, is
sent to a new routine, logical_tcp, e.g. which is very similar to
dissect_tcp, but it doesn't print sequence numbers and information
that is relevent to each individual packet. It only prints information
relevant to the group of packets as a whole (like TCP port).
Dissect_tcp() and logical_tcp() can share the same code that
determines which is the next layer to call, dissect_nbt().

In the protocol tree, a routine like logical_tcp() would print out a
tree item like:
	TCP connect()
or	TCP send()
or	TCP close()

Under this tree item would be the next layer, like NBT. We shouldn't
have to modify dissect_nbt() to deal properly with the larger "packet"
sent to it by logical_tcp().

The main problem I see is not keeping track of which packets form a
logical transmission, but grouping the data in each of those packets
together so that the dissect() routines as they are written won't have
to be changed. The dissect() routines grab the data from the u_char
pd[] array, so the easiest solution is to copy all the data from the group
of packets into one buffer so that the data from one packet would be
adjacent to the data of the next packet.

Are there better solutions?

--gilbert