Conversation
For probing parsers used with a pattern, restrict the max depth to these probing parsers and not all probing parsers. Finishing protocol detection earlier allows to parse data earlier in the case we recognize only one side.
When an app-layer is recognized for one side, but the other is still unknown, and the parsing of the one side errors, it disables app-layer, and thus the ending pseudo-packets do not get a chance to conclude for app-layer detection on the unknown side. So count in stats the app-layer protocol that was recognized the first time.
When probing parser is only tried from one recognized side of the protocol, even if this parser failed, it never set probing parser done as no mask were used.
As these have no StateAlloc, AppLayerParserParse disables app-layer parsing, which prevents other side protocol detection...
|
As it stands now, any field with a number is compared against our baseline. The first jq looks like it will always equal the number of lines in stats.json? Unless I'm missing something (it is returning nothing for me as is). |
Is it clearer ? |
|
WARNING: ERROR: QA failed on IPS_AFP_drop_chk.
Pipeline 13570 |
|
Ah, yes it is. I don't think we capture flow events. There are limits on the size of files we can collect. I can a run with 'flow' logged to compare but I may have to do it manually. |
|
As noted in other PRs, ignore the IPS section of this. Just updated baseline for that test. |
|
So @jufajardini pgsql probing parser to client accepts anything that has at least 5 bytes : you should uncomment the error return in |
|
Rebased in #8892 |
3 participants
Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/1125 preliminary work
Describe changes:
Modifies #8696 by incrementing pop3 counters
Summing up :
statsfield about flows are not matching the count offlowwith app_proto because of so many corner casesUSERpattern matched)@ct0br0 @pevma should QA count the number of flows with app_proto instead of resorting to stats ?
cf
jq 'select(.event_type=="flow" and .app_proto=="ftp") | .app_proto' log/eve.json | wc -lversusjq 'select(.event_type=="stats") | .stats."app_layer".flow.ftp' log/eve.jsonas pointed out #8327 (comment)@victorjulien how should this be handled ? Create many tickets and find the right priority order to deal with them ?
Should it begin with just commit f27a6f1 but using port 110 instead of POP3 ? That would solve QA wrongly tagging POP3 flows as FTP