kernel-packages team mailing list archive
-
kernel-packages team
-
Mailing list archive
-
Message #85466
[Bug 1383615] Re: Path MTU discovery doesn't work if there is no route to transit host
** Description changed:
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
+ 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
+ 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
+ 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 217.78.182.234 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
+ 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 217.78.182.234 unreachable - need to frag (mtu 1448), length 36
+ 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 217.78.182.234 unreachable - need to frag (mtu 1448), length 36
+ 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
+ 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
+ [ 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
+ 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.
** Description changed:
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 217.78.182.234 unreachable - need to frag (mtu 1448), length 36
+ 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.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1383615
Title:
Path MTU discovery doesn't work if there is no route to transit host
Status in “linux” package in Ubuntu:
Confirmed
Bug description:
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1383615/+subscriptions
References
