ICMP analyser incorrectly handles ICMP connections


I have been testing BRO scripts on DARPA 1998 dataset (Week 3 - Wednesday) TCPDUMP https://www.ll.mit.edu/ideval/data/1998/training/week3/wednesday/tcpdump.gz. This file contains a lot of ICMP packets. I was testing ICMP events in BRO to understand their role.

  • event icmp_echo_request(c: connection, icmp: icmp_conn, id: count, seq: count, payload: string)

  • event icmp_echo_reply(c: connection, icmp: icmp_conn, id: count, seq: count, payload: string)

It seems that, the ICMP analyser does not handle the ICMP connections in the right way. I have noticed that, when I use those 2 events the "c: connection" variable does not return the right results.

For example, the mentioned DARPA file contains the following ICMP traces between hosts and the exchanged packet are summarized in the following table:

No. Time Source Destination Protocol Length Info
28076 898088609.998513 ICMP 60 Echo (ping) request id=0xf305 seq=0/0 ttl=63
28077 898088610.000822 ICMP 60 Echo (ping) reply id=0xf305 seq=0/0 ttl=254
28150 898088612.998292 ICMP 60 Echo (ping) request id=0xf305 seq=256/1 ttl=63
28151 898088612.998641 ICMP 60 Echo (ping) reply id=0xf305 seq=256/1 ttl=254
28669 898088644.998259 ICMP 60 Echo (ping) request id=0xf405 seq=0/0 ttl=63
28670 898088644.998652 ICMP 60 Echo (ping) reply id=0xf405 seq=0/0 ttl=254
28682 898088647.998159 ICMP 60 Echo (ping) request id=0xf405 seq=256/1 ttl=63
28683 898088647.998566 ICMP 60 Echo (ping) reply id=0xf405 seq=256/1 ttl=254
30478 898088768.759437 ICMP 60 Echo (ping) request id=0xf176 seq=0/0 ttl=63
30479 898088768.760917 ICMP 60 Echo (ping) reply id=0xf176 seq=0/0 ttl=254
31016 898088797.366418 ICMP 60 Echo (ping) request id=0xf276 seq=0/0 ttl=63
31017 898088797.366861 ICMP 60 Echo (ping) reply id=0xf276 seq=0/0 ttl=254

It can be seen that, there are 6 ICMP connections by exchanging 12 packets (6 Echo Requests and 6 Echo Replays). Whereas, Bro will handle them as 2 connections only making the final results inaccurate.

I have found that, BRO will treat all requests and replays between timestamps 898088609.998513 and 898088647.998566 as one connection and between timestamps 898088768.759437 and 898088797.366861 as another connection.

The results of calling events icmp_echo_request and icmp_echo_reply on that file between the named hosts ( and can bee found in the attached file (results.txt) as well as the script file (test_icmp.bro).

The following commands were called to obtain the results
> wget -c https://www.ll.mit.edu/ideval/data/1998/training/week3/wednesday/tcpdump.gz
> gzip -d < tcpdump.gz > week3_Wednesday.tcpdump
> bro -r week3_Wednesday.tcpdump test_icmp.bro > results.txt


Security Onion 12.4 (Linux 3.13.0-63-generic #104~precise1-Ubuntu SMP x86_64 GNU/Linux) installed On VMware Workstation (10.0.3 build-1895310) running on Windows 8.1 Enterprise


Seth Hall
June 15, 2016, 6:00 AM

This is a known behavior. Bro is creating fake "connections" for ICMP traffic. What you are likely looking for is an icmp.log (which doesn't exist yet) which would have a have a different logging unit than "connection".




Oman Security Officer


External issue ID



Affects versions