Hi Nicholas,
I may have sent the mail too soon .The patch is showing regression in
other areas.
Covering section (RFC 3720 5.3.3) which says,
-------------<snip>--------------------
If the target responds to a Login Request that has the T bit set to 1
with a Login Response that has the T bit set to 0, the initiator
should keep sending the Login Request (even empty) with the T bit set
to 1, while it still wants to switch stage, until it receives the
Login Response that has the T bit set to 1 or it receives a key that
requires it to set the T bit to 0.
-------------<snip>--------------------
On 5/28/2014 2:12 PM, Tejas Vaykole wrote:
Hi Nicholas,
On 5/28/2014 2:35 AM, Nicholas A. Bellinger wrote:
On Mon, 2014-05-26 at 11:47 +0530, Tejas Vaykole wrote:
Hi ,
I'm looking for help in understanding the CHAP authentication
(Non
Mutual) behavior of LIO Target.
I am sending a the login request in following order-
I-> T : Login request with TargetName,InitiatorName,AuthMethod=CHAP.
T-> I : AuthMethod=CHAP. TargetAlias=LIO Target,TargetProtalGroup=1
I ->T : Login request with CHAP_A=5
T ->I : CHAP_A=5,CHAP_I=X ,CHAP_C="<some challenge>"
I ->T : Login request with No parameters, Tbit=1,CSG bit =0, NSG bit =3
T ->I : Success.
According to the RFC3270 clause section 8.2. I am expecting a login
reject for a last Login request (forced transit to Full Feature Phase )
but the Target sends a success.
RFC 3720: Section 8.2
----------------------<snip>-----------------------
"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."
---------------------<snip>------------------------
If I check the dmesg, it shows Login Failed. I have also attached the
pcap for the same.
Am I looking at an error in LIO CHAP implementation? I am expecting a
initiator Error at this point However still maintains its state at
Security negotiation.
Your comment Please.
So it's the zero-length payload that is causing the target to send a
response with CSG=0,T=0, requesting that the initiator complete the
security negotiation phase.
However, I do agree that the login should be failed at this point..
Here's a quick patch to return INITIATOR_ERR for the zero-length
security payload case, otherwise for the non zero length payload case
the existing logic should hit a failure while processing parameter keys.
Please test.
I have tested the patch you have given.
i have attached the pcap for this test.The patch is working fine.
dmesg output -
[root@root test_suite_iscsi]# dmesg -c
[ 1903.548513] Initiator sent zero length security payload
[ 1903.548525] iSCSI Login negotiation failed.
--nab
diff --git a/drivers/target/iscsi/iscsi_target_nego.c
b/drivers/target/iscsi/iscsi_target_neg
index 75b6859..49f77c9 100644
--- a/drivers/target/iscsi/iscsi_target_nego.c
+++ b/drivers/target/iscsi/iscsi_target_nego.c
@@ -773,6 +773,11 @@ static int iscsi_target_handle_csg_zero(
}
goto do_auth;
+ } else if (!payload_length) {
+ pr_err("Initiator sent zero length security payload\n");
+ iscsit_tx_login_rsp(conn,
ISCSI_STATUS_CLS_INITIATOR_ERR,
+ ISCSI_LOGIN_STATUS_AUTH_FAILED);
+ return -1;
}
if (login->first_request)
--
Thanks and regards.
Tejas Vaykole
Development Engineer.
Calsoft Inc.|Ext- 3169
--
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
