Re: [Bugme-new] [Bug 8756] New: Route advmss copied to ALL routes when interface MTU changes

Re: [Bugme-new] [Bug 8756] New: Route advmss copied to ALL routes when interface MTU changes

[Andrew Morton]

On Sat, 14 Jul 2007 15:34:31 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8756

It is unclear which kernel version this applies to?

>            Summary: Route advmss copied to ALL routes when interface MTU
>                     changes
>            Product: Networking
>            Version: 2.5
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: IPV6
>         AssignedTo: yoshfuji@linux-ipv6.org
>         ReportedBy: bugzilla@fire.lp0.eu
> 
> 
> Steps to reproduce:
> 1. Have multiple network devices and routes for them with standard (low, i.e.
> 1500) MTUs and default ADVMSS (e.g. 1440)
> 2. Change the MTU on one of them to something high (e.g. 7200)
> 3. The ADVMSS is incorrectly set for ALL routes based on the new MTU of the
> interface that changed.
> 
> Note: if addrconf is running then the ADVMSS will be reset on the next RA, so
> this will impede attempts to reproduce.
> 
> # ip -6 r
> fe80::/64 dev sit0  metric 256  expires 4481744sec mtu 1480 advmss 1440
> hoplimit 4294967295
> fe80::/64 dev ppp0  metric 256  expires 19071345sec mtu 1500 advmss 1440
> hoplimit 4294967295
> fe80::/64 dev eth0  metric 256  expires 19072430sec mtu 1500 advmss 1440
> hoplimit 4294967295
> default dev ppp0  metric 1024  expires 19071347sec mtu 1500 advmss 1440
> hoplimit 4294967295
> 
> # ifconfig eth0 mtu 7200
> 
> # ip -6 r
> fe80::/64 dev sit0  metric 256  expires 4481732sec mtu 1480 advmss 7140
> hoplimit 4294967295 <-- wrong
> fe80::/64 dev ppp0  metric 256  expires 19071334sec mtu 1500 advmss 7140
> hoplimit 4294967295 <-- wrong
> fe80::/64 dev eth0  metric 256  expires 19072419sec mtu 7200 advmss 7140
> hoplimit 4294967295 <-- correct
> 
> Explicitly setting the MTU on these other routes (although this is not possible
> without having to add another route due to bug 8755) automatically sets ADVMSS
> appropriately.
> 

Re: [Bugme-new] [Bug 8756] New: Route advmss copied to ALL routes when interface MTU changes

[Simon Arlott]

On 15/07/07 05:48, Andrew Morton wrote:
> On Sat, 14 Jul 2007 15:34:31 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
> 
>> http://bugzilla.kernel.org/show_bug.cgi?id=8756
> 
> It is unclear which kernel version this applies to?

Linus' 2.6 tree, as of Mon Jul 9 15:50:56 2007 -0700

For some reason it says "Version: 2.5" on the email and "Version: " on
the website...

> 
>>            Summary: Route advmss copied to ALL routes when interface MTU
>>                     changes
>>            Product: Networking
>>            Version: 2.5
>>           Platform: All
>>         OS/Version: Linux
>>               Tree: Mainline
>>             Status: NEW
>>           Severity: normal
>>           Priority: P1
>>          Component: IPV6
>>         AssignedTo: yoshfuji@linux-ipv6.org
>>         ReportedBy: bugzilla@fire.lp0.eu
>> 
>> 
>> Steps to reproduce:
>> 1. Have multiple network devices and routes for them with standard (low, i.e.
>> 1500) MTUs and default ADVMSS (e.g. 1440)
>> 2. Change the MTU on one of them to something high (e.g. 7200)
>> 3. The ADVMSS is incorrectly set for ALL routes based on the new MTU of the
>> interface that changed.
>> 
>> Note: if addrconf is running then the ADVMSS will be reset on the next RA, so
>> this will impede attempts to reproduce.
>> 
>> # ip -6 r
>> fe80::/64 dev sit0  metric 256  expires 4481744sec mtu 1480 advmss 1440
>> hoplimit 4294967295
>> fe80::/64 dev ppp0  metric 256  expires 19071345sec mtu 1500 advmss 1440
>> hoplimit 4294967295
>> fe80::/64 dev eth0  metric 256  expires 19072430sec mtu 1500 advmss 1440
>> hoplimit 4294967295
>> default dev ppp0  metric 1024  expires 19071347sec mtu 1500 advmss 1440
>> hoplimit 4294967295
>> 
>> # ifconfig eth0 mtu 7200
>> 
>> # ip -6 r
>> fe80::/64 dev sit0  metric 256  expires 4481732sec mtu 1480 advmss 7140
>> hoplimit 4294967295 <-- wrong
>> fe80::/64 dev ppp0  metric 256  expires 19071334sec mtu 1500 advmss 7140
>> hoplimit 4294967295 <-- wrong
>> fe80::/64 dev eth0  metric 256  expires 19072419sec mtu 7200 advmss 7140
>> hoplimit 4294967295 <-- correct
>> 
>> Explicitly setting the MTU on these other routes (although this is not possible
>> without having to add another route due to bug 8755) automatically sets ADVMSS
>> appropriately.
>> 


-- 
Simon Arlott

[PATCH [Bug 8756]] IPv6: Don't update ADVMSS on routes where the MTU is not also updated

[Simon Arlott]

The ADVMSS value was incorrectly updated for ALL routes when the MTU 
is updated because it's outside the effect of the if statement's 
condition.

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
---
This fixes http://bugzilla.kernel.org/show_bug.cgi?id=8756

 net/ipv6/route.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 919de68..55ea80f 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1983,9 +1983,10 @@ static int rt6_mtu_change_route(struct rt6_info *rt, void *p_arg)
 	    !dst_metric_locked(&rt->u.dst, RTAX_MTU) &&
 	    (dst_mtu(&rt->u.dst) > arg->mtu ||
 	     (dst_mtu(&rt->u.dst) < arg->mtu &&
-	      dst_mtu(&rt->u.dst) == idev->cnf.mtu6)))
+	      dst_mtu(&rt->u.dst) == idev->cnf.mtu6))) {
 		rt->u.dst.metrics[RTAX_MTU-1] = arg->mtu;
-	rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(arg->mtu);
+		rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(arg->mtu);
+	}
 	return 0;
 }
 
-- 
1.5.0.1

-- 
Simon Arlott

Re: [PATCH [Bug 8756]] IPv6: Don't update ADVMSS on routes where the MTU is not also updated

[David Miller]

From: Simon Arlott <simon@fire.lp0.eu>
Date: Mon, 23 Jul 2007 20:25:45 +0100

> The ADVMSS value was incorrectly updated for ALL routes when the MTU 
> is updated because it's outside the effect of the if statement's 
> condition.
> 
> Signed-off-by: Simon Arlott <simon@fire.lp0.eu>

Thanks for fixing this bug Simon, patch applied.