Index: [Article Count Order] [Thread]

Date: Thu, 9 Nov 2006 18:56:15 +0900
From: Yukiyo Akisada <Yukiyo.Akisada@jp.yokogawa.com>
Subject: [users:00264] Re: Computed checksum is wrong
To: olivier.matz@6wind.com
Cc: users@tahi.org
Message-Id: <20061109185615.0f8f9023.Yukiyo.Akisada@jp.yokogawa.com>
In-Reply-To: <4552EF4C.3070907@6wind.com>
References: <4542064C.6000302@6wind.com>	<200611090338246.SM02732@037f27dd816a40c>	<4552EF4C.3070907@6wind.com>
X-Mail-Count: 00264

Hi, Olivier.

On Thu, 09 Nov 2006 10:05:16 +0100
Olivier MATZ <olivier.matz@6wind.com> wrote:

> TAHI tells the test is FAIL because it processes the checksum field by
> itself to 0x0000, which seems incorrect according to the RFC below.
> 
> >>      o  Unlike IPv4, when UDP packets are originated by an IPv6 node,
> >>          the UDP checksum is not optional.  That is, whenever
> >>          originating a UDP packet, an IPv6 node must compute a UDP
> >>          checksum over the packet and the pseudo-header, and, if that
> >>          computation yields a result of zero, it must be changed to hex
> >>          FFFF for placement in the UDP header.  IPv6 receivers must
> >>          discard UDP packets containing a zero checksum, and should log
> >>          the error.

This text says 'UDP checksum' specifically.
You may know, RFC 768 says the same.

This rule is only for UDP, isn't it?
The value of 0 is valid for protocols other than UDP.


> With the patch, I can't see the problem anymore. But what I'm not sure
> in my patch is : is it the good way to do it ?
> 
> In my opinion, the variable 'optionable' is true when the checksum can
> be an option. So, I replaced the test :
> 
> "if checksum is 0 and can be an option => set it to 0xFFFF"
> by :
> "if checksum is 0 and _cannot_ be an option => set it to 0xFFFF"

Because of above explanation, the original code says,
    optionable==true && checksum==0    =>    inverse checksum

You can also see MmUppChecksum() in McInit.cc.
We only use optionable==false for UDP.
I think that we don't need to change anything.

Thanks,


------------------------------------------------------------------------
Yukiyo Akisada <Yukiyo.Akisada@jp.yokogawa.com>