Hi, Mr. Volz,
Thanks for your feedback.
They are very important to me.
Now I have begun fixing these bugs.
But something you said is not very clear to me.
Please confirm them.
Thanks a lot!
> 3. I fail to see what is invalid about the RENEW message in
> S_RFC3315_18.2.3_DiscardReceiptRenewMsg.seq?
In this test case it is hoped to check whether the RENEW message
via unicast is processed rightly. (Reply with StatusCode:UseMulticast )
> 2. For S_RFC3315_15_DiscardSolicitwithInvalidOP.seq,
> S_RFC3315_15_DiscardRenewwithInvalidOP.seq, and
> S_RFC3315_15_DiscardDeclinewithInvalidOP.seq,
> S_RFC3315_15_DiscardReleasewithInvalidOP.seq,
> S_RFC3315_15.10_ClientIDOPMatch.seq, I see nothing in RFC
> 3315 that would require a server to do anything to check for
> the existance of the Preference Option from a client and drop
> the packet. While the Preference Option is only used in
> server messages to clients, there is no real harm in a client
> including it and a properly implemented server would IGNORE
> unknown options.
> Note that this is different from the Server Identifier Option
> I mentioned for other tests cases - the Solicit, Confirm, and
> Rebind messages are specially designed to be sent to *ALL*
> servers, not just one. Hence, there are valid reasons why a
> server that receives one of these messages should detect the
> inclusion of this option and consider the message invalid.
> Also, section 15 of RFC 3315 specifically indicates these checks.
I think your meaning is that is not necessory to check the Preference
Option in the Client message. So the NUT(server) can send a reply
to the client if it receive a message include Preference Option.
That is, the server should IGNORE the message from client with
Preference. Or other option like "Server Unicast option".
I only want to check whether the server discard a message from client inlcude
invalid option in these test scripts.
At RFC3315 p98,line 5443,there is a table of allowed options in DHCP
messages. And p27,line 1500, the RFC3315 said,"Clients and servers
SHOULD discard any messages that contain options that are not allowed
to appear in the received message".
Based them I think a Solicit message with Preference option should be
discard by server.
Is my understanding right?
> 5. In S_RFC3315_22.13_StatusCodeOP.seq, the following message
> is sent and the expected response is a Reply with a Status
> Code option? Why?
> What's wrong with this request? Is the absense of an IAADDR
> option in the IA_NA option supposed to generate an error? If
> so, this is mistaken as I don't see that an IAADDR option is required.
>
> Or, is there something I missed in this test sequence
> (SOLICIT/ADVERTISE/REQUEST/REPLY)?
>
> R10: ----- RECEIVED -- R10 -----
> R10: -> received 56 bytes from fe80::200:ff:fe00:a2a2, port 1027
> R10: -> +- Start of REQUEST (3) message (56 bytes)
> R10: -> | transaction-id 101
> R10: -> | client-identifier (1) option (14 bytes)
> R10: -> | 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2
> R10: -> | server-identifier (2) option (14 bytes)
> R10: -> | 00:01:00:01:43:b2:b2:e5:00:03:ba:6c:9f:b9
> R10: -> | ia-na (3) option (12 bytes)
> R10: -> | (iaid 101010, t1 1h6m40s, t2 1h23m20s)
> R10: -> +- End of REQUEST message
> R10: ----- END OF RECEIVED -- R10 -----
The expected test result of it is check the format of status code option.
Would you show me the log file of this test item.
I guess it is same as the problem 4. That is, the the test expects the
Status Code option to be in the main part of the Reply. I plan to change
it and let it accept both "in IA option" and "in main part".
> 6. None of the relay tests appear to be working for me.
> I notice that the client requests are coming from and being
> sent to fe80::200:ff:fe00:a2a2, which works fine. However,
> the relay requests are coming from fe80::200:ff:fe00:a4a4 and
> this does not work (ie, replies aren't received). I am
> running on FreeBSD 6.0? Perhaps I missed up something in the setup?
Would you like show me logs file of them. Thanks.
I think the other items in your email are bugs of the current scripts.
I have begun to fix them.
I expected your reply.
Thanks a lot!
Sincerely yours,
Haoda