On Mon, Feb 28, 2011 at 10:45:08PM +0100, Nicolas de Pesloüan wrote:

Le 28/02/2011 17:32, Andy Gospodarek a écrit :

quoted

On Sat, Feb 26, 2011 at 12:08:03AM +0100, Nicolas de Pesloüan wrote:

quoted

Le 25/02/2011 23:24, Andy Gospodarek a écrit :

[...]

quoted

quoted

I confirmed your suspicion, this breaks ARP monitoring.  I would still
welcome other opinions though as I think it would be nice to fix this as
low as possible.

Why do you want to fix it earlier that in ndisc_recv_ns drop? Your
original idea of silently dropping the frame there seems perfect to me.

Maybe it's just me, but I cannot understand why we want a bunch of extra
packets floating up into the stack when they may only create issues for
the recipients of these duplicate frames.

Clearly my original patch needs to be refined so ARP monitoring still
works, but I would rather fix the issue there than in a higher layer.

Jay explained that the current implementation should already trap those 
frames, on inactive slaves, in modes where inactive slaves exist. I agree 
with him.

What mode are you seeing this problem in? If the current "should drop" 
logic is leaking, then yes, we should fix it. But we currently don't see 
where it is leaking.

Use round-robin.  To reproduce just take the interface down and bring it
back up.  You should see the messages right away.

I've been doing some more testing on a new patch and should have
something ready tomorrow.  My latest patch actually replaces the final
'return 0' with a call to a function that will return true if the sender
was the device that received it.  This will hopefully prevent some of
the failures with the first patch I posted.  I'll know a bit more
tomorrow if this approach seems reasonable.