[ https://bro-tracker.atlassian.net/browse/BIT-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15304#comment-15304 ]
Jon Siwek commented on BIT-1119: -------------------------------- {quote} I'm going ahead merging this but I'm wondering about the new detect_filtered_trace flag. It's pretty common (in the research world, anyways to run Bro on a SYN/FIN/RST trace and I imagine having this by default off can add a lot for warnings in that case. Can we add some other heuristic to detect such a trace (i.e., guess whether detect_filtered_trace should be on) ? A (very) coarse approach would simply be a global variable recording if we've ever seen anything else than a TCP control packet. Thoughts? {quote} If a person found out that Bro automatically switched modes part way through the trace, they will probably just re-run after manually toggling the option, right? Maybe treat it in a similar way to checksums -- have a FAQ and/or have some script warn if all TCP connections are missing 100% of content and suggest toggling {{detect_filtered_trace}} if the person would like to trade off correctness for minimized output. But if it's actually not that important for a person using filtered traces to minimize output, I think it's fine enough as is? > topic/jsiwek/tcp-improvements > ----------------------------- > > Key: BIT-1119 > URL: https://bro-tracker.atlassian.net/browse/BIT-1119 > Project: Bro Issue Tracker > Issue Type: Improvement > Components: Bro > Affects Versions: git/master > Reporter: Jon Siwek > Fix For: 2.3 > > > This branch is in the bro, bro-testing, and bro-testing-private repos and has > a few changes to improve reporting of TCP connection sizes and gaps (commit > messages explain in more detail). > The baseline changes in the external repos all seemed reasonable/explainable > (or actually fix a problem). There's too much changed to go through > case-by-case and actually check things, but I did do closer examinations of > unique differences as I came across them (e.g. try to corroborate Bro results > via wireshark). Then for those that seem to follow the same trend as > something I already inspected, I wouldn't manually check. -- This message was sent by Atlassian JIRA (v6.2-OD-07-028#6211) _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev