Re: [PATCH] openvswitch: Trim off padding before L3 conntrack processing

2017-12-17 Thread Pravin Shelar
On Thu, Dec 14, 2017 at 12:05 PM, Ed Swierk wrote: > On Wed, Dec 13, 2017 at 4:58 PM, Pravin Shelar wrote: >> On Tue, Dec 12, 2017 at 8:17 AM, Ed Swierk >> wrote: >>> A short IPv4 packet may have up to 6 bytes of padding

Re: [PATCH] openvswitch: Trim off padding before L3 conntrack processing

2017-12-14 Thread Ed Swierk
On Wed, Dec 13, 2017 at 4:58 PM, Pravin Shelar wrote: > On Tue, Dec 12, 2017 at 8:17 AM, Ed Swierk wrote: >> A short IPv4 packet may have up to 6 bytes of padding following the IP >> payload when received on an Ethernet device. >> >> In the normal

Re: [PATCH] openvswitch: Trim off padding before L3 conntrack processing

2017-12-13 Thread Pravin Shelar
On Tue, Dec 12, 2017 at 8:17 AM, Ed Swierk wrote: > A short IPv4 packet may have up to 6 bytes of padding following the IP > payload when received on an Ethernet device. > > In the normal IPv4 receive path, ip_rcv() trims the packet to > ip_hdr->tot_len before invoking

[PATCH] openvswitch: Trim off padding before L3 conntrack processing

2017-12-12 Thread Ed Swierk
A short IPv4 packet may have up to 6 bytes of padding following the IP payload when received on an Ethernet device. In the normal IPv4 receive path, ip_rcv() trims the packet to ip_hdr->tot_len before invoking NF_INET_PRE_ROUTING hooks (including conntrack). Then any subsequent L3+ processing