-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Protodetect probing mask32 7437 v2 #12307
base: master
Are you sure you want to change the base?
Protodetect probing mask32 7437 v2 #12307
Conversation
There was an implicit limit of 32 app-layer protocols used by probing parsers through a mask, meaning that Suricata should not support more than 32 app-layer protocols in total. This limit is relaxed to each flow not being able to run more than 32 probing parsers, meaning that for each source and destination port combination, the sum of registered probing parsers should not exceed 32, even if there are more than 32 in total. Also sets probing parsers done sooner in the case the other side of the connection was detected first. Ticket: 7437
Ticket: 7469
WARNING:
Pipeline 24024 |
A minimal change to get the same QA change should be diff --git a/src/app-layer-detect-proto.c b/src/app-layer-detect-proto.c
index a65a98c88a..b40c0adc44 100644
--- a/src/app-layer-detect-proto.c
+++ b/src/app-layer-detect-proto.c
@@ -619,7 +619,7 @@ again_midstream:
else if (pp_port_sp)
mask = pp_port_sp->alproto_mask;
- if (alproto_masks[0] == mask) {
+ if ((alproto_masks[0] & mask) == mask) {
FLOW_SET_PP_DONE(f, dir);
SCLogDebug("%s, mask is now %08x, needed %08x, so done",
(dir == STREAM_TOSERVER) ? "toserver":"toclient", meaning we have tried all expected probing parsers and maybe more... |
I don't understand this comment. What is the choice we have to make here? Which one is (more) correct? |
I think this PR is more correct than the minimal change, but also more complex as it does more stuff, including this accidental fix during the refactoring. But if you want to process by little steps, we can make the minimal change with its QA rebase line, and then rebase this PR which will not change anymore QA results |
Will we want to backport? If so, smaller and well isolated steps would be preferred. Otherwise I'd say we can move ahead with this PR. |
Good question, I do not think we need to backport this as long as we do not add new app-layer protocols in 7. What do you think ? |
Link to ticket: https://redmine.openinfosecfoundation.org/issues/
https://redmine.openinfosecfoundation.org/issues/7437
https://redmine.openinfosecfoundation.org/issues/7469
Describe changes:
SV_BRANCH=OISF/suricata-verify#2200
Closing #12256 to get this part first
#12233 with
This will require a QA baseline update as highlighted by the SV test