Install Wireshark on Debian 13 / 12 Desktop

The package installs in one command. What stops people is the question the installer asks halfway through, and the fact that the default answer leaves you unable to capture a single packet. Wireshark on Debian ships with packet capture locked to root, on purpose, and nothing in the desktop menu tells you that. The fix is two commands and one logout.

Original content from computingforgeeks.com - post 27180

This guide covers how to install Wireshark on Debian 13 and Debian 12, what the dumpcap debconf question actually changes on disk, how to capture as a normal user through the wireshark group, and when to skip the GUI and install tshark instead. It also covers the packaging change that breaks older instructions, the Flathub build and what it cannot do, and remote capture over SSH. Everything below was tested in August 2026 on Debian 13 (Wireshark 4.4.16) with a GNOME desktop and on Debian 12 (Wireshark 4.0.17) headless. The packaging and permission work was done on both releases, the command line capture on the headless box, and the GUI, Flatpak and remote capture sections on the desktop.

Install Wireshark from the Debian repositories

Both releases carry Wireshark in main, so no third-party repository is involved. Refresh the package index and pull the GUI:

sudo apt update
sudo apt install wireshark

Partway through, apt stops and hands you a debconf dialog. This is the decision that determines whether the install is usable by you or only by root.

Note which button is highlighted. The default is No, and the template that ships in wireshark-common states why: enabling it “may be a security risk, so it is disabled by default”. Pressing Enter accepts No. So does any unattended install, because the preseeded default is false.

Confirm what landed:

wireshark -v | head -1
apt-cache policy wireshark | head -3

Use apt-cache policy rather than apt policy here, because the latter prints a “apt does not have a stable CLI interface” warning on stderr that clutters scripted checks. On Debian 13 the pair prints the 4.4.x series from trixie:

Wireshark 4.4.16.
wireshark:
  Installed: 4.4.16-0+deb13u1
  Candidate: 4.4.16-0+deb13u1

Debian 12 reports the 4.0.x series and adds the packaging detail in its version string:

Wireshark 4.0.17 (Git v4.0.17 packaged as 4.0.17-0+deb12u3).

Neither release has Wireshark in backports. Checking both archives returns only the main and security pockets, so the version in the release is the version you get unless you build from source or reach for Flatpak (covered further down).

apt-cache madison wireshark | grep -i packages

Two lines on Debian 13, both from trixie, neither from trixie-backports:

wireshark | 4.4.16-0+deb13u1 | mirror+file:/etc/apt/mirrors/debian.list trixie/main amd64 Packages
wireshark | 4.4.15-0+deb13u1 | mirror+file:/etc/apt/mirrors/debian-security.list trixie-security/main amd64 Packages

What changed between Debian 13 and Debian 12

Older Wireshark instructions for Debian tell you to install wireshark-qt. That package no longer exists in Debian 13. The GUI moved into the wireshark package itself, which used to be a 30 KB metapackage and is now the real thing, built against Qt6 instead of Qt5. The quickest way to see which package owns the GUI on a given box is dpkg -S /usr/bin/wireshark, which answers wireshark on Debian 13 and wireshark-qt on Debian 12.

Item	Debian 13 (trixie)	Debian 12 (bookworm)
Wireshark series	4.4.x	4.0.x
GUI package	wireshark	wireshark-qt
Role of wireshark	The GUI itself	30 KB metapackage pointing at wireshark-qt
Qt generation	Qt6 (libqt6gui6)	Qt5 (libqt5gui5)
Dissector library	libwireshark18	libwireshark16
In backports	No	No
CLI package	tshark	tshark
Capture helper	dumpcap from wireshark-common	dumpcap from wireshark-common

Error: “Package ‘wireshark-qt’ has no installation candidate”

Run the old command on Debian 13 and apt tells you what replaced it:

sudo apt install wireshark-qt

The error names the two packages that took its place:

Package wireshark-qt is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  wireshark-common wireshark

E: Package 'wireshark-qt' has no installation candidate

Install wireshark on Debian 13, and on Debian 12 either name works, since wireshark pulls wireshark-qt anyway.

Decide between the GUI and tshark before you install

The GUI drags in a Qt stack. How much that costs depends entirely on what the machine already runs, and the difference is large enough to matter on a server.

Install on	apt install wireshark	apt install tshark
Debian 13 with GNOME already installed	58 packages, 47.0 MiB	13 packages, 22.5 MiB
Debian 13 minimal (cloud image, no desktop)	271 packages, 178.4 MiB	30 packages, 27.9 MiB
Debian 12 minimal (cloud image, no desktop)	193 packages, 113.6 MiB	23 packages, 21.5 MiB

Those figures come from apt-get install -s for the counts and apt-get install --print-uris for the download size, with the apt cache emptied first. Those totals are MiB, because the division is by 1048576; apt’s own “Need to get” line counts in decimal units, so the two will differ by a few percent. The desktop row was measured on a lean gnome-core install, so a full GNOME system with recommends already pulled in lands a little lower again. Run the check yourself before committing to the GUI on a box you care about:

sudo apt-get install -s wireshark | grep 'newly installed'
sudo apt-get clean
sudo apt-get install --print-uris -y wireshark | grep "^'" | awk '{s+=$3} END {printf "%.1f MiB\n", s/1048576}'

One trap in that second command: --print-uris prints progress lines as well as URI lines, and only the URI lines start with a quote. Sum without filtering and the total is nonsense. It also prints no URI lines at all in two other cases, and since the awk total still fires you get a confident 0.0 MiB rather than an error: when the .deb files are already sitting in /var/cache/apt/archives, which is why the clean runs first, and when the package is already installed, which is why this measurement has to happen before you install anything. Read 0.0 MiB as the failure signature, not as a free download.

A headless server gets tshark. A desktop where you plan to read the packets gets wireshark. Installing the GUI package does not give you tshark, because nothing in the GUI’s dependency chain pulls it. That catches people who install Wireshark, then try to script a capture:

tshark -D

On a fresh wireshark-only install, the shell has no such binary:

bash: tshark: command not found

Add it, and on a machine that already has the GUI it is a single package:

sudo apt install tshark

Give a normal user permission to capture

Capture privileges live in one binary, /usr/bin/dumpcap, shipped by wireshark-common. Wireshark and tshark do not touch the network themselves; they fork dumpcap and read from it. That is the privilege separation the debconf question is about, and it means the fix is a property of one 250 KB helper rather than of the whole GUI.

With the default answer in place, the helper is a plain executable owned by root:

ls -l /usr/bin/dumpcap
sudo getcap /usr/bin/dumpcap
getent group wireshark

Mode 0755, no capabilities set, and no group to join:

-rwxr-xr-x 1 root root 248488 Jul  1 09:02 /usr/bin/dumpcap

Reopen the question and answer it the other way:

sudo dpkg-reconfigure wireshark-common

Select Yes. The package’s postinst does three things: it creates the wireshark system group, chmods the helper to 0754 with that group, and sets two file capabilities on it. Check all three:

ls -l /usr/bin/dumpcap
sudo getcap /usr/bin/dumpcap
getent group wireshark

The three lines that mean capture will work:

-rwxr-xr-- 1 root wireshark 248488 Jul  1 09:02 /usr/bin/dumpcap
/usr/bin/dumpcap cap_net_admin,cap_net_raw=eip
wireshark:x:104:

Read that mode carefully. It is 0754, not 0755, so “other” has read but no execute. A user outside the group cannot even start the binary, which is why the failure mode changes completely once you answer Yes.

The group is created empty, and nothing adds you to it:

sudo usermod -aG wireshark $USER

Then log out of the desktop and back in. Group membership is stamped onto a session when it starts, so your current shell and your current GNOME session both still lack it. id proves it:

id -nG

Immediately after usermod, in the same session, wireshark is absent from that list. A fresh login shows it at the end. If you only need a terminal capture right now, newgrp gives the current shell the new group without a full logout:

newgrp wireshark
id -nG

The group now leads the list, and capture works in that shell:

wireshark adm dialout cdrom floppy sudo audio dip video plugdev debian

Unattended installs: preseed the answer instead

Scripted builds never see the dialog, so they always get the locked-down default. Feed debconf the answer before apt runs and the postinst takes the group and capability path on first install:

echo "wireshark-common wireshark-common/install-setuid boolean true" | sudo debconf-set-selections
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y wireshark tshark
sudo usermod -aG wireshark "$USER"

Verified on Debian 13: after those three lines, dumpcap came up 0754 root:wireshark with both capabilities, no dialog and no dpkg-reconfigure pass needed.

That only applies to a first install. On a machine where the package is already present, debconf-set-selections changes the stored answer and nothing else, so the helper keeps whatever mode it has until you tell the package to reconfigure itself with the new answer:

sudo dpkg-reconfigure -f noninteractive wireshark-common

Same result as answering Yes in the dialog, with nothing to click.

Error: “You do not have permission to capture on device”

This is what the default install produces, on the command line and in the GUI. It is a permission error from the socket call, not a missing interface:

dumpcap: You do not have permission to capture on device "eth0".
(socket: Operation not permitted)
Please check to make sure you have sufficient permissions.

Wireshark’s own dialog carries the full Debian-specific fix, including the exact dpkg-reconfigure and usermod commands and the reminder to log back in:

Worth knowing before you go hunting: the interface list is not empty in this state. With the helper still at 0755, anything can execute it, so both tshark -D and the Wireshark welcome screen enumerate every device and only the capture itself fails. So an empty interface list is a different problem entirely, and not the one this section is about.

Error: “bash: /usr/bin/dumpcap: Permission denied”

Different message, different cause. This one appears after you answer Yes, for any user who is not in the wireshark group. Mode 0754 strips the execute bit from “other”, so the shell refuses before Wireshark’s code ever runs:

bash: line 1: /usr/bin/dumpcap: Permission denied

The fix is the usermod above plus a fresh login, not another dpkg-reconfigure.

The same 0754 mode also changes what interface enumeration does, which is why the two error sections do not contradict each other. Native interface enumeration goes through dumpcap, so for a non-member tshark -D fails on the exec and falls back to the extcap plugins, which are separate helper binaries and need no privileges of their own:

tshark: Couldn't run dumpcap in child process: Permission denied
1. ciscodump (Cisco remote capture)
2. dpauxmon (DisplayPort AUX channel monitor capture)
3. randpkt (Random packet generator)
4. sdjournal (systemd Journal Export)
5. sshdump (SSH remote capture)
6. udpdump (UDP Listener remote capture)
7. wifidump (Wi-Fi remote capture)

Reading a saved file with tshark -r keeps working for that user, because nothing forks dumpcap on the read path.

Error: “getcap: command not found”

getcap lives in /usr/sbin, which is not in a normal user’s PATH on Debian. Every capability check in this guide runs under sudo for that reason. Without it:

bash: getcap: command not found

Either run sudo getcap or call the absolute path /usr/sbin/getcap.

Take the first capture from the command line

Prove the permissions before opening a GUI. It saves you guessing at which layer something is broken. The interface name is the one value that repeats across every command here, so pull it once from the routing table:

export IFACE=$(ip route show default | awk '{print $5}' | head -1)
echo "capturing on ${IFACE}"

That picks the interface carrying your default route, which is what you want in nearly every case. Wireshark’s own view of the machine comes from tshark -D, and it includes more than network cards:

tshark -D

Alongside the real device and the pseudo-devices, the extcap plugins register themselves as capture sources:

1. eth0
2. any
3. lo (Loopback)
4. bluetooth-monitor
5. nflog
6. nfqueue
7. dbus-system
8. dbus-session
9. ciscodump (Cisco remote capture)
10. dpauxmon (DisplayPort AUX channel monitor capture)
11. randpkt (Random packet generator)
12. sdjournal (systemd Journal Export)
13. sshdump (SSH remote capture)
14. udpdump (UDP Listener remote capture)
15. wifidump (Wi-Fi remote capture)

USB capture is missing from that list, and it will stay missing for a normal user. The usbmon interfaces read from /sys/kernel/debug, which is root-only, so they appear only when tshark -D itself runs under sudo. Membership in the wireshark group does not cover it, and README.Debian states as much: capturing USB packets “is not enabled for non-root users by using Linux Capabilities”.

Grab three packets to confirm the capture path end to end:

dumpcap -i "${IFACE}" -c 3 -w /tmp/verify.pcapng

Counts tick up as packets arrive, and the summary line reports zero drops on a healthy setup:

File: /tmp/verify.pcapng
Packets: 1 Packets: 2 Packets: 3 Packets captured: 3
Packets received/dropped on interface 'eth0': 3/0 (pcap:0/dumpcap:0/flushed:0/ps_ifdrop:0) (100.0%)

Now something useful. Capture filters run in the kernel and throw away what they do not match, so they cost less and lose what you did not ask for. Display filters run over what you already captured. The syntax differs: capture filters use libpcap syntax, display filters use Wireshark’s own field names. This grabs a dozen packets of plain HTTP:

tshark -i "${IFACE}" -f "tcp port 80" -c 12 -w /tmp/http.pcap

Generate the traffic from a second terminal while that runs, otherwise you will sit there watching an idle interface:

curl -s -o /dev/null http://deb.debian.org/debian/dists/stable/Release

Read it back and the handshake is right there at the top, followed by the request and the reassembled response:

tshark -r /tmp/http.pcap | head -6

Three packets to set up the connection, then the GET. Frame lengths well over 1,514 bytes further down a capture like this are the kernel’s receive offload handing Wireshark coalesced segments, which is normal on a virtio NIC and rarer on physical hardware:

    1 0.000000000 10.0.1.50 → 151.101.194.132 TCP 74 38338 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM TSval=3770770814 TSecr=0 WS=128
    2 0.060696269 151.101.194.132 → 10.0.1.50 TCP 74 80 → 38338 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 SACK_PERM TSval=1447688805 TSecr=3770770814 WS=512
    3 0.060730155 10.0.1.50 → 151.101.194.132 TCP 66 38338 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=3770770875 TSecr=1447688805
    4 0.060870334 10.0.1.50 → 151.101.194.132 HTTP 171 GET /debian/dists/stable/Release HTTP/1.1 
    5 0.121473691 151.101.194.132 → 10.0.1.50 TCP 66 80 → 38338 [ACK] Seq=1 Ack=106 Win=144896 Len=0 TSval=1447688866 TSecr=3770770875
    6 0.123571344 151.101.194.132 → 10.0.1.50 TCP 771 HTTP/1.1 200 OK  [TCP segment of a reassembled PDU]

Then narrow it with a display filter and print only the fields you care about. This is where tshark earns its place in scripts:

tshark -r /tmp/http.pcap -Y 'http.request' -T fields -e ip.src -e ip.dst -e http.host -e http.request.uri

One tab separated line per request:

10.0.1.50	151.101.194.132	deb.debian.org	/debian/dists/stable/Release

capinfos summarises a file without dissecting it, which is the quickest way to check whether a capture someone sent you is worth opening:

capinfos /tmp/http.pcap | head -8

Note the format line. Despite the .pcap name used in the command above, the file is pcapng, because that is what Wireshark writes by default now:

File name:           /tmp/http.pcap
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  nanoseconds (9)
Packet size limit:   file hdr: (not set)
Number of packets:   12
File size:           18 kB
Data size:           17 kB

For a broader look at protocol behaviour rather than individual packets, the TCP and UDP comparison walks through the same handshake field by field, and the layer model breakdown maps what you see in the detail pane onto the OSI layers.

Read the capture in the GUI

Launch it from the Activities overview or from a terminal. Running it from a terminal is worth doing the first time, because startup warnings land in the shell rather than nowhere:

wireshark

The welcome screen is the interface list, and one detail on it tells you whether the permission work above took effect: the sparkline. Interfaces that have both capture access and traffic draw a live graph beside the name, which is why an idle loopback stays blank even when everything is set up correctly. A list with no graph anywhere, on a machine that is clearly passing traffic, is the tell that capture is still denied.

Double-click an interface to start capturing, or start with a filter already applied from the command line, which is how the next screenshot was taken:

wireshark -i "${IFACE}" -k -f "tcp port 80"

-k means start immediately, -f sets the capture filter, and the window title reports both so you never lose track of what a capture is scoped to.

Type a display filter in the bar under the toolbar to cut a running capture down without losing anything. The bar turns green when the expression parses and red when it does not. Opening a saved file with the filter already in place works too:

wireshark -r /tmp/http.pcap -Y http -g 4

-g 4 jumps to and selects packet 4, so the detail pane is populated the moment the window appears. Expanding the HTTP layer shows the request headers as text, which is usually the fastest way to answer “what did this client actually send”.

One thing Wireshark will not do is stop you running it as root. In an Xorg session sudo wireshark starts and captures, sparklines and all, because root has capture rights regardless of the group. The message text is compiled in, as “You are running Wireshark” and “This could be dangerous”, alongside a preference labelled “Warn if running with elevated permissions (e.g. as root)”, and on the version tested no dialog appeared in any of three runs of sudo wireshark -k -i eth0: with no recent_common file at all, with privs_warn_if_elevated: TRUE written into one, and with it set to FALSE. All three went straight to a window titled “Capturing from eth0”. Do not count on being warned. A stock Debian 13 GNOME session runs Wayland rather than Xorg and behaves differently for root GUI apps; that case was not tested here.

Root is still the wrong habit. The whole point of the dumpcap split is that the dissectors, which are the large and complex part, run unprivileged, and Debian’s README.Debian calls the group route the preferred install for that reason.

If you want the display-filter and analysis side in more depth, the packet analysis walkthrough covers filter expressions, following streams and exporting objects. The workflow is identical on Debian; only the install differs.

Rotate capture files instead of filling the disk

A capture left running overnight to catch an intermittent fault will happily eat the root filesystem. dumpcap has a ring buffer for that, and it is the one flag worth learning before you leave a capture unattended. Rotate every four seconds, stop after thirteen, to see the mechanism work quickly:

dumpcap -i "${IFACE}" -b duration:4 -a duration:13 -w /tmp/ring.pcap

Each rotation opens a new file, numbered and timestamped from the name you gave:

-rw------- 1 debian debian 5620 Aug 21 10:37 /tmp/ring_00001_20260821103656.pcap
-rw------- 1 debian debian 4636 Aug 21 10:37 /tmp/ring_00002_20260821103701.pcap
-rw------- 1 debian debian 5312 Aug 21 10:37 /tmp/ring_00003_20260821103705.pcap
-rw------- 1 debian debian  720 Aug 21 10:37 /tmp/ring_00004_20260821103709.pcap

For real work, cap by size and file count instead of duration so the ring stays bounded forever. This keeps three files of one megabyte and deletes the oldest as it goes:

dumpcap -i "${IFACE}" -b filesize:1024 -b files:3 -a duration:25 -w /tmp/ring2.pcapng

That run took 19,451 packets with zero drops and left exactly three files on disk, numbered from where the rotation had reached rather than from one:

-rw------- 1 debian debian 1025136 Aug 21 11:20 /tmp/ring2_00025_20260821112033.pcapng
-rw------- 1 debian debian 1026216 Aug 21 11:20 /tmp/ring2_00026_20260821112033.pcapng
-rw------- 1 debian debian  601288 Aug 21 11:20 /tmp/ring2_00027_20260821112033.pcapng

Scale those two numbers to whatever ceiling you can afford, remembering that filesize counts in kilobytes of 1000 bytes rather than 1024, which is why the block above shows a shade over a million bytes for filesize:1024. Ten 100 MB files is -b filesize:100000 -b files:10. Drop the -a duration limit and the capture runs until you stop it, within that fixed disk budget. Note the file mode too: captures come out 0600, readable only by you, which is the right default for a file that may hold credentials in cleartext.

The Flathub build is newer but cannot capture

Debian 13 sits a full stable series behind upstream, and the Wireshark project’s own download page lists a PPA for Ubuntu and nothing for Debian. So Flathub looks like the obvious way to get a current version. It half works, and the half that fails is the important half.

sudo apt install flatpak
sudo flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
sudo flatpak install -y flathub org.wireshark.Wireshark

The install lands a considerably newer build than trixie carries, on a KDE runtime:

          ID: org.wireshark.Wireshark
     Version: 4.6.7
      Origin: flathub
   Installed: 184.8 MB
     Runtime: org.kde.Platform/x86_64/6.11

Reading files works, but only files the sandbox can see. Its filesystem grant is home:ro plus xdg-public-share, so your home directory is readable and everything else, /tmp included, is not. Copy the capture into $HOME first:

cp /tmp/http.pcap ~/
flatpak run --command=tshark org.wireshark.Wireshark -r ~/http.pcap -c 3

That dissects normally, which is what makes the Flatpak useful when you need a newer dissector than trixie ships. Point it at the original path instead and it fails in a way that looks like a missing file rather than a sandbox boundary:

tshark: The file "/tmp/http.pcap" doesn't exist.

Check the grants yourself with flatpak info --show-permissions org.wireshark.Wireshark. Capturing is another story.

Error: “PF_PACKET sockets not supported” and the WSL1 red herring

Ask the sandboxed build to capture and you get a message that sends people down entirely the wrong path:

flatpak run --command=dumpcap org.wireshark.Wireshark -i "${IFACE}" -c 2 -w /tmp/f1.pcap

The Windows Subsystem for Linux has nothing to do with it:

Capturing on 'eth0'
dumpcap: The capture session could not be initiated on capture device "eth0".
(Packet capture is not supported on that device - PF_PACKET sockets not supported - is this WSL1?)
Please check that you have the proper interface or pipe specified.

Compare that wording with the failure from the distro build earlier. The unprivileged host binary said “Operation not permitted”, which is a capability problem. This one is a different refusal, and it comes from the sandbox rather than from the kernel’s permission check. Ask for a packet socket inside the sandbox and the address family itself has gone missing:

flatpak run --command=python3 org.wireshark.Wireshark -c 'import socket; socket.socket(socket.AF_PACKET, socket.SOCK_RAW, 0)'

The traceback ends on errno 97, EAFNOSUPPORT:

OSError: [Errno 97] Address family not supported by protocol

Run that same line on the host and the family is recognised; only privilege decides whether the socket is created. Any non-root process gets errno 1, EPERM, in the wireshark group or not, because the capability lives on the dumpcap binary rather than on the group, and a Python process is not dumpcap. That is the same refusal the default install reports as “Operation not permitted”, and under sudo the socket is created. Errno 97 turned up only inside the sandbox on this machine, where /proc/self/status reads Seccomp: 2 with one filter loaded against Seccomp: 0 on the host. The message names WSL1 because that environment returns the same errno for reasons of its own, which is precisely why the wording sends people the wrong way here.

That distinction matters, because the tempting fix is to hand the sandbox the host network and the network is not what is missing. The Flathub build does leave the network share out, so by default /proc/net/dev inside lists only lo and dumpcap -D offers any, lo, bluetooth-monitor, nflog, nfqueue, dbus-system and dbus-session with no network card at all. Grant the share and the card duly appears:

flatpak run --share=network --command=dumpcap org.wireshark.Wireshark -D

The real card is first in the list now, exactly as it is on the host:

1. eth0
2. any
3. lo (Loopback)
4. bluetooth-monitor
5. nflog
6. nfqueue
7. dbus-system
8. dbus-session

Capture on that card and the output is the PF_PACKET failure again, word for word:

flatpak run --share=network --command=dumpcap org.wireshark.Wireshark -i "${IFACE}" -c 1

So the empty interface list and the capture failure are two separate facts rather than cause and effect, and repairing the first leaves the second untouched. Setting the same capabilities on the Flatpak’s bundled helper that Debian sets on its own is the other dead end:

DC=$(sudo find /var/lib/flatpak/app/org.wireshark.Wireshark -name dumpcap | head -1)
sudo setcap cap_net_raw,cap_net_admin=eip "${DC}"
sudo /usr/sbin/getcap "${DC}"

The capabilities stick, getcap confirms them, and the capture fails with the identical message afterwards. Two things make it pointless: the sandbox runs with NoNewPrivs: 1 against NoNewPrivs: 0 on the host, which renders file capabilities inert in there, and the address family is refused before any device is opened anyway. Take them straight back off, because that bundled helper is mode 0755 root:root rather than Debian’s 0754 root:wireshark, so leaving cap_net_admin on it hands every local user a privilege the distro packaging deliberately withholds:

DC=$(sudo find /var/lib/flatpak/app/org.wireshark.Wireshark -name dumpcap | head -1)
sudo setcap -r "${DC}"

None of this is a misconfiguration, and the packaging says so three times over before you ever capture. The Flathub build ships its AppStream summary as “Network protocol analyzer (without capture support)” and its description carries a note that the build “does not support capturing data”. Both are sitting in the installed metainfo:

grep -ho "Network protocol analyzer[^<]*" /var/lib/flatpak/app/org.wireshark.Wireshark/x86_64/stable/*/files/share/metainfo/*.xml
grep -ho "does not support capturing data" /var/lib/flatpak/app/org.wireshark.Wireshark/x86_64/stable/*/files/share/metainfo/*.xml

Each match prints twice, which is the glob rather than a duplicate file: stable/* expands to both the deployed commit directory and the active symlink that points at it. The third warning is the launcher’s own, not Wireshark’s. The Flathub build starts through a wrapper script that raises a zenity dialog reading “This Wireshark package does not support capturing data.”, and it is a gate rather than a notice: the two buttons are “Run Wireshark” and “Exit”, and Exit ends the run before Wireshark starts. Confirm once and it touches a warning_shown file under the app’s own cache directory so it never asks again, and SKIP_WARNING=1 bypasses it outright. None of the flatpak run --command= calls above ever showed it, because --command replaces the wrapper.

So treat the Flatpak as an analysis front end: capture with the distro package or with dumpcap on the machine that has the traffic, then open the file in whichever build has the dissector you need. One limit rides along with that. The home directory is mounted read only, which a shell inside the sandbox demonstrates plainly: echo test > ${HOME}/x answers “Read-only file system”. So ~/Public is the only host directory the manifest grants for writing, and an exported object or a Save As has to land there. The app’s own ~/.var/app/org.wireshark.Wireshark tree takes writes as well, which is where the wrapper keeps its state file, along with the sandbox’s own /tmp, which is a private one and not the host directory that was invisible earlier. Neither is anywhere you would later go looking for a capture.

Capture on the server, analyze on the desktop

Most of the traffic worth looking at is not on your laptop. Debian’s README.Debian for the package advises capturing with dumpcap and analyzing as an ordinary user in a separate step, and dumpcap writing to stdout stretches that same split across two machines. The catch is that everything in the permission section applies to the remote box as well: that host needs its own Yes answer and its own wireshark group membership for the SSH user, or the capture fails there instead of here. Set the remote host once:

export REMOTE="[email protected]"

The interface name in the commands below belongs to the remote host, not yours, so look it up there rather than reusing ${IFACE}: ssh "${REMOTE}" 'ip route show default'. A cloud image often reports eth0 like the lab box here, while a normal install reports something closer to enp1s0 or ens3. Then pull a fixed number of packets straight into a local file:

ssh -n "${REMOTE}" "dumpcap -i eth0 -c 8 -w - -f 'tcp port 22'" > /tmp/remote.pcapng

The remote side reports progress on stderr while the packets travel down stdout, and the local file is a normal pcapng:

Capturing on 'eth0'
File: -
Packets: 4 Packets: 8 Packets captured: 8
Packets received/dropped on interface 'eth0': 8/0 (pcap:0/dumpcap:0/flushed:0/ps_ifdrop:0) (100.0%)

Drop the packet count and pipe into Wireshark instead of a file, and you get a live remote capture in the GUI:

ssh -n "${REMOTE}" "dumpcap -i eth0 -w - -f 'tcp port 22'" | wireshark -k -i -

The window title reads Capturing from Standard input and packets from the other machine fill the list in real time. The desktop needs no capture capability on its own NIC for this, though it does still need to be able to execute dumpcap, because Wireshark forks it even when the packets arrive on stdin:

Filtering on port 22 while the capture itself rides SSH is worth doing once, just to watch your own session scroll past in the packet list.

Wireshark ships a graphical version of the same idea as the SSH remote capture: sshdump entry in the interface list, configured through the gear icon beside it.

There is a catch in it that costs people an afternoon. sshdump’s default remote capture command is tcpdump, and tcpdump on Debian is mode 0755 with no capabilities set, so the wireshark group grants nothing there. The default configuration fails on an otherwise working setup:

tcpdump: eth0: You don't have permission to perform this capture on that device
(socket: Operation not permitted)

The fix is one radio button, not the text field next to it. sshdump’s options dialog has a Remote capture command selection radio with three choices, dumpcap, tcpdump and Other:, and it ships with tcpdump pre-selected. Set it to dumpcap and sshdump builds the remote command itself against the binary the wireshark group actually covers. The free-text Remote capture command field below it is read only when the radio is on Other:, so typing a dumpcap command in there while leaving the radio alone changes nothing and you get the same failure again.

You can read those choices straight out of the plugin, which also tells you where it lives on architectures other than amd64:

SSHDUMP=$(dpkg -L wireshark-common | grep extcap/sshdump)
"${SSHDUMP}" --extcap-interface sshdump --extcap-config | grep 'arg=9'

The default is explicit in the output:

value {arg=9}{value=dumpcap}{display=dumpcap}
value {arg=9}{value=tcpdump}{display=tcpdump}{default=true}
value {arg=9}{value=other}{display=Other:}

On the command line, which is where this was verified, the call below works because it omits the selection flag entirely, and the free-text command is honoured when nothing is selected:

"${SSHDUMP}" --extcap-interface sshdump \
  --capture --fifo /tmp/ssh.fifo.pcapng \
  --remote-host 10.0.1.51 --remote-username debian \
  --sshkey ~/.ssh/id_ed25519 --remote-interface eth0 \
  --remote-capture-command "dumpcap -i eth0 -w - -f 'tcp port 22' -c 6"

For containers and pods, where there is no dumpcap to run, the same split applies with different tooling: capture into a file on the node and copy it out, as in the pod traffic capture guide.

On a Debian workstation, pair Wireshark with the socket-level view from ss and netstat, which answers “who is connected” faster than any capture will, and with a GNS3 lab on the same machine when you want traffic you fully control. Coming from another distribution, the Linux Mint install steps cover the Ubuntu side of the same package, where the PPA does give you a current release.

The short version of everything above: answer Yes to the dumpcap question, add yourself to the wireshark group, log back in, and look for the sparkline next to your interface. Past that point it is all filters.