Date: Wed, 7 Jan 2009 03:54:51 +0200 From: <Peter.Hunt@nokia.com> Subject: [users:01066] Re: Question about V6LC_2_2_14_C in IPv6 Core Protocols 4.0.3 To: <akisada@tahi.org> Cc: <users@tahi.org> Message-Id: <808F2ECE7425024994976AC3D44BDCF4C8B8D0@vaebe108.NOE.Nokia.com> References: <808F2ECE7425024994976AC3D44BDCF4C8B8CE@vaebe108.NOE.Nokia.com> <20090107100009.c6fc27e7.akisada@tahi.org> X-Mail-Count: 01066I'm afraid I don't have any clever ideas about how to determine the =reachable time. I agree that you can only derive it indirectly from the =packets sent by the NUT, and I can't think of any way to determine how =long the NUT is in STALE state. Allowing for up to 1 ping interval extra in the check, as you suggest, =would help avoid false failures. Perhaps you could also decrease the =interval between pings (to 0.5 seconds, for example), to reduce the =amount of extra time the test allows to a minimum. Peter________________________________From: ext Yukiyo Akisada [mailto:akisada@tahi.org]Sent: Tue 1/6/2009 5:00 PMTo: Hunt Peter (Nokia-S/MtView)Cc: users@tahi.orgSubject: Re: [users:01063] Question about V6LC_2_2_14_C in IPv6 Core =Protocols 4.0.3Hi, Peter.Thanks for reporting.The resolution of time is always the problem on our tool.Now the tool is repeating transmission of Echo Request and waiting =packets alternately.I guess that every "waiting packets" steps are the bottleneck.Maybe this sequence must be somehow optimized.In this moment,I'm planning to separate transmission loop and waiting loop in the =source code.Because v6eval can record every received packts,examining received packts can be done after sending every Echo Requests.And talking about RFC description and how to calculate,your interpretation is right.But I don't have any other idea to calculate the reachable timeonly by receiving packet from NUT.This is not the fundamental solution,but I think that optimizing the sequence aboveand applying the margin for the interval of Echo Request will improve =it.Or, if you have a good idea to calculate the reachable time by other =way,please let me know.Thanks,On Tue, 6 Jan 2009 23:04:47 +0200<Peter.Hunt@nokia.com> wrote:> > I'm running into a problem with one of the tests in the IPv6 Core =Protocols test suite in the following configuration:> > TN: FreeBSD 6.3-RELEASE> Test Tool: v6eval-3.1.0> Package: IPv6 Core Protocols Self_Test_4-0-3> > Running the router tests (i.e. "make ipv6ready_p2_router").> > I'm seeing a failure with test "V6LC_2_2_14_C - Reachable Time =Configuration", which I think may be due to an error in the way the test =script measures the reachable time. I suspect the test script is not =accounting for the time in which the ND entry is in "STALE" state.> > If I'm reading the RFC correctly, the ND entry should go through the =following states on the NUT:> > 1) Enters REACHABLE state when NA received (and first echo reply sent)> 2) Enters STALE state ReachableTime milliseconds after NA received.> 3) Enters DELAY state when first echo reply sent after entering STALE =state.> 4) Enters PROBE state 5 seconds after entering DELAY state (sends =first NS)> > The test calculates the reachable time as the interval between the =first echo reply sent at 1) and the first NS sent at 4), minus 5 =seconds. However, this calculation does not account for the time that =the entry was in STALE state (i.e. the interval between the entry =entering STALE state and the reception of the next echo request).> > This error results in the reachable time calculation being too large, =by up to the interval between echo requests sent by the TN. When the =random reachable time is close to 15, this miscalculation results in the =test failing.> > I'm also seeing a problem where the TN sends echo requests at =intervals of up to 1.5 seconds, which makes this problem worse.> > Best regards,> Peter Hunt> Software Engineer> Nokia S&S>--Yukiyo Akisada <akisada@tahi.org>1066_2.html (attatchment)(tag is disabled)