From: Brian Haley <brian.haley@hp.com>
To: Dave Jones <davej@redhat.com>
Cc: netdev@vger.kernel.org, jiabwang@redhat.com
Subject: Re: Fwd: [Bug 470774] New: [RFC1981-PMTU]Multicast Destination - One Router test failed
Date: Tue, 11 Nov 2008 14:50:11 -0500 [thread overview]
Message-ID: <4919E1F3.1080101@hp.com> (raw)
In-Reply-To: <20081111174232.GA32434@redhat.com>
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 <herbert@gondor.apana.org.au>
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 <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
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);
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
next prev parent reply other threads:[~2008-11-11 19:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-11 17:42 Fwd: [Bug 470774] New: [RFC1981-PMTU]Multicast Destination - One Router test failed Dave Jones
2008-11-11 19:50 ` Brian Haley [this message]
[not found] ` <491A7571.4020905@redhat.com>
2008-11-12 15:12 ` Brian Haley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4919E1F3.1080101@hp.com \
--to=brian.haley@hp.com \
--cc=davej@redhat.com \
--cc=jiabwang@redhat.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).