netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* IPv6 Address Resolution in Linux 2.6.27
@ 2013-02-08 20:23 Mudric, Dusan (Dusan)
  2013-02-11 17:13 ` Ben Hutchings
  0 siblings, 1 reply; 2+ messages in thread
From: Mudric, Dusan (Dusan) @ 2013-02-08 20:23 UTC (permalink / raw)
  To: netdev

Hi,

I experience Address Resolution problem while using Linux 2.6.27.

A and B use global IPv6 addresses. 
. 2009::6:173 - 'A'  global address (the capture monitors its port)
. 2009::6:172 - 'B' global address

Both A and B are about 8 seconds in the reachable states (STALE / DELAY / PROBE) with full audio, and then ~30 seconds in the INCOMPLETE state. This happens periodically.

Media behavior when phones talk P2P:
RTP directions   #reference packet  Starting time Time diff [seconds]
172 <- -> 173          940                                13.5                  -
172     -> 173        1779                                21.5                 8
172 <- -> 173        4134                               63.9              42
172     -> 173         4983                               71.9                8
172 <- -> 173        7361                             114.3             42
172     -> 173         8211                             122.4               8

I added debug info in net\ipv6\ndisc.c ndisc_recv_na() to print src and dst IPs.
I added debug info in neigh_update() to print LL address and a new state
I enabled NEIGH_PRINTKx and ND_PRINTKx

Observations:
1. 173 discover and lose 172 address in periodic manner - 8 / 42 / 8 / 42 / .
2. When 173 loses 172 (and when it gets it again) we see ICMPv6 traffic: NS from 173 to 172 and NA from 172 to 173
. During the time 173 can't reach 172 there are ICMPv6 NS messages from 173 and NA to 173. 173 ndisc_recv_na() is not called. NAs are silently discarded somewhere. At the same time, 173 neighbor cache entry does not follow the RFC4861. neigh_update() state changes from INCOMPLETE to STALE do DELAYED after the first timeout. It should stay in INCOMPLETE. From DELAYED state it goes to PROBE which is allowed by RFC. It stays in PROBE for 3sec (3 NS retransmissions) and goes to FAILED state. 2sec later is send NS again and goes into DELAYED state.
3. NDP:
a. 172 sends only 3 solicitation request for 173 during the capture period, while 173 sends solicitation to 172 every second
b. 173 reach 172 only after 172 sends advertisement to 173' LL address (not the global one and without the "override" flag)

Q: Is this a known problem? If yes, is there a patch for it?

Regards, 
Dušan Mudrić 

Software Architect
Endpoints & Video Solutions
Avaya Global Communication Systems
Telephone: (613) 595-9045
425 Legget Drive, Ottawa, Ontario, K2K 2W2

"I have always believed, and I still believe, that whatever good or bad fortune may come our way, we can always give it meaning and transform it into something of value." - Hermann Hesse

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: IPv6 Address Resolution in Linux 2.6.27
  2013-02-08 20:23 IPv6 Address Resolution in Linux 2.6.27 Mudric, Dusan (Dusan)
@ 2013-02-11 17:13 ` Ben Hutchings
  0 siblings, 0 replies; 2+ messages in thread
From: Ben Hutchings @ 2013-02-11 17:13 UTC (permalink / raw)
  To: Mudric, Dusan (Dusan); +Cc: netdev

On Fri, 2013-02-08 at 20:23 +0000, Mudric, Dusan (Dusan) wrote:
> Hi,
> 
> I experience Address Resolution problem while using Linux 2.6.27.
[...]

This is quite an old version.  You should re-test on a current version
or, if this is a distribution kernel, use the distribution's support
channels.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-02-11 17:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-08 20:23 IPv6 Address Resolution in Linux 2.6.27 Mudric, Dusan (Dusan)
2013-02-11 17:13 ` Ben Hutchings

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).