Bug 6726 livedev ips/v6 #10869
Bug 6726 livedev ips/v6 #10869
Conversation
Improve it for af-packet, dpdk, netmap. Check would not consider an interface IDS if the `default` section contained a copy-mode field.
In general, improve IPS setup error checking. Ticket: OISF#5588.
For the capture methods that support livedev and IPS, livedev.use-for-tracking is not supported. This setting causes major flow tracking issues, as both sides of a flow would be tracked in different flows. This patch disables the livedev.use-for-tracking setting if it is set to true. A warning will be issued. Ticket: OISF#6726.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #10869 +/- ##
==========================================
+ Coverage 82.95% 82.99% +0.03%
==========================================
Files 917 917
Lines 247367 247353 -14
==========================================
+ Hits 205198 205284 +86
+ Misses 42169 42069 -100
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
Information: ERROR: QA failed on SURI_TLPW2_autofp_suri_time. ERROR: QA failed on SURI_TLPR1_suri_time.
Pipeline 20109 |
There was a problem hiding this comment.
Thanks for the work Victor
CI : 🟢
Code : looks good... Should we have default livedev: use-for-tracking: auto that is true in IDS and false in IPS ?
Commits segmentation : looks fine
Commit messages : Nice
Git ID set : looks fine for me
CLA : :-p
Doc update : should there be one ?
Redmine ticket : look good
Rustfmt : not needed
Tests : How do we automate the testing of this ?
Dependencies added: none added
|
replaced by #10914 |
|
Merged in #10921, thanks! |
Alternative approach to #10863: instead of erroring out, we just disable the offending setting with a warning.
I think I like this better, as the
livedev.use-for-trackingis enabled by default and will confuse everyone enabling the relevant IPS modes. So this is a more user friendly approach.https://redmine.openinfosecfoundation.org/issues/5588
https://redmine.openinfosecfoundation.org/issues/6726
Changes since #10864: