Follow -> TCP Stream fails to present one side of the conversation if the stream has a RST during handshake
Following a TCP Stream fails to work when the TCP stream has a failing package that required a resend.
Steps to reproduce
Open the provided capture of the TCP conversation and use the Follow > TCP Stream function
What is the current bug behavior?
Only one stream (red) is displayed, the response stream (blue) is ommitted
What is the expected correct behavior?
Both streams are displayed accordingly
Sample capture file
Version 3.6.8 (v3.6.8-0-gd25900c51508) Compiled (64-bit) using Microsoft Visual Studio 2019 (VC++ 14.32, build 31332), with Qt 5.15.2, with libpcap, with GLib 2.66.4, with zlib 1.2.11, with Lua 5.2.4, with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.44.0, with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.9.10, with libsmi 0.4.8, with QtMultimedia, with automatic updates using WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled resampler), with Minizip. Running on 64-bit Windows 10 (21H2), build 22000, with AMD Ryzen 9 3950X 16-Core Processor (with SSE4.2), with 130983 MB of physical memory, with GLib 2.66.4, with Qt 5.15.2, with Npcap version 1.60, based on libpcap version 1.10.2-PRE-GIT, with c-ares 1.17.0, with GnuTLS 3.6.3, with Gcrypt 1.8.3, with nghttp2 1.44.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.4.0, without AirPcap, with light display mode, without HiDPI, with LC_TYPE=English_New Zealand.utf8, binary plugins supported (21 loaded).
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information