[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <664ca1651b66_14f7a8294cb@willemb.c.googlers.com.notmuch>
Date: Tue, 21 May 2024 09:28:05 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Paolo Abeni <pabeni@...hat.com>,
Chengen Du <chengen.du@...onical.com>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net,
edumazet@...gle.com,
kuba@...nel.org,
netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] af_packet: Handle outgoing VLAN packets without hardware
offloading
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.
Powered by blists - more mailing lists