Path MTU discovery doesn't work if there is no route to transit host

[Alexander Ponyatykh]

Suppose there is host X you want to connect to and there is some host Y on the path to X with MTU less than 1500. In usual conditions linux can discover PMTU, but not when there is no route to Y via the same interface as to X.

Example: 10.2.2.2 is X, 10.2.2.2.1 is Y,10.0.0.2 is localhost and 10.0.0.1 is gateway.

# ip route
default via 10.0.0.1 dev wlan0 proto static
10.0.0.0/22 dev wlan0 proto kernel scope link src 10.0.0.2 metric 9
# tracepath -n 10.2.2.2
 1?: [LOCALHOST] pmtu 1500
 1: 10.0.0.1 2.362ms
...
 6: 10.2.2.2.1 6.100ms
 7: 10.2.2.2.1 7.450ms pmtu 1448
 7: 10.2.2.2.2 9.232ms !H
     Resume: pmtu 1448
# ping -M do -c 2 -s 1422 10.2.2.2
PING 10.2.2.2 (10.2.2.2) 1422(1450) bytes of data.
From 10.2.2.1 icmp_seq=1 Frag needed and DF set (mtu = 1448)
ping: local error: Message too long, mtu=1448

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

tcpdump output:
10:53:54.813146 IP 10.0.0.2 > 10.2.2.2: ICMP echo request, id 3218, seq 1, length 1430
10:53:54.819162 IP 10.2.2.1 > 10.0.0.2: ICMP 10.2.2.2 unreachable - need to frag (mtu 1448), length 36

Now lets add direct route to X and remove default route.

# ip route del default
# ip route add 10.2.2.2 via 10.0.0.1 dev wlan0
# ip route
10.0.0.0/22 dev wlan0 proto kernel scope link src 10.0.0.2 metric 9
10.2.2.2 via 10.0.0.1 dev wlan0
# ping -M do -c 2 -s 1422 10.2.2.2
PING 10.2.2.2 (10.2.2.2) 1422(1450) bytes of data.

--- 10.2.2.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1008ms

tcpdump output:
12:01:43.222181 IP 10.0.0.2 > 10.2.2.2: ICMP echo request, id 4100, seq 1, length 1430
12:01:43.234057 IP 10.2.2.1 > 10.0.0.2: ICMP 10.2.2.2 unreachable - need to frag (mtu 1448), length 36
12:01:44.231103 IP 10.0.0.2 > 10.2.2.2: ICMP echo request, id 4100, seq 2, length 1430
12:01:44.239092 IP 10.2.2.1 > 10.0.0.2: ICMP 10.2.2.2 unreachable - need to frag (mtu 1448), length 36

For example, this behavior breaks VPN when all traffic is routed via tunnel. In this case there is only direct route to VPN gateway (except local net) via physical interface, and VPN packets larger than PMTU are discarded, since PMTUD doesn't work.

I've also tested mainline kernel v3.18-rc1-utopic with the same results.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-37-generic 3.13.0-37.64
ProcVersionSignature: Ubuntu 3.13.0-37.64-generic 3.13.11.7
Uname: Linux 3.13.0-37-generic i686
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ranma 1846 F.... lxpanel
CRDA: Error: [Errno 2] Нет такого файла или каталога: 'iw'
CurrentDesktop: LXDE
CurrentDmesg:
 [ 70.293614] init: plymouth-upstart-bridge main process ended, respawning
 [ 70.338543] init: plymouth-upstart-bridge main process (1658) terminated with status 1
 [ 70.338612] init: plymouth-upstart-bridge main process ended, respawning
Date: Tue Oct 21 10:28:06 2014
HibernationDevice: RESUME=UUID=67a1a865-4137-4325-a898-25905a17804b
InstallationDate: Installed on 2014-09-08 (42 days ago)
InstallationMedia: Lubuntu 14.04.1 LTS "Trusty Tahr" - Release i386 (20140722.2)
MachineType: ASUSTeK Computer INC. 901
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-37-generic root=/dev/mapper/root ro rootflags=subvol=@ persistent quiet splash
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-37-generic N/A
 linux-backports-modules-3.13.0-37-generic N/A
 linux-firmware 1.127.7
SourcePackage: linux
StagingDrivers: zram
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 08/01/2008
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1202
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 901
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: x.xx
dmi.chassis.asset.tag: 0x00000000
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTek Computer INC.
dmi.chassis.version: x.x
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1202:bd08/01/2008:svnASUSTeKComputerINC.:pn901:pvrx.x:rvnASUSTeKComputerINC.:rn901:rvrx.xx:cvnASUSTekComputerINC.:ct10:cvrx.x:
dmi.product.name: 901
dmi.product.version: x.x
dmi.sys.vendor: ASUSTeK Computer INC.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

Once this bug is reported upstream, please add the tag: 'kernel-bug-reported-upstream'.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel