diff mbox

Fwd: [Bug 470774] New: [RFC1981-PMTU]Multicast Destination - One Router test failed

Message ID 4919E1F3.1080101@hp.com
State Not Applicable, archived
Delegated to: David Miller
Headers show

Commit Message

Brian Haley Nov. 11, 2008, 7:50 p.m. UTC 
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>

                 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

Comments

Brian Haley Nov. 12, 2008, 3:12 p.m. UTC | #1 
>> So which TAHI test was this?  Have they tracked down a commit that 
>> caused this to break?
> I use TAHI 4-0-3 RFC1981, if you can access my website , please see 
> http://10.66.65.20/self_test/ipv6-core/Self_Test_4-0-3_F10/

That looks like an internal link.  Either way, I'm guessing this was 
test 13 (Checking For Increase in PMTU), which passed for RHEL 5.3 
recently I think.

>>> 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.

So can you verify your kernel has this fix?  Or can you run a later 
kernel and see if it's fixed?

> I check using the command, get the following info:
>  #cat /proc/net/dev_snmp6/eth0|grep -i frag
>    Ipv6FragOKs           0
>    Ipv6FragFails           0
>    Ip6FragCreates        0

You'll actually want to look at eth1, which is where the pings are going 
out, I was just giving that as an example.

-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 mbox

Patch

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);