[Michael Mann <mmann78@xxxxxxxxxxxx>]

This may be related/similar to bug 6392 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6392).

 

I believe the capture in this bug has only a few "leftover" bytes (and I thought the issue may be related to amount of fixed data needed by dissector).  However 38 bytes seems much larger than a typical amount of fixed bytes.  So the issue really may be the TCP dissector and not your protocol/dissector.

 

 

-----Original Message-----
From: Graham Bloice <graham.bloice@xxxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Aug 5, 2016 9:48 am
Subject: Re: [Wireshark-dev] dissecting TCP packets with multiple PDUs

On 5 August 2016 at 14:08, John Dill <John.Dill@xxxxxxxxxxxxxxxxx> wrote:

I have a TCP protocol that sends multiple PDUs.  So far, my dissector seems to handle the cases where one PDU is split across multiple frames, and when multiple PDUs are dissected in one frame.  Unfortunately, I'm having issues where the TCP dissection stops if I have multiple PDUs that are split inside a frame, e.g.

 

packet 37104 TCP segment (536)

packet 37167 TCP segment (498) - creates reassembled TCP size of (1034) which is correct

 

However, packet 37167 has the start of another PDU containing 38 bytes.  I can't seem to get the dissector to recognize the start of it.

 

​I printed out the captured length, but it always seems to be 1034.  I'm not sure how to recognize that the current frame has leftover bytes to start a new dissection.

 

Is there an example plugin that someone can suggest that I can investigate to see how this scenario is handled?

 

Thanks,

John D.

 

Is your dissector returning the number of bytes it dissected?

--

Graham Bloice

___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe