Date: Thu, 14 Jun 2007 17:29:06 -0400 From: "Peter Carney" <pcarney@treck.com> Subject: [dhcptest:00179] Re: FW: Re: Tests that check for DNS and Domain Search Options To: <Hideshi.Enokihara@jp.yokogawa.com> Cc: <dhcptest@tahi.org> Message-Id: <753EF94A8CD3E6439DCD566B99F4D7421EC51B@ms1.treck.com> X-Mail-Count: 00179Hideshi, I agree with Scott. The function options_exist() that is defined in DHCP_common.pm has twopossible return values: 0 and 1.It will return 0 if all of the options exist.It will return 1 if any of the options do not exist. Taking C_RFC3646_5_InvDecDnsSvrOpt.seq as an example, it callsoptions_exist() with ($CMP_CID|$CMP_DNS_SVR).This will return with a 0 (and therefore cause the test to fail) only ifboth of these options exist, if only one of the options is present thenthis will return with a 1 (and the test will still pass). I believethis to be incorrect. If either of these options is present the testshould fail. Also, with C_RFC3646_5_InvDecDnsSvrOpt.seq, checking for the presence ofa Client Identifier option is incorrect. From RFC3315, a Declinemessage MUST be discarded by a server if it does not include a ClientIdentifier option. Finally, with C_RFC3646_5_InvDecDnsSchLstOpt.seq, I believe that itshould check not only for $CMP_DNS_LST but also for $CMP_DNS_SVR aswell. Because testing for this is based on logic that requires a failure ifany of the options do exist (which is different from the return valuesof options_exist() when called with multiple options) it is requiredthat you call the options_exist() function one time for each option youare checking for. Here is how I believe it should look: C_RFC3646_5_InvDecDnsSchLstOpt.seq:$ret = options_exist(\%dec, ($CMP_DNS_LST));if ($ret != 0) { $ret = options_exist(\%dec, ($CMP_DNS_SVR));}if($ret == 0){ vLogHTML('<FONT COLOR="#FF0000">DHCPv6 Client should not sendDecline with Domain Search List option and/or DNS Recursive Name Serveroption!</FONT><BR>'); dhcpExitFail;} C_RFC3646_5_InvDecDnsSvrOpt.seq: (note the removal of $CMP_CID)$ret = options_exist(\%dec, ($CMP_DNS_LST));if ($ret != 0) { $ret = options_exist(\%dec, ($CMP_DNS_SVR));}if($ret == 0){ vLogHTML('<FONT COLOR="#FF0000">DHCPv6 Client should not sendDecline with Domain Search List option and/or DNS Recursive Name Serveroption!</FONT><BR>'); dhcpExitFail;} Please let me know your thoughts. Thank you, Peter CarneyDevelopment EngineerTreck Inc.http://www.treck.com <http://www.treck.com> ________________________________From: Scott Langley [mailto:slangley@tadboise.com] Sent: Tuesday, June 05, 2007 9:53 PMTo: Hideshi.Enokihara@jp.yokogawa.comCc: dhcptest@tahi.orgSubject: [dhcptest:00178] Re: FW: Re: Tests that check for DNS andDomain Search Options Hi Hideshi,I think I agree with your thoughts about what the tests should do. The problem is that our client device does include options 23 and 24 inits Decline packets - and yet the Tahi Tests reports that they "PASS"these tests. I would expect our product to fail these tests.Regards,Scott-----Original Message-----From: Hideshi.Enokihara@jp.yokogawa.com[mailto:Hideshi.Enokihara@jp.yokogawa.com]Sent: Tue 6/5/2007 7:07 PMTo: Scott LangleyCc: dhcptest@tahi.orgSubject: RE: FW: [dhcptest:00173] Re: Tests that check for DNS andDomain Search OptionsHello 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 DNSRecursive 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 DNSand 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 includeboth options 23 and 24: C_RFC3646_5_InvDecDnsSchLstOpt.seq C_RFC3646_5_InvDecDnsSvrOpt.seq I suspect that the options_exist() method of DHCPv6_common.pmmay be flawed. These four other tests, below, are similarly written, but Ican't say if there is anything wrong with them because our productdoesn'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 DNSand 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 andDomain > Search Options > > Hi Hideshi, > > These are probably the test that would fail due to thisreason, 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 andDomain 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, ifyou 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 DNSand > Domain Search Options > > > Order of the options should not matter (either in theORO 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 andDomain > Search Options > > > > Hello, > > Many of the tests in the RFC 3646 and RFC 3736 sectionsof the > DHCPv6 Self Test Suite 1.01 (and earlier) are failing for usfor the > wrong reason. > > The way our (client) product is currently behaving itrequests > 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 - TestDHCP_CONF.4.1.1: Option > Request option Format > PartA: Option request Option Format(DNS Recursive NameServer > option) > > fail because option 13 is not option 23, according tothe code: > > if($sol($optionCode != 23) { > # Logging of failure message. > } > > Shouldn't the test be re-written to check whether or notoption > 23 is among the options requested > rather than whether or not it is the first optionrequested? > > Also, I know our client shouldn't be requesting option12, > Server Unicast, as that option should only appear in Replymessages > coming from a server. I don't think you have any tests yetthat check > for the appearance of options in different message types asdescribed 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 Treck, Inc. - Confidentiality NoticeThis electronic transmission may contain information that is proprietary =or confidential. You are hereby notified that any dissemination, distribution or duplication of this electronic transmission to some =other entity, without the expressed written consent of Treck, Inc. is =strictly prohibited, unless the contents of this electronic transmission specifically authorizes you to do so. If your receipt of this =electronic transmission is in error, please notify the corporate offices of Treck, Inc. immediately by calling (513) 528-5732, or by reply to this transmission.179_2.html (attatchment)(tag is disabled)