Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] reassembled PDU for lua dissector in case of a seq overrun

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Wed, 18 May 2016 10:47:26 -0400


On Sat, May 14, 2016 at 11:31 AM, João Valverde <joao.valverde@xxxxxxxxxxxxxxxxxx> wrote:


On 13-05-2016 16:12, Strauß, Martin wrote:
Dear all,
I've written a lua dissector for a company intern binary protocol. Usually it is capable to dissect everything (if no packet is missing).
 I considered that one tcp packet may contain multiple PDU, and also that a PDU may span over multiple tcp packets.
However now I have a 9 GB big file in front of me, where the dissector stopped working in the middle of the file.
As far as I can see the problem is that the ressambling of PDUs does not work if the seq overruns

The last successfully dissected PDU ends at its tcp packet end.
The first not correctly processed PDU is transported in several  tcp packets:
  1. segment:  Summery: [TCP segment of a reassembled PDU]                                                   (Seq: 4294911444 Len: 63712    my_PDU_size:135816)
  2. segment: Summery: scp-config → 49998 [ACK] Seq=7860 Ack=18424 Win=63992 Len=1448 TSval=274170360 TSecr=16005993

=> the second segment should have been part of the reassembled PDU, however it does not contain a list of the reassembled  TCP segments [x Reassembled TCP Segments ...] in the packet details.
And the dissector receives a buffer containing only the content of the second segment.
It seems as if the overruns resets the reassembling of the PDU.

Is this a bug, a known behavior?
I guess it can't be a mistake in the lua dissector, as the reassembling fails and even when I report a wrong PDU size it should add the first segment somewhere (which it doesn't).
Any ideas ?

A superficial analysis of packet-tcp.c suggests a bug, because the sequence number arithmetic is not performed modulo 2**32.

In which case a bug should be opened: https://bugs.wireshark.org