[ 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 bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev