Date: Thu, 20 Sep 2007 12:32:34 +0900
From: Hideshi Enokihara <Hideshi.Enokihara@jp.yokogawa.com>
Subject: [dhcptest:00217] Re: FW:  DHCPv6 self-test MRT issues
To: tammy_leino@mentor.com
Cc: dhcptest@tahi.org
Message-Id: <20070920123234.48d4c25a.Hideshi.Enokihara@jp.yokogawa.com>
In-Reply-To: <0260031F55435342859BFB2CCA6773D81B898C6A@EXCHANGE03.jp.ykgw.net>
References: <0260031F55435342859BFB2CCA6773D81B898C6A@EXCHANGE03.jp.ykgw.net>
X-Mail-Count: 00217

Hello Tammy,

Thank you for your report again.

I would like to investigate the test scripts,
Could you use attached file, please?

Then, please send back the log.

Moreover, could you tell us which test is working wrong?

Best regards,

Hidehsi


On Thu, 20 Sep 2007 12:25:45 +0900
<Hideshi.Enokihara@jp.yokogawa.com> wrote:

>  
> 
> ________________________________
> 
> From: Leino, Tammy [mailto:tammy_leino@mentor.com] 
> Sent: Thursday, September 20, 2007 5:58 AM
> To: dhcptest@tahi.org
> Subject: [dhcptest:00215] DHCPv6 self-test MRT issues
> 
> 
> 
> Hello All, 
> 
> I am seeing another timing issue with the TAHI self-test suite that I
> feel is an anamoly in the test scripts.  I can reproduce this with all
> MRD tests.  I will use #42 from RFC3315 as an example since I have
> worked out the specific math that causes this issue.  Yes, it is an MRT
> computation error, but it shows up in the MRD tests.
> 
> Here is the specific sequence that will cause the problem: 
> 
> 1 - Send first Confirm msg : rt = .93 (with RAND = -.07) 
> 2 - Send second Confirm msg : rt = 1.92 (with RAND = .06) 
> 3 - Send third Confirm msg : rt = 4.01 (with RAND = .08), but this is
> greater than the MRT of 4, so we recompute it using this algo per RFC
> 3315:
> 
>       if (RT > MRT)
>          RT = MRT + RAND*MRT 
> 
> rt ends up being set to 4.36 (with RAND = .09) 
> 
> The test fails, because the tester does not wait long enough for the
> packet.  It is waiting only 1.92 * 2 + (1.92 * .1) max seconds, which is
> 4.03, but according to the algo specified in RFC 3315, the time could be
> longer depending on the value of RAND.
> 
> It looks to me like the TAHI suite is not taking into account the
> highest possible value obtained when recomputing RT if RT exceeds MRT.
> I have attached my logs for your reference, but note that you will not
> see the fourth Confirm message since the test suite errors out before it
> is sent.  It is sent though - I see it in my packet trace and when
> stepping through the code.
> 
> Best Regards,
> Tammy 
> <<test_42.zip>> 
> 
> 


-- 
*************************************
Hideshi Enokihara
IPv6 Business
Network & Software Development Dept.
Yokogawa Electric Corporation

	
217_2.x-perl (attatchment)(tag is disabled)

217_3.seq