(Responding again, as target-devel seemed to drop the last email)
On Tue, 2014-06-17 at 13:41 +0200, Christophe Vu-Brugier wrote:
> I am testing the LIO iSCSI target with the Windows Certification Kit
> and I observe that the CHAP tests (one-way and mutual) fail and that
> one of the failures is caused by a regression since linux v3.10. The
> one-way CHAP test performs the following checks:
>
> 1/ valid response is returned using hexadecimal encoding
> 2/ valid response is returned using base64 encoding
> 3/ invalid response is returned using hexadecimal encoding
> 4/ invalid response is returned using base64 encoding
>
> I expect the base64 tests to fail since there is no support for base64
> encoded CHAP responses in LIO. My problem is with the third test
> "invalid response with hexadecimal encoding": the Windows
> Certification Kit displays the following error:
>
> Failed to receive the next login response PDU from the target
>
> I observed that this test works with Linux v3.9 so I ran a bisection
> between v3.9 and v3.10. Here are the results:
>
> # good: [3f99306] iscsi-target: Add iscsit_transport API template
> git bisect good 3f99306337ba1871afc8568e8b36004ce3cee039
> # only skipped commits left to test
> # possible first bad commit: [cdb7266] iscsi-target: Add per transport iscsi_cmd alloc/free
> # possible first bad commit: [03aa207] iscsi-target: Add iser-target parameter keys + setup during login
> # possible first bad commit: [baa4d64] iscsi-target: Initial traditional TCP conversion to iscsit_transport
>
> I skipped some commits because I got compilation errors with them. So
> now, I have an indication of when the regression was introduced but I
> did not manage to determine where the error is precisely in the code.
>
> I ran network captures with `tcpdump` that you will find attached. The
> "whql-chap-invalid-resp-hexa*" PCAP files are shorter versions of the
> two other PCAP files and contain only the packets sent during the
> "invalid response with hexadecimal encoding" test. The target is
> 192.168.3.81 and the initiator is 192.168.3.88.
>
> In the network dumps, I observe that packet 8 is correctly decoded as
> "Login Response (Authentication failed)" in the v3.9 trace but not in
> the v3.15 trace.
>
> Do you have any clue about this issue? Or maybe suggestions on how I
> can further investigate this bug?
>
> Best regards,
Thanks for the detailed bug-report.
So looking at this, it appears the issue involves the login response PDU
containing the exception status class / detail is not being explicitly
cleared in >= v3.10 code.
The following patch addresses the issue on my end, and correctly reports
the 'iSCSI login failed due to authorization failure' to the initiator.
Please confirm on your side.
--nab
diff --git a/drivers/target/iscsi/iscsi_target_util.c b/drivers/target/iscsi/iscsi_target_util.c
index 53e157c..fd90b28 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -1295,6 +1295,8 @@ int iscsit_tx_login_rsp(struct iscsi_conn *conn, u8 status_class, u8 status_deta
login->login_failed = 1;
iscsit_collect_login_stats(conn, status_class, status_detail);
+ memset(&login->rsp[0], 0, ISCSI_HDR_LEN);
+
hdr = (struct iscsi_login_rsp *)&login->rsp[0];
hdr->opcode = ISCSI_OP_LOGIN_RSP;
hdr->status_class = status_class;
--
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
