MTU Mismatch or Packet Loss? Determining Why Large Transfers Stall

Use do-not-fragment size tests and packet captures to separate a repeatable size boundary from random loss or congestion.

The decision matters when small pings and web requests work, but large SMB, backup, or VPN transfers pause or reset. The two competing states are path MTU black hole or MSS problem and ordinary loss, congestion, or unstable link. Begin with a saved configuration and disposable data, observe one branch at a time, and stop if the test expands data-loss, permission, or availability risk.

Separate Path Mtu Black Hole Or Mss Problem From Ordinary Loss, Congestion, Or Unstable Link

Record the environment before changing anything: software and firmware versions, device identities, mount or network path, free space, permissions, and the observable symptom. The baseline must preserve enough detail to reproduce small pings and web requests work, but large SMB, backup, or VPN transfers pause or reset.

The first candidate is path MTU black hole or MSS problem. The second is ordinary loss, congestion, or unstable link. The current packetization layer PMTU discovery defines the mechanism or command boundary used in the test; it does not replace observation from this specific home server.

Write the acceptance condition and stop condition before running the discriminator. A pass must change the evidence predicted by one branch while leaving unrelated services unchanged; a fail must return the system to the saved state rather than trigger a chain of speculative fixes.

Run One Controlled Discriminator

Use this discriminator: probe increasing non-fragmenting sizes, run iperf with controlled MSS, and capture ICMP too-big messages plus retransmissions. Keep workload, client, path, file set, and timing constant so the result is attributable to the changed variable.

Use path MTU discovery to select the field that can actually separate the branches, then capture its timestamp, exit status, error text, device or snapshot identity, latency, transferred bytes, permissions, and recovery state. A clean command exit is not enough when identity, durability, or application state is the claim under test.

Repeat the test once after a restart, reconnect, remount, or cold cache when that event is part of the original condition. If the first run is destructive or the environment cannot be restored, stop and reproduce on a disposable copy instead.

ping -M do -s 1472 target
tracepath target
iperf3 -c target --set-mss 1360

Interpret Which Branch the Evidence Supports

PASS: failure begins at a stable packet size and changes with MTU or MSS, or loss is size-independent and bursty. Record the exact version, identity, and workload that passed so the conclusion stays conditional rather than becoming a universal claim.

FAIL: different routes or VPN overhead produce different thresholds, so map each path separately. A fail does not automatically prove the opposite branch when network, memory, permissions, or source consistency can influence both; isolate those shared dependencies before escalating.

EXCEPTION OR AMBIGUOUS RESULT: return interfaces to 1500 and restore ICMP handling before further jumbo-frame tests. Preserve logs and do not run repair, prune, destroy, repartition, or recursive ownership commands until a recoverable copy exists.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Apply the Matched Action and Reproduce the Original Failure

Apply the action matched to the observed branch, then repeat the original condition rather than a reduced substitute. The decision holds only when failure begins at a stable packet size and changes with MTU or MSS, or loss is size-independent and bursty across two cycles or the relevant reboot, sleep, interruption, or load transition.

Use the end-to-end MTU settings to check the nearest dependent workflow, but keep the original trigger unchanged. Unrelated datasets, shares, containers, users, and recovery points must retain their previous access and timing.

The stop boundary is explicit: if different routes or VPN overhead produce different thresholds, so map each path separately, return to the last verified configuration, retain the evidence, and escalate to a deeper platform or hardware test only when the branch is repeatable.

After the target result holds, compare it with the separate traffic paths so the fix does not move risk into a neighboring service. A successful target test with a new backup, identity, timeout, or availability failure is still a failed change.

FAQ

For large-transfer stall diagnosis, the remaining searches usually concern why do small pings succeed during an mtu black hole, can wi-fi loss look like an mtu problem, and should mss clamping be the permanent fix. The answers below keep those edge cases separate from the primary decision.

The acceptance boundary does not move: failure begins at a stable packet size and changes with MTU or MSS, or loss is size-independent and bursty. If a follow-up condition changes the filesystem, identity, network path, or application version, repeat only the discriminator affected by that change.

Stop broadening the experiment when different routes or VPN overhead produce different thresholds, so map each path separately. At that point, return interfaces to 1500 and restore ICMP handling before further jumbo-frame tests; preserve the evidence before escalating to the platform, storage, or hardware owner.

Why do small pings succeed during an MTU black hole?

They fit below the constraining MTU and never need the missing too-big feedback.

Can Wi-Fi loss look like an MTU problem?

Yes. Packet capture and repeated size thresholds separate random retransmission from a deterministic boundary.

Should MSS clamping be the permanent fix?

Only when the routed or tunneled design requires it; first correct MTU and ICMP handling where possible.

The diagnosis is finished when the same workload makes the evidence follow path MTU black hole or MSS problem or ordinary loss, congestion, or unstable link, and the matched action removes the original symptom without creating a second one. If neither branch stays repeatable, keep the logs and saved state intact; uncertainty is a reason to escalate, not to stack more fixes.