Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX
From: Jesse Gross <hidden>
Date: 2011-01-19 16:26:51
Also in:
lkml
On Mon, Jan 17, 2011 at 10:17 AM, Simon Arlott [off-list ref] wrote:
On 17/01/11 16:00, Ben Hutchings wrote:quoted
On Sun, 2011-01-16 at 14:09 +0000, Simon Arlott wrote:quoted
[ 1.666706] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 16, addr 00:e0:81:4d:2b:ec [ 1.666767] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt gbit lnktim msi desc-v3 I have eth0 and eth0.3840 which works until I add eth0 to a bridge. While eth0 is in a bridge (the bridge device is up), eth0.3840 is unable to receive packets. Using tcpdump on eth0 shows the packets being received with a VLAN tag but they don't appear on eth0.3840. They appear with the VLAN tag on the bridge interface.[...] This means the behaviour is now consistent, whether or not hardware VLAN tag stripping is enabled. (I previously pointed out the inconsistent behaviour in <http://thread.gmane.org/gmane.linux.network/149864>.) I would consider this an improvement.Shouldn't the kernel also prevent a device from being both part of a bridge and having VLANs? Instead everything appears to work except incoming traffic.
It might make sense, although you have similar effects with non-vlan traffic to the device as well. You could make the same argument that we shouldn't allow IP addresses, etc. to be assigned to bridged devices. There are also other components that use the bridge hooks that would need to be checked. All this starts to get a bit messy.