Hi, 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 time
only by receiving packet from NUT.
This is not the fundamental solution,
but I think that optimizing the sequence above
and 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>