Hi,
At 11:42 PM 8/21/00 -0700, Guy Harris wrote:
>On Tue, Aug 22, 2000 at 02:21:29PM +0900, Richard Sharpe wrote:
>> Why are we doing a conversation_init in rescan_packets?
>
>Because I added a call to "conversation_init()" in "colorize_packets()"
>in revision 1.120 of "file.c", and that was carried along.
>
>The comment for the checkin is:
[Deletia]
> Have the ONC RPC "init" routine zero out the table of RPC calls,
> so that it completely erases any state from the previous
> dissection pass (so that, for example, if you run a filtering
> pass, it doesn't mark any non-duplicate packets as duplicates
> because it remembers them from the previous pass).
>
>The third paragraph suggests that there is currently one reason why we
>*do* have to call "protocol_init()" in "rescan_packets()".
[Deletia]
>This is the problem for which I infer you created the mechanism for
>hanging per-protocol data off of the frame_data structure for a packet -
>remember the stuff that the dissector figured out on the initial
>sequential pass, so that it can retrieve that information when the
>packet is next dissected, without having to reconstruct that
>information, as correctly figuring that information out may be possible
>only during a sequential pass.
OK, in the SMTP protocol, I only need to hang info off of the frames that
contain a mail message. I had hoped to stick info in the conversation that
allowed me to figure out the right things on the first pass and then not
have to figure this out again.
It may be, however, if I think carefully about it that I can use the
visited flag for each field as well.
Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx
Samba (Team member, www.samba.org), Ethereal (Team member, www.zing.org)
Contributing author, SAMS Teach Yourself Samba in 24 Hours
Author, Special Edition, Using Samba