This version is no longer supported. If this is still reproducible on a
newer/supported version, please reopen.
** Changed in: linux (Ubuntu)
Status: Incomplete => Won't Fix
--
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/1160966
Title:
PMTU discovery no longer works in Linux 3.6+ with routers that do not
send next hop MTU information
Status in Linux:
Confirmed
Status in linux package in Ubuntu:
Won't Fix
Bug description:
After upgrading to raring, I found that path MTU discovery no longer worked
correctly for accessing some devices on the other side of an IPsec tunnel.
Bisection revealed the problems started with 3.6 and are still present in
3.9-rc4 (latest available at time of reporting).
Some investigation into code changes leads me to the belief that Linux lost
support for handling ICMP destination unreachable fragmentation needed packets
for which the next hop MTU field is zero. This is an expected condition when
dealing with older routers, as RFC792 originally defined ICMP destination
unreachable fragmentation needed without a next hop MTU field, and it was
later
added in bytes previously allocated as unused.
The particular router in my case generating such packets is a machine running
OpenBSD 4.6.
A commit that appears to be of particular interest in this bug is
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=46517008e1168dc926cf2c47d529efc07eca85c0
I have also filed this bug in upstream kernel bugzilla as
https://bugzilla.kernel.org/show_bug.cgi?id=55861 - I'm reporting here
also to track this as a regression of raring vs. quantal.
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1160966/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
