Hello Scott,
Thank you for your report.
But, these tests that you mentioned are correct, I think.
These tests focus on following statements in RFC 3646.
----------------------------
5. Appearance of these options
The DNS Recursive Name Server option MUST NOT appear in any other
than the following messages: Solicit, Advertise, Request, Renew,
Rebind, Information-Request, and Reply.
The Domain Search List option MUST NOT appear in any other than the
following messages: Solicit, Advertise, Request, Renew, Rebind,
Information-Request, and Reply.
----------------------------
So, these tests really expect that the message does not include DNS
Recursive Name Server option/Domain Search List option.
regards,
...Hideshi
________________________________
From: Scott Langley [mailto:slangley@tadboise.com]
Sent: Wednesday, June 06, 2007 2:17 AM
To: Enokihara, Hideshi (Hideshi.Enokihara@jp.yokogawa.com)
Cc: dhcptest@tahi.org
Subject: RE: FW: [dhcptest:00173] Re: Tests that check for DNS
and Domain Search Options
Hi Hideshi,
The revised files you sent do appear to work properly.
However, I think there are a few more tests that have problems.
These two test pass, even though our DECLINE messages include
both options 23 and 24:
C_RFC3646_5_InvDecDnsSchLstOpt.seq
C_RFC3646_5_InvDecDnsSvrOpt.seq
I suspect that the options_exist() method of DHCPv6_common.pm
may be flawed.
These four other tests, below, are similarly written, but I
can't say if there is anything wrong with them because our product
doesn't yet send CONFIRM and RELEASE messages when it should:
C_RFC3646_5_InvCnfDnsSchLstOpt.seq
C_RFC3646_5_InvCnfDnsSvrOpt.seq
C_RFC3646_5_InvRelDnsSchLstOpt.seq
C_RFC3646_5_InvRelDnsSvrOpt.seq
Thanks.
--
Scott Langley
Adecco Technical
slangley@tadboise.com
-----Original Message-----
From: Hideshi Enokihara
[mailto:Hideshi.Enokihara@jp.yokogawa.com]
Sent: Mon 6/4/2007 7:15 PM
To: Scott Langley
Cc: dhcptest@tahi.org
Subject: Re: FW: [dhcptest:00173] Re: Tests that check for DNS
and Domain Search Options
Hello Scott,
Thank you for your report.
Please use attached files instead of original files.
Then, could you let me know that these scripts work well or not,
please?
Thank you for your cooperation.
Regards,
...Hideshi
On Tue, 5 Jun 2007 09:48:46 +0900
<Hideshi.Enokihara@jp.yokogawa.com> wrote:
>
>
> -----Original Message-----
> From: Scott Langley [mailto:slangley@tadboise.com]
> Sent: Tuesday, June 05, 2007 9:44 AM
> To: dhcptest@tahi.org
> Subject: RE: [dhcptest:00173] Re: Tests that check for DNS and
Domain
> Search Options
>
> Hi Hideshi,
>
> These are probably the test that would fail due to this
reason, from the
> results of doing a grep search:
>
> PCBSD# grep '!= 23' *.seq
>
> C_RFC3646_3_DnsSvrOpt.seq:if($sol{$optionCode} != 23){
> C_RFC3646_3_DnsSvrOpt_Reb.seq:if($reb{$optionCode} != 23){
> C_RFC3646_3_DnsSvrOpt_Ren.seq:if($ren{$optionCode} != 23){
> C_RFC3646_3_DnsSvrOpt_Req.seq:if($req{$optionCode} != 23){
> C_RFC3646_3_DnsSvrOpt_Sol.seq:if($sol{$optionCode} != 23){
>
> PCBSD# grep '!= 24' *.seq
>
> C_RFC3646_3_DnsSchLstOpt_Reb.seq:if($reb{$optionCode} != 24){
> C_RFC3646_3_DnsSchLstOpt_Ren.seq:if($ren{$optionCode} != 24){
> C_RFC3646_3_DnsSchLstOpt_Req.seq:if($req{$optionCode} != 24){
> C_RFC3646_3_DnsSchLstOpt_Sol.seq:if($sol{$optionCode} != 24){
> C_RFC3646_4_DnsSchLstOpt.seq:if($sol{$optionCode} != 24){
>
>
> -----Original Message-----
> From: Hideshi.Enokihara@jp.yokogawa.com
> [mailto:Hideshi.Enokihara@jp.yokogawa.com]
> Sent: Mon 6/4/2007 6:14 PM
> To: dhcptest@tahi.org
> Subject: [dhcptest:00173] Re: Tests that check for DNS and
Domain Search
> Options
>
> Hello Scott,
>
> Yes, we have to fix these bugs as soon as possible.
> Could you let me know the numbers (or titles) of the tests, if
you have
> time, please?
> It will help us to fix the bugs.
>
> regards,
> ...Hideshi
>
>
> ________________________________
>
> From: Bernie Volz (volz) [mailto:volz@cisco.com]
> Sent: Tuesday, June 05, 2007 5:33 AM
> To: dhcptest@tahi.org
> Subject: [dhcptest:00172] Re: Tests that check for DNS
and
> Domain Search Options
>
>
> Order of the options should not matter (either in the
ORO or in
> the Advertise/Reply). So, if the test code is order dependent,
it should
> be fixed.
>
> - Bernie
>
> ________________________________
>
> From: Scott Langley [mailto:slangley@tadboise.com]
> Sent: Monday, June 04, 2007 3:56 PM
> To: dhcptest@tahi.org
> Subject: [dhcptest:00171] Tests that check for DNS and
Domain
> Search Options
>
>
>
> Hello,
>
> Many of the tests in the RFC 3646 and RFC 3736 sections
of the
> DHCPv6 Self Test Suite 1.01 (and earlier) are failing for us
for the
> wrong reason.
>
> The way our (client) product is currently behaving it
requests
> these options:
>
> 13 OPTION_STATUS_CODE
> 12 OPTION_UNICAST
> 23 OPTION_DNS_SERVERS
> 24 OPTION_DOMAIN_LIST
> 7 OPTION_PREFERENCE
>
> Many tests, for example, RFC 3646 - Test
DHCP_CONF.4.1.1: Option
> Request option Format
> PartA: Option request Option Format(DNS Recursive Name
Server
> option)
>
> fail because option 13 is not option 23, according to
the code:
>
> if($sol($optionCode != 23) {
> # Logging of failure message.
> }
>
> Shouldn't the test be re-written to check whether or not
option
> 23 is among the options requested
> rather than whether or not it is the first option
requested?
>
> Also, I know our client shouldn't be requesting option
12,
> Server Unicast, as that option should only appear in Reply
messages
> coming from a server. I don't think you have any tests yet
that check
> for the appearance of options in different message types as
described in
> Appendix A of RFC3315.
>
> http://tools.ietf.org/html/rfc3315#page-98
>
> Thanks.
>
> Scott Langley
> Adecco Technical
> slangley@tadboise.com
>
>
>
>
>
--
*************************************
Hideshi Enokihara
IPv6 Business
Network & Software Development Dept.
Yokogawa Electric Corporation