Hello Scott,
> The purpose of the tests is probably to make sure that the
> DECLINE packets don't include actual DNS recursive name
> server and Domain Search List options. Is that correct?
Yes, your thought is correct.
These tests verify such kink of cases.
Thanks,
> -----Original Message-----
> From: Scott Langley [mailto:slangley@tadboise.com]
> Sent: Tuesday, June 19, 2007 8:26 AM
> To: dhcptest@tahi.org
> Subject: RE: [dhcptest:00184] Re: FW: Re: Tests that check
> for DNS and Domain Search Options
>
> Hi Hideshi,
>
> Talking about this with Peter, we agreed that we were
> interpreting the intent of this test differently:
>
> I was interpreting the prohibition of the appearance of the
> DNS recursive name server option and the Domain Search List
> options as applying to the option request section and not to
> actual returned options. My interpretation is probably wrong.
>
> The purpose of the tests is probably to make sure that the
> DECLINE packets don't include actual DNS recursive name
> server and Domain Search List options. Is that correct?
>
> Scott
>
>
> -----Original Message-----
> From: Hideshi.Enokihara@jp.yokogawa.com
> [mailto:Hideshi.Enokihara@jp.yokogawa.com]
> Sent: Sun 6/17/2007 10:30 PM
> To: pcarney@treck.com
> Cc: dhcptest@tahi.org
> Subject: [dhcptest:00184] Re: FW: Re: Tests that check for
> DNS and Domain Search Options
>
> Hello Peter,
>
> Actually, I have not added any modification to
> C_RFC3646_5_InvDecDnsSchLstOpt.seq.
>
> I have modified only for C_RFC3646_5_InvDecDnsSvrOpt.seq.
>
>
> Could you verify these behavoirs, please?
>
> Thanks,
>
>
> -----Original Message-----
> From: Peter Carney [mailto:pcarney@treck.com]
> Sent: 2007/06/15 (?) 21:17
> To: Enokihara, Hideshi (Hideshi.Enokihara@jp.yokogawa.com)
> Cc: dhcptest@tahi.org
> Subject: RE: [dhcptest:00180] Re: FW: Re: Tests that check
> for DNS and Domain Search Options
>
> Hideshi,
>
>
>
> I think your modifications are correct. Can you please email
> me the .seq files once they have been updated?
>
>
>
>
>
> Thank you,
>
>
>
> Peter Carney
>
> Development Engineer
>
> Treck 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 PM
> To: Peter Carney
> Cc: dhcptest@tahi.org
> Subject: RE: [dhcptest:00180] Re: FW: Re: Tests that check
> for DNS and Domain 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 DNS and 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
> test purpose.
>
>
>
> C_RFC3646_5_InvDecDnsSchLstOpt.seq:
>
> $ret = options_exist(\%dec, ($CMP_DNS_LST));
>
> if($ret == 0){
>
> vLogHTML('<FONT COLOR="#FF0000">DHCPv6 Client
> should not send 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 not send 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
> that check for DNS and Domain Search Options
>
> Hideshi,
>
>
>
> I agree with Scott.
>
>
>
> The function options_exist() that is defined in
> DHCP_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, it calls options_exist() with ($CMP_CID|$CMP_DNS_SVR).
>
> This will return with a 0 (and therefore cause
> the test to fail) only if both of these options exist, if
> only one of the options is present then this will return with
> a 1 (and the test will still pass). I believe this to be
> incorrect. If either of these options is present the test
> should fail.
>
>
>
> Also, with C_RFC3646_5_InvDecDnsSvrOpt.seq,
> checking for the presence of a Client Identifier option is
> incorrect. From RFC3315, a Decline message MUST be discarded
> by a server if it does not include a Client Identifier option.
>
>
>
> Finally, with
> C_RFC3646_5_InvDecDnsSchLstOpt.seq, I believe 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
> requires a failure if any of the options do exist (which is
> different from the return values of options_exist() when
> called with multiple options) it is required that you call
> the options_exist() function one time for each option 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
> Client should not send Decline with Domain Search List option
> and/or DNS Recursive 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
> Client should not send Decline with Domain Search List option
> and/or DNS Recursive 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 check for DNS and Domain 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 in its 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 PM
> To: Scott Langley
> Cc: dhcptest@tahi.org
> Subject: RE: FW: [dhcptest:00173] Re: Tests
> that check for DNS and Domain Search Options
>
> Hello 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 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 that check for DNS
> and 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 include
> both options 23 and 24:
>
> C_RFC3646_5_InvDecDnsSchLstOpt.seq
> C_RFC3646_5_InvDecDnsSvrOpt.seq
>
> I 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.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 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,
> ...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 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 Enokihara
> IPv6 Business
> Network & Software Development Dept.
> Yokogawa Electric Corporation
>
>
>
> Treck, Inc. - Confidentiality Notice
>
> This 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.
>
>
>
>
>
>