[RFC PATCH 00/04]: VLAN vs. packet socket inconsistencies

[Patrick McHardy <kaber@trash.net>]

There are currently a number of inconsistencies when using
VLANs with VLAN acceleration and packet sockets:

1) With hardware tagging, outgoing packets are visible without
    the VLAN header, while with software tagging the full VLAN
    header is visible

2) With hardware stripping, incoming packets for locally configured
    VLANs appear on the VLAN device without being visible on the
    underlying device. Packets for unknown VLANs are not visible
    at all. Without hardware stripping, all VLAN packets are visible
    on the underlying device.

3) With hardware filtering, some drivers disable filtering in
    promiscous mode, some don't. The consensus of some discussions
    on netdev about this was that promiscous mode should disable
    all hardware filters, but keep HW acceleration enabled.

These patches fix point 1) and 2). Point 3) needs changes to the
drivers and will be fixed separetly.

The first patch moves the VLAN tag from the cb to a new skb
member, which is necessary to avoid clashes between VLANs and
qdiscs/packet sockets use of the cb. This means on TX, packet
sockets can get the tag from the skb.

The second patch uses the new skb field to store the VLAN TCI of
stripped VLAN packets on RX and deliver them to packet sockets.

The third patch adds the VLAN TCI to the packet auxdata and delivers
it to userspace, where it can be used to reconstruct the original
packet.

The fourth patch modifies libpcap to reconstruct the original
packet. There might be a better way to do this, but it was
useful for testing.

There are mainly two remaining problems with this approach:

- socket filters for VLAN headers don't work properly since they
   expect the VLAN header to be present. Since with the approach
   taken by these patches, userspace has to have knowledge about
   VLAN acceleration anyway, it seems OK to simply add a filter
   instruction to filter on skb->vlan_tci and have userspace
   construct its filters accordingly.

- packet socket auxdata is only available for non-mmaped sockets.
   For mmaped sockets the only place to store the data is in
   struct tpacket_hdr, but that would break compatibility. Not sure
   what to do about this case.

Comments welcome.