Re: [PATCH] af_packet: Handle outgoing VLAN packets without hardware offloading

[Paolo Abeni <pabeni@redhat.com>]

On Tue, 2024-05-21 at 11:31 +0800, Chengen Du wrote:
> I would appreciate any suggestions you could offer, as I am not as
> familiar with this area as you are.
> 
> I encountered an issue while capturing packets using tcpdump, which
> leverages the libpcap library for sniffing functionalities.
> Specifically, when I use "tcpdump -i any" to capture packets and
> hardware VLAN offloading is unavailable, some bogus packets appear.
> In this scenario, Linux uses cooked-mode capture (SLL) for the "any"
> device, reading from a PF_PACKET/SOCK_DGRAM socket instead of the
> usual PF_PACKET/SOCK_RAW socket.
> 
> Using SOCK_DGRAM instead of SOCK_RAW means that the Linux socket code
> does not supply the packet's link-layer header.
> Based on the code in af_packet.c, SOCK_DGRAM strips L2 headers from
> the original packets and provides SLL for some L2 information.

> From the receiver's perspective, the VLAN information can only be
> parsed from SLL, which causes issues if the kernel stores VLAN
> information in the payload.
> 
> As you mentioned, this modification affects existing PF_PACKET receivers.
> For example, libpcap needs to change how it parses VLAN packets with
> the PF_PACKET/SOCK_RAW socket.
> The lack of VLAN information in SLL may prevent the receiver from
> properly decoding the L3 frame in cooked mode.
> 
> I am new to this area and would appreciate it if you could kindly
> correct any misunderstandings I might have about the mechanism.
> I would also be grateful for any insights you could share on this issue.
> Additionally, I am passionate about contributing to resolving this
> issue and am willing to work on patches based on your suggestions.

One possible way to address the above in a less invasive manner, could
be allocating a new TP_STATUS_VLAN_HEADER_IS_PRESENT bit, set it for
SLL when the vlan is not stripped by H/W and patch tcpdump to interpret
such info.

Side note: net-next is currently closed, and this patch should target
such tree (in the subj prefix).

The merge window for v6.10 has begun and we have already posted our
pull request. Therefore net-next is closed for new drivers, features,
code refactoring and optimizations. We are currently accepting bug
fixes only.

Please repost when net-next reopens after May 26th.

RFC patches sent for review only are obviously welcome at any time.

See:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#development-cycle

Cheers,

Paolo