Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stream: improve 3whs completed by ACK with data #11824

Closed

Conversation

victorjulien
Copy link
Member

@victorjulien victorjulien commented Sep 23, 2024

If the ACK packet completing the 3whs is received, the stream engine will transition to "established". However, the packet itself will not be tagged as "established". This will only happen for the next packet after the 3whs, so that flow:established only matches after the 3whs.

It is possible that the ACK packet completing the 3whs was lost. Since the ACK packets themselves are not acknowledged, there will be no retransmission of them. Instead, the next packet can have the expected ACK flag as well as data.

This case was mishandled in a subtle way. The stream engine state transition was done correctly, as well as the data handling and app-layer updates. However, the packet itself was not tagged as "established", which meant that flow:established would not yet match.

This patch detects this case and tags the packet as established if ACK with data is received that completes the 3whs.

Bug: #7264.

replaces #11821

SV_BRANCH=OISF/suricata-verify#2051

If the ACK packet completing the 3whs is received, the stream engine will
transition to "established". However, the packet itself will not be tagged
as "established". This will only happen for the next packet after the 3whs,
so that `flow:established` only matches after the 3whs.

It is possible that the ACK packet completing the 3whs was lost. Since the
ACK packets themselves are not acknowledged, there will be no retransmission
of them. Instead, the next packet can have the expected ACK flag as well as
data.

This case was mishandled in a subtle way. The stream engine state transition
was done correctly, as well as the data handling and app-layer updates.
However, the packet itself was not tagged as "established", which meant
that `flow:established` would not yet match.

This patch detects this case and tags the packet as established if ACK
with data is received that completes the 3whs.

Bug: OISF#7264.
Copy link

codecov bot commented Sep 23, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.59%. Comparing base (7ab8334) to head (9b27c18).
Report is 12 commits behind head on master.

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #11824   +/-   ##
=======================================
  Coverage   82.58%   82.59%           
=======================================
  Files         914      914           
  Lines      249500   249502    +2     
=======================================
+ Hits       206045   206070   +25     
+ Misses      43455    43432   -23     
Flag Coverage Δ
fuzzcorpus 60.57% <100.00%> (+0.14%) ⬆️
livemode 18.75% <0.00%> (+0.03%) ⬆️
pcap 44.05% <100.00%> (-0.03%) ⬇️
suricata-verify 62.02% <100.00%> (-0.01%) ⬇️
unittests 58.96% <50.00%> (-0.01%) ⬇️

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

Copy link
Contributor

@jufajardini jufajardini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments and commit message look good now.

Code patch was already approved by Philippe, and seems to make sense, given the explanation...

@suricata-qa
Copy link

WARNING:

field baseline test %
SURI_TLPR1_stats_chk
.uptime 649 628 96.76%

Pipeline 22785

@victorjulien victorjulien added this to the 8.0 milestone Sep 24, 2024
@victorjulien
Copy link
Member Author

Merged in #11829, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants