summaryrefslogtreecommitdiff
path: root/net/9p
diff options
context:
space:
mode:
authorPedro Garcia <pedro.netdev@dondevamos.com>2010-07-18 15:38:44 -0700
committerDavid S. Miller <davem@davemloft.net>2010-07-18 15:38:44 -0700
commitad1afb00393915a51c21b1ae8704562bf036855f (patch)
tree68ead91b78624a66f4aabb9699f4b414b914a762 /net/9p
parent01893c82b4e6949f4e3a453c4faea34970359d76 (diff)
vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)
- Without the 8021q module loaded in the kernel, all 802.1p packets (VLAN 0 but QoS tagging) are silently discarded (as expected, as the protocol is not loaded). - Without this patch in 8021q module, these packets are forwarded to the module, but they are discarded also if VLAN 0 is not configured, which should not be the default behaviour, as VLAN 0 is not really a VLANed packet but a 802.1p packet. Defining VLAN 0 makes it almost impossible to communicate with mixed 802.1p and non 802.1p devices on the same network due to arp table issues. - Changed logic to skip vlan specific code in vlan_skb_recv if VLAN is 0 and we have not defined a VLAN with ID 0, but we accept the packet with the encapsulated proto and pass it later to netif_rx. - In the vlan device event handler, added some logic to add VLAN 0 to HW filter in devices that support it (this prevented any traffic in VLAN 0 to reach the stack in e1000e with HW filter under 2.6.35, and probably also with other HW filtered cards, so we fix it here). - In the vlan unregister logic, prevent the elimination of VLAN 0 in devices with HW filter. - The default behaviour is to ignore the VLAN 0 tagging and accept the packet as if it was not tagged, but we can still define a VLAN 0 if desired (so it is backwards compatible). Signed-off-by: Pedro Garcia <pedro.netdev@dondevamos.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/9p')
0 files changed, 0 insertions, 0 deletions