Did you use a “Decode as …” with SoupBinTCP? No, my mistake. I didn’t realize this was a built-in Wireshark dissector. I thought this was your own proprietary dissector since you originally wrote, “I’ve discovered an odd issue with my dissector” [emphasis added by me], and have continued to refer to it as your own dissector.
Anyway, I now see similar output as you did, except for frame 11 instead of frame 10: 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:0: nextseq:0 lastack:0 REV list lastflags:0x0000 base_seq:0 nextseq:0 lastack:0 analyze_sequence numbers frame:12 FWD list lastflags:0x0000 base_seq:3871803454: nextseq:3871803553 lastack:3871803553 REV list lastflags:0x0000 base_seq:3273800524 nextseq:3273800562 lastack:3273800562 I don’t know what to make of that either since I’m not familiar with this protocol. As Jaap already pointed out, Frame 9 is marked as malformed, but apparently you’ve fixed that and the sequence numbers are still wrong, so I guess that’s not the solution. One strange thing I noticed is if you look at “Statistics -> Conversations -> TCP” is that even though the IP’s (127.0.0.1) and ports are always 44000 and 56977, Wireshark has actually indicated that there are 2 separate TCP streams instead of only 1, which is what you get without decoding them as SoupBinTCP. Maybe this is a clue? - Chris From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of David Arnold Sent: Tuesday, December 4, 2018 12:04 AM To: Developer support list for Wireshark <wireshark-dev@wireshark.org> Subject: Re: [Wireshark-dev] Corrupted TCP sequence number calculations? 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<mailto: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> 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] 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 Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___________________________________________________________________________ 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
