Re: [Bugme-new] [Bug 8754] New: Kernel addrconf modifies MTU of non-kernel routes
On 15/07/07 10:29, Simon Arlott wrote: On 14/07/07 23:09, Andrew Morton wrote: On Sat, 14 Jul 2007 14:54:32 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8754 I have an MTU of 16110 set on eth0 on a network where the MTU is 1500 as set by RAs. One of the other hosts on the network has an MRU/MTU of 7200 so I have a specific route to it with this MTU. If I add the route early (i.e. on startup) before address autoconfiguration takes place, when the first RA is received the kernel changes the MTU on my route - this should not happen. This also happens whenever I change the MTU on eth0 - it will alter the MTU on routes *I* have added too. While this is valid behaviour for a new MTU that is too low for the route it is not for an MTU above the route. Changing the MTU also allows the next RA with MTU set changes non-kernel routes too problem to occur again. The problem seems to be that because the IPv6 code maintains its own MTU for each interface, which is set from RAs (router advertisements) and when the interface MTU is set (it's also improperly modifiable via sysctl when it shouldn't be, but that's another bug), it uses that to limit the MTU of every route. I propose that it should use the real interface MTU as the limit for non-kernel routes and the RA MTU for kernel routes. Since IPv6 routes (appear to) always have an MTU (IPv4 routes don't and hence inherit from the interface) this would have the side effect that a user-added route's automatically set MTU would not be lowered by the RA MTU. New user IPv6 routes without an explicit MTU should not have one set and use the RA MTU automatically. Is this ok? I'll send a patch to do this some time this week when I get around to it. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8754] New: Kernel addrconf modifies MTU of non-kernel routes
On 14/07/07 23:09, Andrew Morton wrote: On Sat, 14 Jul 2007 14:54:32 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8754 I have an MTU of 16110 set on eth0 on a network where the MTU is 1500 as set by RAs. One of the other hosts on the network has an MRU/MTU of 7200 so I have a specific route to it with this MTU. If I add the route early (i.e. on startup) before address autoconfiguration takes place, when the first RA is received the kernel changes the MTU on my route - this should not happen. This also happens whenever I change the MTU on eth0 - it will alter the MTU on routes *I* have added too. While this is valid behaviour for a new MTU that is too low for the route it is not for an MTU above the route. Changing the MTU also allows the next RA with MTU set changes non-kernel routes too problem to occur again. -- Simon Arlott - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8754] New: Kernel addrconf modifies MTU of non-kernel routes
On Sat, 14 Jul 2007 14:54:32 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8754 Summary: Kernel addrconf modifies MTU of non-kernel routes Product: Networking Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: IPV6 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have an MTU of 16110 set on eth0 on a network where the MTU is 1500 as set by RAs. One of the other hosts on the network has an MRU/MTU of 7200 so I have a specific route to it with this MTU. If I add the route early (i.e. on startup) before address autoconfiguration takes place, when the first RA is received the kernel changes the MTU on my route - this should not happen. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
