Date: Tue, 9 Jan 2007 09:30:15 +0900
From: Hideshi Enokihara <Hideshi.Enokihara@jp.yokogawa.com>
Subject: [dhcptest:00142] Re: Bug with DHCPv6 Client's of DUID_EN Type
To: slangley@tadboise.com
Cc: dhcptest@tahi.org
Message-Id: <20070109093015.30c12b2b.Hideshi.Enokihara@jp.yokogawa.com>
In-Reply-To: <04654E52DE5D8D47906217E3D32FA9760738BB@sbserver.tadboise.com>
References: <04654E52DE5D8D47906217E3D32FA9760738BB@sbserver.tadboise.com>
X-Mail-Count: 00142

Hi Scott,

Thank you for your report.

I will fix it.

Best regards,

On Fri, 5 Jan 2007 16:33:53 -0700
"Scott Langley" <slangley@tadboise.com> wrote:

> I have a device that cares about whether the enterprise number appearing
> in the Client Identifier field of Tahi-generated ADVERTISE packet
> matches the enterprise number that the client sent in its SOLICIT
> packet.  By making the following change in line 1945 of file
> DHCPv6_common.pm, I as able to make them match:
> 
>  
> 
> BEFORE:
> 
>  
> 
> $cppstr .= " -D\'NUT_DUID_EN_ENNUM =hexstr(\"$optstr\")\' ";
> 
>  
> 
> AFTER:
> 
>  
> 
> $cppstr .= " -D\'NUT_DUID_EN_ENNUM =$optstr\' ";
> 
>  
> 
> Apparently, this field shouldn't converted from hexidecimal to a string
> after all.
> 
> --
> Scott Langley
> I/O Test Engineer
> slangley@tadboise.com <mailto:slangley@tadboise.com> 
> scott.langley@hp.com <mailto:scott.langley@hp.com> 
> (208) 639-8918
> 
>  
> 
> 


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