Ethereal-dev: Re: [ethereal-dev] [sharpe@xxxxxxxxxxxx: [ethereal-cvs] cvs commit: ethereal pa

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

From: Richard Sharpe <sharpe@xxxxxxxxxx>
Date: Sat, 09 Sep 2000 14:02:36 +0900
At 02:37 AM 9/8/00 -0400, Gilbert Ramirez wrote:
>This comment in packet-bxxp.c:
>
>  /* If we have per frame data, use that, else, we must be on the first
>   * pass, so we figure it out on the first pass.
>   *
>   * Since we can't stash info away in a conversation (as they are
>   * removed during a filter operation, and we can't rely on the visited
>   * flag, as that is set to 0 during a filter, we must save per-frame
>   * data for each frame. However, we only need it for requests. Responses
>   * are easy to manage.
>   */
>
>is no longer true. (Remember that long thread we had...)
>
>During a filter operation, filter_packets() calls
>rescan_packets() with redissect == FALSE. That flag is what controls
>the removal of state information and resetting of the visited flag:

Well, the comment is slightly wrong, as it was copied from another
dissector, but I have found that the easiest way to handle these things is:

  If we have per-frame data, use that to display the packet
  Else
    Create the association if needed

    If this packet has data that is needed in later packets, record it in 
    the association.

    If this packet should have info recorded that would not be available
    if someone was doing random packet displays, record it in the 
    per packet data.

By doing the above, we get per-packet data only on those packets that need
it, and if it is all blown away, it will be regenerated when a rescan is done.

I have little need, I think, for the visited flag.

>--gilbert
>

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