Re: Receiving raw packets (incl. VLAN tags) on raw sockets

Jan Grashöfer [off-list ref] writes:

On 14/06/17 16:41, Eric W. Biederman wrote:

quoted

That does not work.  That is is just the software fallback for when
the device driver does not have a special case the processing
vlan tagged packets.

There was a major inconsistency that for a long time the hardware
network drivers were stripping tags and the software ones were not.

The code you are playing with is the fix for the rare slow path
that does not happen to strip the tags.  Disabling the rare slow path
might temporarily solve your symptoms but it will be much more painful
when you are entrenched in your ways and discover that high performance
hardware behaves differently than your software device.

Thanks for your reply! Actually, I was referring to COTS hardware that
incorporates offloading features. But, when it comes to (security)
monitoring, offloading is usually disabled [1,2] to process the
packets as seen on the wire. Thus the "slow path" would be the default
path for most monitoring applications. That is, what makes this
situation kind of weird. After turning off the NIC's VLAN offloading,
it took me some time to realize that now the kernel strips off VLAN
tags. If someone decides that VLAN offloading is not needed, I think
the kernel should not enforce it.

In practice it is too too complicated to support both so we choose the
mode where vlan tags are always stripped.

I can imagine a tweak to pf_packet where it readds the vlan tag before
it gets to user space.  I can not image changing how we treat the vlan
tags internally to the kernel.

There were nasty kernel bugs before: 
bcc6d4790361 ("net: vlan: make non-hw-accel rx path similar to hw-accel")

I don't even want to contemplate opening that can of worms again.

Eric