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: Thu, 13 Oct 2011 17:22:02 -0700 From: Jesse Gross <jesse@...ira.com> To: John Fastabend <john.r.fastabend@...el.com> Cc: Hans Schillström <hans.schillstrom@...csson.com>, Jiri Pirko <jpirko@...hat.com>, Maxime Bizon <mbizon@...ebox.fr>, "davem@...emloft.net" <davem@...emloft.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "fubar@...ibm.com" <fubar@...ibm.com> Subject: Re: [net-next PATCH] net: allow vlan traffic to be received under bond 2011/10/13 John Fastabend <john.r.fastabend@...el.com>: > On 10/13/2011 8:59 AM, Hans Schillström wrote: >> Thu, Oct 13, 2011 at 05:04:34PM CEST, mbizon@...ebox.fr wrote: >>>> >>>> On Tue, 2011-10-11 at 00:37 +0200, Jiri Pirko wrote: >>>> >>>>> Hmm, I must look at this again tomorrow but I have strong feeling this >>>>> will break some some scenario including vlan-bridge-macvlan. >>>> >>>> unless I'm mistaken, today's behaviour: >>>> >>>> # vconfig add eth0 100 >>>> # brctl addbr br0 >>>> # brctl addif br0 eth0 >>>> >>>> => eth0.100 gets no more packets, br0.100 is to be used >>>> >>>> after the patch won't we get the opposite ? >>> >>> Looks like it. The question is what is the correct behaviour... >> >> I think this it become correct now, you should not destroy lover level if possible. >> I.e. as John wrote "it's not an unexpected behaviour" >> >> Consider adding a bridge to a vlan like this >> >> vconfig add eth0 100 >> brctl addbr br1 >> brctl addif br1 eth0.100 >> >> If you later add a bridge (or bond) should the previous added bridge still work ? >> Yes I think so, for me it's the expected behaviour. >> >> brctl addbr br0 >> brctl addif br0 eth0 >> >> Regards >> Hans >> >> > > Sorry I'm not entirely sure I followed the above two posts. Note > this patch restores behavior that has existed for most of the > 2.6.x kernels. In the 3.x kernels VLAN100 is dropped in the > schematic below (assuming eth0 is active), I think this is > incorrect. Actually, for most of 2.6.x the behavior was somewhat non-deterministic since it depended on kernel version and the NIC. As a result, I think we can safely say that this wasn't a particularly firm interface that we have to be wedded to. Based on overwhelming feedback, I think the interface in this patch is the preferred one and what we should stabilize on. -- 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