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