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: [email protected] [mailto:[email protected]] 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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
