handle FIN flag in order of the sequence numbers

[matthiasklein]

This change resolves #1979

All 14 of my “faulty” transmissions that I had recorded are decoded correctly with this change.

[Dimi1010]

Changing base branch to dev as per Contributing.md.

[seladb]

@matthiasklein the X509Toolkit tests fail, I assume that this change is related. Can you please take a look?

[matthiasklein]

@seladb I corrected the number of messages in the test. The 31 extracted certificates still have exactly the same content.

[codecov]

Codecov Report

❌ Patch coverage is 71.42857% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.46%. Comparing base (b91640f) to head (8fb159b).

Files with missing lines	Patch %	Lines
Packet++/src/TcpReassembly.cpp	66.66%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##              dev    #2002    +/-   ##
========================================
  Coverage   83.45%   83.46%            
========================================
  Files         311      311            
  Lines       54578    54581     +3     
  Branches    11808    11607   -201     
========================================
+ Hits        45549    45554     +5     
+ Misses       7830     7794    -36     
- Partials     1199     1233    +34     

Flag	Coverage Δ
alpine320	75.86% <42.10%> (-0.02%)	⬇️
fedora42	75.42% <42.10%> (-0.02%)	⬇️
macos-14	81.56% <52.38%> (-0.01%)	⬇️
macos-15	81.55% <52.38%> (-0.01%)	⬇️
mingw32	69.95% <35.29%> (-0.03%)	⬇️
mingw64	69.93% <35.29%> (+0.08%)	⬆️
npcap	?
rhel94	75.45% <42.10%> (-0.02%)	⬇️
ubuntu2004	59.45% <35.00%> (-0.02%)	⬇️
ubuntu2004-zstd	59.57% <35.00%> (-0.01%)	⬇️
ubuntu2204	75.37% <42.10%> (-0.04%)	⬇️
ubuntu2204-icpx	57.85% <31.57%> (-0.01%)	⬇️
ubuntu2404	75.48% <42.10%> (-0.02%)	⬇️
ubuntu2404-arm64	75.53% <38.88%> (-0.02%)	⬇️
unittest	83.46% <71.42%> (+<0.01%)	⬆️
windows-2022	85.41% <68.42%> (+0.16%)	⬆️
windows-2025	85.44% <68.42%> (+0.12%)	⬆️
winpcap	85.44% <68.42%> (-0.08%)	⬇️
xdp	52.97% <0.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[matthiasklein]

@seladb I have corrected the source code indentations that were complained about. Can you run the tests again?

[seladb]

@matthiasklein can you please walk me through this fix?
Here is what I'm trying to understand: if a FIN packet has the expected sequence number, we still close the connection as we used to do, so additional data packets won't be captured on this flow.
If the FIN packet has a sequence number that doesn't match the expected one, we add it to the out-of-order fragment list and handle the connection close when going over the out-of-order list?

[matthiasklein]

@seladb Yes, it is as you assumed: if the FIN packet has the correct sequence number, it is treated as before.

If the sequence number of the FIN packet is not as expected, it is added to the fragment list and only processed when it is in order based on the sequence number.

This ensures that we receive the complete data for all of our problem transmissions.