[
https://bro-tracker.atlassian.net/browse/BIT-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100#comment-18100
]
Jon Siwek commented on BIT-1251:
--------------------------------
"content_gap" is intentionally (or maybe just historically... hard to tell) not
raised in some situations. Particularly if Bro doesn't consider a connection
fully established, it may not raise it unless you "redef
report_gaps_for_partial=T;". In this case, the default behavior has a
detrimental interaction with TCP reassembly -- we miss a segment from the
server and start buffering further segments (because we don't know for sure if
it will come out of order later), the server sends a FIN and so Bro considers
the server endpoint closed, finally the client ACKs enough that we can tell
there's a gap, but we don't raise "content_gap" because the connection is no
longer "fully established".
Addressing some root problems here might take significant changes/rewrite of
the TCP analysis, so you might check in to the workaround of redef'ing
"report_gaps_for_partial" (source code comments claim a downside of that is
raising "content_gap" falsely in more situations, but not sure how
common/relevant that still is).
> content_gap not being raised
> ----------------------------
>
> Key: BIT-1251
> URL: https://bro-tracker.atlassian.net/browse/BIT-1251
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: git/master
> Environment: Fedora 20
> Reporter: Jimmy Jones
> Attachments: analyser.bro, test5-10mb.pcap.gz
>
>
> Using the attached bro script, I extract out the http response, which
> contains some null padding for the missing packets. However the content_gap
> event never gets raised, despite http_entity_data not receiving the entire
> download.
--
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
