Bugzilla – Bug 265
IPv6 duplicate address
Last modified: 2005-10-02 14:28:02
You need to log in before you can comment on or make changes to this bug.
Usually after resume from suspend-to-disk i get these messages: Oct 7 15:46:06 rootix kernel: Restarting tasks... done Oct 7 15:50:04 rootix kernel: ICMPv6 NA: someone advertises our address on eth1! Oct 7 15:51:07 rootix kernel: eth1: duplicate address detected! Oct 7 15:51:12 rootix kernel: eth1: duplicate address detected! Oct 7 15:52:42 rootix last message repeated 2 times From looking at the code in /usr/src/linux/net/ipv6/ndisc.c and /usr/src/linux/net/ipv6/addrconf.c it looks like the ipv6 stack is receiving packets advertising the interface's own address. NA means Neighbourhood Advertisement. From what little knowledge i have of ipv6, i think that when an ipv6 interface is brough up, it tries to assign an address to itself and sends a NA so that others know the interface has that address. I think the problem here is that the NA is being received by the card/driver itself. Hmmm, just tested this and it's reproducible: rootix:~# dmesg -c > /dev/null rootix:~# ifconfig eth1 down rootix:~# dmesg -c rootix:~# ifconfig eth1 up rootix:~# dmesg -c eth1: duplicate address detected! looks like when the card is ifconfig'ed up and ipv6 tries to configure it's link-local address it sends the NA and somehow the card/driver receives that packet back. I never had this problem with ipw2100, can it be something to do with the order things are setup when the interface comes up, or could it be the card really receiving the echo from the AP(don't know if it's possible). In case it's our packet retransmitted back to us from the AP i have some questions: - Does the AP really retransmit our own packet back to us if it's (i.e.) destined for the boradcast or some multicast address? - Does the card/driver really allow packets with it's own mac address as the source to come in?
*** Bug 268 has been marked as a duplicate of this bug. ***
ipw2100 firmware doesn't support filtering out its own packets. We need to do it in the driver.
Created an attachment (id=76) [details] filter out card's own packets
Additional Comment #2 From Zhu Yi probably refers to ipw2200, not ipw2100.
Hi, seems to be not finally fixed. See last line of output: Nov 11 07:53:15 knecht logger: Loading ipw2200 in normal-mode Nov 11 07:53:15 knecht kernel: ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 0.13 Nov 11 07:53:15 knecht kernel: ipw2200: Copyright(c) 2003-2004 Intel Corporation Nov 11 07:53:15 knecht kernel: ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection Nov 11 07:53:17 knecht kernel: ICMPv6 NA: someone advertises our address on eth2!
Created an attachment (id=83) [details] Patch that fixes the problem in ipw2200.c instead of the common code Here is a patch that fixes the problem in the ipw2200.c code instead of the common ieee80211 code. The 2100b device doesn't have this problem and we are constantly syncing the ieee80211 code.
Fix will be in the next release v0.14
Hi Rusty, I applied the patch to my 0.13 sources and retest looks fine... Lars
I'm resetting bug state to RESOLVED, VERIFIED until an official build comes out with the fix in it, after which we someone can re-test as mark the bug fix as VERIFIED. This will help catch a situation where a patch doesn't make it to the build.
Per Rusty, this is fixed in 0.14
The bug is verified in ipw2200 v0.14.
*** Bug 403 has been marked as a duplicate of this bug. ***
Agree with Rusty's fix. I didn't conclude "my packets" all use addr3 before. Cool! ;-)
Verified FIXED in 0.14 Thanks guys.