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: <m28ud5u47u.wl@sfc.wide.ad.jp>
Date:	Sun, 03 May 2015 23:26:45 +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


At Sat, 2 May 2015 18:00:55 -0700,
Martin KaFai Lau wrote:

> > 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
> Was it captured at the sender side?
> Did the receiver (2001:1::2) get the echo request?

the capture was on the sender side.

the receiver got the echo request: I will detail the next
email but since two nodes connected back to back via
point-to-point data link, the receiver side also has exactly
the same pcap.

> > (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 
> > 
> hmm...It is weird.  It is a /64 route, so it should have
> failed the (rt->dst.flags & DST_HOST) test anyway...
> 
> > # 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
> > 
> You meant without 'arp off'? 

Yes, I meant that.

>  Can you grep those IP from 'ip -6 neigh'?

there is no output from 'ip -6 neigh' since the interfaces
is configured with IFF_NOARP.
 
> Can you try this patch just to confirm:

I applied the updated patch and the ping successfully got
replies.

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