Received-SPF: pass (google.com: domain of linux-kernel+bounces-185011-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 21 May 2024 09:28:05 -0400
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>, 
 Chengen Du <chengen.du@canonical.com>, 
 Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: davem@davemloft.net, 
 edumazet@google.com, 
 kuba@kernel.org, 
 netdev@vger.kernel.org, 
 linux-kernel@vger.kernel.org
Message-ID: <664ca1651b66_14f7a8294cb@willemb.c.googlers.com.notmuch>
In-Reply-To: <eaf33ba66cbdc639b0209b232f892ec8a52a1f21.camel@redhat.com>
References: <20240520070348.26725-1-chengen.du@canonical.com>
 <664b97e8abe7a_12b4762946f@willemb.c.googlers.com.notmuch>
 <CAPza5qcGyfcUYOoznci4e=1eaScVTgkzAhXfKSG3bTzC=aOwew@mail.gmail.com>
 <eaf33ba66cbdc639b0209b232f892ec8a52a1f21.camel@redhat.com>
Subject: Re: [PATCH] af_packet: Handle outgoing VLAN packets without hardware
 offloading
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: 7bit

Paolo Abeni wrote:
> 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.

Bogus how exactly?

> > 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.

Trying to extract L2 or VLAN information from the any device may be
the real issue here.

> > 
> > 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.

ETH_HLEN is pulled, but the VLAN tag is still present, right?

> > 
> > 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.

Any change must indeed not break existing users. It's not sufficient
to change pcap/tcpdump. There are lots of other PF_PACKET users out
there. Related, it is helpful to verify that tcpdump agrees to a patch
before we change the ABI for it.