nd6_na_input: duplicate IP6 address

[Mike Pumford]

Seeing a lot of these messages coming from the kernel after my update to
the latest 8.0-STABLE branch (as of yesterday morning)

nd6_na_input: duplicate IP6 address <IPv6 address of machine>

First one appears when booting just after printing duplicate detection.

Network interface is:
wm0 at pci0 dev 25 function 0: I218 V Ethernet Connection (rev. 0x00)
wm0: interrupting at msi2 vec 0
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address 10:c3:7b:95:20:ed
wm0: 0x2a4480<FLASH,IOH_VALID,PCIE,ASF_FIRM,AMT,WOL>
ihphy0 at wm0 phy 2: i217 10/100/1000 media interface, rev. 5

This is using dhcpd with default config apart from the fact that I've
disabled slaac private and enabled slaac hwaddr

Another machine on the same network with a static V6 address does not
see these message when running the same kernel.

It doesn't seem to impact v6 connectivity as far as I can tell.

Mike


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Hi Mike

Post by Mike Pumford
Seeing a lot of these messages coming from the kernel after my update to
the latest 8.0-STABLE branch (as of yesterday morning)
nd6_na_input: duplicate IP6 address <IPv6 address of machine>
First one appears when booting just after printing duplicate detection.
wm0 at pci0 dev 25 function 0: I218 V Ethernet Connection (rev. 0x00)
wm0: interrupting at msi2 vec 0
wm0: PCI-Express bus
wm0: 2048 words FLASH
wm0: Ethernet address 10:c3:7b:95:20:ed
wm0: 0x2a4480<FLASH,IOH_VALID,PCIE,ASF_FIRM,AMT,WOL>
ihphy0 at wm0 phy 2: i217 10/100/1000 media interface, rev. 5
This is using dhcpd with default config apart from the fact that I've
disabled slaac private and enabled slaac hwaddr
Another machine on the same network with a static V6 address does not
see these message when running the same kernel.
It doesn't seem to impact v6 connectivity as far as I can tell.

Looking at the -8 kernel code, it will print this message before
deciding on a course of action.

As it's not impacted v6 connectivity - and you can verify by ifconfig
that no address is duplicated, then the kernel is notifying another node
that it's address is the dupliate and not yours.

The other machine won't see this because it's using a different address.

We should probably fix the kernel messages to at least print the lla of
the other node to help debugging.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mike Pumford]

Post by Roy Marples
Looking at the -8 kernel code, it will print this message before
deciding on a course of action.
As it's not impacted v6 connectivity - and you can verify by ifconfig
that no address is duplicated, then the kernel is notifying another node
that it's address is the dupliate and not yours.
The other machine won't see this because it's using a different address.
We should probably fix the kernel messages to at least print the lla of
the other node to help debugging.

So this seems to suggest that the machine thinks there is another host
on the same network that has the same IP?

If so that's very odd because almost all of my machines are using auto
assigned addresses based on MAC address and the ones with static
addresses haven't moved for ages.

Mike

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Mike Pumford

Post by Roy Marples
Looking at the -8 kernel code, it will print this message before
deciding on a course of action.
As it's not impacted v6 connectivity - and you can verify by ifconfig
that no address is duplicated, then the kernel is notifying another
node that it's address is the dupliate and not yours.
The other machine won't see this because it's using a different address.
We should probably fix the kernel messages to at least print the lla
of the other node to help debugging.

So this seems to suggest that the machine thinks there is another host
on the same network that has the same IP?
If so that's very odd because almost all of my machines are using auto
assigned addresses based on MAC address and the ones with static
addresses haven't moved for ages.

There are many situations where the NS/NA packets get looped back into
the origination node, causing these false positives.
I added RFC 7527 support to NetBSD over a year ago which will debut in
NetBSD-9.0. This adds a nonce to the DAD packets to ensure looped back
DAD packets can easily be ignored.

So from NetBSD-9.0 onwards you won't see those messages, unless a node
really is using your IP address!

Hope this helps

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mike Pumford]

Post by Roy Marples
There are many situations where the NS/NA packets get looped back into
the origination node, causing these false positives.
I added RFC 7527 support to NetBSD over a year ago which will debut in
NetBSD-9.0. This adds a nonce to the DAD packets to ensure looped back
DAD packets can easily be ignored.

What's puzzling is that up until my last os update I never saw any of
these messages. Has the kernel print only just been added? If its always
been there something in the OS has to have changed to trigger them on
this host as the network environment has not changed at all. The rate at
which they are produced is swamping everything else in the kernel
message buffer.

I've also now updated another system and its now showing exactly the
same symptoms with exactly the same config.

Is there anything I can do to debug this further?

Mike

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andy Ruhl]

Post by Mike Pumford
What's puzzling is that up until my last os update I never saw any of
these messages. Has the kernel print only just been added? If its always
been there something in the OS has to have changed to trigger them on
this host as the network environment has not changed at all. The rate at
which they are produced is swamping everything else in the kernel
message buffer.
I've also now updated another system and its now showing exactly the
same symptoms with exactly the same config.
Is there anything I can do to debug this further?

I think what's being said is something like: This could be a timing
difference between your current kernel and the previous one where a
packet originating from your machine can get looped around and then
trigger the duplicate address detection. Apparently the (network?)
hardware shouldn't do this but it does.

Roy said he's adding code so the machine can detect this condition and
ignore it.

There doesn't seem to be much to do if I'm understanding this right,
unless you want to find out why your hardware is doing this.

Andy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mike Pumford]

I've had some more information about this and suspect that it's dhcpcd
NA messages that are being looped back in.
If you stop dhcpcd, do the messages go away?

Just tested that now. With dhcpcd runnning I get a burst of 3-6 messages
every 10 mins. Its now been runnning without dhcpcd for about 20 mins
and I've not seen any further messages. I'll leave it running it that
state for a while and report back if anything changes.

As an additional data point I have 3 systems at the same level.

One is staticaly addressed and doesn't see these messages. 2 use dhcpcd
and do. All of them used different variants of the intel(wm) adapters
but they are otherwise quite different.

dhcpdc System 1:
cpu0 at mainbus0 apid 0
cpu0: Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, id 0x306c3
cpu0: package 0, core 0, smt 0
wm0 at pci0 dev 25 function 0: I218 V Ethernet Connection (rev. 0x00)
wm0: interrupting at msi2 vec 0

dhcpdc System 2:
cpu0 at mainbus0 apid 0
cpu0: AMD GX-412TC SOC , id 0x730f01
cpu0: package 0, core 0, smt 0
wm0 at pci1 dev 0 function 0: I210 Ethernet (Copper, FLASH less) (rev. 0x03)
wm0: for TX and RX interrupting at msix0 vec 0 affinity to 0
wm0: for TX and RX interrupting at msix0 vec 1 affinity to 1
wm0: for TX and RX interrupting at msix0 vec 2 affinity to 2
wm0: for TX and RX interrupting at msix0 vec 3 affinity to 3
wm0: for LINK interrupting at msix0 vec 4

static system:
cpu0 at mainbus0 apid 0
cpu0: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, id 0x6fb
cpu0: package 0, core 0, smt 0
wm0 at pci4 dev 3 function 0: Intel i82541PI 1000BASE-T Ethernet (rev. 0x05)
wm0: interrupting at ioapic0 pin 22
wm0: 32-bit 33MHz PCI bus


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Mike Pumford

I've had some more information about this and suspect that it's dhcpcd
NA messages that are being looped back in.
If you stop dhcpcd, do the messages go away?

Just tested that now. With dhcpcd runnning I get a burst of 3-6 messages
every 10 mins. Its now been runnning without dhcpcd for about 20 mins
and I've not seen any further messages. I'll leave it running it that
state for a while and report back if anything changes.

This should fix it :)

http://releng.netbsd.org/cgi-bin/req-8.cgi?show=1262

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Roy Marples

Post by Mike Pumford

I've had some more information about this and suspect that it's
dhcpcd NA messages that are being looped back in.
If you stop dhcpcd, do the messages go away?

Just tested that now. With dhcpcd runnning I get a burst of 3-6
messages every 10 mins. Its now been runnning without dhcpcd for about
20 mins and I've not seen any further messages. I'll leave it running
it that state for a while and report back if anything changes.

This should fix it :)
http://releng.netbsd.org/cgi-bin/req-8.cgi?show=1262

It's now been pulled up, so if you update you should no longer see that
message with dhcpcd :)

Sorry for that.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mike Pumford]

Post by Roy Marples
It's now been pulled up, so if you update you should no longer see that
message with dhcpcd :)

Excellent. If triggered off a build so I'll be able to install it later
today.

Post by Roy Marples
Sorry for that.

Not a problem. The price you occasionally pay for running ongoing
development branches (even stable ones) :).

If current has code to deal with this a different way you wouldn't have
spotted it there.

Mike

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Mike Pumford]

Post by Mike Pumford

Post by Roy Marples
It's now been pulled up, so if you update you should no longer see
that message with dhcpcd :)

Excellent. If triggered off a build so I'll be able to install it later
today.

Fix confirmed. Has been running for about 24 hours with the new code and
no nd6 messages at all.

Mike

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Mike Pumford

Post by Mike Pumford

Post by Roy Marples
It's now been pulled up, so if you update you should no longer see
that message with dhcpcd :)

Excellent. If triggered off a build so I'll be able to install it
later today.

Fix confirmed. Has been running for about 24 hours with the new code and
no nd6 messages at all.

Thanks for the feedback!

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de