[ https://bro-tracker.atlassian.net/browse/BIT-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Siwek updated BIT-1240: --------------------------- Resolution: Fixed Status: Closed (was: Open) > TCP gaps inserted in wrong place > -------------------------------- > > Key: BIT-1240 > URL: https://bro-tracker.atlassian.net/browse/BIT-1240 > Project: Bro Issue Tracker > Issue Type: Problem > Components: Bro > Affects Versions: git/master, 2.3 > Environment: CentOS 6 > Reporter: Jimmy Jones > Fix For: 2.4 > > Attachments: get-hole1.trace > > > Using attached test file, I tried using the file analysis framework to > extract out the payload, which is a copy of one of the bro testcases but with > a packet removed. > However the extracted file has nulls padded at the beginning, but they should > be at offset 1448. Looking at what happens, the gap is signalled to File::Gap > before the data is received in File::DataIn, which calculates the offset to > write the payload by adding the seen bytes to the missing byte count. Should > gaps always be signalled in order with the data - this also affects users of > content_gap, who would receive the data and hole "out of order"? > Used the following bro script: > event file_new(f: fa_file) > { > Files::add_analyzer(f, Files::ANALYZER_EXTRACT, [$extract_filename=f$id]); > } -- This message was sent by Atlassian JIRA (v6.4-OD-05-008#64003) _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev