[Bro-Dev] [JIRA] (BIT-1255) TCP reassembly issue

Jon Siwek (JIRA) jira at bro-tracker.atlassian.net
Thu Sep 18 12:03:07 PDT 2014


    [ 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)


More information about the bro-dev mailing list