Bug 705293 - [TAHI][IPv6][Core-router] Failed on tahi test "Part B: NUT receives DAD NS (target == NUT)"
Summary: [TAHI][IPv6][Core-router] Failed on tahi test "Part B: NUT receives DAD NS (t...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.7
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jiri Benc
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 705298 705300 705303 705304 705311 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-17 09:57 UTC by xhu
Modified: 2011-11-21 10:13 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-11-21 10:13:03 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description xhu 2011-05-17 09:57:56 UTC
Description of problem:
Failed on tahi test "Part B: NUT receives DAD NS (target == NUT)"

The test description can be seen in http://focus.bne.redhat.com/~xhu/Core-Router/Conform/RHEL5u7-beta/Self_Test_5-0-0-Router-RHEL5.7beta-20110516/addr.p2/LLA_DAD_NSPostDAD_SameDstSameTgt.html

The test log can be seen in http://focus.bne.redhat.com/~xhu/Core-Router/Conform/RHEL5u7-beta/Self_Test_5-0-0-Router-RHEL5.7beta-20110516/addr.p2/3.html

The test tcpdump file can be seen in http://focus.bne.redhat.com/~xhu/Core-Router/Conform/RHEL5u7-beta/Self_Test_5-0-0-Router-RHEL5.7beta-20110516/addr.p2/3_html_Link0.pcap and http://focus.bne.redhat.com/~xhu/Core-Router/Conform/RHEL5u7-beta/Self_Test_5-0-0-Router-RHEL5.7beta-20110516/addr.p2/3_html_Link1.pcap

Version-Release number of selected component (if applicable):
kernel-2.6.18-261.el5
radvd-0.9.1-4

How reproducible:
everytimes

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Failed on tahi test "Part B: NUT receives DAD NS (target == NUT)"

Expected results:
Tahi test "Part B: NUT receives DAD NS (target == NUT)" should be pass

Additional info:

Comment 1 RHEL Program Management 2011-06-21 05:26:25 UTC
This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.7 and Red Hat does not plan to fix this issue the currently developed update.

Contact your manager or support representative in case you need to escalate this bug.

Comment 3 vladimir.velisavljev 2011-10-17 15:30:17 UTC
These two bugs can be easily fixed by modifying one condition in the file:
/net/ipv6/addrconf.c, 
function void addrconf_dad_failure(struct inet6_ifaddr *ifp), 
around line 1436:
	       if (idev->cnf.accept_dad >= 1 && !idev->cnf.disable_ipv6) {

Comment 4 Thomas Graf 2011-10-27 18:47:42 UTC
I don't understand the point of the last packet being sent. It's not related to the NUT's address fe80::baac:6fff:fe3e:6387 on which DAD is being performed on.

Comment 6 Jiri Benc 2011-11-14 21:20:31 UTC
All of the bugs boil down to RFC 4862 5.4.5, which states:

   If the address is a link-local address formed from an interface
   identifier based on the hardware address, which is supposed to be
   uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
   operation on the interface SHOULD be disabled.

As it is "SHOULD", the implementation may choose to behave differently if there is a good reason. In case of Linux, the default behavior is not to stop IPv6 on the interface. To behave accordingly to this clause, the administrator has to set accept_dad sysctl to 2:

  sysctl net.ipv6.conf.eth0.accept_dad=2

I believe this should fix the problem. Could you please retest with this setting applied (probably for all interfaces)?

Comment 7 Jiri Benc 2011-11-14 21:23:16 UTC
*** Bug 705298 has been marked as a duplicate of this bug. ***

Comment 8 Jiri Benc 2011-11-14 21:23:39 UTC
*** Bug 705300 has been marked as a duplicate of this bug. ***

Comment 9 Jiri Benc 2011-11-14 21:23:55 UTC
*** Bug 705303 has been marked as a duplicate of this bug. ***

Comment 10 Jiri Benc 2011-11-14 21:25:48 UTC
*** Bug 705304 has been marked as a duplicate of this bug. ***

Comment 11 Jiri Benc 2011-11-14 21:26:11 UTC
*** Bug 705311 has been marked as a duplicate of this bug. ***

Comment 13 Jiri Benc 2011-11-21 10:13:03 UTC
Thanks. Closing, then.


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