This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Seeing PKTAP metadata in Wireshark GUI

0

I've just discovered pktap, an Apple pseudo interface which adds info about the process id particularly.

sudo tcpdump -q -n -i pktap,en0 -k
21:02:59.849248 (en0, proc Google Chrome:244, svc BE, out) IP 192.168.178.54.53338 > 199.16.156.230.443: tcp 0

As I've seen this page regarding pktap display filter, https://www.wireshark.org/docs/dfref/p/pktap.html, my guess was that Wireshark was able to decode that as well, not only the cli of macOS.

I've tried to save the file, but I didn't succeed to reopen the pcapng with the medata informations.

sudo tcpdump -q -n -i pktap,en0 -k -w mytrace.pcapng

I've discovered that launching tcpdump -i pktap creates a pseudo pktap0 interface during the capture, and running a second tcpdump on that pktap0 interface doesn't save any medatadata neither...

How can I save a pcapng on macOS and be able to reopen it later, showing that processus metadata in Wireshark GUI and using PKTAP display filters?

asked 04 Jul '16, 12:12

TomLaBaude's gravatar image

TomLaBaude
66171724
accept rate: 66%


One Answer:

0

tcpdump, when capturing from a pktap interface, doesn't write out the raw PKTAP header; what Wireshark can dissect is the raw pktap header. Instead, it writes out the pktap metadata using various pcap-ng features - including the "local use" block types, which they use for a block they call a Process Information Block (PIB), with a block code of 0x80000001, containing information about a process, and the "local use" option types, which they use for an Enhanced Packet Block option they call the "PIB index", with an option code of PCAPNG_EPB_E_PIB_IN, containing the index of the previously-seen Process Information Block corresponding to the process to or from which the packet was sent.

Sadly, that means that their pcapng files might be misread by programs in which a block code of 0x80000001 is interpreted as another type of block or in which an EPB option code of 0x8003 is interpreted as another type of option.

Wireshark won't have a problem with that block or that option - it'll just ignore them.

Wireshark would have to be changed to have a preference to let it interpret them as the Apple-specific local blocks and options.

The pcapng specification has been updated to include support for "custom" blocks and options, the tags for which include a "Private Enterprise Number" (PEN) for an organization, so that Apple could have a block type and option types with a PEN of 63, which would always be interpreted as their block and options.

Or they could get together with the HONE people and others and come up with something to put into the pcapng standard to use to mark packets as going to or from a particular process.

answered 04 Jul '16, 16:56

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Hi Guy, thanks for your detailed answer. Thanks to your answer, I've successfully seen the process id and process string in an hexa editor before some packets of my pcapng file. ("Google Chrome", "firefox", ...)

Considering Wireshark/tshark development, perhaps an alternative, while Apple metadata are not standard yet, would be to show/access the various blocks of the pcapng (which are standards) After it would be up to the user to deal/interpret with the content of each block. I'll fill a bug about it.

(06 Jul '16, 03:01) TomLaBaude