PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information

[Max Bowsher]

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.

[Joseph Salisbury (jsalisbury)]

Did your bisect point to commit 46517008e1168dc926cf2c47d529efc07eca85c0 as being the first bad commit? If so, I can built a test kernel with that commit reverted.

[Max Bowsher (maxb)]

I bisected only as far as I could using already built packages in the mainline kernel-ppa. The rest of the detail, and locating that specific commit were done by inspecting the source and git logs.

[penalvch (penalvch)]

Max Bowsher, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>