* Fw: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
@ 2013-03-27 15:31 Stephen Hemminger
2013-03-28 1:59 ` Li Wei
0 siblings, 1 reply; 3+ messages in thread
From: Stephen Hemminger @ 2013-03-27 15:31 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 27 Mar 2013 08:25:40 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
https://bugzilla.kernel.org/show_bug.cgi?id=55861
Summary: PMTU discovery no longer works in Linux 3.6+ with
routers that do not send next hop MTU information
Product: Networking
Version: 2.5
Kernel Version: 3.6 onwards
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: _@maxb.eu
Regression: Yes
After upgrading recently, 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
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Fw: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
2013-03-27 15:31 Fw: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information Stephen Hemminger
@ 2013-03-28 1:59 ` Li Wei
2013-03-28 2:24 ` David Miller
0 siblings, 1 reply; 3+ messages in thread
From: Li Wei @ 2013-03-28 1:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
It seems to be in icmp_unreach():
case ICMP_FRAG_NEEDED:
if (ipv4_config.no_pmtu_disc) {
LIMIT_NETDEBUG(KERN_INFO pr_fmt("%pI4: fragmentation needed and DF set\n"),
&iph->daddr);
} else {
info = ntohs(icmph->un.frag.mtu);
if (!info)
goto out;
When MTU is zero, we skip the process in icmp_socket_deliver() which propagate
this error to transport protocols.
After some investigation it seems in transport protocols' err_handler which
finally called dst->update_pmtu(ip_rt_update_pmtu for IPv4) can deal with this
situation properly.
So I think we can simply kill the check of icmph->un.frag.mtu here.
On 03/27/2013 11:31 PM, Stephen Hemminger wrote:
>
>
> Begin forwarded message:
>
> Date: Wed, 27 Mar 2013 08:25:40 -0700
> From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
>
>
> https://bugzilla.kernel.org/show_bug.cgi?id=55861
>
> Summary: PMTU discovery no longer works in Linux 3.6+ with
> routers that do not send next hop MTU information
> Product: Networking
> Version: 2.5
> Kernel Version: 3.6 onwards
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: _@maxb.eu
> Regression: Yes
>
>
> After upgrading recently, 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
>
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
2013-03-28 1:59 ` Li Wei
@ 2013-03-28 2:24 ` David Miller
0 siblings, 0 replies; 3+ messages in thread
From: David Miller @ 2013-03-28 2:24 UTC (permalink / raw)
To: lw; +Cc: stephen, netdev
From: Li Wei <lw@cn.fujitsu.com>
Date: Thu, 28 Mar 2013 09:59:04 +0800
> It seems to be in icmp_unreach():
>
> case ICMP_FRAG_NEEDED:
> if (ipv4_config.no_pmtu_disc) {
> LIMIT_NETDEBUG(KERN_INFO pr_fmt("%pI4: fragmentation needed and DF set\n"),
> &iph->daddr);
> } else {
> info = ntohs(icmph->un.frag.mtu);
> if (!info)
> goto out;
>
> When MTU is zero, we skip the process in icmp_socket_deliver() which propagate
> this error to transport protocols.
No, really, MTU field should not be set to zero. It should be set to
the actual MTU value we should use.
If you remove this check then we'll go down to the ipv4 routing code
and use the minimum ipv4 MTU, you absolutely do not want that.
The old code, that was removed, would try to guess in this case using
a table, the guard for this code path had comment:
/* BSD 4.2 derived systems incorrectly adjust
* tot_len by the IP header length, and report
* a zero MTU in the ICMP message.
*/
So the machines sending these zero MTUs are very broken.
I'm not accomodating such broken systems, sorry.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-03-28 2:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-27 15:31 Fw: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information Stephen Hemminger
2013-03-28 1:59 ` Li Wei
2013-03-28 2:24 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).