Most recent kernel where this bug did *NOT* occur: Unknown Distribution:Debian Hardware Environment:Laptop Software Environment: Problem Description:8021q vlan, tags not visible on base interface. e.g. create vlans #vconfig add eth1 330 tcpdump -i eth1 ping [via eth1.330] The dump has no vlan info/tag If sniffing on a interface connected to a trunk port on a switch the tags can be seen. Steps to reproduce: create a vlan add a subnet to the vlan interface run ping out the interface sniff on base interface. if done with 2 vlans, the base interface displays the traffic from both, interleaved with no vlan tags.
This will be the case with any NIC that does hw-acceleration (e1000 and most other newer NICs). It would require modifying the driver to not advertise it's vlan hw-accel and not strip tags internally for this sniffing to work. It is possible you could get the NIC driver writer(s) to allow the VLAN-HW-ACCEL to be disabled, so please redirect this bug to them.
Is there real value to HW vlan acceleration ? Adding and removing 4bytes form a packet header ? CRC HW acceleration makes sense as it is a CPU intensive task. Being able to see the packets as they on the wire entering and leaving the interface is valuable, and a great debugging tool.
What's the course of action? This seems quite useful to have headers for sniffing, maybe it should be some configurable option (like module parameter) that driver would implement. But I agree this seems to be driver's task. You may want to bring up this topic on LKML for discussion. Thanks.