Eric why do we force the length field to '5' in the ip_fast_csum()
call of inet_gro_receive()? This happened as part of commit
a9e050f4e7f9d36afe0dcc0bddba864ee442715e ("net: tcp: GRO should be ECN
friendly")
This will cause the checksum check to fail for any IPV4 header with
options.
If that's intended, the way to do this is to reject by checking the
iph->ihl value, rather than doing so obscurely via the checksum call.
On Mon, 2012-10-22 at 23:46 -0400, David Miller wrote:
Eric why do we force the length field to '5' in the ip_fast_csum()
call of inet_gro_receive()? This happened as part of commit
a9e050f4e7f9d36afe0dcc0bddba864ee442715e ("net: tcp: GRO should be ECN
friendly")
This will cause the checksum check to fail for any IPV4 header with
options.
If that's intended, the way to do this is to reject by checking the
iph->ihl value, rather than doing so obscurely via the checksum call.
--
Hi David
GRO on IPv4 only supports ihl = 5, this is tested in :
if (*(u8 *)iph != 0x45)
goto out_unlock;
I also was planning to add some code to ip_fast_csum(addr, X) to have a
fast path (no conditional jump) for the case where X is the constant 5
Thanks !
From: Eric Dumazet <redacted>
Date: Tue, 23 Oct 2012 08:01:34 +0200
GRO on IPv4 only supports ihl = 5, this is tested in :
if (*(u8 *)iph != 0x45)
goto out_unlock;
I also was planning to add some code to ip_fast_csum(addr, X) to have a
fast path (no conditional jump) for the case where X is the constant 5
Oh indeed, thanks for clearing that up.