Suricata

Enip's parsing function registers ENIPParse in both the request direction and response direction, so each direction corresponds to an independent transaction. However, the transaction analysis engine analyzes both the request and response directions for each transaction, which results in duplication of detection and alert events, and the original IP and destination IP of the alert event are confused.
We can use this simple rule to verify enip messages with only one request and response：
alert enip any any -> any any (msg:"SURICATA enip test ";enip_command:99 ;sid:6450008; rev:1;)
We only expect two alerts, but 6 were reported：
08/19/2020-15:48:38.084428 [] [1:6450008:1] SURICATA enip test [] [Classification: (null)] [Priority: 3] {TCP} 172.25.23.2:44818 -> 172.25.23.1:31304
08/19/2020-15:48:38.125584 [] [1:6450008:1] SURICATA enip test [] [Classification: (null)] [Priority: 3] {TCP} 172.25.23.1:31304 -> 172.25.23.2:44818
08/19/2020-15:48:38.125584 [] [1:6450008:1] SURICATA enip test [] [Classification: (null)] [Priority: 3] {TCP} 172.25.23.1:31304 -> 172.25.23.2:44818
08/19/2020-15:48:42.160720 [] [1:6450008:1] SURICATA enip test [] [Classification: (null)] [Priority: 3] {TCP} 172.25.23.2:44818 -> 172.25.23.1:31304
08/19/2020-15:48:38.125584 [] [1:6450008:1] SURICATA enip test [] [Classification: (null)] [Priority: 3] {TCP} 172.25.23.1:31304 -> 172.25.23.2:44818
08/19/2020-15:48:42.160720 [] [1:6450008:1] SURICATA enip test [] [Classification: (null)] [Priority: 3] {TCP} 172.25.23.2:44818 -> 172.25.23.1:31304
In fact, all protocols that do not associate a request with a response have this problem.
I have make a pull request; https://github.com/OISF/suricata/pull/5313.