the tcp reassembly routine ignores packet with an invalid checksum
(since the checksum is invalid there is no point in trying to
reassemble invalid data)
if you want reassembly to work in presence of incorrect tcp checksums
youll have to disable tcp checksum verification in preferences.
On 4/26/07, Turner, Jay <Jay.Turner@xxxxxxxxxxxxxxxxxx> wrote:
I am using Wireshark 0.99.3a. I will upgrade later (or if my problem is
a problem in this version).
Am I misunderstanding tcp_dissect_pdus() or the use of the offset
parameter in the get_proto_message_len() routine?
Frame 6: 12 bytes: [ version: 1 byte ] [ length of message: 2 bytes ] [
control: 1 byte ] [ data: 8 bytes ]
Frame 7: ACK
Frame 8: 15 bytes: [ data: 15 bytes (continued from frame 6) ]
My get_proto_message_len() is called for frame 6. I get 23 from the
"length of message" field. I return 1+2+1+23=27 to say that is the total
length of a message.
Frame 6 is displayed using the data generated through my dissector and
it is correct. At the bottom it says [Unreassembled Packet [incorrect
TCP checksum]: proto] (The invalid checksum is part of what I am
analyzing and doesn't affect my dissector).
Frame 7 is displayed as an ACK.
Frame 8 is displayed as if my dissector was called just to dissect frame
8 and so it is only partially recognized. The get_proto_message_len()
routine is called on frame 8 with an offset of 0 and I check the tvb at
offset 1 (like frame 6) to get the length of the total message, but it
is in the middle of data and the length is invalid.
The Analyze>>Expert Info menu item says "Unreassembled Packet (Exception
occurred)" but running under the debugger I am getting no debug
exceptions.
I thought that tcp_dissect_pdus pulled the frame together so that my
dissector is only called on complete messages. But if so, how would it
be able to display my message as I click from frame to frame? Maybe I am
misunderstanding how to use tcp_dissect_pdus.
Thank you,
Jay Turner
