lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 28 Feb 2011 21:35:25 -0500 From: Andy Gospodarek <andy@...yhouse.net> To: Nicolas de Pesloüan <nicolas.2p.debian@...il.com> Cc: Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org, David Miller <davem@...emloft.net>, Herbert Xu <herbert@...dor.hengli.com.au>, Jay Vosburgh <fubar@...ibm.com>, Jiri Pirko <jpirko@...hat.com> Subject: Re: [PATCH net-2.6] bonding: drop frames received with master's source MAC 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 : >> On Sat, Feb 26, 2011 at 12:08:03AM +0100, Nicolas de Pesloüan wrote: >>> Le 25/02/2011 23:24, Andy Gospodarek a écrit : >> [...] >>>> >>>> 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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists