# Issue with small pcap files and -r **URL:** \ **Category:** Zeek\ **Created:** [January 7, 2013, 11:48pm UTC](https://community.zeek.org/t/issue-with-small-pcap-files-and-r/2530 "2013-01-07T23:48:38Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Mike\_Sconzo](https://avatars.discourse-cdn.com/v4/letter/m/d6d6ee/32.png) [@Mike\_Sconzo](https://community.zeek.org/u/Mike_Sconzo)\ **Post date:** [January 7, 2013, 11:48pm UTC](https://community.zeek.org/t/issue-with-small-pcap-files-and-r/2530/1 "2013-01-07T23:48:38Z")
When running bro in stand alone mode is there a size cutoff for it to do anything with a pcap file? In bro 2.0 and 2.1 if I run, on a small pcap (76k through 6mb): bro -C -r ./input.pcap /usr/local/bro/share/bro/site/local.bro it only creates loaded\_scripts.log notice\_policy.log packet\_filter.log However, if I run the same commandline on a larger pcap 512mb it produces more "normal" logs. conn.log http.log etc... I've looked through the pcaps in snort, wireshark, tcpdump, and tshark and none of them have issues reading any of the small pcap files (snort will also flag alerts where appropriate). There is app data where expected in packet payloads and multiple setup/teardowns per pcap. I skimmed through the trace file and didn't see anything that looked like an error. Am I missing something simple? Does this have implications with running bro in production? Thanks, -=Mike ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [January 8, 2013, 12:25am UTC](https://community.zeek.org/t/issue-with-small-pcap-files-and-r/2530/2 "2013-01-08T00:25:09Z")
> When running bro in stand alone mode is there a size cutoff for it to > do anything with a pcap file? No, small traces should produce the expected output. We have indeed a larger number of unit tests that rely on that; see, e.g., testing/btest/scripts/base/protocols/smtp/basic.test for one using a rather small SMTP trace. My best guess is that's indeed something with your trace. Try some of the small traces in testing/btest/Traces and see what they give you. > I've looked through the pcaps in snort, wireshark, tcpdump, and tshark One difference between these and Bro is that Bro tracks the TCP state; if there's trouble with that, Bro might abort processing, even though the other tools continue with their packet-based analysis. Do you get a conn.log? That should show up in any case. Robin ---
**Author:** ![Mike\_Sconzo](https://avatars.discourse-cdn.com/v4/letter/m/d6d6ee/32.png) [@Mike\_Sconzo](https://community.zeek.org/u/Mike_Sconzo)\ **Post date:** [January 8, 2013, 2:06am UTC](https://community.zeek.org/t/issue-with-small-pcap-files-and-r/2530/3 "2013-01-08T02:06:55Z")
There are 3-way handshakes and no conn log is produced. The pcaps used for the tests worked correctly when I tried them. However, the pcaps I'm testing on have a GRE tunnel in them. After digging around a bit more it seems like this might be the issue. I didn't look close enough in wireshark, and the rest of the tools do the decapsulation before showing results Thanks for the quick response. -=Mike ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [January 8, 2013, 4:00pm UTC](https://community.zeek.org/t/issue-with-small-pcap-files-and-r/2530/4 "2013-01-08T16:00:27Z")
Ah, that explains it, GRE support isn't there yet (but should pretty straight-forward to add; we have a ticket for that [http://tracker.bro-ids.org/bro/ticket/867](http://tracker.bro-ids.org/bro/ticket/867)) Robin ---
**Author:** ![Mike\_Sconzo](https://avatars.discourse-cdn.com/v4/letter/m/d6d6ee/32.png) [@Mike\_Sconzo](https://community.zeek.org/u/Mike_Sconzo)\ **Post date:** [January 8, 2013, 9:49pm UTC](https://community.zeek.org/t/issue-with-small-pcap-files-and-r/2530/5 "2013-01-08T21:49:50Z")
I might have some free cycles to poke at adding this functionality, it may be entirely out of may capability at the moment but any help of "if I were going to add it this is where it would need to go" would be helpful in figuring out if I can do it or not. If it's done in binpac++ I'll just bow out now. 🙂 ---
**Author:** ![Siwek\_Jon](https://avatars.discourse-cdn.com/v4/letter/s/90db22/32.png) [@Siwek\_Jon](https://community.zeek.org/u/Siwek_Jon)\ **Post date:** [January 8, 2013, 10:24pm UTC](https://community.zeek.org/t/issue-with-small-pcap-files-and-r/2530/6 "2013-01-08T22:24:35Z")
> I might have some free cycles to poke at adding this functionality, it > may be entirely out of may capability at the moment but any help of > "if I were going to add it this is where it would need to go" would be > helpful in figuring out if I can do it or not. I think GRE tunnel decapsulation should look pretty similar to IP tunnel decapsulation which is coded in NetSessions::DoNextPacket() of Sessions.cc -- look for the switch statement cases for IPPROTO\_IPV4/IPPROTO\_IPV6. You might be able to simply lump IPPROTO\_GRE in with that code block if you modify NetSessions::ParseIPPacket() to be able to extract the inner IP packet from a GRE encapsulation (possibly generating a some new "gre\_packet\_header" event with the parsed header fields) and also change the EncapsulatingConn constructor to explicitly require the type of tunnel as an argument. Enum values for the tunnel types are defined in types.bif; it would make sense to add a new GRE type there.     Jon ---
**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:40pm UTC](https://community.zeek.org/t/issue-with-small-pcap-files-and-r/2530/7 "2022-05-06T15:40:44Z")