Date: Tue, 5 Jun 2007 11:16:39 -0600 From: "Scott Langley" <slangley@tadboise.com> Subject: [dhcptest:00176] Re: FW: Re: Tests that check for DNS and Domain Search Options To: "Hideshi Enokihara" <Hideshi.Enokihara@jp.yokogawa.com> Cc: <dhcptest@tahi.org> Message-Id: <04654E52DE5D8D47906217E3D32FA976073C6C@sbserver.tadboise.com> References: <0260031F55435342859BFB2CCA6773D81B898B49@EXCHANGE03.jp.ykgw.net> <20070605101509.4c30796d.Hideshi.Enokihara@jp.yokogawa.com> X-Mail-Count: 00176Hi 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.seqI 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.seqThanks.--Scott LangleyAdecco Technicalslangley@tadboise.com-----Original Message-----From: Hideshi Enokihara [mailto:Hideshi.Enokihara@jp.yokogawa.com]Sent: Mon 6/4/2007 7:15 PMTo: Scott LangleyCc: dhcptest@tahi.orgSubject: 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,...HideshiOn 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 EnokiharaIPv6 BusinessNetwork & Software Development Dept.Yokogawa Electric Corporation176_2.html (attatchment)(tag is disabled)