<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=shift_jis">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>
<BODY>
<DIV>Hi, Amit</DIV>
<DIV> </DIV>
<DIV> Thank you for your answers.</DIV>
<DIV> </DIV>
<DIV> I think you are right.</DIV>
<DIV> But I have a question, which is whether DNS search list and DNS
Name Server option MUST be used at the same time.</DIV>
<DIV> My test item is Only to check DNS search list
Option.</DIV>
<DIV> </DIV>
<DIV> By the way, have you finished all test items except these two
items.</DIV>
<DIV> </DIV>
<DIV> Hope your answers.</DIV>
<DIV> Thank you very much.</DIV>
<DIV> </DIV>
<DIV> Best regards,</DIV>
<DIV> Zhang</DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi Zhang,</DIV>
<DIV> </DIV>
<DIV>The following test script is passing</DIV>
<DIV>C_RFC3736_5_3_InfWDnsSvrOpt.seq</DIV>
<DIV> </DIV>
<DIV>but C_RFC3736_5_3_InfWDnsSchLstOpt.seq script is failing.</DIV>
<DIV> </DIV>
<DIV>The problem is... i am sending both DNS Server Option code and Domain
Server List OPtion code in the Option request Option.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Is it the case that only one option code should be included in the OPtion
request option???</DIV>
<DIV> </DIV>
<DIV>I am also waiting for MRD of rebind's new script.</DIV>
<DIV> </DIV>
<DIV>Thanks and regards,</DIV>
<DIV>Amit</DIV>
<DIV><BR><BR><B><I>zhang <zhang@64translator.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR>
<DIV>Hi Amit,</DIV>
<DIV> </DIV>
<DIV> Thank you very much for your report.</DIV>
<DIV> I am sorry that I am late to reply to you.</DIV>
<DIV> </DIV>
<DIV> According to your description, I examined the test script and
common files.</DIV>
<DIV> There is a bug in the file of DHCPv6_common.pm.</DIV>
<DIV> I have fixed that error.</DIV>
<DIV> And I attache the file to this Email.</DIV>
<DIV> </DIV>
<DIV> Now you can continue your test. </DIV>
<DIV> By the way, I want to know the result of MRD test of
Confirm.Would you tell me?</DIV>
<DIV></DIV>
<DIV> Thanks a lot.</DIV>
<DIV> Best regards,</DIV>
<DIV> Zhang</DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi Zhang,</DIV>
<DIV> </DIV>
<DIV>Thanks for ssending new test script for confirm MRD, I will test the sam!
e and let you know the result.</DIV>
<DIV>I hope you will modify Rebind MRD too.</DIV>
<DIV> </DIV>
<DIV>I have few more doubts....</DIV>
<DIV> </DIV>
<DIV>In the new scripts that is version 2 scripts :</DIV>
<DIV> </DIV>
<DIV>C_RFC3736_5_3_InfWDnsSvrOpt.seq</DIV>
<DIV> </DIV>
<DIV>Here you are checking the request_option_code in Option Request Option to
be 23.</DIV>
<DIV> </DIV>
<DIV>I am sending it properly but stil its saying <FONT color=#ff0000>Option
Code is not correct!</FONT></DIV><FONT color=#ff0000></FONT>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR><B><I>zhang <zhang@64translator.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR>
<DIV>Hi Amit,</DIV>
<DIV> </DIV>
<DIV> I have finished the modificatio! n for Confirm MRD.</DIV>
<DIV> But I have no NUT.</DIV>
<DIV> I atteched the test script to this Email.</DIV>
<DIV> Would you use it to test and give me your test result ?</DIV>
<DIV> Thank you very much in advance.</DIV>
<DIV> </DIV>
<DIV> Best regards,</DIV>
<DIV> zhang</DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi Zhang,</DIV>
<DIV> </DIV>
<DIV>Thanks for your immediate reply.</DIV>
<DIV> </DIV>
<DIV>Now i got what actually the test case was, thanks a lot.</DIV>
<DIV>Will mail you if i have further issues...</DIV>
<DIV> </DIV>
<DIV>Thanks and regards,</DIV>
<DIV>Amit</DIV>
<DIV><BR><BR><B><I>zhang <zhang@64translator.com></I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR>
<DIV>Hi Amit,</DIV>
<DIV> </DIV>
<DIV> Thank you for your immeidate feedback.</DIV>
<DIV> I am very glad to receive your letter.</DIV>
<DIV> </DIV>
<DIV> Now I begin to explain to you.</DIV>
<DIV> ---------------------------------------------------------------------------------------------------</DIV>
<DIV> From the specification of RFC3315, the following
specificati! ons were written.</DIV>
<DIV> </DIV>
<DIV> "- sends a Request message if the IA contained a
Status Code option<BR> with the NoBinding
status (and does not send any additional<BR>
Renew/Rebind messages)"</DIV>
<DIV> </DIV>
<DIV> I think that when client receive the Reply to
Renew with status code of NoBinding, </DIV>
<DIV> the client should send Request message to ask for
Address.<! /DIV>
<DIV> </DIV>
<DIV> If you share the same idea with me, I think you
are right.</DIV>
<DIV> </DIV>
<DIV>
----------------------------------------------------------------------------------------------------</DIV>
<DIV> About the test item,
C_RFC3633_12_1_RebWIAPDOpt.seq, I can make an explanation now.</DIV>
<DIV> </DIV>
<DIV> This test case is described as following:</DIV>
<DIV>
NUT
TN</DIV>
<DIV> |
|</DIV>
<DIV> | ------------ > | Solicit (W IA_PD
option)</DIV>
<DIV> | <------------ | Advertise
(W/ IA_PD option )
<DIV> | ------------ > | Reques! t (W/
IA_PD option )</DIV></DIV>
<DIV> | <------------ | Request (W/!
IA_PD option ) </DIV>
<DIV>
<DIV> |
| Reboot NUT </DIV>
<DIV> | ------------> | Rebind (W/
IA_PD option )</DIV>
<DIV> </DIV>
<DIV> In RFC3633, there a! re information about
this test case.</DIV>
<DIV> </DIV>
<DIV> "In some circumstances the requesting router may need
verification<BR> that the delegating router still has a valid
binding for the<BR> requesting router. Examples of times
when a requesting router may<BR> ask for such verification
include:</DIV>
<DIV> </DIV>
<DIV> o The requesting router reboots.</DIV>
<DIV> </DIV>
<DIV> o The requesting router's up! stream link
flaps.</DIV>
<DIV> </DIV>
<DIV> o The requesting router is physically disconnected
from a wired<BR> connection.</DIV>
<DIV> </DIV>
<DIV> If such verification is needed the requesting router
MUST initiate a<BR> Rebind/Reply message exchange as described
in section 18.1.4,<BR> "Creation and Transmission of Rebind
Messages" of RFC 3315, with the<BR> &n! bsp; exception that the
retransmission parameters should be set as for the<BR> Confirm
message, described in section 18.1.2, "Creation and<BR>
Transmission of Confirm Messages" of RFC 3315. The requesting
router<BR> includes any IA_PDs, along with prefixes associated
with those IA_PDs<BR> in its Rebind message."</DIV>
<DIV> </DIV>
<DIV> So the condition that Requesting Router send
Rebind message, is the same with Confirm.</DIV>
<DIV> Therefore, When you test Rebind message when you reboot
your Requesting Router,</DIV>
<DIV> you will see the information about Confirm.</DIV>
<DIV> There are the message that you must have
seen.</DIV>
<DIV> " In order to send confirm message According to RFC3315,
you can choose as follows:"<BR>
" 1. The client reboots"<BR> "
2. T! he client is physically connected to a wired
connection."<BR> " 3. The client
returns from sleep mode.<BR> "
4. The client using a wireless technology changes access
points."<BR> " Note the
situation that IA_PD option test is
performed.".<BR> " IA_PD
information is released by Rebind message.
".<BR> ! " then press enter key.
"<BR> In order to not make user confused, I add "Note the
situation ..........." after the last condition item.</DIV>
<DIV> I think what you want me to explain is above.</DIV>
<DIV> </DIV>
<DIV> Thank you for your report.</DIV>
<DIV> If you feel inconvinience, please tell me, I
will consider to modify it.</DIV>
<DIV> </DIV>
<DIV> You are appreciated.</DIV>
<DIV> <! /DIV>
<DIV> Best regards.</DIV>
<DIV> </DIV>
<DIV> Zhang </DIV></DIV>
<DIV> </DIV>
<DIV>
<HR>
</DIV>
<DIV id=RTEContent>
<DIV>Hi zhang,</DIV>
<DIV> </DIV>
<DIV>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???</DIV>
<DIV> </DIV>
<DIV>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...</DIV>
<DIV> </DIV>
<DIV>C_RFC3633_12_1_RebWIAPDOpt.seq</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Amit<BR><BR><B><I>zhang <zhang@64translator.com></I></B>
wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2802" name=GENERATOR>
<DIV>Hi Amit,</DIV>
<DIV>&nbs! p;</DIV>
<DIV> Thank you for your report.</DIV>
<DIV> After reading your Email, I think you want to let me
confirm the foll! owing two test items, don't you ?</DIV>
<DIV>
<DIV> C_RFC3315_18_1_8_RenReplyWIAStatusNoBinding.seq</DIV>
<DIV> C_RFC3315_18_1_8_RebReplyWIAStatusNoBinding.seq</DIV>
<DIV> </DIV>
<DIV> These two test cases are according to the
specifications of RFC3315.</DIV>
<DIV> In the! chapter 18.1.8 of RFC3315,the following
messages are written.</DIV>
<DIV>
--------------------------------------------------------------------------------------</DIV></DIV>
<DIV> " When the client receives a Reply message in response
to a Renew or<BR> Rebind message, the client examines each
IA independently. For each<BR> IA in the original
Renew or Rebind message, the client:</DIV>
<DIV> </DIV>
<DIV> - sends a Req! uest message if the IA contained
a Status Code option<BR> with the
NoBinding status (and does not send any
additional<BR> Renew/Rebind
messages)</DIV>
<DIV> </DIV>
<DIV> - sends a Renew/Rebind if the IA is not in the
Reply message</DIV>
<DIV> </DIV>
<DIV> - otherwise accepts the information in the
IA"</DIV>
<DIV>
---------------------------------------------------------------------------------------</DIV>
<DIV> According to! above message, I draw two
conclusions:</DIV>
<DIV> </DIV>
<DIV> 1. If Client sends Renew/Rebind message, but
Server give the information with status of NoBinding,</DIV>
<DIV> the Client should send Request message.</DIV>
<DIV> </DIV>
<DIV> 2. If Server give the information with IA
which Client doesnot need, then, Client should not
change</DIV>
<DIV> any internal information, and then after T1/T2 ,
will send renew/rebind. I make T1/T2 shorter, and So</DIV>
<DIV> the test time will become shorter.</DIV>
<DIV> </DIV>
<DIV> These are my methods and reasons to these test
cases.</DIV>
<DIV> What do you think so?If I am understanding,
please contact ! me.</DIV>
<DIV> You will be very appreciated.</DIV>
<DIV> </DIV>
<DIV> Thank you very much.<!
/DIV>
<DIV> </DIV>
<DIV> Best regards,</DIV>
<DIV> </DIV>
<DIV> Zhang </DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi zhang,</DIV>
<DIV> </DIV>
<DIV>Thanks for for considering my request.</DIV>
<DIV>I tested all the 3 test cases for solicit transmission, now all are
passing.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>And one more thing...</DIV>
<DIV>I am testing all the test scripts for client as well as for the
server.</DIV>
<DIV> </DIV>
<DIV>I have one! more doubt in client...</DIV>
<DIV> </DIV>
<DIV>C_RFC3315_18_1_8_RenReplyNotWantedIA.seq</DIV>
<DIV>C_RFC3315_18_1_8_RebReplyNotWantedIA.seq</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>And,</DIV>
<DIV>C_RFC3315_18_1_8_RenReplyWIAStatusNoBinding.seq</DIV>
<DIV>C_RFC3315_18_1_8_RebReplyWIAStatusNoBinding.seq</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>I guess this is a bug in the test script.</DIV>
<DIV>Pleas! e check the same and let me know.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit</DIV>
<DIV><BR><BR><B><I>zhang <zhang@64translator.com></I></B>
wrote:</DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"
s="replbq" clas!>
<META content="MSHTML 6.00.2900.2802" name=GENERATOR>
<DIV>Hi, Amit,</DIV>
<DIV> </DIV>
<DIV> Thank you for! your report.</DIV>
<DIV> I have examined the test scripts.</DIV>
<DIV> </DIV>
<DIV> Fistly, let me explain the First RT.</DIV>
<DIV>-------------------------------------------------------------------------</DIV>
<DIV> In Section 14 of RFC3315, there are following
specification:</DIV>
<DIV> </DIV>
<DIV> "RT for the first message transmission is based on
IRT:</DIV>
<DIV> RT = IRT + RAND*! IRT ".</DIV>
<DIV>---------------------------------------------------------------------------</DIV>
<DIV>Normally, RAND should be a Random value between -0.1 and
0.1.</DIV>
<DIV>---------------------------------------------------------------------------</DIV>
<DIV> In Section 17.1.2 of RFC3315, the followin! g words were
written.</DIV>
<DIV> </DIV>
<DIV> "Rather, the client collects Advertise messages until
the first RT has elapsed.<BR> Also, the first RT MUST be
selected to be ! strictly greater than IRT<BR> by choosing
RAND to be strictly greater than 0."</DIV>
<DIV>----------------------------------------------------------------------------</DIV>
<DIV> So,as to first Solicit retransmission time(First
RT), RAND becomes a Random value between 0
and 0.1. </DIV>
<DIV> </DIV>
<DIV></DIV>
<DIV> Then, please let me explain the three test cases
one by one.</DI! V>
<DIV> =========================================================================================</DIV>
<DIV> 1. C_RFC3315_17_1_2_SolWaitAdv.seq</DIV>
<DIV> </DIV>
<DIV>(1) Test case<BR></DIV>
<DIV>Client
Server</DIV>
<DIV>|
| </DIV>
<DIV>| ---------------> | Solicit</DIV>
<DIV>| <--------------- | Advertise (preference = 0! or less
than 255)</DIV>
<DIV>| ---------------> | Request</DIV>
<DIV> </DIV>
<DIV>(2)Specifications of RFC3315</DIV>
<DIV> </DIV>
<DIV> "If the client is waiting for an Advertise
message, the mechanism in<BR> section 14 is modified as
follows for use in the transmission of<BR> Solicit
messages. ! ! The message exchange is not terminated by
the<BR> receipt of an Advertise before the first RT has
elapsed. Rather, the<BR> client collects Advertise
messages until the first RT has elapsed.<BR> Also, the
first RT MUST be selected to be strictly greater than
IRT<BR> by choosing RAND to be strictly greater than
0."<BR></DIV>
<DIV>(3) Explanation</DIV>
<DIV> </DIV>
<DIV> when Client receives the Advertise message from
low-preference DHCPv6 Server,! </DIV>
<DIV>It must wait first RT. When First RT pass, the Client will
accept this DHCPv6 Server,</DI! V>
<DIV>and then send Request to Server(In fact, multicast to server, but
with Server identifier </DIV>
<DIV>option).</DIV>
<DIV> And first RT is not very identical to the
specification in section 14 of RFC3315.</DIV>
<DIV>In regulation, Fisrst RT = IRT + RAND*IRT , but
RAND must be larger than 0.</DIV>
<DIV> </DI! V !>
<DIV>(4) The limitation of test script</DIV>
<DIV></DIV>
<DIV> Because it is Client who determines when to accept
the Server and when to send request,</DIV>
<DIV>the TN(Server End) cannot know ! the accurate time of Client and
ONLY use the time when </DIV>
<DIV>receiving the message from Client.</DIV>
<DIV> This instance is obvious example. The Client can
ONLY use the time when receiving Request.</DIV>
<DIV>So, this time interval (Actually, this interval should
be between the time Send! ing Solicit and the time ACCEPTING
Server) </DIV>
<DIV>will include the Client diposing time and net! work transmission
time.</DIV>
<DIV> But I think this delay should be very small value and must
less than 0.1s.</DIV>
<DIV> Therefore, If you find the time is not in right range,
because, the First RT must less than IRT.</DIV>
<DIV></DIV>
<DIV>(5)Implementaion </DIV>
<DIV> </DIV>
<DIV> In RFC3315, there are t! ! he recommended
value about IRT and RAND.</DIV>
<DIV> SOL_TIMEOUT 1 sec</DIV>
<DIV>
RAND
[-0.1, +0.1] , uniform distribution </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>2.C_RFC3315_17_1_2_SolNoWaitAdv.seq</DIV>
<DIV> </DIV>
<DIV>
<DIV>(1) Test case<BR></DIV>
<DIV>Client
Server</DIV>
<DIV>| ! ;
| </DIV>
<DIV>| ---------------> | Solicit</DIV>
<DIV>| <--------------- | Advertise (preference
= 255)</DIV>
<DIV>| ---------------> | Request</DIV></DIV>
<DIV></DIV>
<DIV>
<DIV>(2)Specifications of RFC3315</DIV>
<DIV> </DIV>
<DIV> "If the client receives an Advertise message that does
not<BR> include a Preference ! option with a preference
value of 255, the<BR> client continues to wait until the
first RT elapses."</DIV>
<DIV> </DIV>
<DIV>(3) Explanation</DIV>
<DIV> </DIV>
<DIV> In this case, the Client receive the DHCPv6 server
with highest preference value which is 255.</DIV><! DIV>So the
Client will accept this server and immediately send Request message to
the Server.</DIV>
<DIV> </DIV>
<DIV>(4) Limitation of test script</DIV>
<DIV></DIV>
<DIV> Because i! t is Client who determines when to accept
the Server and when to send request,</DIV>
<DIV>the TN(Server End) cannot know the accurate time of Client and
ONLY use the time when </DIV>
<DIV>receiving the message from Client.</DIV>
<DIV> This instance is obvious example. The Client can
ONLY use the time when receiving Request.</DIV>
<DIV>So, this time interval (Actually, this interval should
be between the time Sending Solicit and the time ACC! EPTING
Server) </DIV>
<DIV>will include the Client diposing time and network transmission
time.</DIV>
<DIV> </DIV>
<DIV> This test assumes that the Client will complete all
operations in First IRT.</DIV>
<DIV> So the PASS condition is interval between the receptions
of Solicit and Reques! t, is not great than IRT.</DIV>
<DIV></DIV>
<DIV>(5)Implementaion </DIV>
<DIV> </DIV>
<DIV> In RFC3315, there are the recommended
value about IRT and RAND.</DIV>
<DIV> &! nbsp; SOL_TIMEOUT 1 sec</DIV>
<DIV>
RAND
[-0.1, +0.1] , uniform distribution </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>3.C_RFC3315_17_1_2_SolNoAdvRT.seq</DIV>
<DIV> <!
! /DIV>
<DIV>
<DIV>
<DIV>(1) Test case<BR></DIV>
<DIV>Client
Server</DIV>
<DIV>|
| </DIV>
<DIV>| ---------------> | Solicit</DIV>
<DIV>|
| Server donnot response to Client</DIV>
<DIV>| ---------------> | Client-retransmitted Solicit<! /DIV>
<DIV>| <--------------- | Advertise (preference
= 255)</DIV>
<DIV>| ---------------> | Request</DIV>
<DIV> </DIV>
<DIV>
<DIV>(2)Specifications of RFC3315</DIV>
<DIV> </DIV>
<DIV> "If the client does not receive any Advertise messages
before the<BR> ! &n! bsp; first RT has elapsed, it begins the
retransm! ission mechanism<BR> described in section
14."</DIV>
<DIV> </DIV>
<DIV>(3) Explanation</DIV>
<DIV> </DIV>
<DIV> This is the test case including test of
First RT and Reaction of Advertise to
Retransmitted Solicit.</DIV>
<DIV> The judgement is the interval betw! een the
receptions of solicit and retransmitted solicit, should be between IRT
and IRT + RAND*IRT.</DIV>
<DIV> </DIV>
<DIV>(4)Limitation of test script</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV> No.</DIV>
<DIV></DIV>
<DIV>
<DIV></DIV>(5)Implementaion </DIV>
<DIV> ! ;</DIV>
<DIV> First RT = IRT + RAND*IRT RAND should be
larger than 0 and less than +RAND.</DIV>
<DIV> As recommended in RFC3315, First RT should be value
between 1sec and 1.1sec.</DIV>
<DIV>===================================================================================================</DIV>
<DIV> </DIV>
<DIV>Abov! e words are my understanding of Solicit
Retransmission and Acceptation of Advertise.</DIV>
<DIV>Base on those, the test scripts were written.</DIV>
<DIV> </DIV>
<DIV>What do you think about those?</DIV>
<DIV>If you find I is misunderstanding the specifications or you
have some advice, please ! contact me.</DIV>
<DIV>You will be appreciated very much.</DIV>
<DIV> </DIV>
<DIV>By the way, do you have used all of test scripts?</DIV>
<DIV> </DIV>
<DIV>Best regards,</DIV>
<DIV>zhang </DIV></DIV></DIV></DIV></DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi Zhang,</DIV>
<DIV> </DIV>!
<DIV>I have few more doubts on the following scripts....</DIV>
<DIV> </DIV>
<DIV>C_RFC3315_17_1_2_SolWaitAdv.seq</DIV>
<DIV>C_RFC3315_17_1_2_SolNoWaitAdv.seq</DIV>
<DIV>C_RFC3315_17_1_2_SolNoAdvRT.seq<!
! /DIV>
<DIV> </DIV>
<DIV>Here Its comparing the for the time periods.</DIV>
<DIV> </DIV>
<DIV>These 3 test cases are failing saying "Not in r! ight time
range!"</DIV>
<DIV> </DIV>
<DIV>I am sending first solicit message random time between 0-1
second, but stil they are failing.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit</DIV>
<DIV> </DIV>
<DIV><BR><BR><B><I>zhang <zhang@64translator.com></I></B>
wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><M!
ETA name="GENERAT! OR" content="MSHTML 6.00.2900.2769">
<DIV>Hi, Amit</DIV>
<DIV> </DIV>
<DIV> You are welcome.</DIV>
<DIV> And I appreciate your report.</DIV>
<DIV> If you have other problems! a! bout DHCPv6 client
test cases, please contact me.</DIV>
<DIV> </DIV>
<DIV>Best regards,</DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi Zhang,</DIV>
<DIV> </DIV>
<DIV>Th! anks for your support.</DIV>
<DIV> </DIV>
<DIV>I have tested "Transmit DHCP using Unicast Address", its
working fine. No bugs in that test script, that test case got
passed.</DIV>
<DIV> </DIV>
<DIV>You send the new test scripts for MRD after modification, i
will test and let you know t! he results.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit<BR><BR><B><I>zhang <zhang@64translator.com></I></B>
wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="M! SHTML 6.00.2900.2769"
name=GENERATOR>
<DIV>Hi, Amit </DIV>
<DIV> </DIV>
<DIV> First, thank you for your report.</DIV>
<DIV> </DIV>
<DIV> I am very sorry, It is a BUG.</DIV>
<DIV> ! ;! ; 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".</DIV>
<DIV> If the l! atter test is OK, this test can be
ignored.</DIV>
<DIV> And I have look into the source code,
and configuration of server address of ServerUnicast Option
is wrong. </DIV>
<DIV></DIV>
<DIV> And I have a question to you. Have you performed the
test of "Transmit DHCP u! sing Unicast Address".</DIV>
<DIV> I want to know the result of that test.</DIV>
<DIV></DIV>
<DIV> By the way, about fix of MRD, I think I
will finish them by this friday.</DIV>
<DIV> I am very sorry to have you wait.</DIV>
<DIV> </DIV>
<DIV> Thank you! .</DIV>
<DIV> </DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi zhang,</DIV>
<DIV> </DIV>
<DIV>I have one more doubt in client test cases.</DIV>
<DIV>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.<BR></DIV>
<DIV>When my cli! ent sends the renew msg to that address, its
saying Could not get Renew Message and gets failed.</DIV>
<DIV> </DIV>
<DIV>Please explain me this...</DIV>
<DIV> </DIV>
<DIV>Thanks and regards,</DIV>
<DIV>Amit</DIV>
<DIV> </DIV>
<DIV><BR><B><I>zhang <zhang@64translator.com></I></B>
wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR>
<DIV>Hi amit,</DIV>
<DIV> </DIV>
<DIV> Thank you very much for your
report.</DIV>
<DIV> </DI! V>
<DIV> Now I cannot draw a con! clusion from your
description.</DIV>
<DIV> Following words are just my deduction.</DIV>
<DIV></DIV>
<DIV> I think there may be ! ! the problem of
nut.def.</DIV>
<DIV> For example, if using Linux OS, the
Link0 will be set as following,</DIV>
<DIV> Link0 eth0
aa:bb:cc:dd:ee:ff </DIV>
<DIV> </DIV>
<DIV> From your description, the reason may be
that you use "LINK0" other than "Link0". </DIV>
<DIV> And so you cannot get the variable of
Link0_addr.</DIV>
<DIV> Can you try to examine that and the path
of nut.def ? </DIV>
<DIV> Or else, you can send your nut.def to
me.</DIV>
<DIV> </DIV>
<DIV> Thanks,</DIV>
<DIV> Best regards,</DIV>
<DIV>
Zhang </DIV>
<DIV> </DIV><DI! V>
<HR>
<DIV></DIV>
<DIV>Hi Zhang,</DIV>
<DIV> </DIV>
<DIV>I tried testing the "Use of upstream address when sends
DHCP message"</DIV><DI! V !>I even checked that the Nut.def file
has proper MAC address assigned for LINK0.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Could you please look int! o ! the same and tell me what to
do.</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit</D! IV>
<DIV> </DIV>
<DIV><BR><B><I>zhang <zhang@64translator.com></I></B>
wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR>
<DIV>Hi amit</DI! V>
<DIV> </DIV>
<DIV> ! You question makes me think more
about the test case. Thank you very much.</DIV>
<DIV> </DIV>
<DIV> Now I can reply to you.</DIV>
<DIV> </DIV>
<DIV> 1. Use of upstream address when sends D! HCP
message</DIV>
<DIV> </DIV>
<DIV> In RFC3633, " When a
requesting router sends a DHCP message, it SHOULD be sent
on<BR> the interface associated with the upstream
router (ISP network). The<BR> upstream
interface is typically determined by configurat! ion." is
decribed.</DIV>
<DIV> </DIV>
<DIV> ----I think this test is us! ed
to test the upstr! eam interface that the Requesting Router is
using.</DIV>
<DIV> It is a better way to u! ! se
Interface MAC address to determine whose interface(Link)
Requesting Router is using.</DIV>
<DIV> I am very sorry, there is some
inconsistenc! e between the test script and the test
specification.</DIV>
<DIV> I will change the test specification
to make them consistent.</DIV>
<DIV> By the way, when you test ,
please set Nut.def file, and set Link0 as your
upstre! am interface.</DIV>
<DIV> The test will check MAC address and
determine if It is Link0. It is the limitation.</DIV>
<DIV> </DIV>
<DIV> 2.About MRD test.</DIV>
<DIV> </DIV>
<DIV> ----I think my consideration is
not enough to these test cases.</DIV>
<DIV> I think they are BUGs.</DIV>
<DIV> And I am considering how to fix th! em.
I need some time! .</DIV>
<DIV> After fixing, I will contact you.</DIV>
<DIV></DIV>
<DIV> &! ;nbs! p; what about other test items? If you
have other questions, I will be glad to discuss them with
you.</DIV>
<DIV> </DIV>
<DIV>
<HR>
</DIV>
<DIV>Hi Zhang</DIV>
<DIV> </DIV>
<DIV>Tha! nks for your immediate response. I wil test with the
.seq file you have sent.</DIV>
<DIV> </DIV>
<DIV>I have two more doubts.</DIV>
<DIV>1> There are two test saying "Use of upstream address
when sends DHCP message".</DIV>
<DIV> I wanted to know what
exactly are these two test cases. Becauses these test cases
are failing giving an error as </DIV>
<DIV>"NUT Link MAC Address is
00:50:da:91:dd:ba<BR> Upstream Link number should be
Link0 ."</DIV>
<DIV> </DIV>
<DIV>In the script he is comparing the ! Ma! cAdrress with
some variable, i could not understand that...</DIV>
<DIV> </DIV>
<DIV>Plz tell me what we ne! ed to do exactly.</DIV>
<DIV> </DIV>
<DIV>2> Two test cases are to verify the MRD of Confirm
mess! age a! nd Rebind message.</DIV>
<DIV>What i am doing is, my DHCP client stops retransmitting
when the next retransmission time exceeds MRD of that
message.</DIV>
<DIV>But the scr! ipt stil waits for some more ti! me and he
compares two messages and say they are not same.</DIV>
<DIV> </DIV>
<DIV>Please clarify this doubt also...</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Regards,</DIV>
<DIV>Amit</DIV>
<DIV><BR><B><I>zhang <zhang@64translator.com></I></B>
wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2900.2769" name=GENERATOR>
<DIV>Hi, amit</DIV>
<DIV> </DIV>
<DIV> Thank you for your report.</DIV>
<DIV> </DIV>
<DIV> I am sure that this is a bug, and
I have fixed it.</DIV>
<DIV> We will fix this bug ! in next version.!
</DIV>
<DIV></DIV>
<DIV> I attach two files to this mail. </DIV>
<DIV>&nbs! p; You can use them to continue
your test.</DIV>
<DIV> </DIV>
<DIV> If you find some other problems, please
cont! act us.</DIV>
<DIV>
<HR>
! </DIV>
<DIV>Hi...</DIV>
<DIV> </DIV>
<DIV>I have implemented DHCPv6</DIV>
<DIV>I am testing my client and server using the tahi test
scripts.</DIV>
<DIV> </DIV>
<DIV>I have a doubt in one of the client script.</DIV>
<DIV> </DIV>
<DIV>The script is :
C_RFC3633_11_1_AdvWStatusCodeNoPrefixAvail.seq</DIV>
<DIV> </DIV>
<DIV>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".</DIV>
<DIV> </DIV>
<DIV>But while sending the reply message he is sending wrong
transaction ID.</D! IV>
<DIV> </! DIV>
<DIV>Can u plz clarify this...</DIV>
<DIV> ! ;</DIV>
<DIV>Thanks.</D! IV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Amit<BR><BR><B><I>dhcptest-admin@tahi.org</I></B>
wrote:</DIV>
<BLOCKQUOTE class=replbq
style="PADDING-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid; MAR: 5px">Cauti!
o! n: If you reply this mail, your reply will be sent to
the mailing list!<BR>post articles
<DHCPTEST@TAHI.ORG><BR>commands
<DHCPTEST-CTL@TAHI.ORG><BR>maintainer
<DHCPTEST-ADMIN@TAHI.ORG><BR><BR>Welcome to ! our mailing
list <DHCPTEST@TAHI.ORG>!<BR><BR>This mail contains the
fundamental usage of the mailing list server.<BR><BR>1 How
to use this server<BR><BR>Plaese send commands in the mail
body not subject to the
address<BR><DHCPTEST-CTL@TAHI.ORG>.<BR><BR>The command
syntax is as follows:<BR><BR>help<BR><BR>mget last:10
mp<BR><BR>Pla! es! e send the "help" to the address
<DHCPTEST-CTL@TAHI.ORG>for help and<BR>server functions
overview<BR><BR>help<BR><BR>to get general in! formation
on this list<BR><BR>guide<BR><BR>If you want to make a
contact w! ith the mailing list ma! intainer,
please<BR>e-mail
to<BR><BR>dhcptest-admin@tahi.org<BR><BR>ML server exists
to descrease routine works by maintainers. Please
try<BR>to use server functi! ons as co! uld as
possible.<BR><BR>dhcptest@tahi.org
Maintainer<BR>dhcptest-admin@tahi.org
<BR><BR><BR></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India
Matrimony</A>: Find your partner now.
<HR>
</DIV></DIV></DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>:
Find your partner now.
<HR>
</DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>:
Find your partner now.
<HR>
</DIV></DIV></BLOCKQUO! TE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>:
Find your partner now.
<HR>
</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></DIV></DIV></DIV></DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yaho! o! India Matrimony</A>: Find
your partner now.
<HR>
</DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>: Find your
partner now.
<HR>
</BLOCKQ! UOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>: Find your
partner now.
<HR>
</DIV></DIV></DIV></DIV></DIV></BLOCKQUOTE>
<DIV></DIV></BLOCKQUOTE>
<BLOCKQUOTE></BLOCKQUOTE>
<DIV></DIV></BLOCKQUOT! E>
<DIV><BR></DIV>
<DIV></DIV>
<BLOCKQUOTE></BLOCKQUOTE>
<DIV></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>: Find your
partner now.
<HR>
<BLOCKQUOTE></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com/">Yahoo! India Matrimony</A>: Find your
partner now. <!
HR></DIV>
<BLOCKQUOTE></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Send instant messages to your online friends
http://in.messenger.yahoo.com
<HR>
</DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV>
<P>Send instant messages to your online friends http://in.messenger.yahoo.com
<HR>
</BODY></HTML>