Wild exaggeration. Wireshark is very limited in what it can do and has gained few if any new power-user features (especially when it comes to extensibility and programmability) in more than a decade of development. The macOS-specific functionality in this very post has been available for years.
Anyone who relies on non-trivial packet capture or processing workflows, ditches Wireshark (optionally reusing dissectors) and writes custom tooling (which is very easy to do).
And I know with certainty that it did not work when I wrote my previous blog post about this, back in 2021.
So, from what I can see, the specific functionality to dissect Darwin metadata in pcapng captures, from macOS' tcpdump, has not been "...available for years.".
Even the dissector stuff feels so.. broken? unmaintained? The lua api is very annoying to use and python support was removed over a decade ago. Have not used the C API so maybe thats just what most people use and its good, but for my usecase I usually just want to quickly sketch out a view for a custom protocol that I can see in the UI.
I would absolutely love for someone to write a good alternative to wireshark.
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.
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.
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.
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)
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.
I think it is not an exaggeration to say that without Wireshark, so much of modern computing would never have been developed and we would be stuck in the past. The amount of visibility it gives is immense. I have used it for years, decades now.
VPNs have existed for a long time, while wireshark is the current new curve, there will always be the next curve that emerges and evolves to replace the current one.
You can do this with any capture device if you pipe the output to a FIFO handle and open it in wireshark. It can be a bit janky and you’re usually better off using the GUI configs when they’re available. But it gives you a bunch of flexibility to do things like “capture tcpdump in a docker exec in an SSH session on a remote host” [0].
It supports ETW as an input format, but I (personally) haven't yet gotten my head around how to do the same.
My current worflow is capture with pktmon, then analysis in Microsoft Network Monitor to expose PID stuff.
I figure there /has/ to be a way to do it similarly in Wireshark, I just haven't found a how-to and haven't dug into it myself. Once I do (it's on my casual todo list) I'll do a writeup on that as well, since it'd be super useful.
> ptcpdump is a tcpdump-compatible packet analyzer powered by eBPF, automatically annotating packets with process/container/pod metadata when detectable. Inspired by jschwinger233/skbdump.
One piece of modern software without which, modern society would not exist. People don’t realize there’s no real alternative.
Melodramatic, and more importantly, wrong.
> People don’t realize there’s no real alternative
EtherPeek/OmniPeek has entered the chat
There were tools before Wireshark, and there will be tools after it's long gone. Just because you haven't heard of them doesn't mean they don't exist!
Wild exaggeration. Wireshark is very limited in what it can do and has gained few if any new power-user features (especially when it comes to extensibility and programmability) in more than a decade of development. The macOS-specific functionality in this very post has been available for years.
Anyone who relies on non-trivial packet capture or processing workflows, ditches Wireshark (optionally reusing dissectors) and writes custom tooling (which is very easy to do).
> The macOS-specific functionality in this very post has been available for years.
Can you provide a reference? From what I can see this dissection was only added about five months ago: https://gitlab.com/wireshark/wireshark/-/commit/389f6356c9d5...
(And just hit release with 4.6.0.)
And I know with certainty that it did not work when I wrote my previous blog post about this, back in 2021.
So, from what I can see, the specific functionality to dissect Darwin metadata in pcapng captures, from macOS' tcpdump, has not been "...available for years.".
Even the dissector stuff feels so.. broken? unmaintained? The lua api is very annoying to use and python support was removed over a decade ago. Have not used the C API so maybe thats just what most people use and its good, but for my usecase I usually just want to quickly sketch out a view for a custom protocol that I can see in the UI.
I would absolutely love for someone to write a good alternative to wireshark.
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.
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.
https://wiki.wireshark.org/Development/sharkd
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.
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)
>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?
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...
I think it is not an exaggeration to say that without Wireshark, so much of modern computing would never have been developed and we would be stuck in the past. The amount of visibility it gives is immense. I have used it for years, decades now.
[dead]
Edit: Misread name, can't delete comment.
VPNs have existed for a long time, while wireshark is the current new curve, there will always be the next curve that emerges and evolves to replace the current one.
Wireshark != Wireguard
Total misread on my part. I was trying to figure out how this was relevant to wireguard.
Wireshark is great.
Recently I discovered you can use an android device as a live remote capture device for bluetooth and Internet captures and iOS for Internet captures.
Not creating a capture and then downloading it, actual real time network captures.
You can do this with any capture device if you pipe the output to a FIFO handle and open it in wireshark. It can be a bit janky and you’re usually better off using the GUI configs when they’re available. But it gives you a bunch of flexibility to do things like “capture tcpdump in a docker exec in an SSH session on a remote host” [0].
[0] https://gist.github.com/milesrichardson/fcec8c6d54a21845dd9f...
Any ways to bring that to Linux or Windows? I've long yearned for a solution for this.
It supports ETW as an input format, but I (personally) haven't yet gotten my head around how to do the same.
My current worflow is capture with pktmon, then analysis in Microsoft Network Monitor to expose PID stuff.
I figure there /has/ to be a way to do it similarly in Wireshark, I just haven't found a how-to and haven't dug into it myself. Once I do (it's on my casual todo list) I'll do a writeup on that as well, since it'd be super useful.
ptcpdump: https://github.com/mozillazg/ptcpdump :
> ptcpdump is a tcpdump-compatible packet analyzer powered by eBPF, automatically annotating packets with process/container/pod metadata when detectable. Inspired by jschwinger233/skbdump.
awesome-ebpf > Tools: https://github.com/zoidyzoidzoid/awesome-ebpf#tools
opensnitch is an egress firewall that displays PIDs: https://github.com/evilsocket/opensnitch
edgeshark: https://github.com/siemens/edgeshark :
> Discover and capture container network traffic from your comfy desktop Wireshark, using a containerized service and a Wireshark plugin.
Looks like it's possible to select containers from a GUI form with edgeshark. Perhaps something similar for process selection?