Hi,
I use exactly the same solution for one proprietary enycrypted protocol
and it works well. You can go on it that way.
Concernig your questions:
1. I do not know any better solution now.
2. As I know it is stable "enough" at least for your solution. See note
below.
3. I think it is better to save decrypted data and other PDU information
into the frame data. It would create huge table for serching in the
conversation.
Note: I met following problem. If you decrypt more PDUs in one frame and
create new tvb real data for each of them then remember that
TVB_RAW_OFFSET() is not unique within frame if you call it inside
decrypted data becase each begin of decrypted data has TVB_RAW_OFFSET()
equal to 0. But it would be problem only if you need some unique id
within any protocol encapsulated in your encrypted protocol.
Regards,
Tomas
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bryant Eastham
Sent: Thursday, September 20, 2007 1:44 AM
To: [email protected]
Subject: [Wireshark-dev] Question on PDU (not frame)
identification
All-
I am faced with the need for individual PDU identification and
data storage over TCP/IP. I have worked with both conversations in all
their flavors and the p_*_proto_data routines, but I need to obtain
state for each PDU in terms of my protocol, not the underlying frame.
Ignoring the incredible thorny issues of retransmissions and
cases where reassembly isn't possible or fails for other reasons (I am
using tcp_dissect_pdus), the easiest way to accomplish this seems to be:
1. Use a session to maintain the ongoing state from PDU to PDU.
2. Use proto_data for storage in each frame.
3. Use a lookup table in each proto_data to store per-PDU data.
That leaves me with determining a key for the lookup table. The
most obvious is TVB_RAW_OFFSET(); it appears to be stable and unique for
each PDU in the frame.
A couple of questions to the experts:
1. Am I missing something obvious, some other solution? This
feels like a common need, and my solution feels sort of hackish.
2. Is TVB_RAW_OFFSET actually stable? Can people think of a
reason that it would change during the many dissector calls?
3. Should the data storage be in the session, using a key that
is a combination of the frame number and the offset?
If people care, the reason that I need per-PDU is for decryption
information. I need to store a nonce associated with the PDU that is
either passed on the wire *or* is based on the previous value. If it was
one or the other I wouldn't need per PDU state, but the first PDU in the
frame could use a value based on the previous PDU (in another frame,
hence the conversation), the second PDU in the frame could pass a
different value on the wire, and the last PDU in the frame could be
either...
Of course, thinking while I am writing, as long as I know the
state at the beginning of the frame (from the conversation) then I can
always move from that point on without problems. Stupid me.
Oh well, the question is still interesting from a "maybe I'll
need it some day" perspective...
Thanks,
--
Bryant Eastham [EMAIL PROTECTED]
Chief Architect
Panasonic Electric Works Laboratory of America, Inc. , Salt Lake
City Lab
4525 South Wasatch Blvd., Suite 100, Salt Lake City, Utah 84124
Phone : 801.993.7124 Fax: 801.993.7260
MEW Intranet: https://pewla.mew.com/slc/index.php/User:Beastham
<https://pewla.mew.com/slc/index.php/User:Beastham>
_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev
