netdev - Re: [PATCH net-next 3/5] ipv6: Stop /128 route from disappearing after pmtu update

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <m2bni2tsv0.wl@sfc.wide.ad.jp>
Date:	Sun, 03 May 2015 09:19:47 +0900
From:	Hajime Tazaki <tazaki@....wide.ad.jp>
To:	kafai@...com
Cc:	netdev@...r.kernel.org, hannes@...essinduktion.org,
	steffen.klassert@...unet.com, davem@...emloft.net,
	yangyingliang@...wei.com, shengyong1@...wei.com, Kernel-team@...com
Subject: Re: [PATCH net-next 3/5] ipv6: Stop /128 route from disappearing after pmtu update


Hello Martin,

thank you for your quick reply.

At Sat, 2 May 2015 16:20:40 -0700,
Martin KaFai Lau wrote:

> > - how to reproduce it
> > 
> > the test is simply sending an IPv6 packet to a node on the
> > same subnet to verify the connectivity (e.g., ping6
> > 2001:1::2 from 2001:1::1) and echo packets didn't get back.
> > 
> > reverting this commit fixes the issue.
> > 
> > please take a look at it: I'm glad to know if this only
> > happens in my local environment.
> Thanks for reporting.
> 
> I cannot reproduce in my environment.
(snip)
> 15:58:34.658150 6a:aa:e6:a1:ce:f9 > 52:54:00:12:34:56, ethertype IPv6 (0x86dd), length 118: 2001:1::2 > 2001:1::1: ICMP6, echo request, seq 5, length 64
> 15:58:34.658275 52:54:00:12:34:56 > 6a:aa:e6:a1:ce:f9, ethertype IPv6 (0x86dd), length 118: 2001:1::1 > 2001:1::2: ICMP6, echo reply, seq 5, length 64
> 
> I suspect there is a RTF_LOCAL route getting a ICMPv6 too-big packet.
> 
> Can you provide a tcpdump at both ends?  Also, the output of
> the 'ip -6 a' and 'ip -6 r show'.

- tcpdump -vvv
09:00:00.200000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::200:ff:fe00:1 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 00:00:00:00:00:01
            0x0000:  0000 0000 0001
09:00:00.401092 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::200:ff:fe00:2 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 00:00:00:00:00:02
            0x0000:  0000 0000 0002
09:00:01.000000 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1008) 2001:1::1 > 2001:1::2: [icmp6 sum ok] ICMP6, echo request, seq 1
09:00:02.000000 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1008) 2001:1::1 > 2001:1::2: [icmp6 sum ok] ICMP6, echo request, seq 2
09:00:03.000000 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1008) 2001:1::1 > 2001:1::2: [icmp6 sum ok] ICMP6, echo request, seq 3
09:00:04.000000 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 1008) 2001:1::1 > 2001:1::2: [icmp6 sum ok] ICMP6, echo request, seq 4
09:00:04.200000 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::200:ff:fe00:1 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 00:00:00:00:00:01
            0x0000:  0000 0000 0001
09:00:04.401092 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 16) fe80::200:ff:fe00:2 > ff02::2: [icmp6 sum ok] ICMP6, router solicitation, length 16
          source link-address option (1), length 8 (1): 00:00:00:00:00:02            0x0000:  0000 0000 0002
(snip)

- 'ip -6 a' at the ping6 sender
7: sim0: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:1::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::200:ff:fe00:1/64 scope link 
       valid_lft forever preferred_lft forever

- 'ip -6 r show' at the ping6 sender
2001:1::/64 dev sim0  proto kernel  metric 256 
fe80::/64 dev sim0  proto kernel  metric 256 

# the results of ip command on receiver side are almost
  similar.

I found that the test uses non-ARP interface between nodes:
if I changed the interface to 'non-NOARP' NIC, the issue has
gone away without the revert.

I'm using the following scenario: just FYI.

https://gist.github.com/thehajime/26be8606ddbb924f357c

> Also, can you try the following change which is a partial revert.  If ping goes
> through again, can you capture the 'ip -6 show' on both sides quickly after the
> test.
> 
> Thanks,
> --Martin
> 
> diff --git i/net/ipv6/route.c w/net/ipv6/route.c
> index 3522711..60212d4 100644
> --- i/net/ipv6/route.c
> +++ w/net/ipv6/route.c
> @@ -1124,7 +1124,7 @@ static void ip6_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
>  	struct rt6_info *rt6 = (struct rt6_info *)dst;
> 
>  	dst_confirm(dst);
> -	if (mtu < dst_mtu(dst) && (rt6->rt6i_flags & RTF_CACHE)) {
> +	if (mtu < dst_mtu(dst) && rt6->rt6i_dst.plen == 128) {
>  		struct net *net = dev_net(dst->dev);
> 
>  		rt6->rt6i_flags |= RTF_MODIFIED;

this partial revert didn't change my situation.


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