NPM experts may view NetFlow and packet-based analytics as competing approaches to the same problem, but the reality is that both have merits that complement each other to accelerate network investigations.
The NetFlow adapter does not support response time reporting. All response times report as zero.
Filtering when opening a capture file does not work with encrypted files (such as those created by ORA) since Omnipeek has no means of filtering them before they are decrypted and opened.
Performing Forensic Searches on capture files other than standard *.pkt files (e.g., *.pcap, *.wpz, *.cap, and *.pcapng), are limited to a 256MB ring buffer. All packets are analyzed, so all statistics are accurate and reflect the entire search, but only the last 256MB worth of packets are available for viewing.
Application classification is done with entire packet contents before slicing is applied when saving packets, so when the file is reloaded the entire packet is no longer present which may result in different (or no) application classification.
Application classification may return different results if all the packets that make up a flow are not present, in particular the TCP handshake packets.
Cisco and Aruba access points may report incorrect signal and noise percent values in Omnipeek.
In a tcpdump capture, if no packets are filtered and you stop the capture on some remote systems (e.g., Mac OS and Debian Linux), the remote tcpdump processes might not shut down. You may need to SSH into the remote system and shut down the tcpdump processes manually.
Compass does not take Inter Frame Gap into account in utilization calculations, which results in the utilization calculations in the Compass dashboard to be different from the utilization calculations in the Network dashboard.
If the installer launches Omnipeek for you, it is not possible to open a file by double-clicking or ‘dragging and dropping’ it in Omnipeek.