netdev - Re: Fwd: [Bug 470774] New: [RFC1981-PMTU]Multicast Destination

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 11 Nov 2008 14:50:11 -0500
From:	Brian Haley <brian.haley@...com>
To:	Dave Jones <davej@...hat.com>
Cc:	netdev@...r.kernel.org, jiabwang@...hat.com
Subject: Re: Fwd: [Bug 470774] New: [RFC1981-PMTU]Multicast Destination -
 One	Router test failed

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@...dor.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@...dor.apana.org.au>
     Signed-off-by: David S. Miller <davem@...emloft.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html