Bug 688292 - VLAN 0 should be treated as "no vlan tag"
Summary: VLAN 0 should be treated as "no vlan tag"
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.9
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-16 17:57 UTC by Mike Belangia
Modified: 2018-11-14 13:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-17 12:55:20 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Mike Belangia 2011-03-16 17:57:57 UTC
Description of problem:

Text taken from post:

http://kerneltrap.org/mailarchive/linux-netdev/2010/7/18/6281270

- 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).



Version-Release number of selected component (if applicable):
Kernel-2.6.9-89.35.1

How reproducible:
Every time

Steps to Reproduce:
1. Send packets tagged with VLAN 0 to a system without VLAN 0 configured
2. Packets are dropped 
3.

Actual results:
Discarded packets

Expected results:
Packets not dropped

Additional info:

Comment 1 Mike Belangia 2011-03-17 12:55:20 UTC
Please disregard.  The customer has now clarified that he does not see this behavior on RHEL 4.


Note You need to log in before you can comment on or make changes to this bug.