The PPPoE Packet Ceiling

01 — The Symptom: Calls Work. Chat Doesn't.

It started as a vague complaint: “some websites aren't loading.” Not a DNS error, not a connection-refused — pages would just hang, spinning indefinitely. Then a second thread appeared: LINE, the app most of Japan uses for daily messaging, wouldn't send or receive chat messages over the same Wi-Fi — while LINE voice calls on the same phone worked without a hitch. Cellular data on the same device had no issue at all.

That combination — fine on cellular, fine for voice, broken for chat and some web traffic — is a fairly specific fingerprint once you've seen it before.

Reproduced identically on a wired VLAN and a separate Wi-Fi VLAN (including 6GHz) — ruling out band, VLAN, and device as the cause.

02 — The Ceiling: A Ceiling PPPoE Never Advertises

Textbooks will tell you PPPoE knocks 8 bytes off a standard 1500-byte Ethernet frame, leaving an MTU of 1492. In Japan, that number is usually wrong — and not for a mysterious reason. On NTT's Flets fibre network, PPPoE only runs as far as NTT's local facility; from there to the ISP's own equipment (the BAS), the session is carried inside an L2TP tunnel. That adds IP, UDP, L2TP and PPP headers — 46 bytes of overhead in total, not PPPoE's usual 8 — bringing the real ceiling down to exactly 1454 bytes. That's precisely what this gateway's ppp0 interface auto-negotiated to. The textbook number and the real, physical ceiling are two different things, and nothing on a router's PPPoE setup screen tells you which one you actually got.

Sourced, not assumed: the L2TP-to-BAS mechanism and byte breakdown are documented at infraexpert.com, and the resulting 1454-byte ceiling is independently confirmed by Yamaha's own RTX router FAQ and Sophos's Flets PPPoE guidance (PDF).

When a sender doesn't know the real ceiling, the internet's usual fallback is Path MTU Discovery: an oversized packet gets rejected with an ICMP message telling the sender to shrink it. That fallback quietly fails when something along the path filters ICMP — extremely common — and the result isn't an error. It's silence. The sender just keeps re-sending a packet that never arrives, which is exactly what “hangs indefinitely” feels like from a browser tab.

A controlled test made the real ceiling measurable. Sending “don't fragment” pings of decreasing size at a broken domain from a wired desktop (bypassing Wi-Fi entirely) gave a clean, reproducible boundary:

03 — Diagnosis: Four Steps to the Root Cause

1. 1

   Isolate

   Identical failure on a wired VLAN and a wireless VLAN, on a phone and a desktop client, on 6GHz and on a completely separate network segment. That rules out Wi-Fi band, VLAN config, and the app itself — the one thing every failing path shared was the PPPoE WAN link.

2. 2

   Measure

   A controlled fragmentation ping test (above) turned a vague “some things don't work” into a hard number: somewhere between 1400 and 1472 bytes, packets stopped arriving.

3. 3

   Inspect

   SSH into the gateway and ip link show told a surprising story: the PPPoE interface (ppp0) had already auto-negotiated down to MTU 1454 — the router had correctly detected the real ceiling on its own.

4. 4

   Confirm

   So the WAN link knew its own ceiling — but nothing was telling the rest of the network about it. Checking for a TCP MSS clamp rule came back empty. That's the whole bug: a correctly-sized interface with no rule enforcing that size on the traffic passing through it.

04 — The Fix: One Rule, Enforced Twice

A TCP MSS clamp tells the gateway: whenever a new connection is being set up through this interface, rewrite the advertised segment size to fit the interface's real MTU — rather than hoping the sender and the internet's ICMP feedback loop sort it out on their own.

iptables -t mangle -A FORWARD -o ppp0 -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

That fixed it instantly — both the hanging websites and LINE chat. But a rule added live over SSH only lives in the running kernel; a reboot wiped it clean, and the symptoms came straight back. PPPoE on this gateway is managed by pppd, which runs any script placed in /etc/ppp/ip-up.d/ automatically — every time the interface comes up, including after a reboot and after any forced reconnect an ISP might trigger:

#!/bin/sh
IFACE="$1"
iptables -t mangle -C FORWARD -o "$IFACE" -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu 2>/dev/null || \
iptables -t mangle -A FORWARD -o "$IFACE" -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Confirmed by rebooting the gateway outright: uptime showed a genuine restart, and the rule — with real traffic already counted against it — was back on its own.

Independent research — not affiliated with or endorsed by Ubiquiti Inc.