Hi Rahul, On Thu, 2014-06-05 at 15:37 +0530, rahul.rane wrote: > Hi, > RFC 3720 Clause 11.1.4 says that the iSCSI target is expected to send a > Login reject when it receives the CHAP_A value out of order > So with Tejas's (CC'ed) updated patch in place to support CHAP_A values as a comma separated list, this particular test will now error out if CHAP_A is not the first key=value received. For reference, that patch queued for v3.16-rc1 is here: iscsi-target: Fix CHAP_A parameter list handling https://git.kernel.org/cgit/linux/kernel/git/nab/target-pending.git/commit/?h=for-next&id=3160723c49605965628c3ee7699e5e956c4f8f51 > However ,i find that LIO is accepting the out of order CHAP_A and sends > a Login success which is an error. Similarly same issues are found for > out of order CHAP_N,CHAP_I,and CHAP_C. > So by 'out of order' I assume you mean sending CHAP_X keys in the wrong step definition, right..? That is, I don't think there is a requirement to ensure CHAP_X keys are in a particular order, as long as they are received in the correct step definition. > please find the attachment for pcap. > > RFC 3720 Clause 11.1.4 > ----------<snip>----------- > For CHAP, in the first step, the initiator MUST use: CHAP_A=A1,A2; where > A1,A2... are proposed algorithms, in order of preference. > The target MUST answer with a Login reject with the "Authentication > Failure" > ----------<snip>----------- > The question is what happens when a CHAP_X key is received in the wrong step definition..? Today, as long as the expected CHAP_X key(s) are received in a specific step definition, all other keys not associated with the step definition are ignored. Based upon the wording in Section 8.2: Whenever an iSCSI target gets a response whose keys, or their values, are not according to the step definition, it MUST answer with a Login reject with the "Initiator Error" or "Missing Parameter" status. what needs to happen is once the expected CHAP_X keys are received and complete the step definition, any other key=value pairs will automatically trigger a authentication failure. I need to think a bit more about how that patch should look, but please expect something to test over the next days. Thanks! --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
