Diagnosing Bandwidth Saturation — Fedora

Guide to quickly identify the cause of abnormally low Internet throughput on a Fedora machine, and to locate the process or device responsible.

Notation: replace <interface_wifi> with your interface (e.g. wlp0s20f3).

Symptoms

Speedtest reports throughput well below the nominal contracted rate
Unexpected asymmetry (strong signal): for example upload > download on a residential ADSL/VDSL/fiber line, where the opposite is normally expected
Generalized perceived slowness
Wifi in good shape (decent signal, high negotiated bitrate)

Asymmetry is an excellent indicator — when one direction is throttled and the other is nominal, it is almost always a unidirectional consumer (massive download such as cloud sync, or massive upload such as backup).

Cascading Diagnostic

1. Measure and confirm stability

sudo dnf install -y speedtest-cli
speedtest-cli --secure --simple

Three consecutive measurements to rule out the server-selection effect:

for i in 1 2 3; do speedtest-cli --secure --simple; done

If the values are stable at a low level → genuine degradation, not an artifact.

2. Compare IPv4 vs IPv6

speedtest-cli (Python) does not support -4/-6 directly; use --source with the local IPv4:

speedtest-cli --secure --simple --source $(ip -4 -o addr show <interface_wifi> | awk '{print $4}' | cut -d/ -f1)

If IPv4 and IPv6 give similarly degraded figures → the problem is not specific to one protocol family.

3. Compare across devices

Run a simultaneous test on a smartphone connected to the same wifi (test-ipv6.com, fast.com, the Speedtest app).

Smartphone normal, Fedora degraded → problem on the Fedora side (drivers, signal, local process, MTU)
Both smartphone and Fedora degraded → global network saturation or Internet line issue

4. Check wifi link quality

iw dev <interface_wifi> link

Indicators to examine:

Signal: > -65 dBm is fine, > -50 dBm is excellent
Negotiated bitrate: should be at least 5× the expected Internet throughput
Frequency: 5 GHz (or 6 GHz Wi-Fi 6E) rather than 2.4 GHz for high throughput
HE-MCS / VHT-MCS: indicates the modulation (Wi-Fi 6 vs Wi-Fi 5 vs Wi-Fi 4)

If the wifi link is nominal, the bottleneck is elsewhere. No point looking on this side.

5. Identify the consuming process

sudo dnf install -y nethogs
sudo nethogs -d 2 <interface_wifi>

-d 2 refreshes every 2 seconds. To quit: q or Ctrl+C. If the interface hangs:

sudo pkill nethogs

The table shows, per process: PID / USER / PROGRAM / DEV / SENT / RECEIVED (in kB/s).

Mental conversion: kB/s × 8 = kbps. So 6000 kB/s ≈ 48 Mbps.

Common Suspects

Cloud sync (download)

Dropbox (/home/.../.dropbox-dist/...dropbox)
OneDrive, Google Drive, iCloud Drive (on a nearby Mac)
Mega, pCloud, Sync.com
Resilio Sync, Syncthing

Symptom: sustained download of several MB/s, low upload. Typical causes: initial sync, restore, a large shared folder just added, massive conflicts.

Backup (upload)

Time Machine (from a nearby Mac on the network, to a NAS)
BackBlaze, Carbonite
Restic, Borg, Duplicati (to a remote target)

Symptom: sustained upload, low download.

Updates

Steam, Epic, Battle.net, GOG Galaxy
Apple Software Update (App Store, security)
dnf-automatic on Fedora
Docker pull of large images
flatpak update, snap refresh

Streaming / Live

Plex / Jellyfin transcoding (CPU + bandwidth load)
Apple TV streaming 4K HDR
IP cameras: Eufy, Ring, Arlo, Reolink — uploading footage to the cloud
Downloading TV series (4K HDR ≈ 25 Mbps sustained)

IoT / Off-screen

Tesla in service mode when connected to the home wifi (software update)
Eufy HomeBase syncing hours of recordings
Video doorbells after motion detection
Robot vacuum uploading maps
Console (PS5, Xbox, Switch): system update or silent game download

Additional Tools

iftop — active connections per IP pair

sudo dnf install -y iftop
sudo iftop -i <interface_wifi>

Useful keys: t toggle layout, n resolve/no-resolve, p show ports, q quit.

Useful when nethogs is not enough (for example consumption from a Docker container whose PID attribution is ambiguous).

bmon — aggregated view per interface

sudo dnf install -y bmon
bmon -p <interface_wifi>

Good for confirming at a glance the total load on the wifi interface.

ss — established TCP connections

ss -tn state established

To see where current connections are going (remote IP/port). Useful for spotting suspicious destinations.

Cumulative counters

ip -s link show <interface_wifi>
sleep 5
ip -s link show <interface_wifi>

The difference in RX/TX bytes between the two measurements = average throughput over 5 s. Crude method but with no dependencies.

vnstat — long-term history

sudo dnf install -y vnstat
sudo systemctl enable --now vnstatd
vnstat -i <interface_wifi>

Gives the daily/monthly consumption history. Relevant for spotting a gradual drift rather than an instantaneous spike.

Confirmation and Resolution

Once the culprit is identified:

kill <PID>

or via the relevant app — always preferable:

Dropbox: systray icon → Preferences → Bandwidth → “Limit download rate”
Steam: Preferences → Downloads → Limits
Docker: docker stop <conteneur> or limit via docker run --network
dnf-automatic: edit /etc/dnf/automatic.conf

Re-test the throughput to confirm a return to normal:

speedtest-cli --secure --simple

Long-term Best Practice

A central network monitor (for example ntopng on a Raspberry Pi connected to a mirror port or used as a gateway) lets you instantly see which device is consuming WAN bandwidth, without having to connect to each machine to diagnose.

Typical setup:

Dedicated RPi 4/5, ARM64, recent Debian
ntopng as a systemd service, web UI accessible on the LAN
Data retained for N days for historical analysis
Optional: Confluence/Grafana integration for alerting

Quick reference

speedtest-cli --secure --simple
sudo nethogs -d 2 <interface_wifi>
iw dev <interface_wifi> link

If throughput is degraded + one process dominates the RECEIVED or SENT column → culprit identified, pause/kill and retest.