[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66928c6d9ea62_27541c294c2@willemb.c.googlers.com.notmuch>
Date: Sat, 13 Jul 2024 10:17:17 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Chengen Du <chengen.du@...onical.com>,
willemdebruijn.kernel@...il.com
Cc: davem@...emloft.net,
edumazet@...gle.com,
kuba@...nel.org,
pabeni@...hat.com,
kaber@...sh.net,
netdev@...r.kernel.org,
linux-kernel@...r.kernel.org,
Chengen Du <chengen.du@...onical.com>,
stable@...r.kernel.org
Subject: Re: [PATCH net v10] af_packet: Handle outgoing VLAN packets without
hardware offloading
Chengen Du wrote:
> The issue initially stems from libpcap. The ethertype will be overwritten
> as the VLAN TPID if the network interface lacks hardware VLAN offloading.
> In the outbound packet path, if hardware VLAN offloading is unavailable,
> the VLAN tag is inserted into the payload but then cleared from the sk_buff
> struct. Consequently, this can lead to a false negative when checking for
> the presence of a VLAN tag, causing the packet sniffing outcome to lack
> VLAN tag information (i.e., TCI-TPID). As a result, the packet capturing
> tool may be unable to parse packets as expected.
>
> The TCI-TPID is missing because the prb_fill_vlan_info() function does not
> modify the tp_vlan_tci/tp_vlan_tpid values, as the information is in the
> payload and not in the sk_buff struct. The skb_vlan_tag_present() function
> only checks vlan_all in the sk_buff struct. In cooked mode, the L2 header
> is stripped, preventing the packet capturing tool from determining the
> correct TCI-TPID value. Additionally, the protocol in SLL is incorrect,
> which means the packet capturing tool cannot parse the L3 header correctly.
>
> Link: https://github.com/the-tcpdump-group/libpcap/issues/1105
> Link: https://lore.kernel.org/netdev/20240520070348.26725-1-chengen.du@canonical.com/T/#u
> Fixes: 393e52e33c6c ("packet: deliver VLAN TCI to userspace")
> Cc: stable@...r.kernel.org
> Signed-off-by: Chengen Du <chengen.du@...onical.com>
Reviewed-by: Willem de Bruijn <willemb@...gle.com>
Powered by blists - more mailing lists