Re: Corrupted TCP sequence number calculations?

[David Arnold <davida () pobox com>]

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.Maynard () 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 <gerald () wireshark org <mailto:gerald () 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-bounces () wireshark org <mailto:wireshark-dev-bounces () 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.keuter () xs4all nl <mailto:jaap.keuter () 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 <davida () pobox com <mailto:davida () 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.keuter () xs4all nl <mailto:jaap.keuter () 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 <davida () pobox com <mailto:davida () 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-request () wireshark org?subject=unsubscribe <mailto:wireshark-dev-request () 
> wireshark org?subject=unsubscribe>

Attachment: 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-request () wireshark org?subject=unsubscribe