Hi Chris, Thanks for checking this.
Did you use a “Decode as …” with SoupBinTCP? I believe there’s something my dissector is doing that’s causing the problem (without it, I too see the relative seq/ack numbers looking correct). Thanks, d > On 4 Dec 2018, at 04:55, Maynard, Chris <christopher.mayn...@igt.com> wrote: > > I enabled the same debug and frame 10 looks good: > > 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:3871803454: nextseq:3871803553 > lastack:3871803553 > REV list lastflags:0x0000 base_seq:3273800524 nextseq:3273800562 > lastack:3273800529 > Frame:9 Seq:3273800529 Nextseq:3273800562 > > analyze_sequence numbers frame:11 > FWD list lastflags:0x0000 base_seq:3273800524: nextseq:3273800562 > lastack:3273800562 > REV list lastflags:0x0000 base_seq:3871803454 nextseq:3871803553 > lastack:3871803553 > > > For reference: > Version 2.9.0 (v2.9.0rc0-2723-g46ee43aa) > > Copyright 1998-2018 Gerald Combs <ger...@wireshark.org > <mailto:ger...@wireshark.org>> and contributors. License GPLv2+: GNU GPL > version 2 or later <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html > <http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>> This is free > software; see the source for copying conditions. There is NO warranty; not > even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > Compiled (64-bit) with Qt 5.11.2, with WinPcap SDK (WpdPack) 4.1.2, with GLib > 2.52.2, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.14.0, with Lua 5.2.4, > with GnuTLS 3.4.11, with Gcrypt 1.8.3, with MIT Kerberos, with MaxMind DB > resolver, with nghttp2 1.14.0, with LZ4, with Snappy, with libxml2 2.9.4, > with QtMultimedia, with AirPcap, with SBC, with SpanDSP, with bcg729. > > Running on 64-bit Windows 10 (1809), build 17763, with Intel(R) Xeon(R) CPU > E3-1505M v5 @ 2.80GHz (with SSE4.2), with 16225 MB of physical memory, with > locale English_United States.1252, with WinPcap version 4.1.3 (packet.dll > version 4.1.0.2980), based on libpcap version 1.0 branch 1_0_rel0b > (20091008), with GnuTLS 3.4.11, with Gcrypt 1.8.3, with AirPcap 4.1.0 build > 1622, binary plugins supported (14 loaded). Built using Microsoft Visual > Studio 2017 (VC++ 14.15, build 26730). > > - Chris > > From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org > <mailto:wireshark-dev-boun...@wireshark.org>] On Behalf Of David Arnold > Sent: Monday, December 3, 2018 6:31 AM > To: Developer support list for Wireshark <wireshark-dev@wireshark.org > <mailto:wireshark-dev@wireshark.org>> > Subject: Re: [Wireshark-dev] Corrupted TCP sequence number calculations? > > On 3 Dec 2018, at 18:37, Jaap Keuter <jaap.keu...@xs4all.nl > <mailto: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 > <mailto: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 > <mailto: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 > <mailto: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> > > > > > > > > > > > > > > > > CONFIDENTIALITY NOTICE: This message is the property of International Game > Technology PLC and/or its subsidiaries and may contain proprietary, > confidential or trade secret information. This message is intended solely for > the use of the addressee. If you are not the intended recipient and have > received this message in error, please delete this message from your system. > Any unauthorized reading, distribution, copying, or other use of this message > or its attachments is strictly > prohibited.___________________________________________________________________________ > 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
