Bug 459960 - [TAHI] when Prefix Lifetime greater than 2 hours, RHEL didnot send a NA(RFC4862-5.5.3.e )
[TAHI] when Prefix Lifetime greater than 2 hours, RHEL didnot send a NA(RFC48...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Neil Horman
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-25 05:33 EDT by wang jiabo
Modified: 2008-09-11 10:52 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-11 10:52:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description wang jiabo 2008-08-25 05:33:51 EDT
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
Comment 2 Neil Horman 2008-09-03 13:29:01 EDT
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!
Comment 3 wang jiabo 2008-09-11 10:39:24 EDT
Sorry, the bug is hardware problem.
we have found where problem is 

so do not care the bug
Thanks
Comment 4 Lawrence Lim 2008-09-11 10:52:34 EDT
resolving as NOTABUG as re-testing on an older system works fine. thanks for your time on this bug Neil.

Note You need to log in before you can comment on or make changes to this bug.