Date: Mon, 4 Jun 2007 16:32:36 -0400 From: "Bernie Volz \(volz\)" <volz@cisco.com> Subject: [dhcptest:00172] Re: Tests that check for DNS and Domain Search Options To: <dhcptest@tahi.org> Message-Id: <8E296595B6471A4689555D5D725EBB21042D9160@xmb-rtp-20a.amer.cisco.com> In-Reply-To: <04654E52DE5D8D47906217E3D32FA976073C68@sbserver.tadboise.com> X-Mail-Count: 00172Order of the options should not matter (either in the ORO or in theAdvertise/Reply). So, if the test code is order dependent, it should befixed. - Bernie________________________________From: Scott Langley [mailto:slangley@tadboise.com] Sent: Monday, June 04, 2007 3:56 PMTo: dhcptest@tahi.orgSubject: [dhcptest:00171] Tests that check for DNS and Domain SearchOptionsHello,Many of the tests in the RFC 3646 and RFC 3736 sections of the DHCPv6Self Test Suite 1.01 (and earlier) are failing for us for the wrongreason.The way our (client) product is currently behaving it requests theseoptions:13 OPTION_STATUS_CODE12 OPTION_UNICAST23 OPTION_DNS_SERVERS24 OPTION_DOMAIN_LIST 7 OPTION_PREFERENCEMany tests, for example, RFC 3646 - Test DHCP_CONF.4.1.1: Option Requestoption FormatPartA: 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 isamong the options requestedrather than whether or not it is the first option requested?Also, I know our client shouldn't be requesting option 12, ServerUnicast, as that option should only appear in Reply messages coming froma server. I don't think you have any tests yet that check for theappearance of options in different message types as described inAppendix A of RFC3315.http://tools.ietf.org/html/rfc3315#page-98Thanks.Scott LangleyAdecco Technicalslangley@tadboise.com172_2.html (attatchment)(tag is disabled)