Date: Fri, 15 Jun 2007 08:17:50 -0400 From: "Peter Carney" <pcarney@treck.com> Subject: [dhcptest:00183] Re: FW: Re: Tests that check for DNS and Domain Search Options To: <Hideshi.Enokihara@jp.yokogawa.com> Cc: <dhcptest@tahi.org> Message-Id: <753EF94A8CD3E6439DCD566B99F4D7421EC523@ms1.treck.com> X-Mail-Count: 00183Hideshi, I think your modifications are correct. Can you please email me the.seq files once they have been updated? Thank you, Peter CarneyDevelopment EngineerTreck Inc.http://www.treck.com <http://www.treck.com> ________________________________From: Hideshi.Enokihara@jp.yokogawa.com[mailto:Hideshi.Enokihara@jp.yokogawa.com] Sent: Thursday, June 14, 2007 7:45 PMTo: Peter CarneyCc: dhcptest@tahi.orgSubject: RE: [dhcptest:00180] Re: FW: Re: Tests that check for DNS andDomain Search Options Sorry, I sent this e-mail to Peter. Thank you so much Peter? I would like to hear your thought. Thanks, ________________________________ From: Enokihara, Hideshi (Hideshi.Enokihara@jp.yokogawa.com) Sent: Friday, June 15, 2007 9:42 AM To: pcarney@treck.com Cc: dhcptest@tahi.org Subject: [dhcptest:00180] Re: FW: Re: Tests that check for DNSand Domain Search Options Hello Scott, Thank you for your concrete reports! I will fix these problem as soon as possible. But I think that following correction is enough for the testpurpose. C_RFC3646_5_InvDecDnsSchLstOpt.seq: $ret = options_exist(\%dec, ($CMP_DNS_LST)); if($ret == 0){ vLogHTML('<FONT COLOR="#FF0000">DHCPv6 Client should notsend Decline with Domain Search List option!</FONT><BR>'); dhcpExitFail; } C_RFC3646_5_InvDecDnsSvrOpt.seq: (note the removal of $CMP_CID) $ret = options_exist(\%dec, ($CMP_DNS_SVR)); if($ret == 0){ vLogHTML('<FONT COLOR="#FF0000">DHCPv6 Client should notsend Decline with DNS Recursive Name Server option!</FONT><BR>'); dhcpExitFail; } What do you think? Best regards, ________________________________ From: Peter Carney [mailto:pcarney@treck.com] Sent: Friday, June 15, 2007 6:29 AM To: Enokihara, Hideshi(Hideshi.Enokihara@jp.yokogawa.com) Cc: dhcptest@tahi.org Subject: RE: [dhcptest:00178] Re: FW: Re: Tests thatcheck for DNS and Domain Search Options Hideshi, I agree with Scott. The function options_exist() that is defined inDHCP_common.pm has two possible 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, itcalls options_exist() with ($CMP_CID|$CMP_DNS_SVR). This will return with a 0 (and therefore cause the testto fail) only if both of these options exist, if only one of the optionsis present then this will return with a 1 (and the test will stillpass). I believe this to be incorrect. If either of these options ispresent the test should fail. Also, with C_RFC3646_5_InvDecDnsSvrOpt.seq, checking forthe presence of a Client Identifier option is incorrect. From RFC3315,a Decline message MUST be discarded by a server if it does not include aClient Identifier option. Finally, with C_RFC3646_5_InvDecDnsSchLstOpt.seq, Ibelieve that it should check not only for $CMP_DNS_LST but also for$CMP_DNS_SVR as well. Because testing for this is based on logic that requiresa failure if any of the options do exist (which is different from thereturn values of options_exist() when called with multiple options) itis required that you call the options_exist() function one time for eachoption you are 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 Clientshould not send Decline with Domain Search List option and/or DNSRecursive Name Server option!</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 Clientshould not send Decline with Domain Search List option and/or DNSRecursive Name Server option!</FONT><BR>'); dhcpExitFail; } Please let me know your thoughts. Thank you, Peter Carney Development Engineer Treck Inc. http://www.treck.com <http://www.treck.com> ________________________________ From: Scott Langley [mailto:slangley@tadboise.com] Sent: Tuesday, June 05, 2007 9:53 PM To: Hideshi.Enokihara@jp.yokogawa.com Cc: dhcptest@tahi.org Subject: [dhcptest:00178] Re: FW: Re: Tests that checkfor DNS and Domain Search Options Hi Hideshi, I think I agree with your thoughts about what the testsshould do. The problem is that our client device does includeoptions 23 and 24 in its Decline packets - and yet the Tahi Testsreports that they "PASS" these tests. I would expect our product tofail 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 PM To: Scott Langley Cc: dhcptest@tahi.org Subject: RE: FW: [dhcptest:00173] Re: Tests that checkfor DNS and Domain Search Options Hello Scott, Thank you for your report. But, these tests that you mentioned are correct, Ithink. These tests focus on following statements in RFC 3646. ---------------------------- 5. Appearance of these options The DNS Recursive Name Server option MUST NOT appearin any other than the following messages: Solicit, Advertise,Request, Renew, Rebind, Information-Request, and Reply. The Domain Search List option MUST NOT appear in anyother than the following messages: Solicit, Advertise, Request,Renew, Rebind, Information-Request, and Reply. ---------------------------- So, these tests really expect that the message does notinclude 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 thatcheck for DNS and Domain Search Options Hi Hideshi, The revised files you sent do appear to workproperly. However, I think there are a few more tests thathave problems. These two test pass, even though our DECLINEmessages include both options 23 and 24: C_RFC3646_5_InvDecDnsSchLstOpt.seq C_RFC3646_5_InvDecDnsSvrOpt.seq I suspect that the options_exist() method ofDHCPv6_common.pm may be flawed. These four other tests, below, are similarlywritten, but I can't say if there is anything wrong with them becauseour product doesn't yet send CONFIRM and RELEASE messages when itshould: 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 thatcheck for DNS and Domain Search Options Hello Scott, Thank you for your report. Please use attached files instead of originalfiles. Then, could you let me know that these scriptswork 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 thatcheck for DNS and Domain > Search Options > > Hi Hideshi, > > These are probably the test that would faildue 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 checkfor DNS and Domain Search > Options > > Hello Scott, > > Yes, we have to fix these bugs as soon aspossible. > 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 thatcheck 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 isorder 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 thatcheck for DNS and Domain > Search Options > > > > Hello, > > Many of the tests in the RFC 3646 andRFC 3736 sections of the > DHCPv6 Self Test Suite 1.01 (and earlier) arefailing for us for the > wrong reason. > > The way our (client) product iscurrently 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(DNSRecursive 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 tocheck whether or not option > 23 is among the options requested > rather than whether or not it is thefirst option requested? > > Also, I know our client shouldn't berequesting option 12, > Server Unicast, as that option should onlyappear in Reply messages > coming from a server. I don't think you haveany tests yet that check > for the appearance of options in differentmessage 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 Treck, Inc. - Confidentiality Notice This electronic transmission may contain informationthat is proprietary or confidential. You are hereby notified that anydissemination, distribution or duplication of this electronictransmission to some other entity, without the expressed written consent of Treck,Inc. is strictly prohibited, unless the contents of this electronictransmission specifically authorizes you to do so. If your receiptof this electronic transmission is in error, please notify the corporateoffices of Treck, Inc. immediately by calling (513) 528-5732, or by replyto this transmission.183_2.html (attatchment)(tag is disabled)