PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux |
Confirmed
|
Medium
|
|||
linux (Ubuntu) |
Incomplete
|
Medium
|
Unassigned |
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:/
I have also filed this bug in upstream kernel bugzilla as https:/
Changed in linux: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
tags: | added: needs-kernel-logs raring |
Did your bisect point to commit 46517008e1168dc 926cf2c47d529ef c07eca85c0 as being the first bad commit? If so, I can built a test kernel with that commit reverted.