Wireshark · Ethereal-dev: Re: [ethereal-dev] Should "Follow TCP Stream" filter the display or not?

[Guy Harris <guy@xxxxxxxxxx>]

> Both Gilbert and I have been thinking about this; Gilbert sent out mail
> about this a while ago, discussing an approach that I think was similar
> to the one you're suggesting,

Here are some of the mail messages he's sent out about this (check out
the full threads for more on the topic):

Message-ID: <19990402222527.A2134@xxxxxxxxxx>
Date: Fri, 2 Apr 1999 22:25:27 -0600
From: Gilbert Ramirez <gramirez@xxxxxxxxxx>
To: ethereal-dev@xxxxxxxx
Subject: Re: [ethereal-dev] Standards in decode routines

On Sat, Apr 03, 1999 at 11:20:47AM +0900, Richard Sharpe wrote:
> Hi folks,
> 
> I have insinuated my way onto the team by contributing code and promising
> to contribute more :-) At some stage I am going to have to add my name to
> the list of contributors on the help screen :-) 

Make it so.

> I am starting to wonder if we have any standards around information
> presented by the various decode routines. I am looking for some guidelines,
> and don't mind being part of the solution (ie, coming up with guidelines if
> they are needed). Are there any guidelines? As I am looking more and more
> at TCP level protocols (like SMTP, DNS Zone Transfers, SSH, Telnet, etc),
> it may be that there is a need for such guidelines.

There are no guidelines. Ethereal has been evolving. We have mostly
stayed away from the protocols that are stacked above the
session-oriented transports (TCP, SPX) because of the difficulty of
matching packets of fragmented TCP write()s. Guy has some good ideas on
how to fix this.

What I'd like to do in regards to this is to have an "unfragment"  mode
in ethereal. When used, multiple packets that are known to be part of a
single TCP transmision (write()) will be coalesced together. The packet
summary line will be two lines high. The first line will be the decoding
of the packet (once you put all the packets together for a single TCP
write(), you can send that entire buffer to the next higher layer,
dissect_http() or whatever). The second line will contain a drop-down
list of the individiual frames that make up this TCP write(). If you
select one of these frames, a window pops up showing you the protocol
tree and hex dump of that single frame.

As far as guidelines, I have begun writing a small tutorial on how to
write dissect() routines. It's not yet complete; I wasn't going to show
it until it was ready, but since you asked.... I plan to go into more
detail on how to create the packet summary line, how to associate fields
in the protocol tree with byte ranges in the hex dump, and how to use
the various utility routines in ethereal (ip_to_strval, etc). If anyone
wants to add some paragraphs, please send me the additions! (or wait
until its in CVS)

> THINGS ABOUT ETHEREAL I HAVE A PROBLEM WITH
> 
> 1. It does not presently handle enough protocols. I am contributing towards
> fixing this, as are many others.

Perhaps this tutorial will help with that.

--gilbert

	[tutorial elided]

Date: Mon, 17 May 1999 21:48:03 -0500
From: Gilbert Ramirez <gram@xxxxxxxxxx>
To: ethereal-dev@xxxxxxxx
Subject: Re: [ethereal-dev] SMB decoding and generating decoders
Message-ID: <19990517214803.A13908@xxxxxxxxxx>

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