Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 633122

Summary: Ensure that the itt is the same for all requests within sequence.
Product: Red Hat Enterprise Linux 5 Reporter: Wade Mealing <wmealing>
Component: iscsi-initiator-utilsAssignee: Mike Christie <mchristi>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: medium Docs Contact:
Priority: low    
Version: 5.6CC: bdonahue, coughlan, ltroan, mchristi, syeghiay, tao
Target Milestone: rc   
Target Release: 5.6   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: iscsi-initiator-utils-6.2.0.872-2.el5 Doc Type: Bug Fix
Doc Text:
When encountering a multi-PDU sequence, the open-iscsi administration utility (iscsiadm) sent incorrect initiator task tags (ITT), causing the discovery to fail. With this update, the ITT initialization and allocation sends the correct tags, and iscsiadm works as expected.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-13 22:59:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch with fix. none

Description Wade Mealing 2010-09-13 02:16:34 UTC
Description of problem:

If ISCSI target has long target information and the sendtarget response from the target exceeds the receive buffer size of the initiator.

RFC3720 states that the Initiator Task Tag(ITT) MUST be same for all the requests within a sequence.  However, in the second text command sent from the initiator, ITT is incremented and has a different value from the first command.

Version-Release number of selected component (if applicable):

iscsi-initiator-utils-6.2.0.871-0.16.el5 (RHEL5.5)

How reproducible:

Every time

Steps to Reproduce:

We have created a reproducer using Linux iscsi target.  The Linux iscsi target does not actually reject the target discovery, but it is possible to see that the initiator is sending a request that violates RFC3720.

1. Prepare the iscsi initiator machine
  #yum install iscsi-initiator-utils
  #service iscsi start

2. Prepare the iscsi target machine
  #yum install scsi-target-utils
  #vi /etc/tgt/targets.conf
  Set target information to exceed 32768 Bytes as follows.
  ---
  <target iqn.2010-08.com.example:10000000000000000000000005000000000600000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000001>
   backing-store /data/tgt001.img
  </target>
  <target iqn.2010-08.com.example:20000000000000000000000005000000000600000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000002>
   backing-store /data/tgt002.img
  </target>
  ...
  <target iqn.2010-08.com.example:49900000000000000000000005000000000600000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000499>
   backing-store /data/tgt499.img
  </target>
  <target iqn.2010-08.com.example:50000000000000000000000005000000000600000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000500>
   backing-store /data/tgt500.img
  </target>
  ---
  #service tgtd restart

3. Start network packet capturing on the iscsi initiator machine
 #tcpdump -s 0 -n host "target IP" -w discovery.pcap

4. Run the target discovery on the iscsi initiator machine
 #iscsiadm -m discovery -t st -p "target IP"

5. Check the captured packets
 Investigate discovery.pcap using packet analyzers such as Wireshark.
  
Actual results:

Iscsi target discovery is completed while the ITT value increases in sequence.

Expected results:

RFC3720 states that the Initiator Task Tag(ITT) MUST be same for all the requests within a sequence.  However, in the second text command sent from the initiator, ITT is incremented and has a different value from the first command.

Additional info:

There is a reproducer configured with a Linux iscsi target.  The Linux iscsi target does not actually reject the target discovery, but it is possible to see that the initiator is sending a request that violates RFC3720.

The problems occur during installation time if the ISCI target does reject the  initiator due to lax RFC3720 compliance in its ITT values.

A similar problem / solution in BZ#197248 was found, although this can't be set during installation time.

Comment 2 Wade Mealing 2010-09-13 02:35:07 UTC
Created attachment 446822 [details]
patch with fix.

Comment 8 Mike Christie 2010-09-25 08:50:30 UTC
This is fixed in 
iscsi-initiator-utils-6.2.0.872-2.el5.
It can be downloaded here:
http://people.redhat.com/mchristi/iscsi/rhel5.6/iscsi-initiator-utils/

Comment 11 Jaromir Hradilek 2010-12-08 10:57:48 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When encountering a multi-PDU sequence, the open-iscsi administration utility (iscsiadm) sent incorrect initiator task tags (ITT), causing the discovery to fail. With this update, the ITT initialization and allocation sends the correct tags, and iscsiadm works as expected.

Comment 13 errata-xmlrpc 2011-01-13 22:59:07 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0072.html