Date: Mon, 19 Dec 2005 06:03:13 +0000 (GMT) From: amit agarwal <amit_agarr@yahoo.co.in> Subject: [dhcptest:00030] Re: Welcome to our (dhcptest ML) You are added automatically To: dhcptest@tahi.org Message-Id: <20051219060313.79565.qmail@web8514.mail.in.yahoo.com> In-Reply-To: <200512190050.jBJ0oZw1048394@bahamas.64translator.com> X-Mail-Count: 00030Hi Zhang, Sorry for the delay... I did test MRD for confirm and its working fine.. thanks... and even i updated DHCPv6_common.pm fine, the information request test cases are also passing now. Thanks again. 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 the same 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 Here 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 modification 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 very 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 specification 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 test case is described as following: NUT TN | | | ------------ > | Solicit (W IA_PD option) | <------------ | Advertise (W/ IA_PD option ) | ------------ > | Reques! t (W/ IA_PD option ) | <------------ | 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 router 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 Transmission 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, you 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 "Note the situation ..........." after the last 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. 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 and 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 Renew 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" --------------------------------------------------------------------------------------- According 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. Thank you very much. Best regards, Zhang --------------------------------- Hi zhang, Thanks for for considering my request. I tested all the 3 test cases 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. Please 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 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." ---------------------------------------------------------------------------- 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 preference 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 receiving 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 interval 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. Thanks, Regards, Amit zhang <zhang@64translator.com> wrote: Hi, Amit You are welcome. And I appreciate your report. If you have other 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 know 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 BUG. ! ; 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. I think 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 address 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 the! 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. 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 upstre! 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 fixing, 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 message 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 zhang <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 attach 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 clarify 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 Welcome 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 with 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: Find your partner now. --------------------------------- --------------------------------- Yahoo! India Matrimony: Find your partner now. --------------------------------- --------------------------------- Yahoo! India Matrimony: Find your partner now. --------------------------------- Send instant messages to your online friends http://in.messenger.yahoo.com --------------------------------- Send instant messages to your online friends http://in.messenger.yahoo.com30_2.html (attatchment)(tag is disabled)