[elevation]

As a constant Wireshark user who's personally thanked Gerald Combs for this tool, we don't need an alternative to wireshark, just some architectural refactors. Many packet dissection fields are embarrassingly parallel, but because some of them can involve previous/future packets, wireshark does all packet dissection in a single thread. So when I scoop up 10M packets it can take 20 minutes for the GUI to load them all with a single core, while 100 other cores on the same machine sit idle.

Once loaded, you have to be super careful. One update to the filter bar, like "!icmp" and you'll have to wait another 20 minutes for all the dissectors to be re-run (for some reason.)

As a previous commenter stated, if you work with Wireshark a lot, you eventually write your own tool for your performance needs. It feels magical to have a 3-page C program sitting over libpcap giving reports in miliseconds that would take wireshark minutes.

[rhynolite]

FWIW, Wireshark 4.6.0 ships with `sharkd`, which encapsulates all the EPAN dissectors into a simple to use server that accepts JSON-RPC requests.

It is quite easy to write specialized performance tools on top of `sharkd`, and since it has the entire power of the EPAN (including statistics, charts etc.), using `sharkd` is significantly more effective than reading straight from libpcap.

[vdm]

https://wiki.wireshark.org/Development/sharkd

[rhynolite]

The `sharkd` has been around for quite some while, but until recently one had to build it from source. But now it is included in Wireshark DMG, so it is easier to use.

[ellg]

You're right, and I didnt mean to sound dismissive of the great work that has been put into wireshark. I agree with you on the refactoring comment, and if that's something that can be solved in the current codebase and something I can help contribute towards with donations I would be perfectly fine with this outcome as well.

As it stands though, using the gui bits of the wireshark family of tools is just painful, and slow (as you stated)

[colechristensen]

>It feels magical to have a 3-page C program sitting over libpcap giving reports in miliseconds that would take wireshark minutes.

Any demos available of something like this?

[elevation]

Sadly proprietary, but the core of it was to open a file with pcap_open_offline() [0], and then calling pcap_next() from a loop and reading a few bits out of the packet buffer. With NVMe disks, the information I needed was instantaneous for a 10M packet file.

https://manpages.debian.org/stretch/libpcap0.8-dev/pcap_open...