[ 
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

Reply via email to