Ethereal-dev: Re: [Ethereal-dev] question about dissect protocol based on flow not the packet
On Wed, Jan 22, 2003 at 02:31:17PM -0800, Huagang XIE wrote:
> This is in a tcp flow,
That doesn't matter here. This is an issue that has nothing to do with
TCP.
> Say, the 1st record(maybe in 1 packet or mutitple
> packet) is login request packet, and the 2nd record from client is
> command request, the 3rd one is something else and the 1st record from
> server is login banner, the 2nd is command response etc. Each record
> contain a length to inditicate how long the record is. The record type
> can be identified from the sequence of the record, but not from the
> packet individul.. I just wondering if ethereal dissector can handle
> this kind of thing and how.
>
> I try to use a counter and reset it using conversation(), but it seems
> that the COL_INFO is woring well, but the TREE is not working, for it
> can not get the proper number value in the sequence.
When Ethereal (or Tethereal) reads in the capture file, the packets are
supplied to dissectors in the order in which they appear in the capture
file.
In that case, you know the sequence of the record, and can correctly
identify the record type.
The COL_INFO column is set up when the capture file is read by Ethereal,
so that's correct.
However, in Ethereal, the user can then click on packets in whatever
order they want; that's why, when you click on a packet, the dissector
can't get the sequence number.
The way to handle this would be to, when dissecting a frame, first see
if there's any data attached to the frame for your protocol, using
"p_get_proto_data()". If there isn't, use the counter from the
conversation, and attach the counter value to the frame using
"p_add_proto_data()", otherwise use the counter value from the data you
got with "p_get_proto_data()".
See, for example, packet-smtp.c - which is dissecting a protocol (that
happens to run over TCP) in which you have to know what messages came
before the current piece of data to understand how to dissect the
current piece of data (i.e., is this in command/response mode, or is it
after a DATA command but before the "."?).
