Hi David, Not at the moment, no. Anyone else?
Thanks, Jaap > On 2 Dec 2018, at 23:36, David Arnold <dav...@pobox.com> wrote: > > Hi Jaap, > > Thanks for looking into this. > > The problem with frame 9 appears to be the result of a change to use > ws_strtoi32() to convert a string with trailing whitespace. A very quick > workaround of that (just supplying an end pointer) avoids the reported error, > but doesn’t avoid the TCP sequence number corruption. > > Still investigating; any further suggestions? > > > > d > >> On 30 Nov 2018, at 01:43, Jaap Keuter <jaap.keu...@xs4all.nl> wrote: >> >> 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 <dav...@pobox.com> 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> >>> >>> ___________________________________________________________________________ ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
