Description of problem: when prefix lifetime greater than 2 hours, TN(freebsd computer) send a NS to NUT(RHEL5.2) , NUT did not have sending a NA. Version-Release number of selected component (if applicable): kernel-2.6.18-92.el5 How reproducible: every time Steps to Reproduce: 1. 2. 3. Actual results: when prefix lifetime greater than 2 hours, TN send a NS, NUT didnot reply a NA Expected results: when prefix lifetime greater than 2 hours, TN send a NS, NUT should reply a NA in RFC 4862 s. 5.5.3.e p.20 Additional info: tcpdump message: pass message: [root@dhcp-65-20 Desktop]# tcpdump -r 43.html.Link0.dump reading from file 43.html.Link0.dump, link-type EN10MB (Ethernet) 23:40:37.129871 IP6 :: > ff02::1:ff00:27cd: ICMP6, neighbor solicitation, who has fe80::200:2ff:fe00:27cd, length 24 23:40:39.612381 IP6 fe80::200:2ff:fe00:27cd > ff02::2: ICMP6, router solicitation, length 16 23:40:39.835740 IP6 fe80::200:ff:fe00:100 > ff02::1: ICMP6, router advertisement, length 56 23:40:39.969319 IP6 :: > ff02::1:ff00:27cd: ICMP6, neighbor solicitation, who has 3ffe:501:ffff:100:200:2ff:fe00:27cd, length 24 23:40:41.726887 IP6 fe80::200:2ff:fe00:27cd > ff02::1:ff00:27cd: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::1:ff00:27cd, length 24 23:40:42.750767 IP6 fe80::200:2ff:fe00:27cd > ff02::2:4088:d191: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::2:4088:d191, length 24 23:40:45.337468 IP6 fe80::200:ff:fe00:100 > ff02::1:ff00:27cd: ICMP6, neighbor solicitation, who has 3ffe:501:ffff:100:200:2ff:fe00:27cd, length 32 23:40:45.338092 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor advertisement, tgt is 3ffe:501:ffff:100:200:2ff:fe00:27cd, length 32 23:40:45.784579 IP6 fe80::200:ff:fe00:100 > ff02::1: ICMP6, router advertisement, length 56 23:40:50.336320 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 23:40:51.341130 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 23:40:52.345902 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 23:40:55.615424 IP6 fe80::200:ff:fe00:100 > ff02::1:ff00:27cd: ICMP6, neighbor solicitation, who has 3ffe:501:ffff:100:200:2ff:fe00:27cd, length 32 23:40:55.615964 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor advertisement, tgt is 3ffe:501:ffff:100:200:2ff:fe00:27cd, length 32 23:41:00.614145 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 23:41:01.618901 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 23:41:02.623702 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 01:41:01.111926 IP6 fe80::200:ff:fe00:100 > ff02::1:ff00:27cd: ICMP6, neighbor solicitation, who has 3ffe:501:ffff:100:200:2ff:fe00:27cd, length 32 01:41:01.112623 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor advertisement, tgt is 3ffe:501:ffff:100:200:2ff:fe00:27cd, length 32 01:41:06.110891 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 01:41:07.115653 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 01:41:08.120450 IP6 fe80::200:2ff:fe00:27cd > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 01:41:30.617792 IP6 fe80::200:ff:fe00:100 > ff02::1:ff00:27cd: ICMP6, neighbor solicitation, who has 3ffe:501:ffff:100:200:2ff:fe00:27cd, length 32 failure message: after 2 hous, nut didnot send NA [root@dhcp-65-20 Desktop]# tcpdump -r 431.html.Link0.dump reading from file 431.html.Link0.dump, link-type EN10MB (Ethernet) 22:59:04.112367 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:59:04.238364 IP6 :: > ff02::1:ff0f:be4e: ICMP6, neighbor solicitation, who has fe80::21d:fff:fe0f:be4e, length 24 22:59:05.238951 IP6 fe80::21d:fff:fe0f:be4e > ff02::2: ICMP6, router solicitation, length 16 22:59:05.263659 IP6 fe80::200:ff:fe00:100 > ff02::1: ICMP6, router advertisement, length 56 22:59:06.063240 IP6 :: > ff02::1:ff0f:be4e: ICMP6, neighbor solicitation, who has 3ffe:501:ffff:100:21d:fff:fe0f:be4e, length 24 22:59:06.570322 IP6 fe80::21d:fff:fe0f:be4e > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 22:59:11.295248 IP6 fe80::200:ff:fe00:100 > ff02::1:ff0f:be4e: ICMP6, neighbor solicitation, who has 3ffe:501:ffff:100:21d:fff:fe0f:be4e, length 32 22:59:11.295329 IP6 3ffe:501:ffff:100:21d:fff:fe0f:be4e > fe80::200:ff:fe00:100: ICMP6, neighbor advertisement, tgt is 3ffe:501:ffff:100:21d:fff:fe0f:be4e, length 32 22:59:11.344680 IP6 fe80::200:ff:fe00:100 > ff02::1: ICMP6, router advertisement, length 56 22:59:16.294946 IP6 fe80::21d:fff:fe0f:be4e > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 22:59:17.300352 IP6 fe80::21d:fff:fe0f:be4e > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 22:59:18.305641 IP6 fe80::21d:fff:fe0f:be4e > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 22:59:21.527322 IP6 fe80::200:ff:fe00:100 > ff02::1:ff0f:be4e: ICMP6, neighbor solicitation, who has 3ffe:501:ffff:100:21d:fff:fe0f:be4e, length 32 22:59:21.527387 IP6 3ffe:501:ffff:100:21d:fff:fe0f:be4e > fe80::200:ff:fe00:100: ICMP6, neighbor advertisement, tgt is 3ffe:501:ffff:100:21d:fff:fe0f:be4e, length 32 22:59:26.527066 IP6 fe80::21d:fff:fe0f:be4e > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 22:59:27.532450 IP6 fe80::21d:fff:fe0f:be4e > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 22:59:28.537741 IP6 fe80::21d:fff:fe0f:be4e > fe80::200:ff:fe00:100: ICMP6, neighbor solicitation, who has fe80::200:ff:fe00:100, length 32 01:04:18.315007 IP6 fe80::200:ff:fe00:100 > ff02::1:ff0f:be4e: ICMP6, neighbor solicitation, who has 3ffe:501:ffff:100:21d:fff:fe0f:be4e, length 32 partly test case: 42 Part A: Prefix Lifetime greater than Stored Lifetime PASS 43 Part B: Prefix Lifetime greater than 2 hours FAIL 44 Part C: Prefix Lifetime less than the Stored Lifetime and the Stored Lifetime is less than 2 hours PASS 45 Part D: Prefix Lifetime less than 2 hours and the Stored Lifetime is greater than 2 hours PASS
I assume that in the trace fragment above, fe80::200:ff:fe00:100 is the address of the NUT which is failing to respond to NS's correct? The trace shows that the NS solicitations to that address are unicast, so we don't fall into the DAD category in ndisc_recv_ns. the only other place we send an NA from is in ndisc_recv_ns after we have __neigh_lookup complete. Since the create flag is 1 (since the dest ip addr in the NS is not multicast) we should always get a neigh entry back on that, and so we should always respond with an NA in that case. And even though we are not responding to NS's on that address, we still seem to be be sending out NA's from that address, so the system clearly still knowsn about that address and hasn't aged it out. About the only way I can see us not responding to this is if somehow we never actually process the received NS. Can you please check in /proc/net/stat/ndisc_cache on the NUT before and after the TN sends a NS to to the NUT. I am expecting rcv_probes_ucast to go up (or possibly rcv_probes_mcast if I'm reading the trace wrong). If they do then something odd is going on with the neighbor cache, and I would be interested to see the output of ip -6 neigh show before and after the TN sends its post 2-hour NS. If they don't go up then we are either not processing the NS at all, or finding something unpalatable about it in the sanity checking at the start of ndisc_recv_ns. Thanks!
Sorry, the bug is hardware problem. we have found where problem is so do not care the bug Thanks
resolving as NOTABUG as re-testing on an older system works fine. thanks for your time on this bug Neil.