> On 3 Dec 2018, at 18:37, Jaap Keuter <jaap.keu...@xs4all.nl> wrote: > > Hi David, > > Not at the moment, no. Anyone else?
I discovered some #if’d-out debugging code in tcp_analyse_sequence_number(), which seems to reflect the problem: analyze_sequence numbers frame:1 FWD list lastflags:0x0000 base_seq:0: nextseq:0 lastack:0 REV list lastflags:0x0000 base_seq:0 nextseq:0 lastack:0 analyze_sequence numbers frame:2 FWD list lastflags:0x0000 base_seq:0: nextseq:0 lastack:0 REV list lastflags:0x0000 base_seq:3871803454 nextseq:3871803455 lastack:0 Frame:1 Seq:3871803454 Nextseq:3871803455 analyze_sequence numbers frame:3 FWD list lastflags:0x0000 base_seq:3871803454: nextseq:3871803455 lastack:3871803455 REV list lastflags:0x0000 base_seq:3273800524 nextseq:3273800525 lastack:0 Frame:2 Seq:3273800524 Nextseq:3273800525 analyze_sequence numbers frame:4 FWD list lastflags:0x0000 base_seq:3871803454: nextseq:3871803455 lastack:3871803455 REV list lastflags:0x0000 base_seq:3273800524 nextseq:3273800525 lastack:3273800525 analyze_sequence numbers frame:5 FWD list lastflags:0x0000 base_seq:3273800524: nextseq:3273800525 lastack:3273800525 REV list lastflags:0x0000 base_seq:3871803454 nextseq:3871803504 lastack:3871803455 Frame:4 Seq:3871803455 Nextseq:3871803504 analyze_sequence numbers frame:6 FWD list lastflags:0x0000 base_seq:3273800524: nextseq:3273800525 lastack:3273800525 REV list lastflags:0x0000 base_seq:3871803454 nextseq:3871803504 lastack:3871803504 analyze_sequence numbers frame:7 FWD list lastflags:0x0000 base_seq:3871803454: nextseq:3871803504 lastack:3871803504 REV list lastflags:0x0000 base_seq:3273800524 nextseq:3273800529 lastack:3273800525 Frame:6 Seq:3273800525 Nextseq:3273800529 analyze_sequence numbers frame:8 FWD list lastflags:0x0000 base_seq:3871803454: nextseq:3871803504 lastack:3871803504 REV list lastflags:0x0000 base_seq:3273800524 nextseq:3273800529 lastack:3273800529 analyze_sequence numbers frame:9 FWD list lastflags:0x0000 base_seq:3273800524: nextseq:3273800529 lastack:3273800529 REV list lastflags:0x0000 base_seq:3871803454 nextseq:3871803553 lastack:3871803504 Frame:8 Seq:3871803504 Nextseq:3871803553 analyze_sequence numbers frame:10 FWD list lastflags:0x0000 base_seq:0: nextseq:0 lastack:0 REV list lastflags:0x0000 base_seq:0 nextseq:0 lastack:0 analyze_sequence numbers frame:11 FWD list lastflags:0x0000 base_seq:3273800561: nextseq:0 lastack:3273800562 REV list lastflags:0x0000 base_seq:3871803552 nextseq:3871803553 lastack:0 analyze_sequence numbers frame:12 FWD list lastflags:0x0000 base_seq:3871803552: nextseq:3871803553 lastack:3871803553 REV list lastflags:0x0000 base_seq:3273800561 nextseq:3273800575 lastack:3273800562 Frame:11 Seq:3273800562 Nextseq:3273800575 The sequence numbers in frame 10 appear to have been completely reset. The bogus (relative) sequence number displayed for frame #9 (not reflected here — the absolute values, and packet bytes themselves, appear to be fine) is a result of a bad value for tcpd->fwd->base_seq during the calculations, bearing no resemblance to the initial sequence numbers for either direction’s flow. I haven’t figured out where that’s coming from yet. d > 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 > <mailto:wireshark-dev@wireshark.org>> > Archives: https://www.wireshark.org/lists/wireshark-dev > <https://www.wireshark.org/lists/wireshark-dev> > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > <https://www.wireshark.org/mailman/options/wireshark-dev> > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > <mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe>
signature.asc
Description: Message signed with OpenPGP
___________________________________________________________________________ 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
