# linking a wrong\_fragment event to a connection **URL:** \ **Category:** Zeek\ **Created:** [March 11, 2010, 11:22am UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600 "2010-03-11T11:22:54Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Veronica\_Estrada](https://avatars.discourse-cdn.com/v4/letter/v/ba9def/32.png) [@Veronica\_Estrada](https://community.zeek.org/u/Veronica_Estrada)\ **Post date:** [March 11, 2010, 11:22am UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600/1 "2010-03-11T11:22:54Z")
Hello everyone, I ask this topic again trying to clarify my questions (and my English). I want to associate a summary of wrong fragments to the corresponding line in the connection summary. I made a script to count the different fragment problems trigger by flow\_weird event. How can I know which connection has generated that wrong fragment event? The wrong fragment event only logs src, dst and network\_time. This is not enough to link the fragment to a connection inside connection summary. 1247652196.907274 src\_ip → dst\_ip: fragment\_with\_DF By the way, I read about active and passive timeouts on connections (“Flow-based TCP Connection Analysis” by Limmer and Dressler). I don´t understand how this topic is treated in BRO. I found only one type of timeout (TCP\_inactivity\_timeout). Is this timeout the active timeout? Can I tune a passive timeout? Maybe I am missing others user tunable timeouts that can affect my results. Maybe I am getting into the details of bro design, I want to understand what I am doing, and what I shouldn´t do to get the wrong fragment count inside the conn.bro file. Veronica Estrada Nakao Laboratory The University of Tokyo ---
**Author:** ![Vern](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/vern/32/630_2.png) [@Vern](https://community.zeek.org/u/Vern)\ **Post date:** [March 11, 2010, 3:56pm UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600/2 "2010-03-11T15:56:48Z")
> How can I know which connection has generated that wrong fragment event? In general you can't. Most individual fragments do not possess transport headers, so there is no well-defined connection associated with them. \*If\* the fragment is part of a whole collection, then you can locate the transport header at the beginning of the collection and use its ports - but Bro may not have even seen this first part yet. So it only reports the involved hosts. (It also could in principle report ports if the problematic fragment happens to be the first \*and\* includes a full transport header [which it doesn't have to], but Bro doesn't go out of its way to do the extra work in this case.) > By the way, I read about active and passive timeouts on connections > ("Flow-based TCP Connection Analysis" by Limmer and Dressler). > I don't understand how this topic is treated in BRO. You'll need to explain how those timeouts are defined in that paper for others to be able to comment on how Bro's connection timeouts relate to them.     Vern ---
**Author:** ![Mathew\_Binkley](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@Mathew\_Binkley](https://community.zeek.org/u/Mathew_Binkley)\ **Post date:** [March 11, 2010, 7:01pm UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600/3 "2010-03-11T19:01:36Z")
What is the correct way to tell bro to ignore any traffic between two machines? If I have World, Machine1, and Machine2, then I want to monitor:      World \<-\> Machine1      World \<-\> Machine2 but not Machine1 \<-\> Machine2. Thanks. Mat ---
**Author:** ![Seth\_Hall](https://avatars.discourse-cdn.com/v4/letter/s/50afbb/32.png) [@Seth\_Hall](https://community.zeek.org/u/Seth_Hall)\ **Post date:** [March 11, 2010, 7:44pm UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600/4 "2010-03-11T19:44:12Z")
redef restrict\_filters += {   ["ignore\_machine1\_to\_machine2"] = "not (host 1.2.3.4 and host 1.2.3.5)" }; Don't do that inside of an event handler or function definition.    .Seth ---
**Author:** ![Mathew\_Binkley](https://avatars.discourse-cdn.com/v4/letter/m/47e85d/32.png) [@Mathew\_Binkley](https://community.zeek.org/u/Mathew_Binkley)\ **Post date:** [March 11, 2010, 8:10pm UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600/5 "2010-03-11T20:10:12Z")
Thanks Seth. A slightly different question: how do I ignore traffic between hosts in a particular subnet? I want to ignore all chatter between machines in my cluster, and simply examine traffic between the cluster and the world. Mat ---
**Author:** ![Seth\_Hall](https://avatars.discourse-cdn.com/v4/letter/s/50afbb/32.png) [@Seth\_Hall](https://community.zeek.org/u/Seth_Hall)\ **Post date:** [March 11, 2010, 9:07pm UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600/6 "2010-03-11T21:07:44Z")
I would do something similar to the earlier filter... redef restrict\_filters += {   ["ignore\_internal"] = "not (src net 1.2.3.0/24 and dst net 1.2.3.0/24)" };   .Seth ---
**Author:** ![Veronica\_Estrada](https://avatars.discourse-cdn.com/v4/letter/v/ba9def/32.png) [@Veronica\_Estrada](https://community.zeek.org/u/Veronica_Estrada)\ **Post date:** [March 12, 2010, 4:06pm UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600/7 "2010-03-12T16:06:55Z")
Thanks for your kindly answer about fragment. So maybe I should focus on bad\_TCP\_checksum / bad\_UDP\_checksum and bad\_icmp\_checksum instead of excessively\_large\_fragment, excessively\_small\_fragment, fragment\_inconsistency, fragment\_overlap,fragment\_protocol\_inconsistency etc…)? In that case, I will have the header with the information I need. BTW, in the case of BRO processed KDDCup 99 data, all the wrong fragments belong to SF labeled UDP/ICMP connections (for UDP connections wrong fragment count is 3 and the others 1). I thought SF is printed for completely flows but I read in an old message of this list (nov 2004) that when BRO encounters a flow mid-stream and that flow get shut down BRO uses SF label. You mentioned plans for adding Bro state tracking to solve it. What is the situation at the moment? The paper I am talking about defines the timeouts that could affect the probability to split a flow during its lifetime:active timeout is full length of TCP connection passive timeout refers to idle times in active flows where no packet is transfer (it is called also the maximum packet gap). Thank you in advance for any help you can provide. Veronica ---
**Author:** ![Vern](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/vern/32/630_2.png) [@Vern](https://community.zeek.org/u/Vern)\ **Post date:** [March 18, 2010, 5:46pm UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600/8 "2010-03-18T17:46:33Z")
> Thanks for your kindly answer about fragment. So maybe I should focus on > bad\_TCP\_checksum / bad\_UDP\_checksum and bad\_icmp\_checksum instead > of excessively\_large\_fragment, excessively\_small\_fragment, > fragment\_inconsistency, > fragment\_overlap,fragment\_protocol\_inconsistency > etc..)? In that case, I will have the header with the information I need. Yes, those all have some sort of flow information associated with them. (Though I would skip bad\_icmp\_checksum, as for ICMPs the flow is a somewhat vague notion.) > BTW, in the case of BRO processed KDDCup 99 data Side note: I hope you're only looking at that data get a handle on using Bro or such. Using it for research is a well-known pitfall; see [http://www.icir.org/vern/talks/vp-IDS-Pitfalls-DIMVA07.pdf](http://www.icir.org/vern/talks/vp-IDS-Pitfalls-DIMVA07.pdf) . > when BRO encounters a flow mid-stream and that flow get shut down BRO uses > SF label. You mentioned plans for adding Bro state tracking to solve it. > What is the situation at the moment? It's available, see the discussion "If you set the new control variable record\_state\_history to T" in the CHANGES file. > The paper I am talking about defines the timeouts that could affect the > probability to split a flow during its lifetime: > active timeout is full length of TCP connection passive timeout refers to > idle times in active flows where no packet is transfer (it is called also > the maximum packet gap). Bro does the latter, since it needs to make the decision in real-time.     Vern ---
**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:39pm UTC](https://community.zeek.org/t/linking-a-wrong-fragment-event-to-a-connection/1600/9 "2022-05-06T15:39:03Z")