That's awesome to hear that you can ignore packets you've already
visited. I'm definitely going to add this to my dissector.
The reason I wanted to use sequence numbers was to determine if the
packet I'm looking at was the first packet from the server. But now I
don't need to know it since your suggestions fixes my problem.
Thanks,
------------------
Saad Nader
Middlware Engineer
Powered By Gamespy
-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Bill Meier
Sent: Thursday, September 10, 2009 7:50 AM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] How to handle TCP protocols that have don't
includestate in the message
Saad Nader wrote:
>
> I have a protocol that has very little if not any state information in
> each message that I send or receive as a client. There is also
> encryption going on from one direction (e.g. server -> client). I
have
> trouble when I'm keep state in a conversation since the encryption
> algorithm relies on the previous packet that was sent. So anytime I
> click on a packet from the UI and it fires my dissector, my packets
get
> re-decrypted. I'd like to traverse backwards and not have to worry
> about such issues.
>
>
It sounds like using pinfo->fd->flags.visited may be what you are
seeking.
For example: from the doc/README.binarytrees
NOTE: When you insert items in the tree, it is very likely that you only
want to add any data to the tree during the very first time you process
a particular packet.
Wireshark may reprocess the same packet multiple times afterwards by the
user clicking on the packet or for other reasons.
You probably DO want to protect the insert call within an if statement
such
as
Example:
/* only TRUE first time we process this packet*/
if(!pinfo->fd->flags.visited){
...
<snip>
...
}
You can also look at how this flag is used in other dissectors.
> I would also like to know how I can get TCP sequence numbers for a
> given packet.
>
I'm curious: Why do you want to access the TCP sequence number ?
I would expect the TCP sequence number to not be particularly relevant
to any protocol running on top of TCP.
________________________________________________________________________
___
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe