Kiyoaki,
I have found the checksum issue.
Although RFC 3775 states to use 2 as the Next Header value in the
pseudoheader, TAHI expects this value to be 135.
The pseudo-header contains IPv6 header fields, as specified in
Section 8.1 of RFC 2460 [11]. The Next Header value used in the
pseudo-header is 2. The addresses used in the pseudo-header are
the addresses that appear in the Source and Destination Address
fields in the IPv6 packet carrying the Mobility Header.
I found some threads on-line discussing this issue. Most people believe
the IETF will change RFC 3775 to operate the way TAHI expects. Can you
comment on this if you have time?
Best Regards,
Tammy
-----Original Message-----
From: K.Kawaguchi [mailto:kawaguti@ysknet.co.jp]
Sent: Thursday, June 05, 2008 9:27 PM
To: Leino, Tammy
Cc: users@tahi.org
Subject: Re: [users:00748] Re: MIPv6 Conformance Test Suite CN-1-1
Hello Tammy,
As you expected first, the checksum fields differ. It is the bottom of
the log stuck on below.
This tool is already used for many users. Probably, calculation of the
checksum of this tool will be right.
The checksum calculation of MIPv6 message is described by
"6.1.1. Format" in RFC3775". Please check processing.
1.html#vRecvPKT3 in log file
The logic structure of BE message and the log of the check by the
tool.
-----------------------------------------------
Recv at 16:10:52
Frame_Ether (length:78)
| Hdr_Ether (length:14)
| | DestinationAddress = 00:00:00:00:00:01
| | SourceAddress = 00:a0:7d:08:00:00
| | Type = 34525
| Packet_IPv6 (length:64)
| | Hdr_IPv6 (length:40)
| | | Version = 6
| | | TrafficClass = 0
| | | FlowLabel = 0
| | | PayloadLength = 24
| | | NextHeader = 135
| | | HopLimit = 255
| | | SourceAddress =
3ffe:501:ffff:100:2a0:7dff:fe08:0
| | | DestinationAddress = 3ffe:501:ffff:101::2
| | Hdr_MH_BE (length:24)
| | | NextHeader = 59
| | | HeaderExtLength = 2
| | | Type = 7
| | | Reserved1 = 0
| | | Checksum = 27700 calc(27567)
| | | Status = 1 (Unknown binding for Home
Address destination option)
| | | Reserved2 = 0
| | | Address = 3ffe:501:ffff:104::2
| | Upp_NoNext (length:0)
| | | data =
===Ns_Cn_R0_G_G_G================================= <<<< The internal
packet definition name for evaluation.
A message
may be able to be guessed from a name.
ICMPv6
Neighbor solicitation message.
(snip)
===BeAny================================= <<<< MIPv6 Binding
Error message.
ng compare ext_BE_any.Checksum received:27700 = 27567 <<<< The field
with difference value.
They are
those with difference to the value of a checksum.
-----------------------------------------------
Best Regards
--
Kiyoaki Kawaguchi
""Leino, Tammy" <tammy_leino@mentor.com>" wrote:
> This is a multi-part message in MIME format.
>
>
> Hello Kiyoaki,
>
> I greatly appreciate your advice and offer to lend assistance. I have
> scrutinized the log and output, but I cannot find any error in my BE
> packet.
>
> I have attached the output results of the first test in CN-1-1.
Please
> refer to the BE packet that is being rejected.
>
> Thank you again for your offer to assist.
>
> Best Regards,
> Tammy Leino
>
>
> -----Original Message-----
> From: K.Kawaguchi [mailto:kawaguti@ysknet.co.jp]
> Sent: Thursday, June 05, 2008 4:08 AM
> To: users@tahi.org; Leino, Tammy
> Subject: Re: [users:00742] MIPv6 Conformance Test Suite CN-1-1
>
>
> Hello,
>
> It seems that there is a some difference compared with BE
> message which the tester expected so that you may guess.
>
> Please see log of the test result in a test tool. A difference
> may be able to be found in the part which shows outputted BE
> packet with logic structure.
> Please send log file to me, if the view of log is not known.
>
>
> Best Regards
> --
> Kiyoaki Kawaguchi
>
>
>
> ""Leino, Tammy" <tammy_leino@mentor.com>" wrote:
>
> > This is a multi-part message in MIME format.
> >
> >
> > Hello,
> >
> > I am executing the correspondent node test #1; CN-1-1. I have IPsec
> disabled. My tn.def, nut.def and config.txt files are configured
> properly.
> When TN sends the echo request with a Home Address option (action #3
in
> the
> test procedure), my NUT responds with a BE message matching the three
> criteria
> outlined in the JUDGEMENT for *2 of the test:
> >
> > (*2) MN receives Binding Error.
> > - The Destination Address is set to the Source Address of ICMP
Echo
> Request (MN care-of address).
> > - The Status field is set to 1.
> > - The Home Address field is set to the value in the Home Address
> option in
> the ICMP Echo Request (MN home address).
> >
> > However, TAHI reports the following error and aborts the test:
> >
> > CNT_SendAndRecv Status =UnKnown
> > UnKnown Pkt=>HASH(0x82b75c8)
> > BE - Receive Unexpented Packet
> > -> FAIL
> >
> > I cannot tell what is wrong with my BE message. I viewed it in
> Wireshark,
> and it is formed properly. Wireshark is able to parse it and
recognizes
> it as
> a BE, and I verified that all the requirements of JUDGEMENT *2 are
met.
> >
> > Can anyone shed light on this error? Perhaps a checksum error?
This
> same
> error occurs for all tests that require a BE to be transmitted to the
> TN.
> >
> > Thank you for any assistance you can lend.
> >
> > Best Regards,
> > Tammy Leino
> >
> >
> >
> >
> >
>
>
>
>