> Patrick McHardy wrote:
quoted text
> We've been talking about an IFF_ALLVLAN flag on netdev a while
> ago, which would disable VLAN hardware filters, similar to
> IFF_ALLMULTI. An additional flag on the ethernet device could
> indicate that it should receive unknown VLANs directly. That
> would introduce some possible inconsistencies however since the
> flag could be set without the VLAN code even loaded, in which
> case it would not have any effect.

My original thought was to do something like this in net/core/dev.c
using a method similar to handle_bridge or handle_macvlen.  So, if the
packet doesn't get handled by the ptype_base list and IFF_ALLVLAN is
set, then strip the header and let the packet through.  The sticky point
would be whether or not this policy should be enabled by default, as it
seems to be in other network stacks.

quoted text
> 
> Another possibility would be to use a catch-all VLAN device with
> VID 0xfff (reserved for implementation use). This would allow
> to configure priority mappings, header reordering etc. and have
> separate statistics. The drivers could just use the magic VID
> as an indication to disable filtering, but I would still suggest
> to add the IFF_ALLVLAN flag because its useful on its own.

Most switches treat VLAN 1 as the "Default" or "Administration" VLAN.
It might make sense to map VLAN 1 to the incoming interface, and then
use that as a catch all.  Then again, that might be a terrible idea as
well. =)

quoted text
> This can't be right though, the packet needs to be passed
> up the stack. The same change will also be needed in
> __vlan_hwaccel_rx().

Duly noted - thanks.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html