Hi, Olivier.
Inverse of checksum should be applied only to UDP packet.
Your log is the checksum of ICMPv6, right?
ICMPv6's checksum isn't optional.
So it doesn't need to inverse checksum.
The purpose of inverse is to distinguish the checksum was calculated or not by the sender.
Thanks,
On Fri, 27 Oct 2006 15:14:52 +0200
Olivier MATZ <olivier.matz@6wind.com> wrote:
> Hi all,
>
> I have a FAIL in ready logo phase2 host tests :
>
> Here is a part of the log, as you can see checksum is not the one expected :
>
> | | ICMPv6_ParameterProblem (length:64)
> | | | Type = 4
> | | | Code = 1
> | | | Checksum = 65535 calc(0)
> [...]
> ng compare _ICMPV6_icmperr.Checksum received:65535 = 0
>
>
> This fail occurs in :
> Section 1: RFC 2460 - IPv6 Specification
> TEST 13, Part A: Unrecognized Next Header in Extension Header (Multiple
> Values)
>
> In this test, multiple values of Next Header are tested, so the nut
> generates each time a different packet with a different checksum... on
> my nut I have no luck, the processed checksum is 0.
>
> But as you know (from RFC):
> 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.
>
> I made a patch that fixes the problem, but I'm not really sure of it,
> since I'm not very familiar with TAHI development. Can someone have a
> look at it ? There are 2 fixes in it :
> - first I replaced '~checksum' by 0xFFFF, because ~checksum is
> 0xFFFFFFFF as it is an uint32_t.
> - I also invert the optionable test, because I think we should replace
> the value only if the checksum field is not an option.
>
> Olivier
>
>
------------------------------------------------------------------------
Yukiyo Akisada <Yukiyo.Akisada@jp.yokogawa.com>