Actions
Optimization #6792
closeddetect/port: port grouping is quite slow in worst cases
Effort:
Difficulty:
Label:
Description
Given how the port grouping was done historically, in some worst case scenarios, it could take a very long time to group the signatures on the basis of ports and thus increasing the entire time taken by the engine to start by a huge factor.
Updated by Shivani Bhardwaj 10 months ago
- Status changed from Assigned to In Review
Closed by: https://github.com/OISF/suricata/pull/10567
Updated by Shivani Bhardwaj 9 months ago
- Related to Bug #6414: detect-engine/port: recursive DetectPortInsert calls are expensive added
Updated by Shivani Bhardwaj 9 months ago
- Status changed from In Review to Resolved
Updated by Shivani Bhardwaj 9 months ago
- Related to Bug #6843: detect/port: port ranges are incorrect when a port is single as well as a part of range added
Updated by Shivani Bhardwaj 9 months ago
- Related to Bug #6881: detect/port: port grouping does not happen correctly if gap between a single and range port added
Updated by Shivani Bhardwaj 9 months ago
- Related to Bug #6896: detect/port: upper boundary ports are not correctly handled added
Updated by Victor Julien 8 months ago
- Related to Bug #2908: ip only rules cause suricata to take 17 minutes to start added
Updated by Shivani Bhardwaj 7 months ago
- Status changed from Resolved to Closed
Actions