[HN Gopher] Wireshark 4.6.0 Supports macOS Pktap Metadata (PID, ...
___________________________________________________________________
Wireshark 4.6.0 Supports macOS Pktap Metadata (PID, Process Name,
etc.)
Author : c0nsumer
Score : 118 points
Date : 2025-10-14 14:18 UTC (8 hours ago)
(HTM) web link (nuxx.net)
(TXT) w3m dump (nuxx.net)
| happyPersonR wrote:
| One piece of modern software without which, modern society would
| not exist. People don't realize there's no real alternative.
| armitron wrote:
| 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).
| ellg wrote:
| 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.
| elevation wrote:
| 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 wrote:
| 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 wrote:
| https://wiki.wireshark.org/Development/sharkd
| rhynolite wrote:
| 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.
| colechristensen wrote:
| >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 wrote:
| 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_o
| pen...
| ellg wrote:
| 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)
| bobthebuilders wrote:
| 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.
| c0nsumer wrote:
| > 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://gitl
| ab.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.".
| j45 wrote:
| 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.
| trillic wrote:
| Wireshark != Wireguard
| j45 wrote:
| Total misread on my part. I was trying to figure out how
| this was relevant to wireguard.
|
| Wireshark is great.
| fujigawa wrote:
| 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!
| Avamander wrote:
| Any ways to bring that to Linux or Windows? I've long yearned for
| a solution for this.
| c0nsumer wrote:
| 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.
| westurner wrote:
| 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?
| colechristensen wrote:
| 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.
| chatmasta wrote:
| 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...
___________________________________________________________________
(page generated 2025-10-14 23:01 UTC)