Date: Tue, 6 Jan 2009 23:04:47 +0200 From: <Peter.Hunt@nokia.com> Subject: [users:01063] Question about V6LC_2_2_14_C in IPv6 Core Protocols 4.0.3 To: <users@tahi.org> Cc: <Peter.Hunt@nokia.com> Message-Id: <808F2ECE7425024994976AC3D44BDCF4C8B8CE@vaebe108.NOE.Nokia.com> X-Mail-Count: 01063I'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-RELEASETest Tool: v6eval-3.1.0Package: 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 HuntSoftware EngineerNokia S&S1063_2.html (attatchment)(tag is disabled)