From patchwork Tue Nov 11 19:50:11 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Haley X-Patchwork-Id: 8182 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 46774DDDF0 for ; Wed, 12 Nov 2008 06:50:21 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751470AbYKKTuQ (ORCPT ); Tue, 11 Nov 2008 14:50:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751447AbYKKTuP (ORCPT ); Tue, 11 Nov 2008 14:50:15 -0500 Received: from g1t0027.austin.hp.com ([15.216.28.34]:8395 "EHLO g1t0027.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751384AbYKKTuO (ORCPT ); Tue, 11 Nov 2008 14:50:14 -0500 Received: from smtp2.fc.hp.com (smtp.cnd.hp.com [15.11.136.114]) by g1t0027.austin.hp.com (Postfix) with ESMTP id 7BA98381F7; Tue, 11 Nov 2008 19:50:13 +0000 (UTC) Received: from wrx.usa.hp.com (wrx.usa.hp.com [16.118.120.215]) by smtp2.fc.hp.com (Postfix) with ESMTP id DAD6A2929A5; Tue, 11 Nov 2008 19:35:40 +0000 (UTC) Message-ID: <4919E1F3.1080101@hp.com> Date: Tue, 11 Nov 2008 14:50:11 -0500 From: Brian Haley Organization: Open Source and Linux Organization User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Dave Jones Cc: netdev@vger.kernel.org, jiabwang@redhat.com Subject: Re: Fwd: [Bug 470774] New: [RFC1981-PMTU]Multicast Destination - One Router test failed References: <20081111174232.GA32434@redhat.com> In-Reply-To: <20081111174232.GA32434@redhat.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Dave Jones wrote: > Hopefully this makes more sense to the networking developers > than it does to me. A little... > Description of problem: > TN(FreeBSD7) sends packet too big message to NUT(Fedora10) , > NUT(Fedora10) cannot receive muticast echo request of fragment So which TAHI test was this? Have they tracked down a commit that caused this to break? > Version-Release number of selected component (if applicable): > 2.6.27-0.352.rc7.git1.fc10.i686 Hmmm, I would take a look at this commit: commit b5c15fc004ac83b7ad280acbe0fd4bbed7e2c8d4 Author: Herbert Xu Date: Thu Feb 14 23:49:37 2008 -0800 [IPV6]: Fix reversed local_df test in ip6_fragment I managed to reverse the local_df test when forward-porting this patch so it actually makes things worse by never fragmenting at all. Thanks to David Stevens for testing and reporting this bug. Bill Fink pointed out that the local_df setting is also the wrong way around. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller IP6_INC_STATS(ip6_dst_idev(skb->dst), IPSTATS_MIB_FRAGFAILS); @@ -1421,7 +1421,7 @@ int ip6_push_pending_frames(struct sock *sk) } /* Allow local fragmentation. */ - if (np->pmtudisc >= IPV6_PMTUDISC_DO) + if (np->pmtudisc < IPV6_PMTUDISC_DO) skb->local_df = 1; ipv6_addr_copy(final_dst, &fl->fl6_dst); > 00:42:25.398359 IP6 3ffe:501:ffff:100:21d:fff:fe0f:be4e > ff1e::1:2: ICMP6, > echo request, seq 1, length 1460 > 00:42:26.397533 IP6 3ffe:501:ffff:100:21d:fff:fe0f:be4e > ff1e::1:2: ICMP6, > echo request, seq 2, length 1460 > 00:42:27.397558 IP6 3ffe:501:ffff:100:21d:fff:fe0f:be4e > ff1e::1:2: ICMP6, > echo request, seq 3, length 1460 > 00:42:27.878750 IP6 3ffe:501:ffff:100:200:ff:fe00:100 > > 3ffe:501:ffff:100:21d:fff:fe0f:be4e: ICMP6, packet too big, mtu 1450, length > 1240 Where's the expected fragments? See below where after the TOOBIG the next ping6 will generate them: > 18:21:53.511502 IP6 3ffe:501:ffff:100:200:ff:fe00:100 > > 3ffe:501:ffff:100:20a:ebff:fe85:9e56: ICMP6, packet too big, mtu 1450, length > 1240 > 18:21:54.237694 IP6 3ffe:501:ffff:100:20a:ebff:fe85:9e56 > ff1e::1:2: frag > (0|1400) ICMP6, echo request, seq 0, length 1400 > 18:21:54.237709 IP6 3ffe:501:ffff:100:20a:ebff:fe85:9e56 > ff1e::1:2: frag > (1400|60) > 18:21:55.238522 IP6 3ffe:501:ffff:100:20a:ebff:fe85:9e56 > ff1e::1:2: frag > (0|1400) ICMP6, echo request, seq 1, length 1400 > 18:21:55.238534 IP6 3ffe:501:ffff:100:20a:ebff:fe85:9e56 > ff1e::1:2: frag > (1400|60) > 18:21:56.238482 IP6 3ffe:501:ffff:100:20a:ebff:fe85:9e56 > ff1e::1:2: frag > (0|1400) ICMP6, echo request, seq 2, length 1400 > 18:21:56.238494 IP6 3ffe:501:ffff:100:20a:ebff:fe85:9e56 > ff1e::1:2: frag > (1400|60) Maybe check the interface stats for IPv6 fragments and see why it failed: # cat /proc/net/dev_snmp6/eth0 | grep -i frag It would take me at least a day to get my TAHI box setup to test the latest net-next kernel to see if this is still broken upstream. -Brian --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c index 4e9a2fe..8b67ca0 100644 --- a/net/ipv6/ip6_output.c +++ b/net/ipv6/ip6_output.c @@ -621,7 +621,7 @@ static int ip6_fragment(struct sk_buff *skb, int (*output)(s * or if the skb it not generated by a local socket. (This last * check should be redundant, but it's free.) */ - if (skb->local_df) { + if (!skb->local_df) { skb->dev = skb->dst->dev; icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev);