TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Steve Chen]

Hello,

The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
- Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
the Linux kernel is replying the ICMP echo request in
icmpv6_echo_reply without much checking.  Is this an intentional
non-conformance to RFC3775 section 9.3.1?

Thanks,

Steve

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Brian Haley]

Hi Steve,

On 07/28/2010 11:20 PM, Steve Chen wrote:
> Hello,
> 
> The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
> - Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
> the Linux kernel is replying the ICMP echo request in
> icmpv6_echo_reply without much checking.  Is this an intentional
> non-conformance to RFC3775 section 9.3.1?

Sorry for the late reply.  I've run these tests in the past against
SLES11 (2.6.27 ?) back in January 2009 and this one passed from looking
at my logs.  I don't have that system around anymore to check the config,
etc.  I didn't see any obvious commit that would have broken it from a
quick look, do you have a test setup to do some debugging?  It will
take a little time for me to re-configure mine to run this test.

-Brian

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Steve Chen]

On Thu, Aug 12, 2010 at 4:10 PM, Brian Haley <brian.haley@hp.com> wrote:
> Hi Steve,
>
> On 07/28/2010 11:20 PM, Steve Chen wrote:
>> Hello,
>>
>> The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
>> - Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
>> the Linux kernel is replying the ICMP echo request in
>> icmpv6_echo_reply without much checking.  Is this an intentional
>> non-conformance to RFC3775 section 9.3.1?
>
> Sorry for the late reply.  I've run these tests in the past against
> SLES11 (2.6.27 ?) back in January 2009 and this one passed from looking
> at my logs.  I don't have that system around anymore to check the config,
> etc.  I didn't see any obvious commit that would have broken it from a
> quick look, do you have a test setup to do some debugging?  It will
> take a little time for me to re-configure mine to run this test.

Brian,

I'm using mip6d from git://www.umip.org/git/umip.git commit id
d1c240f3deb690af902ce1ff128780551ff6141c.  Is that the correct version
to use?  Looking at the kernel code again, the checksum error should
have been caught in icmpv6_rcv.  There are probably something wrong
with my setup.  I'll dig around a bit more.

Tests 5-3-1 to 5-3-6 also failed for me.   Did they pass for you?

Steve

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Steve Chen]

[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]

On Thu, Aug 12, 2010 at 6:04 PM, Steve Chen <schen@mvista.com> wrote:
> On Thu, Aug 12, 2010 at 4:10 PM, Brian Haley <brian.haley@hp.com> wrote:
>> Hi Steve,
>>
>> On 07/28/2010 11:20 PM, Steve Chen wrote:
>>> Hello,
>>>
>>> The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
>>> - Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
>>> the Linux kernel is replying the ICMP echo request in
>>> icmpv6_echo_reply without much checking.  Is this an intentional
>>> non-conformance to RFC3775 section 9.3.1?
>>
>> Sorry for the late reply.  I've run these tests in the past against
>> SLES11 (2.6.27 ?) back in January 2009 and this one passed from looking
>> at my logs.  I don't have that system around anymore to check the config,
>> etc.  I didn't see any obvious commit that would have broken it from a
>> quick look, do you have a test setup to do some debugging?  It will
>> take a little time for me to re-configure mine to run this test.
>
> Brian,
>
> I'm using mip6d from git://www.umip.org/git/umip.git commit id
> d1c240f3deb690af902ce1ff128780551ff6141c.  Is that the correct version
> to use?  Looking at the kernel code again, the checksum error should
> have been caught in icmpv6_rcv.  There are probably something wrong
> with my setup.  I'll dig around a bit more.
>
> Tests 5-3-1 to 5-3-6 also failed for me.   Did they pass for you?

By the way, these tests passed for me with the following patch.
Please let me know what you think.

Thanks

Steve

[-- Attachment #2: h_bit_check.patch --]
[-- Type: text/x-patch, Size: 592 bytes --]

Reinstate checks to handle BU with H bit set

Check for the H flag was omitted in 2276ddec36a3789826842ac8316553fa0702ea89.
This caused TAHI correcpondend node tests 118-123 (5.3. Receiving BU with
(H)bit is set) to fail.

diff --git a/src/cn.c b/src/cn.c
index 0318e9e..a036d96 100644
--- a/src/cn.c
+++ b/src/cn.c
@@ -173,6 +173,10 @@ static int cn_bu_check(struct ip6_mh_binding_update *bu, ssize_t len,
 	int ret;
 
 	non_ind = mh_opt(&bu->ip6mhbu_hdr, mh_opts, IP6_MHOPT_NONCEID);
+
+	if (bu->ip6mhbu_flags & IP6_MH_BU_HOME)
+		return non_ind ? -1 : 0;
+
 	if (!non_ind)
 		return -1;
 

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Brian Haley]

On 08/12/2010 07:04 PM, Steve Chen wrote:
> On Thu, Aug 12, 2010 at 4:10 PM, Brian Haley <brian.haley@hp.com> wrote:
>> Hi Steve,
>>
>> On 07/28/2010 11:20 PM, Steve Chen wrote:
>>> Hello,
>>>
>>> The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
>>> - Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
>>> the Linux kernel is replying the ICMP echo request in
>>> icmpv6_echo_reply without much checking.  Is this an intentional
>>> non-conformance to RFC3775 section 9.3.1?
>>
>> Sorry for the late reply.  I've run these tests in the past against
>> SLES11 (2.6.27 ?) back in January 2009 and this one passed from looking
>> at my logs.  I don't have that system around anymore to check the config,
>> etc.  I didn't see any obvious commit that would have broken it from a
>> quick look, do you have a test setup to do some debugging?  It will
>> take a little time for me to re-configure mine to run this test.
> 
> Brian,
> 
> I'm using mip6d from git://www.umip.org/git/umip.git commit id
> d1c240f3deb690af902ce1ff128780551ff6141c.  Is that the correct version
> to use?  Looking at the kernel code again, the checksum error should
> have been caught in icmpv6_rcv.  There are probably something wrong
> with my setup.  I'll dig around a bit more.

The system has long since been dismantled, so I'm not sure what version
of mip6d I used.  Yes, icmpv6_rcv() does check for checksum errors, it
would be good to print-out three addresses to see which one is which,
in case they weren't swapped correctly or something.  It would be good
to know what value skb->ip_summed was too, as a start.

> Tests 5-3-1 to 5-3-6 also failed for me.   Did they pass for you?

I had no failures, but 5 warnings (2-1-6, 2-3-11, 4-7-1, 5-4-2, and
6-3-1).  I'll see if I can get a CN test run done on my current
config.

-Brian

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Steve Chen]

On Thu, Aug 12, 2010 at 9:23 PM, Brian Haley <brian.haley@hp.com> wrote:
> On 08/12/2010 07:04 PM, Steve Chen wrote:
>> On Thu, Aug 12, 2010 at 4:10 PM, Brian Haley <brian.haley@hp.com> wrote:
>>> Hi Steve,
>>>
>>> On 07/28/2010 11:20 PM, Steve Chen wrote:
>>>> Hello,
>>>>
>>>> The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
>>>> - Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
>>>> the Linux kernel is replying the ICMP echo request in
>>>> icmpv6_echo_reply without much checking.  Is this an intentional
>>>> non-conformance to RFC3775 section 9.3.1?
>>>
>>> Sorry for the late reply.  I've run these tests in the past against
>>> SLES11 (2.6.27 ?) back in January 2009 and this one passed from looking
>>> at my logs.  I don't have that system around anymore to check the config,
>>> etc.  I didn't see any obvious commit that would have broken it from a
>>> quick look, do you have a test setup to do some debugging?  It will
>>> take a little time for me to re-configure mine to run this test.
>>
>> Brian,
>>
>> I'm using mip6d from git://www.umip.org/git/umip.git commit id
>> d1c240f3deb690af902ce1ff128780551ff6141c.  Is that the correct version
>> to use?  Looking at the kernel code again, the checksum error should
>> have been caught in icmpv6_rcv.  There are probably something wrong
>> with my setup.  I'll dig around a bit more.
>
> The system has long since been dismantled, so I'm not sure what version
> of mip6d I used.  Yes, icmpv6_rcv() does check for checksum errors, it
> would be good to print-out three addresses to see which one is which,
> in case they weren't swapped correctly or something.  It would be good
> to know what value skb->ip_summed was too, as a start.

It appears that skb->ip_summed is always 1 (CHECKSUM_UNNECESSARY).
I'm using e1000e.  Looking at the driver, there is a checksum offload
hardware.  I think the code is doing frame check on the entire
Ethernet packet.  Since no error was found, it assume everything
inside is correct.
>
>> Tests 5-3-1 to 5-3-6 also failed for me.   Did they pass for you?
>
> I had no failures, but 5 warnings (2-1-6, 2-3-11, 4-7-1, 5-4-2, and
> 6-3-1).  I'll see if I can get a CN test run done on my current
> config.
>

All these tests passed without warnings for me.  However, I do see
warnings on 2-3-10-2 and 6-2-2 with my setup.

Steve

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Brian Haley]

On 08/13/2010 01:34 PM, Steve Chen wrote:
>>>>> The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
>>>>> - Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
>>>>> the Linux kernel is replying the ICMP echo request in
>>>>> icmpv6_echo_reply without much checking.  Is this an intentional
>>>>> non-conformance to RFC3775 section 9.3.1?
[snip]

> It appears that skb->ip_summed is always 1 (CHECKSUM_UNNECESSARY).
> I'm using e1000e.  Looking at the driver, there is a checksum offload
> hardware.  I think the code is doing frame check on the entire
> Ethernet packet.  Since no error was found, it assume everything
> inside is correct.

# ethtool -K ethX rx off

Does that help?  Does using a different NIC help?

-Brian

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Steve Chen]

On Fri, Aug 13, 2010 at 12:55 PM, Brian Haley <brian.haley@hp.com> wrote:
> On 08/13/2010 01:34 PM, Steve Chen wrote:
>>>>>> The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
>>>>>> - Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
>>>>>> the Linux kernel is replying the ICMP echo request in
>>>>>> icmpv6_echo_reply without much checking.  Is this an intentional
>>>>>> non-conformance to RFC3775 section 9.3.1?
> [snip]
>
>> It appears that skb->ip_summed is always 1 (CHECKSUM_UNNECESSARY).
>> I'm using e1000e.  Looking at the driver, there is a checksum offload
>> hardware.  I think the code is doing frame check on the entire
>> Ethernet packet.  Since no error was found, it assume everything
>> inside is correct.
>
> # ethtool -K ethX rx off
>
> Does that help?  Does using a different NIC help?
>

ethtool did not help.

I tried to run the test with a different NIC, but I keep getting

...

IPSEC_AKEY      :               --------------------
IPSEC_EALGO     :               ---------
IPSEC_EKEY      :               ------------------------
IPSEC_SUPPORT   :               OFF
RR_TIMEOUT      :               3
TIMEOUT :               2
WAIT_RATELIMIT  :               1
send Ra_R0_AllNd
Wait 3 sec.
Clear Captured Packets (Link0)
Clear Captured Packets (Link0)
send Ns_R0_AllNd
######### Packe Name(RH) Field Value(NextHeader) is NULL
CNT_SendAndRecv Status=UnKnown
NG UnKnown
  -> Initialization Fail
...

I'm have not been able to locate problem...  Will continue to look Monday.

Steve

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Steve Chen]

On Fri, Aug 13, 2010 at 5:25 PM, Steve Chen <schen@mvista.com> wrote:
> On Fri, Aug 13, 2010 at 12:55 PM, Brian Haley <brian.haley@hp.com> wrote:
>> On 08/13/2010 01:34 PM, Steve Chen wrote:
>>>>>>> The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
>>>>>>> - Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
>>>>>>> the Linux kernel is replying the ICMP echo request in
>>>>>>> icmpv6_echo_reply without much checking.  Is this an intentional
>>>>>>> non-conformance to RFC3775 section 9.3.1?
>> [snip]
>>
>>> It appears that skb->ip_summed is always 1 (CHECKSUM_UNNECESSARY).
>>> I'm using e1000e.  Looking at the driver, there is a checksum offload
>>> hardware.  I think the code is doing frame check on the entire
>>> Ethernet packet.  Since no error was found, it assume everything
>>> inside is correct.
>>
>> # ethtool -K ethX rx off
>>
>> Does that help?  Does using a different NIC help?
>>
>
> ethtool did not help.
>
> I tried to run the test with a different NIC, but I keep getting
>
> ...
>
> IPSEC_AKEY      :               --------------------
> IPSEC_EALGO     :               ---------
> IPSEC_EKEY      :               ------------------------
> IPSEC_SUPPORT   :               OFF
> RR_TIMEOUT      :               3
> TIMEOUT :               2
> WAIT_RATELIMIT  :               1
> send Ra_R0_AllNd
> Wait 3 sec.
> Clear Captured Packets (Link0)
> Clear Captured Packets (Link0)
> send Ns_R0_AllNd
> ######### Packe Name(RH) Field Value(NextHeader) is NULL
> CNT_SendAndRecv Status=UnKnown
> NG UnKnown
>  -> Initialization Fail
> ...

Brian,

Oops, set the Link0 in nut.def to the wrong value.  However, I'm still
getting the same failure with different NIC.  I'll start looking into
the code.  Please let me know your test results.

Thanks,

Steve

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Steve Chen]

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]

On Mon, Aug 16, 2010 at 9:07 AM, Steve Chen <schen@mvista.com> wrote:
> On Fri, Aug 13, 2010 at 5:25 PM, Steve Chen <schen@mvista.com> wrote:
>> On Fri, Aug 13, 2010 at 12:55 PM, Brian Haley <brian.haley@hp.com> wrote:
>>> On 08/13/2010 01:34 PM, Steve Chen wrote:
>>>>>>>> The TAHI correspondent node tests CN-6-4-1 (Processing in upper layer
>>>>>>>> - Echo Checksum) failed for me in the 2.6.32 kernel.  It appears that
>>>>>>>> the Linux kernel is replying the ICMP echo request in
>>>>>>>> icmpv6_echo_reply without much checking.  Is this an intentional
>>>>>>>> non-conformance to RFC3775 section 9.3.1?
>>> [snip]
>>>
>>>> It appears that skb->ip_summed is always 1 (CHECKSUM_UNNECESSARY).
>>>> I'm using e1000e.  Looking at the driver, there is a checksum offload
>>>> hardware.  I think the code is doing frame check on the entire
>>>> Ethernet packet.  Since no error was found, it assume everything
>>>> inside is correct.
>>>
>>> # ethtool -K ethX rx off
>>>
>>> Does that help?  Does using a different NIC help?
>>>
>>
>> ethtool did not help.
>>
>> I tried to run the test with a different NIC, but I keep getting
>>
>> ...
>>
>> IPSEC_AKEY      :               --------------------
>> IPSEC_EALGO     :               ---------
>> IPSEC_EKEY      :               ------------------------
>> IPSEC_SUPPORT   :               OFF
>> RR_TIMEOUT      :               3
>> TIMEOUT :               2
>> WAIT_RATELIMIT  :               1
>> send Ra_R0_AllNd
>> Wait 3 sec.
>> Clear Captured Packets (Link0)
>> Clear Captured Packets (Link0)
>> send Ns_R0_AllNd
>> ######### Packe Name(RH) Field Value(NextHeader) is NULL
>> CNT_SendAndRecv Status=UnKnown
>> NG UnKnown
>>  -> Initialization Fail
>> ...
>
> Brian,
>
> Oops, set the Link0 in nut.def to the wrong value.  However, I'm still
> getting the same failure with different NIC.  I'll start looking into
> the code.  Please let me know your test results.
>
> Thanks,
>
> Steve
>

I trace through the code.  It appears that the network driver (e1000e
for my setup) always set ip_summed to CHECKSUM_UNNECESSARY.  I have
been unsuccessful to get the driver to take the other branch where
ip_summed is set to CHECKSUM_COMPLETE.  Even when I hard code
ip_summed to CHECKSUM_COMPLETE, __skb_checksum_complete_head set
ip_summed to CHECKSUM_UNNECESSARY after recomputing the checksum.

So far the only way I'm able to get ICMP to recompute checksum is
through the attached hack.  Even though I can get all the tests to
pass, but it just seem wrong.

Steve

[-- Attachment #2: force_icmp6_checksum_for_mip6.patch --]
[-- Type: text/x-patch, Size: 785 bytes --]

MR: 39774
Type: Defect Fix
Disposition: Needs submitting to mipv6
Description:
Fix failure in TAHI conformance test CN-6-4-1 - Processing in upper layer -
Echo Checksum.  It appears the kernel does not perform ICMP checksum if
no error was detected at the link layer.  This patch forces an ICMP checksum
recalculation for MIP6.

diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index f23ebbe..54a77ca 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -663,6 +663,9 @@ static int icmpv6_rcv(struct sk_buff *skb)
 
 	/* Perform checksum. */
 	switch (skb->ip_summed) {
+#if defined(CONFIG_IPV6_MIP6) || defined(CONFIG_IPV6_MIP6_MODULE)
+	case CHECKSUM_UNNECESSARY:
+#endif
 	case CHECKSUM_COMPLETE:
 		if (!csum_ipv6_magic(saddr, daddr, skb->len, IPPROTO_ICMPV6,
 				     skb->csum))

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[David Miller]

From: Steve Chen <schen@mvista.com>
Date: Thu, 19 Aug 2010 13:35:14 -0500

> I trace through the code.  It appears that the network driver (e1000e
> for my setup) always set ip_summed to CHECKSUM_UNNECESSARY.  I have
> been unsuccessful to get the driver to take the other branch where
> ip_summed is set to CHECKSUM_COMPLETE.  Even when I hard code
> ip_summed to CHECKSUM_COMPLETE, __skb_checksum_complete_head set
> ip_summed to CHECKSUM_UNNECESSARY after recomputing the checksum.
> 
> So far the only way I'm able to get ICMP to recompute checksum is
> through the attached hack.  Even though I can get all the tests to
> pass, but it just seem wrong.

If turning off hardware RX checksumming with ethtool has no effect,
and the problem is seen with multiple ethernet cards, the problem
is elsewhere.

First of all, if you turn RX checksumming off, the checksum field
of the SKB should always be skb->ip_summed = 0.  If this is not
happening, find out why.

Put diagnostics into drivers/net/e1000e/netdev.c:e1000_rx_checksum()
and see what's happening.

If that code isn't setting ->ip_summed, then something else is,
perhaps some decapsulation code?  Do these packets get embedded
in a tunnel or other kind of transport?  I see that this test
has IPSEC disabled, so it can't be that.

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Steve Chen]

On Thu, Aug 19, 2010 at 7:06 PM, David Miller <davem@davemloft.net> wrote:
> From: Steve Chen <schen@mvista.com>
> Date: Thu, 19 Aug 2010 13:35:14 -0500
>
>> I trace through the code.  It appears that the network driver (e1000e
>> for my setup) always set ip_summed to CHECKSUM_UNNECESSARY.  I have
>> been unsuccessful to get the driver to take the other branch where
>> ip_summed is set to CHECKSUM_COMPLETE.  Even when I hard code
>> ip_summed to CHECKSUM_COMPLETE, __skb_checksum_complete_head set
>> ip_summed to CHECKSUM_UNNECESSARY after recomputing the checksum.
>>
>> So far the only way I'm able to get ICMP to recompute checksum is
>> through the attached hack.  Even though I can get all the tests to
>> pass, but it just seem wrong.
>
> If turning off hardware RX checksumming with ethtool has no effect,
> and the problem is seen with multiple ethernet cards, the problem
> is elsewhere.
>
> First of all, if you turn RX checksumming off, the checksum field
> of the SKB should always be skb->ip_summed = 0.  If this is not
> happening, find out why.

Ahhh, thats my problem.  I incorrectly thought the ip_summed should be
2.  The ip_summed is set to 1 in
__skb_checksum_complete_head.  Looking at the code, shouldn't

if (likely(!sum))

be

if (likely(sum))

Since sum == 0 would indicate an error?

Thanks

Steve

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Jesse Gross]

On Fri, Aug 20, 2010 at 1:16 PM, Steve Chen <schen@mvista.com> wrote:
>
> On Thu, Aug 19, 2010 at 7:06 PM, David Miller <davem@davemloft.net> wrote:
> > From: Steve Chen <schen@mvista.com>
> > Date: Thu, 19 Aug 2010 13:35:14 -0500
> >
> >> I trace through the code.  It appears that the network driver (e1000e
> >> for my setup) always set ip_summed to CHECKSUM_UNNECESSARY.  I have
> >> been unsuccessful to get the driver to take the other branch where
> >> ip_summed is set to CHECKSUM_COMPLETE.  Even when I hard code
> >> ip_summed to CHECKSUM_COMPLETE, __skb_checksum_complete_head set
> >> ip_summed to CHECKSUM_UNNECESSARY after recomputing the checksum.
> >>
> >> So far the only way I'm able to get ICMP to recompute checksum is
> >> through the attached hack.  Even though I can get all the tests to
> >> pass, but it just seem wrong.
> >
> > If turning off hardware RX checksumming with ethtool has no effect,
> > and the problem is seen with multiple ethernet cards, the problem
> > is elsewhere.
> >
> > First of all, if you turn RX checksumming off, the checksum field
> > of the SKB should always be skb->ip_summed = 0.  If this is not
> > happening, find out why.
>
> Ahhh, thats my problem.  I incorrectly thought the ip_summed should be
> 2.  The ip_summed is set to 1 in
> __skb_checksum_complete_head.  Looking at the code, shouldn't
>
> if (likely(!sum))
>
> be
>
> if (likely(sum))
>
> Since sum == 0 would indicate an error?

sum == 0 indicates that the checksum is correct.

If you compute the checksum of a packet containing the correct
checksum the result is 0.  It's like a slightly more complicated
varient of a parity bit.

Re: TAHI CN-6-4-1 failed on Linux 2.6.32 kernel

[Steve Chen]

On Fri, Aug 20, 2010 at 12:35 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Fri, Aug 20, 2010 at 1:16 PM, Steve Chen <schen@mvista.com> wrote:
>>
>> On Thu, Aug 19, 2010 at 7:06 PM, David Miller <davem@davemloft.net> wrote:
>> > From: Steve Chen <schen@mvista.com>
>> > Date: Thu, 19 Aug 2010 13:35:14 -0500
>> >
>> >> I trace through the code.  It appears that the network driver (e1000e
>> >> for my setup) always set ip_summed to CHECKSUM_UNNECESSARY.  I have
>> >> been unsuccessful to get the driver to take the other branch where
>> >> ip_summed is set to CHECKSUM_COMPLETE.  Even when I hard code
>> >> ip_summed to CHECKSUM_COMPLETE, __skb_checksum_complete_head set
>> >> ip_summed to CHECKSUM_UNNECESSARY after recomputing the checksum.
>> >>
>> >> So far the only way I'm able to get ICMP to recompute checksum is
>> >> through the attached hack.  Even though I can get all the tests to
>> >> pass, but it just seem wrong.
>> >
>> > If turning off hardware RX checksumming with ethtool has no effect,
>> > and the problem is seen with multiple ethernet cards, the problem
>> > is elsewhere.
>> >
>> > First of all, if you turn RX checksumming off, the checksum field
>> > of the SKB should always be skb->ip_summed = 0.  If this is not
>> > happening, find out why.
>>
>> Ahhh, thats my problem.  I incorrectly thought the ip_summed should be
>> 2.  The ip_summed is set to 1 in
>> __skb_checksum_complete_head.  Looking at the code, shouldn't
>>
>> if (likely(!sum))
>>
>> be
>>
>> if (likely(sum))
>>
>> Since sum == 0 would indicate an error?
>
> sum == 0 indicates that the checksum is correct.
> If you compute the checksum of a packet containing the correct checksum the
> result is 0.  It's like a slightly more complicated varient of a parity bit.

It appears the issue lies somewhere within CONNTRACK.  A co-worker
tested with CONNTRACK disable, and the test passed.  Looks like I have
a bit of homework to do.  Thank you for all the helpful hints that got
me this far.

Steve