Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
[iscsi] Clarify support for NOP-In
After a more accurate reading of RFC 3720, it becomes clear how NOPs
are supposed to work.  The current implementation (which just ignores
NOP-Ins) is sufficient to cope with NOP-Ins sent to update CmdSN, but
will need to be extended before it can cope with NOP-Ins sent as iSCSI
keepalives.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
  • Loading branch information
mcb30 committed Feb 25, 2011
1 parent 9625132 commit ef87c4a
Showing 1 changed file with 9 additions and 24 deletions.
33 changes: 9 additions & 24 deletions src/net/tcp/iscsi.c
Expand Up @@ -99,6 +99,10 @@ FEATURE ( FEATURE_PROTOCOL, "iSCSI", DHCP_EB_FEATURE_ISCSI, 1 );
__einfo_error ( EINFO_ENOTSUP_TARGET_STATUS )
#define EINFO_ENOTSUP_TARGET_STATUS \
__einfo_uniqify ( EINFO_ENOTSUP, 0x04, "Unsupported target status" )
#define ENOTSUP_NOP_IN \
__einfo_error ( EINFO_ENOTSUP_NOP_IN )
#define EINFO_ENOTSUP_NOP_IN \
__einfo_uniqify ( EINFO_ENOTSUP, 0x05, "Unsupported NOP-In received" )
#define EPERM_INITIATOR_AUTHENTICATION \
__einfo_error ( EINFO_EPERM_INITIATOR_AUTHENTICATION )
#define EINFO_EPERM_INITIATOR_AUTHENTICATION \
Expand All @@ -123,10 +127,6 @@ FEATURE ( FEATURE_PROTOCOL, "iSCSI", DHCP_EB_FEATURE_ISCSI, 1 );
__einfo_error ( EINFO_EPROTO_INVALID_CHAP_RESPONSE )
#define EINFO_EPROTO_INVALID_CHAP_RESPONSE \
__einfo_uniqify ( EINFO_EPROTO, 0x04, "Invalid CHAP response" )
#define EPROTO_INVALID_NOP_IN \
__einfo_error ( EINFO_EPROTO_INVALID_NOP_IN )
#define EINFO_EPROTO_INVALID_NOP_IN \
__einfo_uniqify ( EINFO_EPROTO, 0x05, "Invalid NOP-In received" )

/** iSCSI initiator name (explicitly specified) */
static char *iscsi_explicit_initiator_iqn;
Expand Down Expand Up @@ -609,29 +609,14 @@ static int iscsi_rx_nop_in ( struct iscsi_session *iscsi,

DBGC2 ( iscsi, "iSCSI %p received NOP-In\n", iscsi );

/* RFC 3720 section 10.19 states that "when a target sends a
* NOP-In that is not a response to a Nop-Out received from
* the initiator, the Initiator Task Tag MUST be set to
* 0xffffffff", and section 10.18 states that "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". Since we never send unsolicited NOP-Outs,
* my reading of this is that we can handle all permitted
* NOP-Ins (which must have TTT set to 0xffffffff) by simply
* ignoring them.
*
* There is some ambiguity in the RFC, since there are other
* places that suggest that a target is supposed to be able to
* send an unsolicited NOP-In and expect a NOP-Out response.
* We catch any apparent attempts to use this immediately, so
* that the relevant error gets reported to the iPXE user,
* rather than just having the target drop the connection when
* it times out waiting for the NOP-Out response.
/* We don't currently have the ability to respond to NOP-Ins
* sent as ping requests, but we can happily accept NOP-Ins
* sent merely to update CmdSN.
*/
if ( nop_in->ttt != htonl ( ISCSI_TAG_RESERVED ) ) {
DBGC ( iscsi, "iSCSI %p received invalid NOP-In with TTT "
DBGC ( iscsi, "iSCSI %p received unsupported NOP-In with TTT "
"%08x\n", iscsi, ntohl ( nop_in->ttt ) );
return -EPROTO_INVALID_NOP_IN;
return -ENOTSUP_NOP_IN;
}

return 0;
Expand Down

0 comments on commit ef87c4a

Please sign in to comment.