[
https://bro-tracker.atlassian.net/browse/BIT-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106#comment-18106
]
Jon Siwek commented on BIT-1255:
--------------------------------
There's a bit of a hint in weird.log: "above_hole_data_without_any_acks". A
description can be found at:
https://www.bro.org/sphinx/scripts/base/init-bare.bro.html?highlight=above_hole#id-tcp_max_above_hole_without_any_acks
When it says Bro will "give up", that's pretty literal -- no extra efforts are
taken with the analysis and whatever's been done up to that point is basically
what you get. However, you can redef that option to tune Bro's behavior. For
example, try running that trace w/ {{redef
tcp_max_above_hole_without_any_acks=10000;}}. With git/master, I get the right
md5. Generally, the goal of this is to prevent Bro from buffering unreasonable
amounts of data as it waits to fill in a gap in the TCP stream (which isn't
guaranteed to happen).
> TCP reassembly issue
> --------------------
>
> Key: BIT-1255
> URL: https://bro-tracker.atlassian.net/browse/BIT-1255
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: git/master, 2.3
> Environment: CentOS 6
> Reporter: Jimmy Jones
> Attachments: out.pcap
>
>
> Been testing bro with some messy (but valid) TCP streams, using docker and
> netem (happy to upload a gist if people are interested).
> The attached file reassembles correctly in wireshark, but bro only gives the
> first 4069 bytes when extracted with the file analysis framework, and
> obviously the wrong hash (md5 is the URI).
--
This message was sent by Atlassian JIRA
(v6.4-OD-05-008#64003)
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
