Re: reassembled PDU for lua dissector in case of a seq overrun

[Jeff Morriss <jeff.morriss.ws () gmail com>]

On Sat, May 14, 2016 at 11:31 AM, João Valverde <
joao.valverde () tecnico ulisboa pt> 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

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