# Bro file extraction & out of order packets behavior

**URL:** <https://community.zeek.org/t/bro-file-extraction-out-of-order-packets-behavior/5579>\
**Category:** Zeek\
**Created:** [January 10, 2019, 11:43pm UTC](https://community.zeek.org/t/bro-file-extraction-out-of-order-packets-behavior/5579 "2019-01-10T23:43:07Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce\_Kao](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@Bruce\_Kao](https://community.zeek.org/u/Bruce_Kao)\
**Post date:** [January 10, 2019, 11:43pm UTC](https://community.zeek.org/t/bro-file-extraction-out-of-order-packets-behavior/5579/1 "2019-01-10T23:43:07Z")

</div>

Hi

I am currently investigating an issue with http file extraction with file analyzer that very frequently I see missing\_bytes in the file log which causes the file to be incomplete and fails extract the file nor generate a hash.

I am running bro in a virtual machine sniffing on a interface in promiscuous mode that’s is on a virtual switch.

After examining a bunch of packet captures, I tracked the problem down to that when Bro sees out of order ACKs before actual packet, the problem with missing\_bytes is observed.

This seems to me that there is no TCP reassembler Bro’s documents indicated that the TCP analyzer for the HTTP analyzer (or file analyzer?), since reassembled TCP payloads are only delivered via a tcp\_content event.

Does anyone have any information on how to make this work? Is it a configuration problem or…

Appreciate any tips that you may have thanks!

---

<div class="post-metadata">

**Author:** ![Michael\_Shirk](https://avatars.discourse-cdn.com/v4/letter/m/aeb1de/32.png) [@Michael\_Shirk](https://community.zeek.org/u/Michael_Shirk)\
**Post date:** [January 11, 2019, 12:22am UTC](https://community.zeek.org/t/bro-file-extraction-out-of-order-packets-behavior/5579/2 "2019-01-11T00:22:56Z")

</div>

Take a look at capture\_loss.log to see if you are in fact not seeing complete connections.

Missed bytes is telling you that there may be a problem in the acquisition of packets. Have you verified with a packet capture in Wireshark that you can reassemble the connection to get a complete file?

I would also create a clean pcap of the file transfer and then test you are getting your hits on the hash, and then figure out the issue with the packet acquisition. Sometimes you have to disable checksum verification on the NIC to get things working.

---

<div class="post-metadata">

**Author:** ![Bruce\_Kao](https://avatars.discourse-cdn.com/v4/letter/b/eada6e/32.png) [@Bruce\_Kao](https://community.zeek.org/u/Bruce_Kao)\
**Post date:** [January 11, 2019, 12:33am UTC](https://community.zeek.org/t/bro-file-extraction-out-of-order-packets-behavior/5579/3 "2019-01-11T00:33:52Z")

</div>

Hi Michael

Thanks for the reply. I understand that based on documentation, missing\_bytes is supposed to indicate missing packets. I previously researched that problem and ended up disabling the interface tcp optimization options including checksum as shown in another Bro related thread. The disabling did work as I don’t see any missing packets when I capture packets on the virtual machine’s interface.

However, this problem here seems different to me. Based on packet capture, all the packets do arrive. The difference here is that the ACK arrives prior to the Packets themselves. In wireshark, it would show ACK’ing unseen packet, and immediate shows that those packets arrive immediately after (wireshark marks those as retransmissions).

I have a http capture that is linked below which shows this sequence.

[https://file.io/kBIkJr](https://file.io/kBIkJr)

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\
**Post date:** [May 6, 2022, 3:46pm UTC](https://community.zeek.org/t/bro-file-extraction-out-of-order-packets-behavior/5579/4 "2022-05-06T15:46:17Z")

</div>


