# Bro bug? **URL:** \ **Category:** Zeek\ **Created:** [January 19, 2014, 4:45pm UTC](https://community.zeek.org/t/bro-bug/2968 "2014-01-19T16:45:11Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Kellogg\_Brian\_GS\_IT](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@Kellogg\_Brian\_GS\_IT](https://community.zeek.org/u/Kellogg_Brian_GS_IT)\ **Post date:** [January 19, 2014, 4:45pm UTC](https://community.zeek.org/t/bro-bug/2968/1 "2014-01-19T16:45:11Z")
largeTx.bro alerts on any outgoing Txs over X bytes. If of sufficient size it sends an email alert. get.bash uses tshark to extract captured Security Onion FPC packets from /nsm/sensor\_data/so-OLN-eth0/dailylogs/2014-01-19. I received an email alert saying that 1.1.1.1 transmitted over 1GB of information to 2.2.2.2. Therefore I went to the FPC directory above to extract this communication to see what it was. The extracted content was ~3.5MB in size. I've tested this with several large file uploads and have gotten consistent and accurate results with all tests. Therefore I'm confused as to how this alert was generated. Is this an intermittent bug possibly or am I not understanding something? The email alert I received from Bro 2.2 on Security Onion with all the latest patches is included as well. The duration is odd as well. I've received a handful of similar alerts for large transfers and very short durations. Thank you, Brian Kellogg [largeTx.bro](https://community.zeek.org/uploads/short-url/u06cT3XvwHjV999mjl0ItjxuUqM.bro) (1.77 KB) [alert-email.txt](https://community.zeek.org/uploads/short-url/w6JwKdQGqRruyu3Hvuhvp9BcjUs.txt) (343 Bytes) [get.bash](https://community.zeek.org/uploads/short-url/hF8N1dsimu3wIPl8pdwH1sEShwS.bash) (307 Bytes) ---
**Author:** ![Kellogg\_Brian\_GS\_IT](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@Kellogg\_Brian\_GS\_IT](https://community.zeek.org/u/Kellogg_Brian_GS_IT)\ **Post date:** [January 19, 2014, 5:06pm UTC](https://community.zeek.org/t/bro-bug/2968/2 "2014-01-19T17:06:03Z")
Yes and that is the intention. If you look at the email alert in the email you will see a report size of over 1GB and the Bro script only send emails on any Tx over 50MB. Thank you, Brian Kellogg ---
**Author:** ![Azoff\_Justin](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@Azoff\_Justin](https://community.zeek.org/u/Azoff_Justin)\ **Post date:** [January 19, 2014, 5:09pm UTC](https://community.zeek.org/t/bro-bug/2968/3 "2014-01-19T17:09:01Z")
> largeTx.bro alerts on any outgoing Txs over X bytes. If of sufficient size it sends an email alert. .. > I received an email alert saying that 1.1.1.1 transmitted over 1GB of information to 2.2.2.2. Therefore I went to the FPC directory above to extract this communication to see what it was. The extracted content was ~3.5MB in size. > Message: Orig transmitted 1056737769 bytes to resp. Duration 0.092641 sec. Connection UID Cma6473thsxripFj9k. Can you post the full conn.log entry for this connection? That might help explain what is going on.     grep Cma6473thsxripFj9k conn.log should find the exact entry. ---
**Author:** ![Kellogg\_Brian\_GS\_IT](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@Kellogg\_Brian\_GS\_IT](https://community.zeek.org/u/Kellogg_Brian_GS_IT)\ **Post date:** [January 19, 2014, 5:22pm UTC](https://community.zeek.org/t/bro-bug/2968/4 "2014-01-19T17:22:10Z")
1390143300.845103 Cma6473thsxripFj9k 1.1.1.1 3326 2.2.2.2 80 tcp - 0.092641 1056737769 0 RSTOS0 T 0 SaR 2 88 1 40 (empty) - US so-eth0 Thank you, Brian Kellogg ---
**Author:** ![Kellogg\_Brian\_GS\_IT](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@Kellogg\_Brian\_GS\_IT](https://community.zeek.org/u/Kellogg_Brian_GS_IT)\ **Post date:** [January 19, 2014, 5:33pm UTC](https://community.zeek.org/t/bro-bug/2968/5 "2014-01-19T17:33:32Z")
SaR in the history field is in common for both of the erroneous email alerts I received today. Thank you, Brian Kellogg ---
**Author:** ![Kellogg\_Brian\_GS\_IT](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@Kellogg\_Brian\_GS\_IT](https://community.zeek.org/u/Kellogg_Brian_GS_IT)\ **Post date:** [January 19, 2014, 5:38pm UTC](https://community.zeek.org/t/bro-bug/2968/6 "2014-01-19T17:38:40Z")
Here is the conn log entry for the other one: 1390143593.839386 C3miqNnYs6FBw74c5 3.3.3.3 4235 4.4.4.4 80 tcp - 0.086147 1594489093 0 RSTOS0 T 0 SaR 2 88 1 40 (empty) - US so -eth0 Thank you, Brian Kellogg Security Analyst; IT Governance, Risk, and Compliance 500 Paul Clark Drive, Olean, NY 14760 T: (716) 375-3186 | F: (716) 375-3557 ---
**Author:** ![Azoff\_Justin](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@Azoff\_Justin](https://community.zeek.org/u/Azoff_Justin)\ **Post date:** [January 19, 2014, 5:46pm UTC](https://community.zeek.org/t/bro-bug/2968/7 "2014-01-19T17:46:31Z")
So, with the field names, that is: ts 1390143300.845103 uid Cma6473thsxripFj9k id.orig\_h 1.1.1.1 id.orig\_p 3326 id.resp\_h 2.2.2.2 id.resp\_p 80 proto tcp service - duration 0.092641 orig\_bytes 1056737769 resp\_bytes 0 conn\_state RSTOS0 local\_orig T missed\_bytes 0 history SaR orig\_pkts 2 orig\_ip\_bytes 88 resp\_pkts 1 resp\_ip\_bytes 40 Which shows that bro calculated that there were 1056737769 bytes based on sequence numbers, but only actually saw 88 bytes. I think simply changing $size to $num\_bytes\_ip will fix your problems. ---
**Author:** ![Kellogg\_Brian\_GS\_IT](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@Kellogg\_Brian\_GS\_IT](https://community.zeek.org/u/Kellogg_Brian_GS_IT)\ **Post date:** [January 19, 2014, 6:25pm UTC](https://community.zeek.org/t/bro-bug/2968/8 "2014-01-19T18:25:48Z")
Ah, thank you for the clarification. I was obvsiously misunderstanding how that field was calculated. Thank you, Brian Kellogg ---
**Author:** ![Hank\_Leininger](https://avatars.discourse-cdn.com/v4/letter/h/6bbea6/32.png) [@Hank\_Leininger](https://community.zeek.org/u/Hank_Leininger)\ **Post date:** [January 19, 2014, 6:38pm UTC](https://community.zeek.org/t/bro-bug/2968/9 "2014-01-19T18:38:40Z")
> \> 1390143300.845103 Cma6473thsxripFj9k 1.1.1.1 3326 2.2.2.2 80 tcp - 0.092641 1056737769 0 RSTOS0 T 0 SaR 2 88 1 40 (empty) - US so-eth0 > > So, with the field names, that is: [snip] > duration 0.092641 > orig\_bytes 1056737769 > resp\_bytes 0 > conn\_state RSTOS0 > local\_orig T > missed\_bytes 0 > history SaR [snip] > Which shows that bro calculated that there were 1056737769 bytes based > on sequence numbers, but only actually saw 88 bytes. > > I think simply changing $size to $num\_bytes\_ip will fix your problems. That's probably a decent workaround. Another option would be to only trigger on connections that were fully established - with conn\_state of SF (possibly also RST0 and RSTR) - as those should have the "most reliable" byte counts. I think the problem in Brian's case comes from this not being a normally established / torn down connection. conn\_state RSTOS0 implies Bro saw an incomplete connection attempt be torn down by an RST (by the orignal sender, which is odd, and history SaR means the receiver sent not a SYNACK, and not nothing, but a bare ACK, which is odder still... but that is a story for another day\*). It could be argued that Bro should "know" that for certain failed / incomplete connection types, ACK/SEQ math can be unreliable (maybe it already does for some), and that SaR is a candidate for that (maybe that has already been argued; there's probably good cases to be made both ways). [\*Snip esoteric ramble about the 4 way handshake, etc.] Thanks, Hank Leininger \ D24D 2C2A F3AC B9AE CD03 B506 2D57 32E1 686B 6DB3 ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [January 19, 2014, 7:39pm UTC](https://community.zeek.org/t/bro-bug/2968/10 "2014-01-19T19:39:18Z")
This is actually a bug in Bro's handling of odd tcp sessions and it would be great to get a packet capture so we could fix this and work it into our test suite.   .Seth ---
**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:41pm UTC](https://community.zeek.org/t/bro-bug/2968/11 "2022-05-06T15:41:30Z")
Closed on May 6, 2022, 3:41pm UTC