Hi, Andre.
I got it.
Our test tool just copies SID from ADVERTISE.
And our test tool only recognizes DUID type through 1 to 3.
Then DUID ANY will be used for out of range for descriptive purposes.
Thanks,
On Tue, 6 Oct 2009 21:57:04 -0700
Andre Kostur <akostur@incognito.com> wrote:
> Turns out I found the trigger. My server was sending a duid-llt with a hardware type of 6 instead of 1. This seems to cause tahi to revert to duid any instead of just copying the server duid from the advertise to the request.
>
>
> ----- Original Message -----
> From: Yoshio Uomori <mario@tahi.org>
> To: Andre Kostur
> Cc: users@tahi.org <users@tahi.org>
> Sent: Tue Oct 06 20:54:38 2009
> Subject: Re: [users:01324] DHCPv6 DUID any ?
>
> Hi Andre,
>
> Thank you for your question.
>
> In the beginning, could you send the test log?
>
> Best Regards,
> Yoshio Uomori
>
>
> On Tue, 6 Oct 2009 12:06:23 -0700
> Andre Kostur <akostur@incognito.com> wrote:
>
> > I'm attempting to use the DHCPv6_Self_Test_P2_1_0_17, and having some unexpected behaviours. For the DHCP_CONF.2.1.1 test, part A (standard Solicit/Advertise/Request/Reply), TAHI appears to be sending the Request filling in the server ID with a DUID Any. Two questions:
> >
> >
> > 1) Where is DUID Any defined in RFC?
> >
> > 2) Wouldn't sending a DUID any in a Request defeat the purpose of the Request?
> >
> >
> >
>
>
> --
> Yoshio Uomori <mario@tahi.org>
>
>
>
--
Yukiyo Akisada <akisada@tahi.org>