At 07:52 AM 9/22/00 -0500, Frank Singleton wrote:
>Hello,
>
>I was reading throught the "bxxp" example
>and saw comments like
>
><snip>
> /* 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.
> */
></snip>
>
>I generally capture all, then run dispaly filters , or sometimes
>I use display filters while capturing.
>
>Can I still do this if I implement conversations, according to the
>above comments. Or is there something else more applicable.
I have never used display filters while capturing, but did lots of testing
on capturing and then filtering and resetting and filtering again, and
finally got it fixed so there were no errors.
The approach that I think has to be taken is the following:
1. The initial pass through the packets uses a conversation to
accumulate all the info it needs during subsequent passes.
2. For each packet during the initial pass, save any info in per
packet data that cannot be easily re-computed, or which depends on
previous packets. This is required when the user jumps all over
the place.
3. On subsequent access to packets, check for per-packet/frame data
first and use that if it exists, else use what is in the
conversation and what you can dissect.
4. If a rescan occurs, it does not matter, because the conversation
stuff is blown away, as is the per-frame data, so you start over
again as if it were the first time.
Seems to work for me. In the BXXP dissector, I had to account for the
following:
- A message may be split across multple TCP segments
- A segment may contain multiple BXXP messages
It would have been great if we had segment re-assembly and the TCP layer
delivered a stream of bytes, but we don't. However, while what I have got
works, there will be situations when it will fail, like out of order
segments. Because of the nature of the protocol, however, these out of
order segments are not likely to extend very far in the packet trace.
HTH.
>Any pointers on using per-frame data ??
>
>Thanks / Frank..
>
>
>--
>EUS/SV/Z Frank Singleton ASO Americas BSS
>Office : +1 972 583 3251 ECN 800 33251
>Pager : +1 800 651 1184 Email : eusfrsi@xxxxxxxxxxxxxxx
>Amateur Radio: VK3FCS/KM5WS Email : frank.singleton@xxxxxxxxxxxx
>
>Hardware: HP Omnibook 4150 running Redhat Linux 6.2 (2.2.16 kernel).
>
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
