Wireshark-dev: [Wireshark-dev] Question on PDU (not frame) identification
From: "Bryant Eastham" <beastham@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 19 Sep 2007 17:44:01 -0600

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 beastham@xxxxxxxxxxxxxxxxxxxxxxxxxxx

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