Dissecting packet dump between HP-UX iSCSI initiator and

Albert Chin t10 at mlists.thewrittenword.com
Mon Jul 7 14:56:24 PDT 2008


* 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



More information about the T10 mailing list