[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOrHB_BGfVAXfz4woN5x428BKV5qv5LYHEtpj=tSZwSPXoPH0Q@mail.gmail.com>
Date: Mon, 22 Jan 2018 21:40:12 -0800
From: Pravin Shelar <pshelar@....org>
To: Ed Swierk <eswierk@...portsystems.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
ovs-dev <ovs-dev@...nvswitch.org>
Subject: Re: [PATCH v3 1/2] skbuff: Add skb_network_trim
On Mon, Jan 22, 2018 at 6:42 PM, Ed Swierk <eswierk@...portsystems.com> wrote:
> IPv4 and IPv6 packets may arrive with lower-layer padding that is not
> included in the L3 length. For example, a short IPv4 packet may have
> up to 6 bytes of padding following the IP payload when received on an
> Ethernet device with a minimum packet length of 64 bytes.
>
> Higher-layer processing functions in netfilter (e.g. nf_ip_checksum(),
> and help() in nf_conntrack_ftp) assume skb->len reflects the length of
> the L3 header and payload, rather than referring back to
> ip_hdr->tot_len or ipv6_hdr->payload_len, and get confused by
> lower-layer padding.
>
> In the normal IPv4 receive path, ip_rcv() trims the packet to
> ip_hdr->tot_len before invoking netfilter hooks. In the IPv6 receive
> path, ip6_rcv() does the same using ipv6_hdr->payload_len. Similarly
> in the br_netfilter receive path, br_validate_ipv4() and
> br_validate_ipv6() trim the packet to the L3 length before invoking
> netfilter hooks.
>
> Currently the openvswitch receive path does not perform such trimming,
> which will be fixed by the next patch. In preparation, this patch adds
> a generic skb_network_trim() function.
>
> Signed-off-by: Ed Swierk <eswierk@...portsystems.com>
Acked-by: Pravin B Shelar <pshelar@....org>
Thanks.
Powered by blists - more mailing lists