Your frame 9 dissection errors out (as malformed), which probably trips up the TCP dissector as well, not allowing it to do all it’s work after the payload dissector is done.
Thanks,
Jaap
> On 29 Nov 2018, at 13:34, David Arnold <davida@xxxxxxxxx> wrote:
>
> Hi all,
>
> I’ve discovered an odd issue with my dissector, and I’d really appreciate some debugging pointers.
>
> I have a capture file (attached) which, when viewed without any explicit decoding, looks just fine — in particular, all the TCP seq/ack numbers appear reasonable, and don’t flag any errors. When I set the “Decode As …” option to “SoupBinTCP” (the appropriate protocol), I start to see some errors with the TCP sequence numbers.
>
> Specifically, the reported (relative) sequence numbers are fine for the first 8 packets in the capture, but on the 9th packet, the *reported* value is screwy, and all subsequent packets are therefore messed up too. The bogus reported value is not reflected in in the shown packet bytes, which look consistent with other packets.
>
> I’m testing using a recent clone of Git master, but have also reproduced the problem on v2.1.0 (which I had installed on a handy machine), so it’s not a new problem.
>
> Any suggestions for what might be going wrong much appreciated.
>
> Thanks in advance,
>
>
>
>
> d
>
Attachment:
tradenow.pcap
Description: Binary data
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
