Date: Mon, 4 Jun 2007 13:55:52 -0600 From: "Scott Langley" <slangley@tadboise.com> Subject: [dhcptest:00171] Tests that check for DNS and Domain Search Options To: <dhcptest@tahi.org> Message-Id: <04654E52DE5D8D47906217E3D32FA976073C68@sbserver.tadboise.com> X-Mail-Count: 00171Hello,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_CODE12 OPTION_UNICAST23 OPTION_DNS_SERVERS24 OPTION_DOMAIN_LIST 7 OPTION_PREFERENCEMany tests, for example, RFC 3646 - Test DHCP_CONF.4.1.1: Option Request =option 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 is =among the options requestedrather 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-98Thanks.Scott LangleyAdecco Technicalslangley@tadboise.com171_2.html (attatchment)(tag is disabled)