[
https://bro-tracker.atlassian.net/browse/BIT-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112#comment-18112
]
Jon Siwek commented on BIT-1255:
--------------------------------
{quote}
Based on very little understanding of how Bro's tcp reassembly works... instead
of giving up, would it be preferable to signal a gap and carry on processing
the rest of the connection?
{quote}
Good question, not entirely sure the original motivation for that failure mode.
I think in the absence of ACKs and while still trying to impose limits on the
size of the reassembly buffer, it may become rather arbitrary which segments
get delivered and which get missed, so maybe giving up processing the rest is
to avoid a messy/noisy analysis.
> 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
