tcpdump on Mac: sudo, MAC Address Filters, and a -P Segfault

On the Mac mini that runs this business, every tcpdump capture I tried without sudo failed with exit code 1, and the errors weren't consistent. With no interface given, it said ioctl(SIOCIFCREATE): Operation not permitted, which mentions neither tcpdump nor permissions. Given an interface that doesn't exist, -i nosuch, it said You don't have permission to capture on that device. Reading a saved file worked fine, and that's where I hit the worse problems. One of Apple's own flags, -P, crashed tcpdump with a segmentation fault in 3 of 3 runs. Another, -Q 'proc = curl', was supposed to keep only curl's packets and instead printed all of them, with exit code 0.

"tcpdump mac" gets 96 Google autocomplete completions in our collection. They split two ways: running it on a Mac ("install tcpdump on mac", "how to run tcpdump on mac") and filtering by MAC address ("tcpdump with mac address", "tcpdump mac address filter"). This post covers both. Everything below was run on macOS 26.4.1 as a user without sudo, against the system tcpdump and a 3-packet capture file I generated.

It's already installed: tcpdump on macOS

No install step. macOS ships it at /usr/sbin/tcpdump:

$ tcpdump --version
tcpdump version 4.99.1 -- Apple version 158
libpcap version 1.10.1
LibreSSL 3.3.6

That's older than upstream. On 2026-10-06 tcpdump.org lists tcpdump 4.99.7 and libpcap 1.10.7, and Homebrew's tcpdump formula is at 4.99.7. I didn't install the Homebrew build. Two things to know before you do. It doesn't remove the root requirement, because that comes from the /dev/bpf* devices. It also won't have Apple's options, since the man page labels -k, -Q, -P and the pktap interface as Apple additions. Apple publishes its patched source as tcpdump-158 on its open-source mirror, which is what I read for the line references below.

Why tcpdump on Mac needs sudo

Capturing means opening a BPF device, and on this Mac all of them are root-only:

$ ls -l /dev/bpf0
crw-------  1 root  wheel  0x17000000 Oct  5 10:28 /dev/bpf0

Every live-capture form I tried failed with exit code 1. The message depends on which interface you name:

Command (no sudo)	Error	Exit
tcpdump -D	none: lists 24 interfaces	0
tcpdump (no -i)	ioctl(SIOCIFCREATE): Operation not permitted	1
tcpdump -i any, -i all, -i pktap, -i iptap	same SIOCIFCREATE error	1
tcpdump -i en1	You don't have permission to capture on that device ((cannot open BPF device) /dev/bpf0: Permission denied)	1
tcpdump -i nosuch	same permission error, for an interface that doesn't exist	1
tcpdump -d 'ether host …'	SIOCIFCREATE: even compiling a filter opens a device	1
tcpdump -i en1 -w out.pcap	permission error; out.pcap is not created	1
tcpdump -r file.pcap	none: reading files needs no root	0

The SIOCIFCREATE error comes from Apple's default. Upstream tcpdump picks the lowest-numbered interface that's up, and the first paragraph of the macOS man page still says so. Apple's code does something else: tcpdump.c line 2613 sets device = PKTAP_IFNAME when you don't pass -i. With no interface given, tcpdump on a Mac tries to create a pktap pseudo-interface that taps several interfaces at once, and creating an interface is the step that's refused. tcpdump -D runs without root, but it never lists pktap, all or iptap, so the default device doesn't appear among the 24 it prints.

So the answer to "how to run tcpdump on mac" is sudo tcpdump -i en0, where en0 is whichever interface carries your traffic. On this Mac mini that's en1 (Wi-Fi), as I found in ifconfig on Mac. Wireshark has the same problem on a Mac, and its macOS guide says that to capture "you must install the ChmodBPF launch daemon". As the name says, it changes the permissions on the /dev/bpf* devices, and those are the same devices tcpdump opens. That's the usual route to capturing without typing sudo. I haven't installed it here, so I haven't tested it.

If all you need is to check a filter, give -d a capture file to compile against. It skips the device and prints the BPF program:

$ tcpdump -d -r t.pcap 'ether host 4:5:6:7:8:9'
reading from file t.pcap, link-type EN10MB (Ethernet)
(000) ld       [8]
(001) jeq      #0x6070809       jt 2	jf 4
(002) ldh      [6]
(003) jeq      #0x405           jt 8	jf 4
...
(008) ret      #65535
(009) ret      #0

tcpdump MAC address filter

To filter by MAC address you need the ether qualifier, and to see MAC addresses in the output you need -e. To test them without sudo I wrote a 22-line Python script that writes a 3-frame Ethernet capture: an ARP request from 04:05:06:07:08:09 to broadcast, and a UDP packet each way between that address and 02:1a:2b:3c:4d:5e, using the 192.0.2.0/24 documentation range. I chose the first address because every byte has a leading zero. In the arp command on Mac I found that arp prints those bytes without the zero (4:5:6:7:8:9), so a grep for the padded form misses them.

Filter	Packets matched (of 3)	Exit
ether host 04:05:06:07:08:09	3	0
ether host 4:5:6:7:8:9 (arp's format)	3	0
ether host 04-05-06-07-08-09	3	0
ether host 0405.0607.0809	3	0
ether host 040506070809	3	0
ether src 4:5:6:7:8:9	2	0
ether host 4:5:6:7:8:9 and udp	2	0
host 4:5:6:7:8:9	ethernet address used in non-ether expression	1
ether host 48:3a:2:0:0:1 (absent)	0, no message	0

All five spellings compiled to the same match, so you can paste a MAC straight from arp -an. The output is the other direction. tcpdump pads every byte, which means a grep built from arp's output won't find the address in tcpdump's text:

$ tcpdump -r t.pcap -n -e
23:13:20.000000 04:05:06:07:08:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.0.2.1 tell 192.0.2.10, length 46
23:13:21.000000 04:05:06:07:08:09 > 02:1a:2b:3c:4d:5e, ethertype IPv4 (0x0800), length 54: 192.0.2.10.50000 > 192.0.2.20.9: UDP, length 12

One caution for scripts: a filter that matches nothing exits 0 with no output, the same as a capture where nothing happened. A typo like ether hots does exit 1 (can't parse filter expression: syntax error), so syntax errors show up but a wrong address doesn't. On a live capture you'll also see fewer MACs than you expect to recognize. In the arp post, 55 of 85 neighbors on our Wi-Fi had a private, locally administered address. A filter on a phone's private address can stop matching if the phone later switches to a new one.

Apple's extra flags misbehave on capture files

Apple's tcpdump can tag each packet with the process that sent it. You turn the display on with -k, filter on it with -Q, and save it with -P, which writes pcapng. The man page says the metadata filter is "meaningful only with capture files in the Pcap-ng file format or for interfaces supporting the PKTAP data link type". What it doesn't mention is what happens when you use it anywhere else:

• -Q is silently ignored on a plain pcap. tcpdump -r t.pcap -Q 'proc = curl' printed all 3 packets, none of them from curl, with exit code 0 and no warning. So did -Q 'if = en'. In tcpdump.c the expression is evaluated in exactly two places, both pcapng handlers (handle_pcap_ng_dump and print_pcap_ng_block), and a plain pcap goes through neither. If a script filters by process on the wrong kind of file, it gets every packet back and no error.
• -k is silently ignored too. Plain, -k and -k NP printed identical lines, exit 0.
• -P crashes when you convert a file. tcpdump -r t.pcap -w out.pcapng -P exited 139 (segmentation fault) in 3 of 3 runs. It did the same with a filter added and when writing to stdout. Each run left a crash report in ~/Library/Logs/DiagnosticReports/: EXC_BAD_ACCESS at address 0x0, inside strlen, called from libpcap's pcap_if_info_set_add via pcap_ng_setup_dump. That function starts with strlen(name) on the interface name, and a file being read has no interface. The 188-byte file it left behind holds only a section header, and tcpdump can't read it back (the capture file has no Interface Description Blocks, exit 1). Without -P, the same command wrote a 240-byte pcap that replays all 3 packets.
• -g eats a character. --apple-oneline is supposed to put verbose output on one line for parsing. With -v the line came out as proto UDP (17), length 40192.0.2.10.50000 > 192.0.2.20.9: the length (40) and the source address run together. print-ip.c line 457 skips the whole ")\n " string when -g is set, so the closing parenthesis and the separating spaces go along with the newline. A parser splitting on that line will read a length of 40192.

None of this touches live captures with sudo. That's the case these flags were built for, and there -P has an interface name to work with. The trouble is when you capture as root and post-process as yourself, which is exactly the split the root requirement pushes you toward.

What people ask about tcpdump on macOS

I pulled every question with "tcpdump" in the title from Apple Stack Exchange (2) and from Super User tagged macos (5) through the Stack Exchange API. Seven is too few to rank anything, but two stand out. The most viewed, Super User 904786 (122,035 views), is about rotating capture files with -G, -W and -C. On Apple Stack Exchange, question 476020 asks why tcpdump and Wireshark don't see DNS requests from the browser or ping, and has no accepted answer. I can't capture to test it without sudo. I've covered the resolver side, where macOS answers DNS lookups, in nslookup on Mac. For a hop-by-hop view without packet capture, see traceroute on Mac.

What I didn't run

No live capture: this account has no sudo, so every capture result above is a failure, and -k and -Q were never tested on a real pktap capture with process metadata. I didn't install ChmodBPF, Wireshark or Homebrew's tcpdump. The libpcap source line is from Apple's libpcap-146 tag. The installed library reports itself as libpcap 1.10.1, and I haven't confirmed which Apple tag it was built from. The crash report's stack does match that function.

Measured on 2026-10-06 on a Mac mini M4 (Mac16,10), macOS 26.4.1 (25E253), with /usr/sbin/tcpdump 4.99.1 (Apple version 158), as a user without sudo. Exit codes were read directly, not through a pipe. Filter and flag tests ran against a 3-frame pcap written by my own script, with documentation-range IPs and made-up MAC addresses. Crash details come from the system's own crash reports. Source references are to tags tcpdump-158 and libpcap-146 in Apple's open-source mirror. The Q&A list is every Stack Exchange API result for title=tcpdump on Apple Stack Exchange and on Super User with tag macos, as of the same day.