netdev - Re: [RFC] Should skb->csum include 8021Q header for CHECKSUM_COMPLETE && NETIF_F_HW_VLAN_CTAG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 29 Nov 2013 11:08:22 -0800
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	netdev@...r.kernel.org
Subject: Re: [RFC] Should skb->csum include 8021Q header for
 CHECKSUM_COMPLETE && NETIF_F_HW_VLAN_CTAG_RX

On Fri, 29 Nov 2013 13:28:19 +0000
Thomas Graf <tgraf@...g.ch> wrote:

> Hi
> 
> Given CHECKSUM_COMPLETE, is skb->csum supposed to include the
> checksum of the VLAN header if the header was stripped by the
> NIC?
> 
> The answer is clear for non accelerated VLAN: it covers all of
> the packet without ethernet CRC.
> 
> For the accelerated path the answer is less clear after staring
> at drivers. The stack currently only fixes the csum for the
> software path.
> 
> We are seeing hw csum failure warnings for drivers like enic if
> OVS pops a VLAN header that was previously stripped  in hardware.
> Should we force CHECKSUM_NONE like VXLAN does or are all drivers
> guaranteed to include VLAN bits for CHECK_COMPLETE regardless of
> acceleration?
> 
> Best,
> Thomas
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Most hardware is smart enough that if it strips the VLAN header,
it does not include it in the checksum.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html