Wireshark on Kali Linux: Fix "No Interfaces Found" and "Couldn't Run dumpcap: Permission Denied", Capture Without sudo, and Filters That Work

If Wireshark on Kali Linux shows no interfaces, or says Couldn't run dumpcap in child process: Permission denied or You do not have permission to capture on device, your user account is not allowed to capture yet. Run sudo dpkg-reconfigure wireshark-common and choose Yes, then sudo usermod -aG wireshark $USER, then log out and log back in (the step everyone skips). Check with id -nG: if the word wireshark is there, open Wireshark as yourself, not with sudo, and your network cards will be listed.

Jake's receipt printer kept dropping off the shop's network a few times a day, always at the busiest moment. Ethan brought in his Kali laptop to watch what the printer was actually sending. He opened Wireshark, and the start screen offered him a list of strange remote-capture tools and not a single network card. "It can't see the network?" Jake asked. "It can see it fine," Ethan said. "It just won't let me look yet. Give me two minutes and a logout."

New to Kali or to Wireshark? That is fine; this guide starts at the beginning. Kali Linux is a Debian-based Linux system built for security testing, and Wireshark is the best-known tool in it for looking at network traffic: every message your computer sends or receives, shown one packet at a time, with every field decoded in plain language. It is used every day by network engineers, help-desk staff, developers and students, mostly to answer boring but important questions such as "is this device even talking?" and "why is this so slow?". The commands below use sudo and apt; if those words are new, apt, dpkg and sudo explained takes five minutes.

What Wireshark actually does (in plain English)

Everything your computer says on a network is broken into small pieces called packets. A web page, a DNS lookup that turns a name like kali.org into an address, a print job: all of them leave and arrive as packets. Normally your system reads each packet, hands its contents to the right program and forgets it. Wireshark asks for a copy of every packet as it passes through a network interface (your Ethernet port, your Wi-Fi card, or the loopback interface your computer uses to talk to itself), then lays the copies out so you can read them.

That makes it a recording tool, not a remote control. Wireshark does not change your traffic, block anything or break into anything. It shows you what is already passing through your own interface. What it shows is often surprising, which is the point.

On Kali, "Wireshark" is really three programs that work together, and knowing this makes every error on this page easy to read:

• wireshark is the window you see: the packet list, the decoded details and the filters. It never touches the network card itself.
• tshark is the same engine in the terminal. Same filters, same decoding, text output. Great for servers and for quick checks.
• dumpcap is the small program that actually opens the network interface and records packets. Both wireshark and tshark start it in the background whenever you capture.

Only dumpcap needs special rights, because only it talks to the network hardware. The big program that decodes thousands of protocols runs as you, an ordinary user. Wireshark's developers built it this way on purpose, and it is why the fix is "give dumpcap the right to capture and let your account run dumpcap", not "run Wireshark as root".

Jake: "So the screen and the microphone are separate."

Ethan: "Exactly. The microphone is locked in a cupboard. I need the key to the cupboard, not a key to the whole building."

Is Wireshark already on Kali? Install, open and check it

On a standard Kali install, yes. Wireshark is part of Kali's default, large, everything and top10 tool sets, so most installs and the live images already have it. Check from a terminal:

tshark --version | head -1
TShark (Wireshark) 4.6.6

If the command is not found, install it. The terminal version comes in its own package, and the window version pulls in everything it needs:

sudo apt update
sudo apt install wireshark      # the window (includes dumpcap)
sudo apt install tshark         # the terminal version

During the install, a blue screen asks "Should non-superusers be able to capture packets?" This single question decides most of what follows. On Debian, the system Kali is built on, the default answer is No, which means only root may capture. Choose Yes. If you already answered, or it never asked because Wireshark came preinstalled, you can change the answer at any time (step 2 of the fix). If apt cannot find the package at all, your sources file is the problem, and Kali "Unable to locate package" fixes that first.

To open Wireshark, search for it in the applications menu or type wireshark in a terminal, as your normal user. The start screen lists interfaces with a small live graph of traffic next to each. If that list has your network card, you are done. If it only shows entries such as ciscodump, sshdump and udpdump, read on.

The error messages, decoded

Wireshark's messages on Linux are more helpful than most, once you know which situation each one belongs to. These are the exact texts from Wireshark 4.6.6 on Kali:

One detail from that table trips people up in a way that wastes real time. When dumpcap has no capture rights, every interface name produces the permission error, including names that do not exist. Asking a freshly installed, unconfigured Wireshark for eth0 on a machine whose card is called wlan0 still answers You do not have permission to capture on device "eth0", not "no such device". The permission check comes first. Fix permissions before you start doubting the interface name, and only then trust the There is no device named message.

Ethan: "The bouncer turns you away before checking whether the club even exists."

Fix it: capture as a normal user in five steps

These steps work on Kali installed on a laptop or desktop and in VirtualBox or VMware. They take about two minutes, most of which is logging back in.

1. Check what you have now.

   ls -l /usr/bin/dumpcap
   getcap /usr/bin/dumpcap
   id -nG

   A configured system shows -rwxr-xr-- 1 root wireshark, /usr/bin/dumpcap cap_net_admin,cap_net_raw=eip, and the word wireshark in your groups. Anything missing tells you which step to do.
2. Allow non-root capture.

   sudo dpkg-reconfigure wireshark-common

   Choose Yes (use the arrow keys, then Enter). This creates the wireshark group if needed, makes dumpcap runnable only by root and that group (root wireshark, mode -rwxr-xr--), and gives it exactly two Linux capabilities: cap_net_raw to open raw packet sockets and cap_net_admin to set capture options on interfaces.
3. Add yourself to the group.

   sudo usermod -aG wireshark $USER

   The -a matters: without it, usermod -G replaces your other groups instead of adding one, and you can lose sudo rights in the same command.
4. Log out and log back in (or restart). Closing the terminal is not enough; the whole desktop session needs to start again. The next section shows why.
5. Prove it works.

   id -nG                      # should now include: wireshark
   dumpcap -D                  # lists your interfaces
   tshark -i wlan0 -c 5        # captures five packets, no sudo

   Use your own interface name in the last line (eth0 is common on wired machines and virtual machines). Then open Wireshark from the menu; your cards now appear with their little traffic graphs.

If you would rather not use the group at all, a one-user machine can skip steps 2 and 3 with sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap on a dumpcap that everyone may run. That lets every account on the machine capture, which is fine on a personal laptop and wrong on a shared one. The group approach is the safer default.

Jake: "That's it? Five commands and a logout?"

Ethan: "Four commands. The fifth is just checking I didn't lie to you."

Why it still fails right after usermod

This is the single most common reason people think the fix "didn't work". Linux gives every program its list of groups at the moment you log in, and that list never updates while the program runs. Your desktop session, and every terminal and app started from it, keeps the groups you had when you logged in. usermod changes the account; it does not change sessions that already exist.

Here is the same account, checked from a session opened just before usermod and from a fresh login just after it:

# session that was already open
$ id -nG
kali
$ tshark -D
tshark: Couldn't run dumpcap in child process: Permission denied
1. ciscodump (Cisco remote capture)
...

# fresh login, same account, seconds later
$ id -nG
kali wireshark
$ tshark -D
1. wlan0
2. any
3. lo (Loopback)

Meanwhile getent group wireshark already listed the user in both cases. That is why checking the group file proves nothing; id -nG in the session you are actually using is the honest test. To try the new group without logging out, run newgrp wireshark in a terminal, or sg wireshark -c wireshark to start Wireshark in it. Both only affect that one terminal and what you start from it, so a real logout is still the clean fix.

Why the list shows ciscodump and sshdump but not your network card

The list on Wireshark's start screen comes from two places. Real interfaces come from dumpcap. The others, such as ciscodump, sshdump, udpdump, wifidump, randpkt and sdjournal, are extcap helpers: small separate programs that fetch packets from somewhere else (a router over SSH, a systemd journal, a random packet generator) and need no capture rights on your machine.

When Wireshark cannot run dumpcap, it shows only the extcap entries. So a start screen full of odd tool names and empty of cards is not "no interfaces found"; it is "dumpcap would not start", which is exactly the Couldn't run dumpcap case above. With dumpcap working, the same list starts with your cards, then any, lo, and a few Linux extras such as bluetooth-monitor, nflog and dbus-system, followed by the extcap tools at the bottom.

When capture breaks again: lost capabilities

Capabilities live in the file's extended attributes, and several ordinary file operations wipe them without a word. This one surprised even experienced users: running chown on dumpcap, even to the same owner and group it already had, removes them.

$ getcap /usr/bin/dumpcap
/usr/bin/dumpcap cap_net_admin,cap_net_raw=eip
$ sudo chown root:wireshark /usr/bin/dumpcap
$ getcap /usr/bin/dumpcap
$                                    # nothing: the capabilities are gone
$ tshark -i wlan0 -c 1
tshark: You do not have permission to capture on device "wlan0".
(Attempt to create packet socket failed - CAP_NET_RAW may be required)

Other ways to end up in the same place:

• Copying dumpcap, or restoring it from a backup that does not keep extended attributes.
• A Wireshark built from source and installed in /usr/local/bin. The package's setup only configures /usr/bin/dumpcap; yours needs its own setcap. Run which -a dumpcap to see which one you are using.
• Running dumpcap from a drive mounted with nosuid, which tells Linux to ignore both setuid bits and file capabilities on it.
• A file system without extended attributes, where capabilities cannot be stored at all. When setcap fails, or the setcap tool (package libcap2-bin) is not installed, the package setup falls back to a setuid-root dumpcap instead.

The repair is the same in every case: sudo dpkg-reconfigure wireshark-common and Yes again, or sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap directly. Then getcap to confirm. A routine apt upgrade of Wireshark runs the same setup again with your saved answer, so updates do not usually break it. The one exception is a manual dpkg-statoverride on dumpcap: if an administrator set one, the package leaves dumpcap exactly as that override says and prints it instead (dpkg-statoverride --list /usr/bin/dumpcap shows it).

Why not just sudo wireshark?

Because it works, it is tempting, and every forum thread eventually suggests it. Wireshark itself answers the question in its first line of output:

$ sudo tshark -D
Running as user "root" and group "root". This could be dangerous.

The reason is the size of what runs. Wireshark contains decoders for thousands of protocols, and every one of them reads data straight from the network, including data a hostile device can shape however it likes. Decoders occasionally have bugs, and a bug in a program running as root is a bug with the whole system's permissions. With the group setup, only dumpcap, a small program that just records bytes, has extra rights, and even it gets only two narrow capabilities rather than full root.

There are practical problems too. On desktop sessions that restrict which users may draw on the screen, a root Wireshark may fail to open its window at all, with a "could not connect to display" style error. Capture files saved by a root Wireshark belong to root, so your normal account cannot edit or delete them later without sudo. And it teaches the habit of typing sudo in front of things to make errors go away, which is a habit worth not having on a security distribution. If you are logged in as root because of an old Kali image, Kali's default accounts explains the normal-user setup current images use.

Jake: "So sudo is the master key."

Ethan: "And the group is a key to one cupboard. You don't carry the master key around to fetch a broom."

Pick the right interface: eth0, wlan0, enp0s3, any and lo

Once permissions are sorted, the next question is which interface to watch. List them with their state and address:

ip -br link        # names and up/down state
ip -br addr        # names with IP addresses
dumpcap -D         # the names Wireshark will accept

• eth0: a wired card, and the usual name inside VirtualBox and VMware virtual machines.
• enp0s3, enp2s0, ens33: also wired cards, under the newer naming scheme based on where the card sits in the machine. Same thing, different label.
• wlan0: Wi-Fi. If you expect one and it is missing, the adapter is not detected; Kali Wi-Fi not detected covers that.
• any: a Linux pseudo-interface that captures from all interfaces at once. Handy when you are not sure where traffic goes. It cannot use promiscuous or monitor mode, and the packets lose their real link-layer headers.
• lo: loopback, your machine talking to itself. Watch this to debug a web server or database running on the same machine (localhost traffic never touches a real card).

Pick the interface that has an IP address in ip -br addr and a moving graph on Wireshark's start screen. A flat line means nothing is passing there right now. If your network vanished after an update and no interface has an address, Kali no network after update comes first.

Your first capture in five minutes, in the window and the terminal

In the window: double-click your interface on the start screen. Packets start scrolling. Visit a website, then press the red square to stop. Click any packet: the middle pane shows each layer decoded (Ethernet, IP, TCP or UDP, then the application), and the bottom pane shows the raw bytes. Save with File → Save As; the default .pcapng format keeps everything, including comments.

In the terminal, the same work in a few commands. These were all run as a normal user after the fix above:

# live view of DNS lookups, stop after 4 packets
tshark -i wlan0 -f "udp port 53" -c 4

# record to a file for 60 seconds, then stop on its own
dumpcap -i wlan0 -a duration:60 -w ~/caps/shop.pcapng

# read the file back and print just the names that were looked up
tshark -r ~/caps/shop.pcapng -Y dns -T fields -e dns.qry.name -e dns.flags.response

# a long capture split into files of about 10 MB, keeping only the newest 5
dumpcap -i wlan0 -b filesize:10000 -b files:5 -w ~/caps/ring.pcapng

The file-reading example printed each name twice, once with False (the question) and once with True (the answer), which is how DNS works: every lookup is a pair. The ring buffer creates files with a number and a timestamp in the name, such as ring_00001_20261022230608.pcapng, and quietly deletes the oldest once there are five. That is how you leave a capture running for a day, waiting for an intermittent problem like Jake's printer, without filling the disk.

Ways to stop a capture: -c N after N packets, -a duration:S after S seconds, -a filesize:KB at a size, or Ctrl+C. Ethan used a ring buffer with a capture filter on the printer's address, left the laptop under the counter, and had the answer by closing time: the printer was losing its address lease and asking for a new one every few hours, and the shop's router was slow to answer.

Split, merge, convert and summarize capture files

Kali's Wireshark package ships small command-line tools that save a lot of clicking once you have capture files, especially big ones or files someone else sent you. They need no capture rights, because they only read and write files.

# one-paragraph summary of a file: packets, size, duration
capinfos -c -d -u -E web.pcapng
File encapsulation:  Ethernet
Number of packets:   40
Data size:           11 kB
Capture duration:    0.180364026 seconds

# split a big capture into files of 10 packets each (use -i SECONDS to split by time)
editcap -c 10 web.pcapng part.pcapng
part_00000_20261022230525.pcapng
part_00001_20261022230525.pcapng
...

# merge several files back into one, in time order
mergecap -w merged.pcapng part_*.pcapng

# convert pcapng to the older pcap format for tools that need it
editcap -F pcap web.pcapng web.pcap

A file from tcpdump -w on a server, or from a router's packet capture page, opens directly in Wireshark, because they all share the pcap family of formats. A typical workflow for a problem on a remote server is: capture there with tcpdump or dumpcap and a capture filter, copy the file to your Kali machine, run capinfos to check you got what you expected, and only then open it in the window. Splitting a file of several gigabytes with editcap first keeps Wireshark responsive, since it keeps details about every packet in memory so it can filter instantly, and a huge file means a huge amount of memory.

Capture filters and display filters: two languages, both useful

Wireshark has two kinds of filter, with different syntax, and mixing them up is the most common beginner error after permissions:

Use a capture filter when you are recording for a long time and only care about one device or port, because everything else is never saved. Use display filters the rest of the time: record everything, then narrow the view as often as you like without losing anything.

Typing one language where the other is expected gives a clear error. A display-style expression as a capture filter:

$ tshark -i wlan0 -f "port == 53"
tshark: Invalid capture filter "port == 53" for interface '(null)'.

That string isn't a valid capture filter (can't parse filter expression: syntax error).

Capture filters use words (port 53), display filters use field names and operators (udp.port == 53). A typo in a display filter turns Wireshark's filter bar red, and tshark says so directly: "htp" is not a valid protocol or protocol field.

"Not equal" deserves its own warning. Many packets contain a field twice. A DNS lookup has two UDP ports, yours (a random number such as 42232) and the server's (53). In current Wireshark, udp.port != 53 means "no port equals 53", so it hides DNS completely, which is usually what you want: on the two-packet DNS capture above, it showed 0 packets. If you really mean "at least one port is not 53", write any udp.port != 53, which showed both. The same logic makes ip.addr != 192.168.1.50 the reliable way to hide one noisy host. Old tutorials written for much older versions describe different, confusing behavior here, so trust what your filter bar shows you over a decade-old forum answer.

Wireshark cannot filter by the program that sent traffic, because a packet does not carry a process name. On Linux, find the program's ports with ss -tunp (as root to see every process), then filter on those ports.

Wireshark not showing HTTP? It's HTTPS

You capture while loading a website, type http in the filter bar, and see nothing or almost nothing. Wireshark is fine. Nearly every website now uses HTTPS, where the content is encrypted inside TLS, and Wireshark can only label what it can read. Here is one capture containing two requests made with curl, one to http://example.com/ and one to https://example.com/:

$ tshark -r web.pcapng -Y http.request -T fields -e http.host -e http.request.uri
example.com	/                     # only the plain-HTTP request

$ tshark -r web.pcapng -Y tls.handshake.extensions_server_name \
    -T fields -e tls.handshake.extensions_server_name
example.com                           # the HTTPS one: name visible, content not

$ tshark -r web.pcapng -Y http2 | wc -l
0                                     # the encrypted request is invisible

Two lessons sit in those three commands. First, for "which sites did this device talk to", the display filter tls.handshake.extensions_server_name shows the site name that HTTPS sends in the clear at the start of each connection (the SNI), and the dns filter shows the names looked up. That answers most real questions. Second, the page contents stay hidden unless you have the session keys.

For your own browser or tools, you can have the keys. Programs that honor the SSLKEYLOGFILE environment variable, such as curl and Chrome-family browsers, write their TLS session keys to that file. Support in other browsers varies by version and build, so check yours before relying on it. Point Wireshark at it under Edit → Preferences → Protocols → TLS → (Pre)-Master-Secret log filename, or in the terminal:

SSLKEYLOGFILE=~/caps/keys.log curl -s -o /dev/null https://example.com/

$ tshark -r web.pcapng -o tls.keylog_file:$HOME/caps/keys.log \
    -Y 'http2.header.name == ":path"' -T fields -e http2.header.value
GET,https,example.com,/,curl/8.22.0,*/*

With the key log, the same HTTPS request decodes as HTTP/2: method, scheme, host, path and user agent. Treat that key file like a password. Anyone who has it and the capture can read the decrypted traffic, so delete it when you are finished and never set the variable permanently in your profile.

Reading a capture: the five views that answer most questions

A capture of even one minute can hold thousands of packets, and scrolling through them is how beginners give up. Wireshark has views that summarize the whole file for you. These five answer most real questions, and each has a terminal equivalent you can run on any saved file.

1. The packet list, read properly. Each row is one packet: number, time since the capture started, source, destination, protocol, length and a one-line summary in Info. The colors come from coloring rules you can see under View → Coloring Rules; the one to notice is the black row with red text, Wireshark's "Bad TCP" rule, which marks retransmissions, resets and other TCP trouble. A screen with a few black rows is normal. A screen that is mostly black is your problem.

2. Statistics → Conversations. Who talked to whom, how many packets and bytes each way, and for how long. This is the fastest way to find the device that is using all the bandwidth, or to confirm that a device you expected never spoke at all. In the terminal:

$ tshark -r web.pcapng -q -z conv,tcp
TCP Conversations
...  <-> ...:443    23 frames  9846 bytes  duration 0.1298
...  <-> ...:80     13 frames  1760 bytes  duration 0.0560

3. Statistics → Protocol Hierarchy. What kinds of traffic the capture holds, as a tree with percentages. On the two-request capture above it showed 40 frames: 36 over IPv4, 4 over IPv6, 10 of them TLS and 2 HTTP. If you expected a printer protocol and the tree has none, the device never sent it. Terminal: tshark -r file.pcapng -q -z io,phs.

4. Follow → TCP Stream. Right-click any packet and choose Follow to see the whole conversation as text, both directions, in order. For unencrypted protocols this is magic. The plain-HTTP request from earlier reads like a letter:

$ tshark -r web.pcapng -q -z follow,tcp,ascii,3
GET / HTTP/1.1
Host: example.com
User-Agent: curl/8.22.0
Accept: */*

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Server: cloudflare

The number at the end (3) is the stream index; find it with -Y http.request -T fields -e tcp.stream, or just click in the window.

5. Analyze → Expert Information. Wireshark's own list of things that look wrong, grouped as errors, warnings, notes and chats. Read it with some skepticism. On the tiny, perfectly healthy capture above it listed 10 warnings, including two Connection reset (RST) and eight TCP Zero Window segment: the resets were the system giving up on an IPv6 route that does not exist on that network, and nothing about the page load was actually broken. Expert information tells you where to look, not what is wrong. Terminal: tshark -r file.pcapng -q -z expert.

Two timing fields turn "it feels slow" into a number. dns.time on a DNS response is how long the answer took (the wireshark.org lookup earlier: 0.045 seconds), and http.time on an HTTP response is the time from request to response (the example.com page: 0.018 seconds). Add either as a column (right-click the field, Apply as Column) and sort; anything in whole seconds stands out immediately.

Jake: "So I don't read the book. I read the index."

Ethan: "And then you open the book at the page the index sends you to."

Worked example: why the shop's printer kept dropping off

This is how Ethan used everything above on Jake's problem, step by step, so you can reuse the pattern for any device that "randomly disconnects". Every filter here is a standard Wireshark display filter.

1. Find the device's addresses. The printer's settings page listed its IP and MAC address. Ethan filtered on the MAC rather than the IP (eth.addr == ...), because a device that loses its IP address keeps its MAC, and the moment of losing the IP was exactly what he wanted to see.
2. Record for a long time without filling the disk. A ring buffer with a capture filter on that MAC address (ether host ...), five files of 10 MB, left running through a working day.
3. Look at address assignment. The display filter dhcp showed every address request and reply. Adding the lease time (dhcp.option.ip_address_lease_time) as a column showed the router handing out leases of only a few hours.
4. Look at the requests that went unanswered. dhcp.option.dhcp == 3 shows DHCP Request messages. Each drop matched a Request near the end of a lease with no reply for over a minute, while the printer had already let go of its old address.
5. Rule out the other usual suspect. arp.duplicate-address-detected came back empty, so no other device was claiming the printer's address. That ruled out the classic "two devices with one IP" problem.

The fix was not on the printer at all: Ethan gave it a reserved address on the router, so it no longer had to ask, and the drops stopped the same day. That is the general shape of network troubleshooting with Wireshark: capture at the moment of the problem, filter down to one device, and read the conversation it had just before things went wrong.

Capturing Wi-Fi: monitor mode, the grayed-out checkbox and virtual machines

On Wi-Fi, a normal capture shows your own machine's traffic plus broadcast and multicast, delivered as if it were Ethernet. To see other devices' frames, Wi-Fi management traffic or signal strength, the adapter must be in monitor mode (also called rfmon). Promiscuous mode, which works on wired networks, does little on Wi-Fi: the adapter still only passes up traffic for the network it has joined.

• In the window: Capture → Options, find your Wi-Fi interface, and tick Monitor mode. If the box is grayed out, the system does not think the adapter or its driver can do it.
• In the terminal: add -I, for example dumpcap -i wlan0 -I -w ~/caps/air.pcapng. On an adapter that cannot do it, the answer is Capturing in monitor mode is not supported on device "wlan0". (That device doesn't support monitor mode).
• The Kali way: sudo airmon-ng check kill (stops services that fight over the card), then sudo airmon-ng start wlan0, which usually creates wlan0mon. Capture on wlan0mon, and run sudo airmon-ng stop wlan0mon and restart NetworkManager (sudo systemctl start NetworkManager) to get your normal Wi-Fi back. Monitor mode often disconnects the adapter from its network while it is on.

In VirtualBox or VMware, the virtual machine's network card is a virtual Ethernet card even when the host is on Wi-Fi, so there is no Wi-Fi to put in monitor mode. You need a USB Wi-Fi adapter whose chipset supports monitor mode, passed through to the virtual machine. Kali Wi-Fi not detected covers USB pass-through and which adapters work. If airmon-ng complains that it cannot change things on a busy interface, Kali "could not change MAC" explains the down-change-up order.

To see other machines' wired traffic from a VirtualBox guest on a bridged adapter, set the adapter's Promiscuous Mode to Allow All in the VM's network settings (under Advanced). The default, Deny, hands the guest only its own traffic, which looks exactly like "Wireshark isn't capturing anything from the other devices". Inside a container, the container also needs the NET_RAW and NET_ADMIN capabilities from whatever starts it, on top of everything on this page.

Capture only what you are allowed to

A quick word, because the autocomplete for "wireshark" includes "is it illegal". Using Wireshark is legal. Capturing traffic on networks and devices you own or manage, or that you have permission to test, is normal everyday work. Capturing other people's traffic on a network you have no permission to monitor, such as a café's Wi-Fi or a neighbor's, can break wiretapping and computer misuse laws in many countries, whatever the tool. Capture files can hold names, addresses and session data, so store them like any sensitive file and delete them when the job is done. Ethan captured the shop's printer on the shop's own network, with the owner standing next to him, which is about as clearly allowed as it gets.

The two-minute checklist

1. tshark --version works? If not, sudo apt install wireshark tshark.
2. ls -l /usr/bin/dumpcap shows root wireshark and getcap /usr/bin/dumpcap shows cap_net_admin,cap_net_raw=eip? If not, sudo dpkg-reconfigure wireshark-common → Yes.
3. id -nG includes wireshark? If not, sudo usermod -aG wireshark $USER, then log out and back in.
4. dumpcap -D lists your cards? Then open Wireshark as yourself, never with sudo.
5. The interface name is right? ip -br addr, and pick the one with an address.
6. Filtering? Capture filters use words (port 53); display filters use fields (udp.port == 53).
7. No HTTP visible? Filter on tls.handshake.extensions_server_name and dns, or use a key log for your own browser.
8. Wi-Fi from a VM? A USB adapter that supports monitor mode, passed through to the guest.

Frequently asked questions

The printer has not dropped off the network since the router's address settings were fixed, and Jake now asks to "see the packets" whenever a device misbehaves, which Ethan pretends to find annoying. The laptop stayed set up the safe way: Wireshark runs as Ethan's normal account, dumpcap holds its two small capabilities, and a ring buffer folder sits ready for the next mystery. "Funny," Jake said. "The fix for not seeing anything was a logout." Ethan nodded. "Most of the hard part of networking is knowing which boring thing to try first."

Revision note. Written October 22, 2026, with Wireshark and TShark 4.6.6 from the Kali repository and the error messages they print on a fresh install. "Look before you leap," the proverb says, and Wireshark is how you look.