Large downloads hang but small requests work

Likely causes

1. A link with a smaller MTU on the path (a VPN, a tunnel, PPPoE), and a firewall that drops ICMP fragmentation needed, so path MTU discovery never hears about it.
2. A wrong MTU set by hand on one card, bigger than the network really carries.

Diagnose

Run these in order. The output is what each printed on a lab's real Linux machines.

laptop:~# curl -m 5 -o /dev/null http://10.0.3.10/

A small page loads whole: 100 22. The connection itself works.

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100    22  100    22    0     0  37037      0 --:--:-- --:--:-- --:--:-- 22000

laptop:~# curl -m 5 -o /dev/null http://10.0.3.10/big.txt

The big file connects, then gets 0 out of 300000 bytes: its full-size packets vanish on the way.

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0  292k    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
  0  292k    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
  0  292k    0     0    0     0      0      0 --:--:--  0:00:03 --:--:--     0
  0  292k    0     0    0     0      0      0 --:--:--  0:00:04 --:--:--     0
  0  292k    0     0    0     0      0      0 --:--:--  0:00:05 --:--:--     0
curl: (28) Operation timed out after 5004 milliseconds with 0 out of 300000 bytes received

officeRouter:~# ip link show tunnelNetwork

A router's card on the path says mtu 1400: smaller than the 1500 at both ends.

12: eth1@if60286: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP mode DEFAULT group default 
    link/ether fa:1e:a5:7c:6b:51 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    altname tunnelNetwork

laptop:~# ping -M do -c 2 -s 1450 10.0.3.10

With Don't Fragment set, a working path answers Frag needed and DF set (mtu = 1400). In a black hole that line never comes: the big ping just gets no reply.

PING 10.0.3.10 (10.0.3.10) 1450(1478) bytes of data.
From 10.0.1.2 icmp_seq=1 Frag needed and DF set (mtu = 1400)
ping: local error: message too long, mtu=1400

--- 10.0.3.10 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1020ms

Fix

iptables -D OUTPUT -p icmp --icmp-type fragmentation-needed -j DROP

Stop dropping ICMP fragmentation needed on the router, so path MTU discovery works again.

The fix the lab's challenge "Small pages load, big downloads hang" checks.

officeRouter:~# iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Or, when you cannot let the ICMP through: rewrite the MSS in every SYN the router forwards, so TCP picks segments that fit.

officeRouter:~# iptables -t mangle -S FORWARD
-P FORWARD ACCEPT
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

laptop:~# curl -o /dev/null http://10.0.3.10/big.txt

The same download, ICMP still blocked: 100 292k, the whole file.

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  292k  100  292k    0     0   172M      0 --:--:-- --:--:-- --:--:--  286M

Break it and fix it yourself

Each lab is a small network of real Linux machines in your browser, where this fault happens.

• MTU and fragmentation: when a packet is too big for the next link Pro: its challenge "Small pages load, big downloads hang" set the fault for you to find and fix.

Open MTU and fragmentation: when a packet is too big for the next link