Hi Christophe, 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? > 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
