Date: Thu, 29 Dec 2005 11:49:12 -0500 From: "Bernie Volz \(volz\)" <volz@cisco.com> Subject: [dhcptest:00090] Re: Minor test feedback To: <dhcptest@tahi.org> Message-Id: <8E296595B6471A4689555D5D725EBB2101099C76@xmb-rtp-20a.amer.cisco.com> X-Mail-Count: 00090Hi:Some comments inline below (start with BV>).A suggestion: when the tests are run manually, it would be nice if therewas a way to REPEAT a test. When running through the complete tests, itwasn't always clear how the server should be configured and thus therewere times when a test failed because I hadn't configured the servercorrectly. (Perhaps this is something that the is in the testingframework and could thus benefit ALL tests? Perhaps it is alreadysupported but I don't know how to do it?) The HTML files do provide alot of details, but requires constant cross referencing and sometimes Imisunderstood the nature of the test or goofed the server configuration.While it is possible to run an individual test, the ability to repeatwould make it easier when running through the complete sequence oftests.BTW: Thanks much for developing these tests! This is a very good and anextremely useful endeavor!!- Bernie> -----Original Message-----> From: haoda [mailto:haoda@64translator.com] > Sent: Wednesday, December 28, 2005 8:48 PM> To: dhcptest@tahi.org> Subject: [dhcptest:00083] Re: Minor test feedback> > Hi, Mr. Volz,> > Thanks for your feedback.> They are very important to me.> Now I have begun fixing these bugs.> > But something you said is not very clear to me.> Please confirm them.> Thanks a lot!> > > 3. I fail to see what is invalid about the RENEW message in > > S_RFC3315_18.2.3_DiscardReceiptRenewMsg.seq?> In this test case it is hoped to check whether the RENEW message> via unicast is processed rightly. (Reply with > StatusCode:UseMulticast )I guess I missed that. Some of the indications as to what is expectedfrom a test aren't always that clear.> > > 2. For S_RFC3315_15_DiscardSolicitwithInvalidOP.seq,> > S_RFC3315_15_DiscardRenewwithInvalidOP.seq, and > > S_RFC3315_15_DiscardDeclinewithInvalidOP.seq,> > S_RFC3315_15_DiscardReleasewithInvalidOP.seq,> > S_RFC3315_15.10_ClientIDOPMatch.seq, I see nothing in RFC > > 3315 that would require a server to do anything to check for > > the existance of the Preference Option from a client and drop > > the packet. While the Preference Option is only used in > > server messages to clients, there is no real harm in a client > > including it and a properly implemented server would IGNORE > > unknown options.> > Note that this is different from the Server Identifier Option > > I mentioned for other tests cases - the Solicit, Confirm, and > > Rebind messages are specially designed to be sent to *ALL* > > servers, not just one. Hence, there are valid reasons why a > > server that receives one of these messages should detect the > > inclusion of this option and consider the message invalid. > > Also, section 15 of RFC 3315 specifically indicates these checks.> I think your meaning is that is not necessory to check the Preference> Option in the Client message. So the NUT(server) can send a reply> to the client if it receive a message include Preference Option.> That is, the server should IGNORE the message from client with > Preference. Or other option like "Server Unicast option".> I only want to check whether the server discard a message > from client inlcude> invalid option in these test scripts.> At RFC3315 p98,line 5443,there is a table of allowed options in DHCP > messages. And p27,line 1500, the RFC3315 said,"Clients and servers > SHOULD discard any messages that contain options that are not allowed> to appear in the received message".> Based them I think a Solicit message with Preference option should be> discard by server. > Is my understanding right? BV> Right. But I kind of view this differently. My view is that:A) Servers are usually designed for performance and checking for thingsthat shouldn't be there and otherwise don't cause an issue, isn'tsomething worth wasting processing power on. This is different thanchecking for things that are explicitly needed or would cause issues ifpresent (such as having a server-identifier option in a REBIND).B) This requires constant maintenance because as new options aredefined, new rules must be added to the server for some options to checkwhether they are present or not (a simple table or flag in an option canlikely handle most cases). Until these new rules are incorporated, nochecking can be done for them (a server can't simply drop a packetbecause it includes some unknown option code).C) It is a SHOULD and not a MUST.While you can leave these tests as they are, I'm sure you'll findimplementations that won't pass these tests because they don't botherwith these checks. (I could be wrong, but I don't believe most DHCPv4servers do this level of checking either and it hasn't been an issue.)> > > 5. In S_RFC3315_22.13_StatusCodeOP.seq, the following message > > is sent and the expected response is a Reply with a Status > > Code option? Why?> > What's wrong with this request? Is the absense of an IAADDR > > option in the IA_NA option supposed to generate an error? If > > so, this is mistaken as I don't see that an IAADDR option > is required.> > > > Or, is there something I missed in this test sequence > > (SOLICIT/ADVERTISE/REQUEST/REPLY)?> > > > R10: ----- RECEIVED -- R10 -----> > R10: -> received 56 bytes from fe80::200:ff:fe00:a2a2, port 1027> > R10: -> +- Start of REQUEST (3) message (56 bytes)> > R10: -> | transaction-id 101> > R10: -> | client-identifier (1) option (14 bytes)> > R10: -> | 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2> > R10: -> | server-identifier (2) option (14 bytes)> > R10: -> | 00:01:00:01:43:b2:b2:e5:00:03:ba:6c:9f:b9> > R10: -> | ia-na (3) option (12 bytes)> > R10: -> | (iaid 101010, t1 1h6m40s, t2 1h23m20s)> > R10: -> +- End of REQUEST message> > R10: ----- END OF RECEIVED -- R10 -----> The expected test result of it is check the format of status > code option.> Would you show me the log file of this test item.> I guess it is same as the problem 4. That is, the the test > expects the > Status Code option to be in the main part of the Reply. I > plan to change> it and let it accept both "in IA option" and "in main part".The server's REPLY didn't have a Status Code option. Thus my questionabout what was expected or intended for this test.> > > 6. None of the relay tests appear to be working for me.> > I notice that the client requests are coming from and being > > sent to fe80::200:ff:fe00:a2a2, which works fine. However, > > the relay requests are coming from fe80::200:ff:fe00:a4a4 and > > this does not work (ie, replies aren't received). I am > > running on FreeBSD 6.0? Perhaps I missed up something in the setup?> Would you like show me logs file of them. Thanks.Attached are a couple of the packet log files. They clearly showsomething is going badly. Note that the DHCPv6 server (NUT) is runningon a Solaris 9 box. I could switch the server to another box, such asWindows 2003, if you think there's something bad going on in Solaris 9'sIPv6 support.> > > I think the other items in your email are bugs of the current scripts.> I have begun to fix them.> > I expected your reply.> Thanks a lot!> > Sincerely yours,> Haoda> >90_2.html (attatchment)(tag is disabled)
90_3.html (attatchment)(tag is disabled)