Date: Wed, 21 Dec 2005 06:10:55 +0000 (GMT) From: amit agarwal <amit_agarr@yahoo.co.in> Subject: [dhcptest:00042] Re: MRD test for MRD of Rebind To: dhcptest@tahi.org Message-Id: <20051221061056.2616.qmail@web8512.mail.in.yahoo.com> In-Reply-To: <200512210030.jBL0UHXC070722@bahamas.64translator.com> X-Mail-Count: 00042HI Zhang, Thank you very much, now there is no problem in Rebind MRD, its working fine, the test case got passed. Thanks a lot. Regards, Amit zhang <zhang@64translator.com> wrote: Hi Amit, Thank you very much. I have checked the test script. And I found there is a error in the last judgement. In addition, I add some log information in the test script, If test is faild, you can mail the log to me. Best regards, Zhang --------------------------------- Hi Zhang, I tested the test cases for Information request with Option Request option, all three test cases are passing now. I even tested MRD for rebind but its stil failing... I will tell you how i have coded... I will send a rebind message and wait for its reply, once the timeout period expires and i stil dont get the reply i start retransmitting it. the retransmission time is calculated as per RFC 3315. As the MRD for rebind is 0, and also there is no MRC for rebind. I quit retransmitting whenever the next retransmission time is greater then ValidLifetime, it stops retransmitting and sends solicit message. Please comment. Regards, Amit zhang <zhang@64translator.com> wrote: Hi Amit, Thank you for your Email. I have modified the script of MRD test for Rebind. But I have not test environment for that test.So I hope you can give me your result. Thank you for the help and report that you have been giving. I wish you could continue attentioning to us, and giving us your suggestion. Best regards, Zhang --------------------------------- Hi zhang, Thanks for considering my suggestion. No problem at all, you complete the implementation of rebind MRD and then send both scripts together. Thanks for your immediate responses. Regards, Amit zhang <zhang@64translator.com> wrote: Hi Amit, Thanks for your reply and report . I have rewrite the function that examine the Requested-option-code. From my test, it works well. New function will examine all request-option-codes, and determine if the message is correct according to the test requirement. After I finish the modification of MRD! test of Rebind, I will send them together to you, will you ? I think you are right. This modification will be adapted to the occassions of many request codes. Best regards, Zhang --------------------------------- Hi zhang, Ya i have finished all except these two. the test script compares the first code in the option request option and fails if it is not Domain search list but this should not happen right. It should check all the codes in the option request option and fail only if Domain search list option is not present. If i include only one code, then its passing. But if i do so, i need to change that for the two test cases, that is once should put DNS name server in option request option and change it to Domain search list for the other test case. &nb! sp; Please comment. Regards, Amit zhang <zhang@64translator.com> wrote: ! Hi, Amit Thank you for your answers. I think you are right. But I have a question, which is whether DNS search list and DNS Name Server option MUST be used at the same time. My test item is Only to check DNS search list Option. By the way, have you finished all test items except these two items. Hope your answers. Thank you very much. Best regards, Zhang ! --------------------------------- Hi Zhang, The following test script is passing C_RFC3736_5_3_InfWDnsSvrOpt.seq but C_RFC3736_5_3_InfWDnsSchLstOpt.seq script is failing. The problem ! is... i am sending both DNS Server Option cod! e and Domain Server List OPtion code in the Option request Option. I guess C_RFC3736_5_3_InfWDnsSchLstOpt.seq script is just comparing the first option code in the Option rquest option and not checking other options included in that and its failing. Is it the case that only one option code should be included in the OPtion request option??? I am also waiting for MRD of rebind's new script. Thanks and regards, Amit zhang <zhang@64translator.com> wrote: Hi Amit, Thank you very much for your report. I am sorry that I am late to reply to you. According! to your description, I examined the test script and common files. There is a bug in the file of DHCPv6_common.pm. I have fixed that error. And I attache the file to this Email. Now you can continue your test. By the way, I want to know the result of MRD test of Confirm.Would you tell me? Thanks a lot. Best regards, Zhang --------------------------------- Hi Zhang, Thanks for ssending new test script for confirm MRD, I will test th! e sam! e and let you know the result. I hope you will modify Rebind MRD too. I have few more doubts.... In the new scripts that is version 2 scripts : C_RFC3736_5_3_InfWDnsSvrOpt.seq H! ere you are checking the request_option_code in Option Request Option to be 23. I am sending it properly but stil its saying Option Code is not correct! Thanks, Regards, Amit zhang <zhang@64translator.com> wrote: Hi Amit, I have finished the modificatio! n for Confirm MRD. But I have no NUT. I atteched the test script to this Email. Would you use it to test and give me your test result ? Thank you ver! y much in advance. Best regards, zhang --------------------------------- Hi Zhang, Thanks for your immediate reply. Now i got what actually the test case was, thanks a lot. Will mail you if i have further issues... Thanks and regards, Amit zhang <zhang@64translator.com> wrote: Hi Amit, Thank you for your immeidate feedback. I am very glad to receive your letter. Now I begin to explain to you. --------------------------------------------------------------------------------------------------- From the spec! ification of RFC3315, the following specificati! ons were written. "- sends a Request message if the IA contained a Status Code option with the NoBinding status (and does not send any additional Renew/Rebind messages)" I think that when client receive the Reply to Renew with status code of NoBinding, the client should send Request message to ask for Address. If you share the same idea with me, I think you! are right. ---------------------------------------------------------------------------------------------------- About the test item, C_RFC3633_12_1_RebWIAPDOpt.seq, I can make an explanation now. This te! st case is described as following: NUT TN | | | ------------ > | Solicit (W IA_PD option) | <------------ | Advertise (W/ IA_PD option ) | ------------ > | Reques! t (W/ IA_PD option ) | <------------ &nb! sp;| Request (W/! IA_PD option ) | | Reboot NUT | ------------> | Rebind (W/ IA_PD option ) In RFC3633, there a! re information about this test case. "In some circumstances the requesting router may need verification that the delegating router still has a valid binding for the requesting router. Examples of times when a requesting router may ask for such verification include: o The requesting router reboots. o The requesting router's up! stream link flaps. o The requesting r! outer is physically disconnected from a wired connection. If such verification is needed the requesting router MUST initiate a Rebind/Reply message exchange as described in section 18.1.4, "Creation and Transmissi! on of Rebind Messages" of RFC 3315, with the &n! bsp; exception that the retransmission parameters should be set as for the Confirm message, described in section 18.1.2, "Creation and Transmission of Confirm Messages" of RFC 3315. The requesting router includes any IA_PDs, along with prefixes associated with those IA_PDs in its Rebind message." So the condition that Requesting Router send Rebind message, is the same with Confirm. Therefore, When you test Rebind message when you reboot your Requesting Router, y! ou will see the information about Confirm. There are the message that you must have seen. " In order to send confirm message According to RFC3315, you can choose as follows:" " 1. The client reboots" " 2. T! he client is physically connected to a wired connection." " 3. The client returns from sleep mode. " 4. The client using a wireless technology changes access points." " Note the situation that IA_PD option test is performed.". " IA_PD information is released by Rebind message. ". ! " then press enter key. " In order to not make user confused, I add "Not! e the situation ..........." after the l! ast condition item. I think what you want me to explain is above. Thank you for your report. If you feel inconvinience, please tell me, I will consider to modify it. &nb! sp; You are appreciated. Best regards. Zhang --------------------------------- Hi zhang, From your mail i understand that whenever server sends status code as Nobinding, irrespective of the time periods(T1/T2) it should always send request message. Am I right??? And in the following script, he is waiting for the rebind message with PD Op! tion but he prints a Message saying send Confirm Message on Screen. Please look! into the same a! nd let me know... C_RFC3633_12_1_RebWIAPDOpt.seq Regards, Amit zhang <zhang@64translator.com> wrote: Hi Amit, &nbs! p; Thank you for your report. After reading your Email, I think you want to let me confirm the foll! owing two test items, don't you ? C_RFC3315_18_1_8_RenReplyWIAStatusNoBinding.seq C_RFC3315_18_1_8_RebReplyWIAStatusNoBinding.seq These two test cases are according to the specifications of RFC3315. In the! chapter 18.1.8 of RFC3315,the following messages are written. -------------------------------------------------------------------------------------- " When the client receives a Reply message in response to a Renew or Rebind message, the client examines each IA independently. For each IA in the original Rene! w or Rebind message, the client: - sends a Req! uest message if the IA contained a Status Code option with the NoBinding status (and does not send any additional Renew/Rebind messages) - sends a Renew/Rebind if the IA is not in the Reply message - otherwise accepts the information in the IA" --------------------------------------------------------------------------------------- ! ; Accordi! ng to! above message, I draw two conclusions: 1. If Client sends Renew/Rebind message, but Server give the information with status of NoBinding, the Client should send Request message. 2. If Server give the information with IA which Client doesnot need, then, Client should not change any internal information, and then after T1/T2 , will send renew/rebind. I make T1/T2 shorter, and So the test time will become shorter. These are my methods and reasons to these test cases. What do you think so?If I am understanding, please contact ! me. You will be very appreciated. T! hank you ver! y much. Best regards, Zhang --------------------------------- Hi zhang, Thanks for for considering my request. I tested all the 3 test case! s for solicit transmission, now all are passing. Initially they were failing b! ecause i was testing them when both NUT and TN were on LAN. Then i connected them to hub and tested they got passed... And here we should ! also be very accurate in running the client as soon as we run the scripts... a little time delay in running will fail the test cases. And one more thing... I am testing all the test scripts for client as well as for the server. I have one! more doubt in client... C_RFC3315_18_1_8_RenReplyNotWantedIA.seq C_RFC3315_18_1_8_RebReplyNotWantedIA.seq In these two test cases, you are sending the reply for the renew message changing the T1,T2, preferred lifetime and valid li! fetime values and you expect that this reply should be discarded and should send the renew/rebind message again. And, C_RFC3315_18_1_8_RenReplyWIAStatusNoBinding.seq C_RFC3315_18_1_8_RebReplyWIAStatusNoBinding.seq In these two test cases, you are sending the reply for the renew me! ssage changing the T1,T2, preferred lifetime and valid lifetime values and with status code NoBinding. Here you expect to get the request message. But what my code is doing is once it finds mismatch between T!,T2, preferred lifetime and valid lifetime, it wil send renew/rebind again. I guess this is a bug in the test script. Pleas! ! ! e check the same and let me know. Thanks, Regards, Amit zhang <zhang@64translator.com> wrote: Hi, Amit, Thank you for! your report. I have examined the test scripts. Fistly, let me explain the First RT. ------------------------------------------------------------------------- In Section 14 of RFC3315, there are following specification: "RT for the first message transmission is based on IRT: RT = IRT + RAND*! IRT ". --------------------------------------------------------------------! ------! - Normally, RAND should be a Random value between -0.1 and 0.1. --------------------------------------------------------------------------- In Section 17.1.2 of RFC3315, the followin! g words were written. "Rather, the client collects A! dvertise messages until the first RT has elapsed. Also, the first RT MUST be selected to be ! strictly greater than IRT by choosing RAND to be strictly greater than 0." ---------------------------------------------------------------------------- So,as to first Solicit retransmission time(First RT), RAND becomes a Random value between 0 and 0.1. Then, please let me explain the three test cases one by one. ========================================================================================= 1. C_RFC3315_17_1_2_SolWaitAdv.seq (1) Test case Client Server | | | ---------------> | Solicit | <--------------- | Advertise (preference = 0! or less than 255) | ---------------> | Request (2)Specifications of RFC3315 "If the client is waiting for an Advertise message, the mechanism in section 14 is modified as follows for use in the transmission of Solicit messages. ! ! ! ! The message exchange is not terminated by the receipt of an Advertise before the first RT has elapsed. Rather, the client collects Advertise messages until the first RT has elapsed. Also, the first RT MUST be selected to be strictly greater than IRT by choosing RAND to be strictly greater than 0." (3) Explanation when Client receives the Advertise message from low-preference DHCPv6 Server,! It must wait first RT. When First RT pass, the Client will accept this DHCPv6 Server, and then send Request to Server(In fact, multicast to server, but with Server identifier option). And first RT is not very identical to the specification in section 14 of RFC3315. In regulation, Fisrst RT = IRT + RAND*IRT , but RAND must be larger than 0. (4) The limitation of test script Because it is Client who determines when to accept the Server and when to send request, the TN(Server End) cannot know ! the accurate time of Client and ONLY use the time when receiving the message from Client. This instance is obvious example. The Client can ONLY use ! the time when receiving Request. So, this time interval (Actually, this interval should be between the time Send! ing Solicit and the time ACCEPTING Server) will include the Client diposing time and net! work transmission time. But I think this delay should be very small value and must less than 0.1s. Therefore, If you find the time is not in right range, because, the First RT must less than IRT. (5)Implementaion In RFC3315, there are ! ;! ;t! ! he recommended value about IRT and RAND. SOL_TIMEOUT 1 sec RAND [-0.1, +0.1] , uniform distribution 2.C_RFC3315_17_1_2_SolNoWaitAdv.seq (1) Test case Client Server | ! ; | | ---------------> | Solicit | <--------------- | Advertise (preference = 255) | ---------------> | Request (2)Specifications of RFC3315 "If the client receives an Advertise message that does not include a Preference ! option with a preference value of 255, the client continues to wait until the first RT elapses." (3) Explanation In this case, the Client receive the DHCPv6 server with highest pr! eference value which is 255. So the Client will accept this server and immediately send Request message to the Server. (4) Limitation of test script Because i! t is Client who determines when to accept the Server and when to send request, the TN(Server End) cannot know the accurate time of Client and ONLY use the time when receiving the message from Client. This instance is obvious example. The Client can ONLY use the time when receiv! ! ing Request. So, this time interval (Actually, this interval should be between the time Sending Solicit and the time ACC! EPTING Server) will include the Client diposing time and network transmission time. This test assumes that the Client will complete all operations in First IRT. So the PASS condition is interval between! the receptions of Solicit and Reques! t, is not great than IRT. (5)Implementaion In RFC3315, there are the recommended value about IRT and RAND. &! nbsp; SOL_TIMEOUT 1 sec RAND [-0.1, +0.1] , uniform distribution 3.C_RFC3315_17_1_2_SolNoAdvRT.seq ! ! (1) Test case Client Server | | | ---------------> | Solicit | | Server donnot response to Client | ---------------> | Client-retransmitted Solicit | <--------------- | Advertise (preference = 255) | ---------------> | Request (2)Specifications of RFC3315 "If the client does not receive any Advertise messages before the! ! &n! bsp; first RT has elapsed, it begins the retransm! ission mechanism described in section 14." (3) Explanation This is the test case including test of First RT and Reaction of Advertise to Retransmitted Solicit. The judgement is the inter! val betw! een the receptions of solicit and retransmitted solicit, should be between IRT and IRT + RAND*IRT. (4)Limitation of test script No. (5)Implementaion ! ; First RT = IRT + RAND*IRT RAND should be larger than 0 and less than +RAND. As recommended in RFC3315, First RT should be value between 1sec and 1.1sec. =================================================================================================== Abov! e words are my understanding of Solicit Retransmission and Acceptation of Advertise. Base on those, the test scripts were written. What do you think about those? If you find I is misunderstanding the specifications or you have some advice, ! please ! contact me. You will be appreciated very much. By the way, do you have used all of test scripts? Best regards, zhang --------------------------------- Hi Zhang, ! I have few more doubts on the following scripts.... C_RFC3315_17_1_2_SolWaitAdv.seq C_RFC3315_17_1_2_SolNoWaitAdv.seq C_RFC3315_17_1_2_SolNoAdvRT.seq! ! Here Its comparing the for the time periods. These 3 test cases are failing saying "Not in r! ight time range!" I am sending first solicit message random time between 0-1 second, but stil they are failing. Can u please check and tell me whether there is some problem in the script or i need to modify something in my code itself. &nbs! p; Thanks, Regards, Amit zhang <zhang@64translator.com> wrote: Hi, Amit You are welcome. And I appreciate your report. If you have ! ot! her problems! a! bout DHCPv6 client test cases, please contact me. Best regards, --------------------------------- Hi Zhang, Th! anks for your support. I have tested "Transmit DHCP using Unicast Address", its working fine. No bugs in that test script, that test case got passed. You send the new test scripts for MRD after modification, i will test and let you kno! w t! he results. Thanks, Regards, Amit zhang <zhang@64translator.com> wrote: Hi, Amit First, thank you for your report. I am very sorry, It is a BU! G. ! ;! ; This test case will be deleted in next release version because it is the same test case with that of "Transmit DHCP using Unicast Address". If the l! atter test is OK, this test can be ignored. And I have look into the source code, and configuration of server address of ServerUnicast Option is wrong. And I have a question to you. Have you performed the test of "Transmit ! DHCP u! sing Unicast Address". I want to know the result of that test. By the way, about fix of MRD, I think I will finish them by this friday. I am very sorry to have you wait. Thank you! . --------------------------------- Hi zhang, I have one more doubt in client test cases. There is one test case to! check the! "Format of Server Unicast Option". Here the script is sending the server unicast address as fe80::250:daff:fe91:ddba, which is my DHCP client PC eth0's link l! ocal address. When my cli! ent sends the renew msg to that address, its saying Could not get Renew Message and gets failed. Please explain me this... Thanks and regards, Amit zhang <zhang@64translator.com> wrote: Hi amit, Thank you very much for your report. Now I cannot draw a con! clusion from your description. Following words are just my deduction. &nb! sp; I t! hink there may be ! ! the problem of nut.def. For example, if using Linux OS, the Link0 will be set as following, Link0 eth0 aa:bb:cc:dd:ee:ff From your description, the reason may be that you use "LINK0" other than "Link0". And so you cannot get the variable of Link0_addr. Can you try to examine that and the path of nut.def ? Or else, you can send your nut.def to me. Thanks, Best regards, Zhang --------------------------------- Hi Zhang, I tried testing the "Use of upstream addres! s when sends DHCP message" I even checked that the Nut.def file has proper MAC address assigned for LINK0. I even printed the value got for ! MAC address in get_nut_link_number() fun! ction in DHCPv6_common.pm file. Its the same value which i have assigned against LINK0 in Nut.def file. The test case is failing because its comparing this MAC adress with Link0_addr field. I have no idea from where he is getting t! he! value for this variable. I tried printing this variable but could not print that. I am sending the messages from my client to the script on eth0. And i have set eth0's MAC address(of my client) to LINK0 in Nut.def file. Could you please look int! o ! the same and tell me what to do. Thanks, Regards, Amit zhang <zhang@64translator.com>! wrote:! Hi amit ! You question makes me think more about the test case. Thank you very much. Now I can reply to you. 1. Use of upstream address when sends D! ! HCP message In RFC3633, " When a requesting router sends a DHCP message, it SHOULD be sent on the interface associated with the upstream router (ISP network). The upstream interface is typically determined by configurat! ion." is decribed. ----I think this test is us! ed to test the upstr! eam interface that the Requesting Router is using. &n! bsp;It is a better way to u! ! se Interface MAC address to determine whose interface(Link) Requesting Router is using. I am very sorry, there is some inconsistenc! e between the test script and the test specification. I will change the test specification to make them consistent. By the way, when you test , please set Nut.def file, and set Link0 as your up! stre! am interface. The test will check MAC address and determine if It is Link0. It is the limitation. 2.About MRD test. ----I think my consideration is not enough to these test cases. I think they are BUGs. And I am considering how to fix th! em. I need some time! . After f! ixing, I will contact you. &! ;nbs! p; what about other test items? If you have other questions, I will be glad to discuss them with you. --------------------------------- Hi Zhang Tha! nks for your immediate response. I wil test with the .seq file you have sent. I have two more doubts. 1> There are two test saying "Use of upstream address when sends DHCP message". I wanted to know what exactly are these two test cases. Becauses these test cases are failing giving an error as "NUT Link MAC Address is 00:50:da:91:dd:ba Upstream Link number should be Link0 ." In the script he is comparing the ! Ma! cAdrress with some variable, i could not understand that... Plz tell me what we ne! ed to do exactly. 2> Two test cases are ! to verify the MRD of Confirm mess! age a! nd Rebind message. What i am doing is, my DHCP client stops retransmitting when the next retransmission time exceeds MRD of that message. But the scr! ipt stil waits for some more ti! me and he compares two messages and say they are not same. Please clarify this doubt also... Thanks, Regards, Amit z! hang <zhang@64translator.com> wrote: Hi, amit Thank you for your report. I am sure that this is a bug, and I have fixed it. We will fix this bug ! in next version.! I atta! ch two files to this mail. &nbs! p; You can use them to continue your test. If you find some other problems, please cont! act us. --------------------------------- ! Hi... I have implemented DHCPv6 I am testing my client and server using the tahi test scripts. I have a doubt in one of the! client script. The script is : C_RFC3633_11_1_AdvWStatusCodeNoPrefixAvail.seq Here he says receiving advertisement with Status code "NoPrefixAvail" but what i found was he is sending advertisement with Status code "Success" but he in the reply for request message h! e ! sends Status code "NoPrefixAvail". But while sending the reply message he is sending wrong transaction ID. Can u plz clar! ify this... ! ; Thanks. Regards, Amit dhcptest-admin@tahi.org wrote: Cauti! o! n: If you reply this mail, your reply will be sent to the mailing list! post articles commands maintainer Welco! me to ! our mailing list ! This mail contains the fundamental usage of the mailing list server. 1 How to use this server Plaese send commands in the mail body not subject to the address . The command syntax is as follows: help mget last:10 mp Pla! es! e send the "help" to the address for help and server functions overview help to get ! general in! formation on this list guide If you want to make a contact w! ith the mailing list ma! intainer, please e-mail to dhcptest-admin@tahi.org ML server exists to descrease routine works by maintainers. Please try to use server functi! ons as co! uld as possible. dhcptest@tahi.org Maintainer dhcptest-admin@tahi.org --------------------------------- Yahoo! India Matrimony: Find your partner now. --------------------------------- --------------------------------- Yahoo! India Matrimony: Find your partner now. --------------------------------- --------------------------------- Yahoo! India Matrimony: Find your partner now. --------------------------------- --------------------------------- Yahoo! India Matrimony: Find your partner now. --------------------------------- --------------------------------- Yaho! o! India Matrimony: Find your partner now. --------------------------------- --------------------------------- Yahoo! India Matrimony: Find your partner now. --------------------------------- --------------------------------- Yahoo! India Matrimony: Fi! nd your partner now. --------------------------------- --------------------------------- Yahoo! India Matrimony: Find your partner now. --------------------------------- --------------------------------- Yahoo! India Matrimony: Find your pa! rtner now. Send instant messages to your online friends http://in.messenger.yahoo.com --------------------------------- Send instant messages to your online friends http://in.messenger.yahoo.com --------------------------------- Send instant messages to your online friends http://in.messenger.yahoo.com --------------------------------- Send instant messages to your online friends http://in.messenger.yahoo.com --------------------------------- Send instant messages to your online friends http://in.messenger.yahoo.com --------------------------------- Send instant messages to your online friends http://in.messenger.yahoo.com42_2.html (attatchment)(tag is disabled)