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 <[email protected]> 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 >
tradenow.pcap
Description: Binary data
> ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
