Hi Arshad,
On Wed, 2014-05-21 at 14:23 +0530, Arshad Hussain wrote:
> Hi Nab,
>
> This is with reference to RFC 3720 section 10.18. Which stats that the
> unsolicited NOP-in from target as ping should contain valid TTT and this
> should be carried on to NOP-Out. However, I do not see this is
> happening.
Looking at packet #10 in the capture:
iSCSI (NOP In)
Opcode: NOP In (0x20)
TotalAHSLength: 0x00
DataSegmentLength: 0x00000000
LUN: 0000000000000000
InitiatorTaskTag: 0xffffffff
TargetTransferTag: 0x00000041
StatSN: 0x0dc061cc
ExpCmdSN: 0x00000042
MaxCmdSN: 0x00000081
The outgoing NopIN PDU from the target does contain a valid TTT +
reserved ITT, as expected for a NOPIN that wants to solicit a NOPOUT
ping from the initiator.
> The NOP-out is holding the TTT of 0xFFFFFFFF instead of a
> valid TTT. This looks like RFC break in LIO? Please comment.
>
> 10.18. NOP-Out
>
> <SNIP>
>
> Upon receipt of a NOP-In with the Target Transfer Tag set to a valid
> value (not the reserved 0xffffffff), the initiator MUST respond with
> a NOP-Out. In this case, the NOP-Out Target Transfer Tag MUST
> contain a copy of the NOP-In Target Transfer Tag.
>
> I have attached pcap. The concerning frames are 10 and 11.
>
>From there, the NOPOUT ping on the initiator side is incorrect:
iSCSI (NOP Out)
Opcode: NOP Out (0x00)
.0.. .... = I: Queued delivery
TotalAHSLength: 0x00
DataSegmentLength: 0x00000000
LUN: 0000000000000000
InitiatorTaskTag: 0x00000014
TargetTransferTag: 0xffffffff
CmdSN: 0x00000000
ExpStatSN: 0x00000000
where the TTT is not echoed from the received NOPIN's TTT, and also
contains a non reserved ITT value.
--nab
--
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
