Hi,Mr. Amit,
Thanks for your comment.
>1.
> S_RFC3315_18.2.2_ReceiptConfirmMsgIgnore.seq
> In the above test script, it is said that T1,T2,preferered lifetime and valid lifetime
> in IA_NA option of the reply for confirm messages should be same
> (i.e. values in >reply1 and reply2 must be same). But, the script compares the
> values in reply with the confirm message itself. Could you please look into this
> and comment.
> We are sending the logs for these in 1.zip
I think the meaning of "Server ignore it" is the server don't process it and return it
back directly. So the IA_* option in Confirm & Reply will be same.
In your test log, the time has assigned a new value. They are same as the result of Request/Reply.
Does it means your server process it?
Please notice one point, that is your IA_address option is in the main part of
the Reply message. I think it must in the IA_* option according the RFC3315.
" B Appearance of Options in the Option field of DHCP Options."
> 2.
> S_RFC3633_10_IAPDPreOPLifetime.seq
> S_RFC3633_10_IgnoreLifetime.seq
> T! he above scripts test the values of T1, T2 and lifetimes being kept as the original
> values. We are doing the same i.e. the values in reply is same as that in advertisement
> but still these tests are getting failed. Please check the same
> We are sending the logs for these in 2.zip
The 2 test items are same, so there is only one item in the next version.
Only the S_RFC3633_10_IgnoreLifetime.seq is be kept.Please skip the first one.
And we had update it. (for the next version)
Please use the new files, they are more clear.
In this test, NUT will ignore the preferred lifetimes and T1, T2. the value of preferred lifetimes and
T1, T2 is keep the original value as Advertise message.
In fact, in our script, we send a invalid packet to NUT to test whether it has been ignored by the server.
> 3.
> S_RFC3736_5.1_SLDHCPRelayreply.seq
> S_RFC3736_5.2_SLDHCPInterID.seq
> S_RFC3736_5.2_SLDHCPRelaySvr.seq
> In the above test scripts we are framing the relay-reply message and sending it to
> 3ffe:501:ffff:100:200:ff:fe00:a4a4, but this address is not getting reflected. i.e. NS is
> being sent to resolve this address and no NA is got.
> We are sending the logs for these in 3.zip
I think the test don't need to assign Global address to the NUT. The NS send by NUT is
using a global-address in your log file.(3ffe:501:ffff:100::a1a1)
Best regard yours,
Haoda
attatchment (application/octet-stream) ignored(encoded)
attatchment (application/octet-stream) ignored(encoded)