<!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 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
specifications 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> | ------------ > | Request (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 are 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 upstream 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> 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. The 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
Option but he prints a Message saying send Confirm Message on Screen. Please
look into the same and 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> </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 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> - 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 because 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>Please 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.</DIV>
<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> </DIV>
<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 Sending 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 the 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 Request, 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> 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 between 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 about 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 the 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 using 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>
<DIV>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 DHCP
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 use 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 upstream
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> 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 message
and 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> 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.</DIV>
<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 with the
mailing list maintainer, 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></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></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></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></BLOCKQUOTE></DIV></DIV></BLOCKQUOTE>
<DIV><BR></DIV></BLOCKQUOTE></DIV>
<P>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com">Yahoo! India Matrimony</A>: Find your partner
now.
<HR>
</BODY></HTML>