The same capture above, writing to a file called out.cap, would be as follows: Recording this requires using the pktap pseudo interface (see the tcpdump man page about the -interface argument) to ensure this data is saved into the file. This would be very nice, as it’d make parsing large captures much easier.įor now it seems the best way to do this is to record the capture to a file, then feed it back into tcpdump. Unfortunately, due to the non-standard way Apple writes this metadata into files, it’s not viewable in Wireshark. The bold line is the packet going out to 8.8.8.8, and the pid dig.76987 portion shows that it’s from a dig process, which had process ID 76987. Tcpdump: verbose output suppressed, use -v or -vv for full protocol decode In this example I’m filtering on just the host 8.8.8.8 ( Google Public DNS) then running dig in another window to look up ~ % sudo tcpdump -k -i en0 host 8.8.8.8 Using tcpdump with the -k argument one can print process name and PID to the console. On Windows this is very easy using Pktmon / netsh trace / Network Monitor to do a capture, but on macOS it’s not that straightforward. While there are ways to look at which process has an open socket or whatnot, this doesn’t help with UDP, and it’s often quite useful to simply do a recording then later see which process is responsible for creating a packet. There are many times when one wants to see which process is responsible for network traffic on a endpoint.
0 Comments
Leave a Reply. |