# Bro and Fragmentation. **URL:** \ **Category:** Zeek\ **Created:** [August 13, 2018, 4:00pm UTC](https://community.zeek.org/t/bro-and-fragmentation/5411 "2018-08-13T16:00:13Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![fatema\_bannatwala](https://avatars.discourse-cdn.com/v4/letter/f/5f9b8f/32.png) [@fatema\_bannatwala](https://community.zeek.org/u/fatema_bannatwala)\ **Post date:** [August 13, 2018, 4:00pm UTC](https://community.zeek.org/t/bro-and-fragmentation/5411/1 "2018-08-13T16:00:13Z")
Hi All, Recently I was troubleshooting some fragmentation occurring in UDP DNS responses from our DNS servers, because of packet size \> 1500 bytes. The responses are completely valid, including 13 additional RR’s with 7 Authoritative records, hence exceeding the normal size of the packet, and getting fragmented into two packets. When grep’ed the connection from the dns.log file in Bro, appeared that Bro logged two connections for the single fragmented DNS response: 2018-08-13T10:16:40-0400 C42pXn2GRPxmh8JRBd 74.220.198.174 19401 128.175.13.16 53 udp 34754 - [upenn.edu](http://upenn.edu) 1 C\_INTERNET 1 5 MX - - F F F F 1 - - F - - 2018-08-13T10:16:40-0400 CsFVfL2czxAmhLprqj 74.220.198.174 19401 128.175.13.16 53 udp 34754 - [upenn.edu](http://upenn.edu) - - - - 0 NOERROR T F F F 0 [cluster5a.us.messagelabs.com](http://cluster5a.us.messagelabs.com),[cluster5.us.messagelabs.com](http://cluster5.us.messagelabs.com), 900.000000,900.000000,900 .000000 F [dns1.udel.edu](http://dns1.udel.edu),[dns2.udel.edu](http://dns2.udel.edu),[adns1.upenn.edu](http://adns1.upenn.edu),[sns-pb.isc.org](http://sns-pb.isc.org),,[adns3.upenn.edu](http://adns3.upenn.edu),[adns2.upenn.edu](http://adns2.upenn.edu) 128.91.254.22,2607:f470:1002::2:3,2607:f4 70:1003::3:c,,128.91.251.33,2607:f470:1001::1:a,128.91.3.128 I verified the transaction ID ( 34754) with the one in the pcap capture of the same traffic from the firewall and was curious to know how Bro deals with the Fragmentation assembly and logging. Any thoughts? Thanks! Fatema. P.S: I can provide the pcap capture to the corresponding connection mentioned above. ---
**Author:** ![Jon\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/71c47a/32.png) [@Jon\_Siwek](https://community.zeek.org/u/Jon_Siwek)\ **Post date:** [August 13, 2018, 5:16pm UTC](https://community.zeek.org/t/bro-and-fragmentation/5411/2 "2018-08-13T17:16:50Z")
If valid IP fragments are received in a short enough interval then I'd expect Bro to reassemble them without such visible effects on application-layer logging. The thing that's most suspicious in the logs here is that there's a different connection ID (C42pXn2GRPxmh8JRBd vs. CsFVfL2czxAmhLprqj), meaning something about these packets caused Bro to create separate connections and finding out why that happened would also implicitly answer the question of why fragmentation reassembly didn't happen (reassembly state is per-connection). Some relevant script options to check: const udp\_inactivity\_timeout = 1 min &redef; const frag\_timeout = 0.0 sec &redef; You could also check if there's any "weirds" related these connections for possible clues. I can also help take a look at any pcaps you have to give a more definitive answer of what happened in this case. - Jon ---
**Author:** ![Michal\_Purzynski1](https://avatars.discourse-cdn.com/v4/letter/m/a88e57/32.png) [@Michal\_Purzynski1](https://community.zeek.org/u/Michal_Purzynski1)\ **Post date:** [August 19, 2018, 1:47am UTC](https://community.zeek.org/t/bro-and-fragmentation/5411/3 "2018-08-19T01:47:27Z")
Correct me if I’m wrong, but those settings will keep IP fragments in memory indefinitely, subject to other timeouts, risking OOM. ---
**Author:** ![seth](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/seth/32/642_2.png) [@seth](https://community.zeek.org/u/seth)\ **Post date:** [August 20, 2018, 8:40pm UTC](https://community.zeek.org/t/bro-and-fragmentation/5411/4 "2018-08-20T20:40:29Z")
If you are running with the default local.bro you will get a script loaded called tuning/packet-fragments.bro with this line in it... redef frag\_timeout = 5 min; 5 minutes is still a rather long time but at least it's not indefinite.    .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:45pm UTC](https://community.zeek.org/t/bro-and-fragmentation/5411/5 "2022-05-06T15:45:58Z")
Closed on May 6, 2022, 3:45pm UTC