Dissecting packet dump between HP-UX iSCSI initiator and
Black_David at emc.com
Black_David at emc.com
Tue Jul 8 12:33:53 PDT 2008
* From the T10 Reflector (t10 at t10.org), posted by:
* Black_David at emc.com
*
This looks like a fairly simple problem. According to SPC-3, Appendix
D.2, an ASC of 20h/09h means "ACCESS DENIED - INVALID LU IDENTIFIER".
It looks like only LUN 0 exists at the target, but the initiator
tried other LUNs for some reason, and got this check condition on
every non-zero LUN. I suggest examining what the results of the
REPORT LUNS command were and how those results were handled at the
initiator.
This list is not a good place to debug implementations in this fashion.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david at emc.com Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf
> Of Albert Chin
> Sent: Monday, July 07, 2008 5:56 PM
> To: t10 at t10.org
> Subject: Dissecting packet dump between HP-UX iSCSI initiator and
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Albert Chin <t10 at mlists.thewrittenword.com>
> *
> We've had some problem connecting the HP-UX 11.23/IA iSCSI
> initiator to
> the OpenSolaris b91 iSCSI target. The first problem was that
> in response
> to the HP-UX iSCSI initiator SendTargets=All command, the
> Solaris iSCSI
> target would respond with:
>
> TargetName=iqn.1986-03.com.sun:02:d0774d84-2a4a-6f8d-ee11-da6fcfd0e481
> TargetAddress=192.168.1.15,1
> when what the HP-UX iSCSI initiator wanted (and failed otherwise) was:
>
> TargetName=iqn.1986-03.com.sun:02:d0774d84-2a4a-6f8d-ee11-da6fcfd0e481
> TargetAddress=192.168.1.15:3260,1
> That is, the HP-UX iSCSI initiator wanted the iSCSI port number in the
> TargetAddress response. We fixed that by allowing the Solaris iSCSI
> target to return the iSCSI port in the TargetAddress response.
>
> The second problem is that when running the HP-UX "ioscan -H 255"
> command to resolve the devices on the target, rather than running in
> <20s, it takes 4m to run. We've created a packet dump of the
> communication between both hosts and posted it to:
> ftp://support.thewrittenword.com/outgoing/ioscan-snoop
>
> Based on what we see:
> (initiator) SCSI: Inquiry LUN: 0x00
> (target) SCSI: Data in LUN: 0x00 (Inquriy Response Data)
> (target) SCSI: Response LUN: 0x00 (Inquriy) (Good)
> (initiator) SCSI: Report LUNs LUN: 0x00
> (target) SCSI: Data in LUN: 0x00 (Report LUNs Response Data)
> SCSI: Response LUN: 0x00 (Report LUNs)
> (initiator) SCSI: Inquiry LUN: 0x00
> (target) SCSI: Data in LUN: 0x00 (Inquriy Response Data)
> (target) SCSI: Response LUN: 0x00 (Inquriy) (Good)
> ...
> (initiator) SCSI: Inquiry LUN: 0x01
> (target) SCSI Response (Check Condition) LUN:0x01
> The Wireshark dump of this response is:
> iSCSI (SCSI Response)
> Opcode: SCSI Response (0x21)
> Flags: 0x82
> ...0 .... = o: No overflow of read part of
> bi-directional command
> .... 0... = u: No underflow of read part of
> bi-directional command
> .... .0.. = O: No residual overflow occurred
> .... ..1. = U: Residual underflow occurred
> Response: Command completed at target (0x00)
> Status: Check Condition (0x02)
> TotalAHSLength: 0x00
> DataSegmentLength: 0x00000016
> InitiatorTaskTag: 0x01a402fe
> StatSN: 0x00000009
> ExpCmdSN: 0x00000009
> MaxCmdSN: 0x00000047
> ExpDataSN: 0x00000000
> BidiReadResidualCount: 0x00000000
> ResidualCount: 0x00000000
> Request in: 78
> Time from request: 0.000085000 seconds
> SenseLength: 0x0014
> SCSI: SNS Info
> [LUN: 0x0001]
> Valid: 0
> .111 0000 = SNS Error Type: Current Error (0x70)
> Filemark: 0, EOM: 0, ILI: 0
> .... 0101 = Sense Key: Illegal Request (0x05)
> Sense Info: 0x00000000
> Additional Sense Length: 0
> Command-Specific Information: 00000000
> Additional Sense Code+Qualifier: Unknown (0x2009)
> Field Replaceable Unit Code: 0x00
> .. = SKSV: False
> Sense Key Specific: 000000
> (initiator) SCSI: Inquiry LUN: 0x02
> (target) SCSI Response (Check Condition) LUN:0x02
> Wireshark dump of this response is the same as for LUN:0x01
> (initiator) SCSI: Inquiry LUN: 0x03
> (target) SCSI Response (Check Condition) LUN:0x03
> Wireshark dump of this response is the same as for LUN:0x01
> ...
>
> According to table 27 of spc3r21c.pdf, it defines 0x05,
> Illegal Request,
> as:
> ILLEGAL REQUEST: Indicates that:
> a) The command was addressed to an incorrect logical unit number
> (see SAM-3);
> b) The command had an invalid task attribute (see SAM-3);
> c) The command was addressed to a logical unit whose current
> configuration prohibits processing the command;
> d) There was an illegal parameter in the CDB; or
> e) There was an illegal parameter in the additional parameters
> supplied as data for some commands (e.g., PERSISTENT RESERVE
> OUT).
> If the device server detects an invalid parameter in the
> CDB, it shall
> terminate the command without altering the medium. If the
> device server
> detects an invalid parameter in the additional parameters
> supplied as
> data, the device server may have already altered the medium.
> and from spc3r23.pdf:
> (6.4)
> In response to an INQUIRY command received by an incorrect logical
> unit, the SCSI target device shall return the INQUIRY
> data with the
> peripheral qualifier set to the value defined in 6.4.2.
> The INQUIRY
> command shall return CHECK CONDITION status only when the device
> server is unable to return the requested INQUIRY data.
> ...
> (6.4.2)
> ...
> The PERIPHERAL QUALIFIER field and PERIPHERAL DEVICE TYPE field
> identify the peripheral device connected to the logical unit. If
> the SCSI target device is not capable of supporting a peripheral
> device connected to this logical unit, the device server shall set
> these fields to 7Fh (i.e., PERIPHERAL QUALIFIER field set to 011b
> and PERIPHERAL DEVICE TYPE field set to 1Fh).
>
> I don't know if this post is on-topic but can someone comment
> on whether
> or not the HP-UX iSCSI initiator is wrong or whether or not
> the Solaris
> iSCSI Target is wrong?
>
> --
> albert chin (china at thewrittenword.com)
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
More information about the T10
mailing list