[
https://bro-tracker.atlassian.net/browse/BIT-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18229#comment-18229
]
Jon Siwek commented on BIT-1265:
--------------------------------
{quote}
Might it be better to mark the connection as successful if data is sent?
{quote}
Yeah, I think that's a nice idea -- seems kind of arbitrary for Bro to close
the session if it knows one side is still actively sending data.
{quote}
Otherwise have to set this to a large number, to cover longest possible TCP
sessions, but presumably has a big impact on memory usage, as "lone" SYN's will
keep state?
{quote}
Yes, I think that would be a concern, but there's also several other timeout
mechanisms (which are also tuneable) that I'm not immediately sure would come
to the rescue even if the one in question was set high.
> Single sided HTTP POST split
> ----------------------------
>
> Key: BIT-1265
> URL: https://bro-tracker.atlassian.net/browse/BIT-1265
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: git/master
> Environment: CentOS 6
> Reporter: Jimmy Jones
> Attachments: sample-upload2-all.pcap, sample-upload2-req.pcap
>
>
> Attached two pcap samples, one is a single sided version of the other, an
> HTTP POST.
> When I process the single sided version (sample-upload2-req) conn.log shows
> two sessions (the HTTP POST tcp connection that has been split) and http.log
> shows a partial upload. However processing the original sample
> (sample-upload2-all) everything is as expected - one connection in conn.log
> and a complete http.log
> Are there any parameters I can tweak to make this work?
--
This message was sent by Atlassian JIRA
(v6.4-OD-05-009#64003)
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
