<!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 report.</DIV>
<DIV> After reading your Email, I think you want to let me confirm
the following 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
message 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,</DIV>
<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 network 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 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 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> 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="GENERATOR" 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> </DIV>
<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 into ! 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
configuration." 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
he ! 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>Plaes! 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></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>
</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>
<P>
<HR SIZE=1>
<A href="http://yahoo.shaadi.com">Yahoo! India Matrimony</A>: Find your
partner now.
<HR>
</DIV></BLOCKQUOTE></BODY></HTML>