[iscsi-initiator-utils: 87/109] Resolves: #740054 #790609 #636013
Chris Leech
cleech at fedoraproject.org
Tue Dec 10 21:26:37 UTC 2013
commit cfcc31b53431e4acf46066ba2589ccf6e4010847
Author: Mike Christie <michaelc at cs.wisc.edu>
Date: Tue Mar 6 05:28:28 2012 -0600
Resolves: #740054 #790609 #636013
iscsi-initiator-utils-add-libiscsi.patch | 104 +-
iscsi-initiator-utils-add-rh-ver.patch | 2 +-
iscsi-initiator-utils-brcm-man.patch | 19 -
iscsi-initiator-utils-dont-sync-kern-sess.patch | 57 -
iscsi-initiator-utils-dont-use-openssl.patch | 47 -
iscsi-initiator-utils-fix-default-bindings.patch | 172 -
iscsi-initiator-utils-fix-iscsiadm-return.patch | 13 -
iscsi-initiator-utils-fix-nlmsglen.patch | 12 -
iscsi-initiator-utils-fix-readme-imode.patch | 12 -
iscsi-initiator-utils-iscsistart-param.patch | 207 -
iscsi-initiator-utils-ofl-iface-fixes.patch | 471 -
iscsi-initiator-utils-ping-and-chap.patch | 1141 +
iscsi-initiator-utils-return-on-exists.patch | 22 -
iscsi-initiator-utils-sync-iscsi.patch |29952 +++++++++++++++++++-
iscsi-initiator-utils-sync-uio-0.7.0.14.patch | 371 -
iscsi-initiator-utils-sync-uio-0.7.0.14g.patch | 1486 -
...=> iscsi-initiator-utils-sync-uio-0.7.2.1.patch | 1803 +-
iscsi-initiator-utils-uip-mgmt.patch | 100 +-
iscsi-initiator-utils.spec | 75 +-
19 files changed, 31456 insertions(+), 4610 deletions(-)
---
diff --git a/iscsi-initiator-utils-add-libiscsi.patch b/iscsi-initiator-utils-add-libiscsi.patch
index 4b0e16e..83fb229 100644
--- a/iscsi-initiator-utils-add-libiscsi.patch
+++ b/iscsi-initiator-utils-add-libiscsi.patch
@@ -1,6 +1,6 @@
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/libiscsi.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/libiscsi.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/libiscsi.c 2011-08-14 16:53:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/libiscsi.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,612 @@
+/*
+ * iSCSI Administration library
@@ -614,9 +614,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.c open-iscsi-2.0
+
+ return 0;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.doxy open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/libiscsi.doxy
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.doxy open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/libiscsi.doxy
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.doxy 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/libiscsi.doxy 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/libiscsi.doxy 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,1473 @@
+# Doxyfile 1.5.7.1
+
@@ -2091,9 +2091,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.doxy open-iscsi-
+# used. If set to NO the values of all tags below this one will be ignored.
+
+SEARCHENGINE = NO
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.h open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/libiscsi.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.h open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/libiscsi.h
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/libiscsi.h 2011-08-14 16:53:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/libiscsi.h 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,344 @@
+/*
+ * iSCSI Administration library
@@ -2439,9 +2439,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/libiscsi.h open-iscsi-2.0
+#endif /* __cplusplus */
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/Makefile open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/Makefile
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/Makefile open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/Makefile
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/Makefile 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/Makefile 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/Makefile 2012-03-05 23:16:31.000000000 -0600
@@ -0,0 +1,61 @@
+# This Makefile will work only with GNU make.
+
@@ -2458,7 +2458,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/Makefile open-iscsi-2.0-8
+
+COMMON_SRCS = sysdeps.o
+# sources shared between iscsid, iscsiadm and iscsistart
-+ISCSI_LIB_SRCS = netlink.o transport.o cxgbi.o be2iscsi.o iscsi_timer.o initiator_common.o iscsi_err.o session_info.o iscsi_util.o dcb_app.o io.o auth.o discovery.o login.o log.o md5.o sha1.o iface.o idbm.o sysfs.o iscsi_sysfs.o iscsi_net_util.o iscsid_req.o
++ISCSI_LIB_SRCS = netlink.o transport.o iser.o cxgbi.o be2iscsi.o iscsi_timer.o initiator_common.o iscsi_err.o session_info.o iscsi_util.o dcb_app.o io.o auth.o discovery.o login.o log.o md5.o sha1.o iface.o idbm.o sysfs.o iscsi_sysfs.o iscsi_net_util.o iscsid_req.o
+FW_PARAM_SRCS = fw_entry.o prom_lex.o prom_parse.tab.o fwparam_ppc.o fwparam_sysfs.o
+
+# sources shared with the userspace utils, note we build these separately
@@ -2504,9 +2504,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/Makefile open-iscsi-2.0-8
+ gcc $(CFLAGS) -M `ls *.c` > .depend
+
+-include .depend ../usr/.depend
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/pylibiscsi.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/pylibiscsi.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/pylibiscsi.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/pylibiscsi.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/pylibiscsi.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/pylibiscsi.c 2011-08-14 16:53:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/pylibiscsi.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,638 @@
+/*
+ * iSCSI Administration library
@@ -3146,9 +3146,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/pylibiscsi.c open-iscsi-2
+ Py_INCREF(&PyIscsiNode_Type);
+ PyModule_AddObject(m, "node", (PyObject *) &PyIscsiNode_Type);
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/setup.py open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/setup.py
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/setup.py open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/setup.py
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/setup.py 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/setup.py 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/setup.py 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,9 @@
+from distutils.core import setup, Extension
+
@@ -3159,9 +3159,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/setup.py open-iscsi-2.0-8
+
+setup (name = 'PyIscsi',version = '1.0',
+ description = 'libiscsi python bindings', ext_modules = [module1])
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_discovery_firmware.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_discovery_firmware.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_discovery_firmware.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_discovery_firmware.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_discovery_firmware.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_discovery_firmware.c 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_discovery_firmware.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,53 @@
+/*
+ * iSCSI Administration library
@@ -3216,9 +3216,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_discovery_firm
+
+ return rc;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_discovery_sendtargets.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_discovery_sendtargets.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_discovery_sendtargets.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_discovery_sendtargets.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_discovery_sendtargets.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_discovery_sendtargets.c 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_discovery_sendtargets.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,60 @@
+/*
+ * iSCSI Administration library
@@ -3280,9 +3280,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_discovery_send
+
+ return rc;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_auth.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_get_auth.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_auth.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_get_auth.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_auth.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_get_auth.c 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_get_auth.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,70 @@
+/*
+ * iSCSI Administration library
@@ -3354,9 +3354,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_auth.c ope
+
+ return rc;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_initiator_name.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_get_initiator_name.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_initiator_name.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_get_initiator_name.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_initiator_name.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_get_initiator_name.c 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_get_initiator_name.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,38 @@
+/*
+ * iSCSI Administration library
@@ -3396,9 +3396,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_initiator_
+
+ return 0;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_network_config.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_get_network_config.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_network_config.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_get_network_config.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_network_config.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_get_network_config.c 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_get_network_config.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,45 @@
+/*
+ * iSCSI Administration library
@@ -3445,9 +3445,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_get_network_co
+
+ return 0;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_login.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_login.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_login.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_login.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_login.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_login.c 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_login.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,52 @@
+/*
+ * iSCSI Administration library
@@ -3501,9 +3501,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_login.c open-i
+
+ return rc;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_logout.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_logout.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_logout.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_logout.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_logout.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_logout.c 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_logout.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,51 @@
+/*
+ * iSCSI Administration library
@@ -3556,9 +3556,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_logout.c open-
+
+ return rc;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_params.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_params.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_params.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_params.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_params.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_params.c 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_params.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,103 @@
+/*
+ * iSCSI Administration library
@@ -3663,9 +3663,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_params.c open-
+
+ return rc;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_set_auth.c open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_set_auth.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_set_auth.c open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_set_auth.c
--- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_set_auth.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/tests/test_set_auth.c 2011-08-14 16:46:24.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/tests/test_set_auth.c 2012-03-05 23:15:31.000000000 -0600
@@ -0,0 +1,58 @@
+/*
+ * iSCSI Administration library
@@ -3725,10 +3725,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/tests/test_set_auth.c ope
+
+ return rc;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/Makefile open-iscsi-2.0-872-rc4-bnx2i.build/Makefile
---- open-iscsi-2.0-872-rc4-bnx2i.base/Makefile 2011-08-14 16:53:01.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/Makefile 2011-08-14 16:46:24.000000000 -0500
-@@ -32,6 +32,7 @@ user: ;
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/Makefile open-iscsi-2.0-872-rc4-bnx2i.work/Makefile
+--- open-iscsi-2.0-872-rc4-bnx2i.base/Makefile 2012-03-05 23:19:56.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/Makefile 2012-03-05 23:15:31.000000000 -0600
+@@ -32,6 +32,7 @@ user: utils/open-isns/Makefile
$(MAKE) -C utils/fwparam_ibft
$(MAKE) -C usr
$(MAKE) -C utils
@@ -3736,7 +3736,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/Makefile open-iscsi-2.0-872-rc4-bn
@echo
@echo "Compilation complete Output file"
@echo "----------------------------------- ----------------"
-@@ -53,6 +54,7 @@ kernel: force
+@@ -56,6 +57,7 @@ kernel: force
force: ;
clean:
@@ -3744,9 +3744,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/Makefile open-iscsi-2.0-872-rc4-bn
$(MAKE) -C utils/sysdeps clean
$(MAKE) -C utils/fwparam_ibft clean
$(MAKE) -C utils clean
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/discovery.c open-iscsi-2.0-872-rc4-bnx2i.build/usr/discovery.c
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/discovery.c 2011-08-14 16:53:01.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/discovery.c 2011-08-14 16:46:24.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/discovery.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/discovery.c
+--- open-iscsi-2.0-872-rc4-bnx2i.base/usr/discovery.c 2012-03-05 23:19:56.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/discovery.c 2012-03-05 23:15:31.000000000 -0600
@@ -36,6 +36,7 @@
#include "types.h"
#include "iscsi_proto.h"
@@ -3783,10 +3783,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/discovery.c open-iscsi-2.0-872
int discovery_fw(void *data, struct iface_rec *iface,
struct list_head *rec_list)
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i.build/usr/idbm.c
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.c 2011-08-14 16:53:01.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/idbm.c 2011-08-14 16:46:24.000000000 -0500
-@@ -1274,9 +1274,9 @@ int idbm_print_all_discovery(int info_le
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.c
+--- open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.c 2012-03-05 23:20:05.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.c 2012-03-05 23:15:31.000000000 -0600
+@@ -1300,9 +1300,9 @@ int idbm_print_all_discovery(int info_le
* fn should return -1 if it skipped the rec, a ISCSI_ERR error code if
* the operation failed or 0 if fn was run successfully.
*/
@@ -3799,9 +3799,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.c open-iscsi-2.0-872-rc4-
{
DIR *iface_dirfd;
struct dirent *iface_dent;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.h open-iscsi-2.0-872-rc4-bnx2i.build/usr/idbm.h
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.h 2011-08-14 16:53:01.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/idbm.h 2011-08-14 16:46:24.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.h
+--- open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.h 2012-03-05 23:20:05.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.h 2012-03-05 23:15:31.000000000 -0600
@@ -98,6 +98,9 @@ struct rec_op_data {
node_rec_t *match_rec;
idbm_iface_op_fn *fn;
@@ -3812,9 +3812,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/idbm.h open-iscsi-2.0-872-rc4-
extern int idbm_for_each_portal(int *found, void *data,
idbm_portal_op_fn *fn, char *targetname);
extern int idbm_for_each_node(int *found, void *data,
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsi_ipc.h open-iscsi-2.0-872-rc4-bnx2i.build/usr/iscsi_ipc.h
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsi_ipc.h 2011-08-14 16:53:01.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/iscsi_ipc.h 2011-08-14 16:46:24.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsi_ipc.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_ipc.h
+--- open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsi_ipc.h 2012-03-05 23:19:56.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_ipc.h 2012-03-05 23:15:31.000000000 -0600
@@ -136,4 +136,6 @@ struct iscsi_ipc {
int (*recv_conn_state) (struct iscsi_conn *conn, uint32_t *state);
};
@@ -3822,9 +3822,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsi_ipc.h open-iscsi-2.0-872
+struct iscsi_ipc *ipc;
+
#endif /* ISCSI_IPC_H */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/Makefile open-iscsi-2.0-872-rc4-bnx2i.build/usr/Makefile
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/Makefile 2011-08-14 16:53:01.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/Makefile 2011-08-14 16:46:24.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/Makefile open-iscsi-2.0-872-rc4-bnx2i.work/usr/Makefile
+--- open-iscsi-2.0-872-rc4-bnx2i.base/usr/Makefile 2012-03-05 23:19:56.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/Makefile 2012-03-05 23:15:31.000000000 -0600
@@ -33,7 +33,7 @@ endif
OPTFLAGS ?= -O2 -g
WARNFLAGS ?= -Wall -Wstrict-prototypes
diff --git a/iscsi-initiator-utils-add-rh-ver.patch b/iscsi-initiator-utils-add-rh-ver.patch
index 24506c5..4d12de6 100644
--- a/iscsi-initiator-utils-add-rh-ver.patch
+++ b/iscsi-initiator-utils-add-rh-ver.patch
@@ -5,7 +5,7 @@
* some other maintainer could merge a patch without going through us
*/
-#define ISCSI_VERSION_STR "2.0-872"
-+#define ISCSI_VERSION_STR "2.0-872.33.el6"
++#define ISCSI_VERSION_STR "2.0-872.34.el6"
#define ISCSI_VERSION_FILE "/sys/module/scsi_transport_iscsi/version"
#endif
diff --git a/iscsi-initiator-utils-ping-and-chap.patch b/iscsi-initiator-utils-ping-and-chap.patch
new file mode 100644
index 0000000..286a852
--- /dev/null
+++ b/iscsi-initiator-utils-ping-and-chap.patch
@@ -0,0 +1,1141 @@
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/doc/iscsiadm.8 open-iscsi-2.0-872-rc4-bnx2i.work/doc/iscsiadm.8
+--- open-iscsi-2.0-872-rc4-bnx2i/doc/iscsiadm.8 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/doc/iscsiadm.8 2012-03-06 05:22:26.000000000 -0600
+@@ -12,11 +12,11 @@ iscsiadm \- open-iscsi administration ut
+
+ \fBiscsiadm\fR \-m session [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-r sessionid | sysfsdir [ \-R ] [ \-u | \-s | \-o new ] ]
+
+-\fBiscsiadm\fR \-m iface [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-I ifacename | \-H hostno|MAC ] [ [ \-o operation ] [ \-n name ] [ \-v value ] ]
++\fBiscsiadm\fR \-m iface [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-I ifacename | \-H hostno|MAC ] [ [ \-o operation ] [ \-n name ] [ \-v value ] ] [ \-C ping [ \-a ip ] [ \-b packetsize ] [ \-c count ] [ \-i interval ] ]
+
+ \fBiscsiadm\fR \-m fw [\-l]
+
+-\fBiscsiadm\fR \-m host [ \-P printlevel ] [ \-H hostno|MAC ]
++\fBiscsiadm\fR \-m host [ \-P printlevel ] [ \-H hostno|MAC ] [ -C chap [ -o operation ] [ -v chap_tbl_idx ] ]
+
+ \fBiscsiadm\fR \-k priority
+
+@@ -41,6 +41,32 @@ daemon (iscsid) be running.
+ .SH OPTIONS
+
+ .TP
++\fB\-a\fR, \fB\-\-ip=\fIipaddr\fP
++\fIipaddr\fR can be IPv4 or IPv6.
++
++This option is only valid for ping submode.
++
++.TP
++\fB\-b\fR, \fB\-\-packetsize=\fIpacketsize\fP
++Specify the ping \fIpacketsize\fR.
++
++This option is only valid for ping submode.
++
++.TP
++\fB\-c\fR, \fB\-\-count=\fIcount\fP
++\fIcount\fR specify number of ping iterations.
++
++This option is only valid for ping submode.
++
++.TP
++\fB\-C\fR, \fB\-\-submode=\fIop\fP
++Specify the submode for mode. op must be name of submode.
++
++Currently iscsiadm support ping as submode for iface. For example,
++
++iscsiadm -m iface -I ifacename -C ping -a ipaddr -b packetsize -c count -i interval
++
++.TP
+ \fB\-d\fR, \fB\-\-debug=\fIdebug_level\fP
+ print debugging information. Valid values for debug_level are 0 to 8.
+
+@@ -55,6 +81,12 @@ the scsi host number assigned to the hos
+ MAC address of a scsi host.
+
+ .TP
++\fB\-i\fR, \fB\-\-interval=\fIinterval\fP
++\fIinterval\fP specify delay between two ping iterations.
++
++This option is only valid for ping submode.
++
++.TP
+ \fB\-I\fR, \fB\-\-interface=\fI[iface]\fR
+ The interface argument specifies the iSCSI interface to use for the operation.
+ iSCSI interfaces (iface) are defined in /var/lib/iscsi/ifaces. For hardware
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_err.h open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_err.h
+--- open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_err.h 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_err.h 2012-03-06 05:22:26.000000000 -0600
+@@ -58,8 +58,12 @@ enum {
+ ISCSI_ERR_ISNS_QUERY = 25,
+ /* iSNS registration/deregistration failed */
+ ISCSI_ERR_ISNS_REG_FAILED = 26,
++ /* operation not supported */
++ ISCSI_ERR_OP_NOT_SUPP = 27,
++ /* device or resource in use */
++ ISCSI_ERR_BUSY = 28,
+ /* Operation failed, but retrying layer may succeed */
+- ISCSI_ERR_AGAIN = 27,
++ ISCSI_ERR_AGAIN = 29,
+
+ /* Always last. Indicates end of error code space */
+ ISCSI_MAX_ERR_VAL,
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_if.h
+--- open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_if.h 2012-03-06 05:22:26.000000000 -0600
+@@ -65,8 +65,11 @@ enum iscsi_uevent_e {
+
+ ISCSI_UEVENT_PATH_UPDATE = UEVENT_BASE + 20,
+ ISCSI_UEVENT_SET_IFACE_PARAMS = UEVENT_BASE + 21,
++ ISCSI_UEVENT_PING = UEVENT_BASE + 22,
++ ISCSI_UEVENT_GET_CHAP = UEVENT_BASE + 23,
++ ISCSI_UEVENT_DELETE_CHAP = UEVENT_BASE + 24,
+
+- ISCSI_UEVENT_MAX = ISCSI_UEVENT_SET_IFACE_PARAMS,
++ ISCSI_UEVENT_MAX = ISCSI_UEVENT_DELETE_CHAP,
+
+ /* up events */
+ ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
+@@ -80,8 +83,9 @@ enum iscsi_uevent_e {
+ ISCSI_KEVENT_IF_DOWN = KEVENT_BASE + 8,
+ ISCSI_KEVENT_CONN_LOGIN_STATE = KEVENT_BASE + 9,
+ ISCSI_KEVENT_HOST_EVENT = KEVENT_BASE + 10,
++ ISCSI_KEVENT_PING_COMP = KEVENT_BASE + 11,
+
+- ISCSI_KEVENT_MAX = ISCSI_KEVENT_HOST_EVENT,
++ ISCSI_KEVENT_MAX = ISCSI_KEVENT_PING_COMP,
+ };
+
+ enum iscsi_tgt_dscvr {
+@@ -195,6 +199,26 @@ struct iscsi_uevent {
+ uint32_t host_no;
+ uint32_t count;
+ } set_iface_params;
++ struct msg_iscsi_ping {
++ uint32_t host_no;
++ uint32_t iface_num;
++ uint32_t iface_type;
++ uint32_t payload_size;
++ uint32_t pid; /* unique ping id associated
++ with each ping request */
++ } iscsi_ping;
++ struct msg_get_chap {
++ uint32_t host_no;
++ uint32_t num_entries; /* number of CHAP entries
++ * on request, number of
++ * valid CHAP entries on
++ * response */
++ uint16_t chap_tbl_idx;
++ } get_chap;
++ struct msg_delete_chap {
++ uint32_t host_no;
++ uint16_t chap_tbl_idx;
++ } delete_chap;
+ } u;
+ union {
+ /* messages k -> u */
+@@ -244,6 +268,13 @@ struct iscsi_uevent {
+ uint32_t data_size;
+ enum iscsi_host_event_code code;
+ } host_event;
++ struct msg_ping_comp {
++ uint32_t host_no;
++ uint32_t status;
++ uint32_t pid; /* unique ping id associated
++ with each ping request */
++ uint32_t data_size;
++ } ping_comp;
+ } r;
+ } __attribute__ ((aligned (sizeof(uint64_t))));
+
+@@ -566,4 +597,20 @@ struct iscsi_stats {
+ __attribute__ ((aligned (sizeof(uint64_t))));
+ };
+
++enum chap_type_e {
++ CHAP_TYPE_OUT,
++ CHAP_TYPE_IN,
++};
++
++#define ISCSI_CHAP_AUTH_NAME_MAX_LEN 256
++#define ISCSI_CHAP_AUTH_SECRET_MAX_LEN 256
++
++struct iscsi_chap_rec {
++ uint16_t chap_tbl_idx;
++ enum chap_type_e chap_type;
++ char username[ISCSI_CHAP_AUTH_NAME_MAX_LEN];
++ uint8_t password[ISCSI_CHAP_AUTH_SECRET_MAX_LEN];
++ uint8_t password_length;
++};
++
+ #endif
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/README open-iscsi-2.0-872-rc4-bnx2i.work/README
+--- open-iscsi-2.0-872-rc4-bnx2i/README 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/README 2012-03-06 05:22:26.000000000 -0600
+@@ -366,7 +366,9 @@ Usage: iscsiadm [OPTION]
+ iscsi_ifacename.
+
+ See below for examples.
+- -m host --host=hostno|MAC --print=level
++ -m iface --interface=iscsi_ifacename -C ping --ip=[ipaddr] --packetsize=[size]
++ --count=[count] --interval=[interval]
++ -m host --host=hostno|MAC --print=level -C chap --op=[op] --value=[chap_tbl_idx]
+ Display information for a specific host. The host
+ can be passed in by host number or by MAC address.
+ If a host is not passed in then info
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/host.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/host.h 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/host.h 2012-03-06 05:22:26.000000000 -0600
+@@ -5,6 +5,9 @@
+ #include "types.h"
+ #include "config.h"
+
++#define MAX_CHAP_BUF_SZ 4096
++#define REQ_CHAP_BUF_SZ (MAX_CHAP_BUF_SZ + sizeof(struct iscsi_uevent))
++
+ struct host_info {
+ struct iface_rec iface;
+ uint32_t host_no;
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.c 2012-03-06 05:22:26.000000000 -0600
+@@ -449,6 +449,30 @@ void idbm_recinfo_iface(iface_rec_t *r,
+ __recinfo_uint16(IFACE_PORT, ri, r, port, IDBM_SHOW, num, 1);
+ }
+
++static void idbm_recinfo_host_chap(struct iscsi_chap_rec *r, recinfo_t *ri)
++{
++ int num = 0;
++
++ __recinfo_uint16(HOST_AUTH_INDEX, ri, r, chap_tbl_idx, IDBM_SHOW,
++ num, 1);
++
++ if (r->chap_type == CHAP_TYPE_OUT) {
++ __recinfo_str(HOST_AUTH_USERNAME, ri, r, username, IDBM_SHOW,
++ num, 0);
++ __recinfo_str(HOST_AUTH_PASSWORD, ri, r, password, IDBM_MASKED,
++ num, 1);
++ __recinfo_int(HOST_AUTH_PASSWORD_LEN, ri, r, password_length,
++ IDBM_HIDE, num, 1);
++ } else {
++ __recinfo_str(HOST_AUTH_USERNAME_IN, ri, r, username, IDBM_SHOW,
++ num, 0);
++ __recinfo_str(HOST_AUTH_PASSWORD_IN, ri, r, password,
++ IDBM_MASKED, num, 1);
++ __recinfo_int(HOST_AUTH_PASSWORD_IN_LEN, ri, r, password_length,
++ IDBM_HIDE, num, 1);
++ }
++}
++
+ recinfo_t *idbm_recinfo_alloc(int max_keys)
+ {
+ recinfo_t *info;
+@@ -479,6 +503,9 @@ void idbm_print(int type, void *rec, int
+ case IDBM_PRINT_TYPE_IFACE:
+ idbm_recinfo_iface((struct iface_rec *)rec, info);
+ break;
++ case IDBM_PRINT_TYPE_HOST_CHAP:
++ idbm_recinfo_host_chap((struct iscsi_chap_rec *)rec, info);
++ break;
+ }
+
+ fprintf(f, "%s\n", ISCSI_BEGIN_REC);
+@@ -849,6 +876,13 @@ int idbm_print_iface_info(void *data, st
+ return 0;
+ }
+
++int idbm_print_host_chap_info(struct iscsi_chap_rec *chap)
++{
++ /* User only calls this to print chap so always print */
++ idbm_print(IDBM_PRINT_TYPE_HOST_CHAP, chap, 1, stdout);
++ return 0;
++}
++
+ int idbm_print_node_flat(void *data, node_rec_t *rec)
+ {
+ if (strchr(rec->conn[0].address, '.'))
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm_fields.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm_fields.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/idbm_fields.h 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm_fields.h 2012-03-06 05:22:26.000000000 -0600
+@@ -116,4 +116,14 @@
+ #define DISC_ISNS_ADDR "discovery.sendtargets.address"
+ #define DISC_ISNS_PORT "discovery.sendtargets.port"
+
++/* host auth fields */
++#define HOST_AUTH_INDEX "host.auth.tbl_idx"
++#define HOST_AUTH_METHOD "host.auth.authmethod"
++#define HOST_AUTH_USERNAME "host.auth.username"
++#define HOST_AUTH_PASSWORD "host.auth.password"
++#define HOST_AUTH_PASSWORD_LEN "host.auth.password_length"
++#define HOST_AUTH_USERNAME_IN "host.auth.username_in"
++#define HOST_AUTH_PASSWORD_IN "host.auth.password_in"
++#define HOST_AUTH_PASSWORD_IN_LEN "host.auth.password_in_length"
++
+ #endif
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.h 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.h 2012-03-06 05:22:26.000000000 -0600
+@@ -168,6 +168,7 @@ enum {
+ IDBM_PRINT_TYPE_DISCOVERY,
+ IDBM_PRINT_TYPE_NODE,
+ IDBM_PRINT_TYPE_IFACE,
++ IDBM_PRINT_TYPE_HOST_CHAP,
+ };
+
+ extern void idbm_print(int type, void *rec, int show, FILE *f);
+@@ -180,4 +181,6 @@ extern struct node_rec *idbm_create_rec(
+ extern struct node_rec *
+ idbm_create_rec_from_boot_context(struct boot_context *context);
+
++extern int idbm_print_host_chap_info(struct iscsi_chap_rec *chap);
++
+ #endif /* IDBM_H */
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iface.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iface.c 2012-03-06 05:23:54.000000000 -0600
+@@ -425,12 +425,23 @@ int iface_get_by_net_binding(struct ifac
+ return ISCSI_ERR_NO_OBJS_FOUND;
+ }
+
+-static int iface_get_iptype(struct iface_rec *iface)
++int iface_get_iptype(struct iface_rec *iface)
+ {
+- if (strcmp(iface->bootproto, "dhcp") && !strstr(iface->ipaddress, "."))
+- return ISCSI_IFACE_TYPE_IPV6;
+- else
+- return ISCSI_IFACE_TYPE_IPV4;
++ /* address might not be set if user config with another tool */
++ if (!strlen(iface->ipaddress) ||
++ !strcmp(UNKNOWN_VALUE, iface->ipaddress)) {
++ /* try to figure out by name */
++ if (strstr(iface->name, "ipv4"))
++ return ISCSI_IFACE_TYPE_IPV4;
++ else
++ return ISCSI_IFACE_TYPE_IPV6;
++ } else {
++ if (strcmp(iface->bootproto, "dhcp") &&
++ !strstr(iface->ipaddress, "."))
++ return ISCSI_IFACE_TYPE_IPV6;
++ else
++ return ISCSI_IFACE_TYPE_IPV4;
++ }
+ }
+
+ static int iface_setup_binding_from_kern_iface(void *data,
+@@ -606,7 +617,7 @@ int iface_match(struct iface_rec *patter
+ return 1;
+
+ if (!strcmp(pattern->name, iface->name)) {
+- if (strcmp(pattern->name, DEFAULT_IFACENAME))
++ if (!strcmp(pattern->name, DEFAULT_IFACENAME))
+ return 1;
+ /*
+ * For default we allow the same name, but different
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iface.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iface.h 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iface.h 2012-03-06 05:22:26.000000000 -0600
+@@ -60,6 +60,7 @@ extern int iface_get_param_count(struct
+ int iface_all);
+ extern int iface_build_net_config(struct iface_rec *iface_primary,
+ int iface_all, struct iovec *iovs);
++extern int iface_get_iptype(struct iface_rec *iface);
+
+ #define iface_fmt "[hw=%s,ip=%s,net_if=%s,iscsi_if=%s]"
+ #define iface_str(_iface) \
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsiadm.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsiadm.c 2012-03-06 05:23:31.000000000 -0600
+@@ -27,6 +27,7 @@
+ #include <unistd.h>
+ #include <string.h>
+ #include <signal.h>
++#include <time.h>
+ #include <sys/stat.h>
+
+ #include "initiator.h"
+@@ -51,6 +52,7 @@
+ #include "isns-proto.h"
+ #include "iscsi_err.h"
+ #include "iscsi_ipc.h"
++#include "iscsi_timer.h"
+
+ static char program_name[] = "iscsiadm";
+ static char config_file[TARGET_NAME_MAXLEN];
+@@ -64,6 +66,8 @@ enum iscsiadm_mode {
+ MODE_HOST,
+ MODE_IFACE,
+ MODE_FW,
++ MODE_PING,
++ MODE_CHAP
+ };
+
+ enum iscsiadm_op {
+@@ -102,9 +106,13 @@ static struct option const long_options[
+ {"show", no_argument, NULL, 'S'},
+ {"version", no_argument, NULL, 'V'},
+ {"help", no_argument, NULL, 'h'},
++ {"submode", required_argument, NULL, 'C'},
++ {"ip", required_argument, NULL, 'a'},
++ {"packetsize", required_argument, NULL, 'b'},
++ {"count", required_argument, NULL, 'c'},
+ {NULL, 0, NULL, 0},
+ };
+-static char *short_options = "RlDVhm:p:P:T:H:I:U:k:L:d:r:n:v:o:sSt:u";
++static char *short_options = "RlDVhm:a:b:c:C:p:P:T:H:i:I:U:k:L:d:r:n:v:o:sSt:u";
+
+ static void usage(int status)
+ {
+@@ -116,12 +124,12 @@ static void usage(int status)
+ iscsiadm -m discoverydb [ -hV ] [ -d debug_level ] [-P printlevel] [ -t type -p ip:port -I ifaceN ... [ -Dl ] ] | [ [ -p ip:port -t type] \
+ [ -o operation ] [ -n name ] [ -v value ] [ -lD ] ] \n\
+ iscsiadm -m discovery [ -hV ] [ -d debug_level ] [-P printlevel] [ -t type -p ip:port -I ifaceN ... [ -l ] ] | [ [ -p ip:port ] [ -l | -D ] ] \n\
+-iiscsiadm -m node [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -L all,manual,automatic ] [ -U all,manual,automatic ] [ -S ] [ [ -T targetname -p ip:port -I ifaceN ] [ -l | -u | -R | -s] ] \
++iscsiadm -m node [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -L all,manual,automatic ] [ -U all,manual,automatic ] [ -S ] [ [ -T targetname -p ip:port -I ifaceN ] [ -l | -u | -R | -s] ] \
+ [ [ -o operation ] [ -n name ] [ -v value ] ]\n\
+ iscsiadm -m session [ -hV ] [ -d debug_level ] [ -P printlevel] [ -r sessionid | sysfsdir [ -R | -u | -s ] [ -o operation ] [ -n name ] [ -v value ] ]\n\
+-iscsiadm -m iface [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -I ifacename | -H hostno|MAC ] [ [ -o operation ] [ -n name ] [ -v value ] ]\n\
++iscsiadm -m iface [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -I ifacename | -H hostno|MAC ] [ [ -o operation ] [ -n name ] [ -v value ] ] [ -C ping [ -a ip ] [ -b packetsize ] [ -c count ] [ -i interval ] ]\n\
+ iscsiadm -m fw [ -l ]\n\
+-iscsiadm -m host [ -P printlevel ] [ -H hostno|MAC ]\n\
++iscsiadm -m host [ -P printlevel ] [ -H hostno|MAC ] [ -C chap [ -o operation ] [ -v chap_tbl_idx ] ]\n\
+ iscsiadm -k priority\n");
+ }
+ exit(status);
+@@ -178,6 +186,21 @@ str_to_mode(char *str)
+ }
+
+ static int
++str_to_submode(char *str)
++{
++ int sub_mode;
++
++ if (!strcmp("ping", str))
++ sub_mode = MODE_PING;
++ else if (!strcmp("chap", str))
++ sub_mode = MODE_CHAP;
++ else
++ sub_mode = -1;
++
++ return sub_mode;
++}
++
++static int
+ str_to_type(char *str)
+ {
+ int type;
+@@ -1277,6 +1300,146 @@ free_buf:
+ return ISCSI_SUCCESS;
+ }
+
++static int get_host_chap_info(uint32_t host_no)
++{
++ struct iscsi_transport *t = NULL;
++ struct iscsi_chap_rec *crec = NULL;
++ char *req_buf = NULL;
++ uint32_t valid_chap_entries;
++ uint32_t num_entries;
++ uint16_t chap_tbl_idx = 0;
++ int rc = 0;
++ int fd, i = 0;
++
++ t = iscsi_sysfs_get_transport_by_hba(host_no);
++ if (!t) {
++ log_error("Could not match hostno %d to "
++ "transport.", host_no);
++ rc = ISCSI_ERR_TRANS_NOT_FOUND;
++ goto exit_chap_info;
++ }
++
++ num_entries = MAX_CHAP_BUF_SZ / sizeof(*crec);
++
++ req_buf = calloc(1, REQ_CHAP_BUF_SZ);
++ if (!req_buf) {
++ log_error("Could not allocate memory for CHAP request.");
++ rc = ISCSI_ERR_NOMEM;
++ goto exit_chap_info;
++ }
++
++ fd = ipc->ctldev_open();
++ if (fd < 0) {
++ rc = ISCSI_ERR_INTERNAL;
++ log_error("Netlink open failed.");
++ goto exit_chap_info;
++ }
++
++get_chap:
++ memset(req_buf, 0, REQ_CHAP_BUF_SZ);
++
++ rc = ipc->get_chap(t->handle, host_no, chap_tbl_idx, num_entries,
++ req_buf, &valid_chap_entries);
++ if (rc < 0) {
++ log_error("get_chap_info failed. errno=%d", errno);
++ rc = ISCSI_ERR;
++ goto exit_chap_info;
++ }
++
++ log_info("Valid CHAP Entries = %d\n", valid_chap_entries);
++
++ crec = (struct iscsi_chap_rec *) (req_buf +
++ sizeof(struct iscsi_uevent));
++
++ if (valid_chap_entries)
++ chap_tbl_idx =
++ (crec + (valid_chap_entries - 1))->chap_tbl_idx + 1;
++
++ /* print chap info */
++ for (i = 0; i < valid_chap_entries; i++) {
++ idbm_print_host_chap_info(crec);
++ crec++;
++ }
++
++ if (valid_chap_entries != num_entries)
++ goto exit_chap_info;
++ else
++ goto get_chap;
++
++ ipc->ctldev_close();
++
++exit_chap_info:
++ if (req_buf)
++ free(req_buf);
++
++ return rc;
++}
++
++static int delete_host_chap_info(uint32_t host_no, char *value)
++{
++ struct iscsi_transport *t = NULL;
++ int fd, rc = 0;
++ uint16_t chap_tbl_idx;
++
++ if (!value) {
++ log_error("CHAP deletion requires --value=table_index.");
++ return ISCSI_ERR_INVAL;
++ }
++
++ chap_tbl_idx = (uint16_t)atoi(value);
++
++ t = iscsi_sysfs_get_transport_by_hba(host_no);
++ if (!t) {
++ log_error("Could not match hostno %d to "
++ "transport.", host_no);
++ rc = ISCSI_ERR_TRANS_NOT_FOUND;
++ goto exit_delete_chap;
++ }
++
++ fd = ipc->ctldev_open();
++ if (fd < 0) {
++ log_error("Netlink open failed.");
++ rc = ISCSI_ERR_INTERNAL;
++ goto exit_delete_chap;
++ }
++
++ log_info("Deleteing CHAP index: %d\n", chap_tbl_idx);
++ rc = ipc->delete_chap(t->handle, host_no, chap_tbl_idx);
++ if (rc < 0) {
++ log_error("CHAP Delete failed.");
++ if (rc == -EBUSY) {
++ rc = ISCSI_ERR_BUSY;
++ log_error("CHAP index %d is in use.", chap_tbl_idx);
++ } else
++ rc = ISCSI_ERR;
++ }
++
++ ipc->ctldev_close();
++
++exit_delete_chap:
++ return rc;
++}
++
++static int exec_host_chap_op(int op, int info_level, uint32_t host_no,
++ char *value)
++{
++ int rc = ISCSI_ERR_INVAL;
++
++ switch (op) {
++ case OP_SHOW:
++ rc = get_host_chap_info(host_no);
++ break;
++ case OP_DELETE:
++ rc = delete_host_chap_info(host_no, value);
++ break;
++ default:
++ log_error("Invalid operation.");
++ break;
++ }
++
++ return rc;
++}
++
+ /* TODO: merge iter helpers and clean them up, so we can use them here */
+ static int exec_iface_op(int op, int do_show, int info_level,
+ struct iface_rec *iface, uint32_t host_no,
+@@ -2082,6 +2245,101 @@ static uint32_t parse_host_info(char *op
+ return host_no;
+ }
+
++static int exec_ping_op(struct iface_rec *iface, char *ip, int size, int count,
++ int interval)
++{
++ int rc = ISCSI_ERR;
++ uint32_t iface_type = ISCSI_IFACE_TYPE_IPV4;
++ struct iscsi_transport *t = NULL;
++ uint32_t host_no;
++ struct sockaddr_storage addr;
++ int i;
++
++ if (!iface) {
++ log_error("Ping requires iface.");
++ rc = ISCSI_ERR_INVAL;
++ goto ping_exit;
++ }
++
++ if (!ip) {
++ log_error("Ping requires destination ipaddress.");
++ rc = ISCSI_ERR_INVAL;
++ goto ping_exit;
++ }
++
++ if (size <= 0) {
++ log_error("Invalid packet size: %d.", size);
++ rc = ISCSI_ERR_INVAL;
++ goto ping_exit;
++ }
++
++ if (count <= 0) {
++ log_error("Invalid number of packets to transmit: %d.", count);
++ rc = ISCSI_ERR_INVAL;
++ goto ping_exit;
++ }
++
++ if (interval < 0) {
++ log_error("Invalid timing interval: %d.", interval);
++ rc = ISCSI_ERR_INVAL;
++ goto ping_exit;
++ }
++
++ rc = iface_conf_read(iface);
++ if (rc) {
++ log_error("Could not read iface %s (%d).", iface->name, rc);
++ goto ping_exit;
++ }
++
++
++ iface_type = iface_get_iptype(iface);
++
++ t = iscsi_sysfs_get_transport_by_name(iface->transport_name);
++ if (!t) {
++ log_error("Can't find transport.");
++ rc = ISCSI_ERR_INVAL;
++ goto ping_exit;
++ }
++
++ host_no = iscsi_sysfs_get_host_no_from_hwinfo(iface, &rc);
++ if (host_no == -1) {
++ log_error("Can't find host_no.");
++ rc = ISCSI_ERR_INVAL;
++ goto ping_exit;
++ }
++
++ rc = resolve_address(ip, NULL, &addr);
++ if (rc) {
++ log_error("Invalid IP address.");
++ rc = ISCSI_ERR_INVAL;
++ goto ping_exit;
++ }
++
++ /* TODO: move this. It is needed by interface for pid */
++ srand(time(NULL));
++
++ for (i = 1; i <= count; i++) {
++ /*
++ * To support drivers like bnx2i that do not use
++ * the iscsi if to send a ping, we can add a transport
++ * callout here.
++ */
++ rc = ipc->exec_ping(t->handle, host_no,
++ (struct sockaddr *)&addr, iface->iface_num,
++ iface_type, size);
++ if (!rc)
++ printf("Ping %d completed\n", i);
++ else
++ printf("Ping %d failed: %s\n", i, iscsi_err_to_str(rc));
++
++ if (i < count)
++ sleep(interval);
++ }
++
++ping_exit:
++ return rc;
++}
++
+ int
+ main(int argc, char **argv)
+ {
+@@ -2091,7 +2349,8 @@ main(int argc, char **argv)
+ int rc=0, sid=-1, op=OP_NOOP, type=-1, do_logout=0, do_stats=0;
+ int do_login_all=0, do_logout_all=0, info_level=-1, num_ifaces = 0;
+ int tpgt = PORTAL_GROUP_TAG_UNKNOWN, killiscsid=-1, do_show=0;
+- int do_discover = 0;
++ int packet_size=32, ping_count=1, ping_interval=0;
++ int do_discover = 0, sub_mode = -1;
+ struct sigaction sa_old;
+ struct sigaction sa_new;
+ struct list_head ifaces;
+@@ -2196,12 +2455,27 @@ main(int argc, char **argv)
+ case 'm':
+ mode = str_to_mode(optarg);
+ break;
++ case 'C':
++ sub_mode = str_to_submode(optarg);
++ break;
+ case 'T':
+ targetname = optarg;
+ break;
+ case 'p':
+ ip = str_to_ipport(optarg, &port, &tpgt);
+ break;
++ case 'a':
++ ip = optarg;
++ break;
++ case 'b':
++ packet_size = atoi(optarg);
++ break;
++ case 'c':
++ ping_count = atoi(optarg);
++ break;
++ case 'i':
++ ping_interval = atoi(optarg);
++ break;
+ case 'I':
+ iface = iface_alloc(optarg, &rc);
+ if (rc == ISCSI_ERR_INVAL) {
+@@ -2262,19 +2536,35 @@ main(int argc, char **argv)
+
+ switch (mode) {
+ case MODE_HOST:
+- if ((rc = verify_mode_params(argc, argv, "HdmP", 0))) {
++ if ((rc = verify_mode_params(argc, argv, "CHdmPov", 0))) {
+ log_error("host mode: option '-%c' is not "
+ "allowed/supported", rc);
+ rc = ISCSI_ERR_INVAL;
+ goto out;
+ }
+-
+- rc = host_info_print(info_level, host_no);
++ if (sub_mode != -1) {
++ switch (sub_mode) {
++ case MODE_CHAP:
++ if (!op || !host_no) {
++ log_error("CHAP mode requires host "
++ "no and valid operation");
++ rc = ISCSI_ERR_INVAL;
++ break;
++ }
++ rc = exec_host_chap_op(op, info_level, host_no,
++ value);
++ break;
++ default:
++ log_error("Invalid Sub Mode");
++ break;
++ }
++ } else
++ rc = host_info_print(info_level, host_no);
+ break;
+ case MODE_IFACE:
+ iface_setup_host_bindings();
+
+- if ((rc = verify_mode_params(argc, argv, "HIdnvmPo", 0))) {
++ if ((rc = verify_mode_params(argc, argv, "HIdnvmPoCabci", 0))) {
+ log_error("iface mode: option '-%c' is not "
+ "allowed/supported", rc);
+ rc = ISCSI_ERR_INVAL;
+@@ -2289,8 +2579,14 @@ main(int argc, char **argv)
+ "interface. Using the first one "
+ "%s.", iface->name);
+ }
+- rc = exec_iface_op(op, do_show, info_level, iface, host_no,
+- name, value);
++
++ if (sub_mode == MODE_PING)
++ rc = exec_ping_op(iface, ip, packet_size, ping_count,
++ ping_interval);
++ else
++ rc = exec_iface_op(op, do_show, info_level, iface,
++ host_no, name, value);
++
+ break;
+ case MODE_DISCOVERYDB:
+ if ((rc = verify_mode_params(argc, argv, "DSIPdmntplov", 0))) {
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_err.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_err.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_err.c 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_err.c 2012-03-06 05:22:26.000000000 -0600
+@@ -49,7 +49,9 @@ static char *iscsi_err_msgs[] = {
+ /* 24 */ "iSCSI login failed due to authorization failure",
+ /* 25 */ "iSNS query failed",
+ /* 26 */ "iSNS registration failed",
+- /* 27 */ "Retryable failure",
++ /* 27 */ "operation not supported",
++ /* 28 */ "device or resource in use",
++ /* 29 */ "Retryable failure",
+ };
+
+ char *iscsi_err_to_str(int err)
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_ipc.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_ipc.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_ipc.h 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_ipc.h 2012-03-06 05:22:26.000000000 -0600
+@@ -134,6 +134,17 @@ struct iscsi_ipc {
+ struct iovec *iovs, uint32_t param_count);
+
+ int (*recv_conn_state) (struct iscsi_conn *conn, uint32_t *state);
++
++ int (*exec_ping) (uint64_t transport_handle, uint32_t host_no,
++ struct sockaddr *addr, uint32_t iface_num,
++ uint32_t iface_type, uint32_t size);
++
++ int (*get_chap) (uint64_t transport_handle, uint32_t host_no,
++ uint16_t chap_tbl_idx, uint32_t num_entries,
++ char *chap_buf, uint32_t *valid_chap_entries);
++
++ int (*delete_chap) (uint64_t transport_handle, uint32_t host_no,
++ uint16_t chap_tbl_idx);
+ };
+
+ struct iscsi_ipc *ipc;
+diff -aurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/netlink.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c 2012-03-06 05:22:41.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/netlink.c 2012-03-06 05:23:02.000000000 -0600
+@@ -25,10 +25,12 @@
+ #include <unistd.h>
+ #include <stdint.h>
+ #include <errno.h>
++#include <time.h>
+ #include <inttypes.h>
+ #include <asm/types.h>
+ #include <sys/socket.h>
+ #include <sys/types.h>
++#include <sys/poll.h>
+ #include <linux/netlink.h>
+
+ #include "types.h"
+@@ -39,6 +41,8 @@
+ #include "iscsi_sysfs.h"
+ #include "transport.h"
+ #include "iscsi_netlink.h"
++#include "iscsi_err.h"
++#include "iscsi_timer.h"
+
+ static int ctrl_fd;
+ static struct sockaddr_nl src_addr, dest_addr;
+@@ -64,6 +68,15 @@ static int ctldev_handle(void);
+
+ #define NLM_SETPARAM_DEFAULT_MAX (NI_MAXHOST + 1 + sizeof(struct iscsi_uevent))
+
++struct iscsi_ping_event {
++ uint32_t host_no;
++ uint32_t pid;
++ int32_t status;
++ int active;
++};
++
++struct iscsi_ping_event ping_event;
++
+ struct nlattr *iscsi_nla_alloc(uint16_t type, uint16_t len)
+ {
+ struct nlattr *attr;
+@@ -323,6 +336,9 @@ __kipc_call(struct iovec *iovp, int coun
+ } else if (ev->type == ISCSI_UEVENT_GET_STATS) {
+ /* kget_stats() will read */
+ return 0;
++ } else if (ev->type == ISCSI_UEVENT_GET_CHAP) {
++ /* kget_chap() will read */
++ return 0;
+ } else {
+ if ((rc = nlpayload_read(ctrl_fd, (void*)ev,
+ sizeof(*ev), 0)) < 0) {
+@@ -1002,7 +1018,7 @@ kset_net_config(uint64_t transport_handl
+ return 0;
+ }
+
+-static int krecv_conn_state(struct iscsi_conn *conn, int *state)
++static int krecv_conn_state(struct iscsi_conn *conn, uint32_t *state)
+ {
+ int rc;
+
+@@ -1024,6 +1040,218 @@ exit:
+ return rc;
+ }
+
++
++
++
++static int
++ksend_ping(uint64_t transport_handle, uint32_t host_no, struct sockaddr *addr,
++ uint32_t iface_num, uint32_t iface_type, uint32_t pid, uint32_t size)
++{
++ int rc, addrlen;
++ struct iscsi_uevent *ev;
++ struct iovec iov[2];
++
++ log_debug(8, "in %s", __FUNCTION__);
++
++ memset(setparam_buf, 0, NLM_SETPARAM_DEFAULT_MAX);
++ ev = (struct iscsi_uevent *)setparam_buf;
++ ev->type = ISCSI_UEVENT_PING;
++ ev->transport_handle = transport_handle;
++ ev->u.iscsi_ping.host_no = host_no;
++ ev->u.iscsi_ping.iface_num = iface_num;
++ ev->u.iscsi_ping.iface_type = iface_type;
++ ev->u.iscsi_ping.payload_size = size;
++ ev->u.iscsi_ping.pid = pid;
++
++ if (addr->sa_family == PF_INET)
++ addrlen = sizeof(struct sockaddr_in);
++ else if (addr->sa_family == PF_INET6)
++ addrlen = sizeof(struct sockaddr_in6);
++ else {
++ log_error("%s unknown addr family %d\n",
++ __FUNCTION__, addr->sa_family);
++ return -EINVAL;
++ }
++ memcpy(setparam_buf + sizeof(*ev), addr, addrlen);
++
++ iov[1].iov_base = ev;
++ iov[1].iov_len = sizeof(*ev) + addrlen;
++ rc = __kipc_call(iov, 2);
++ if (rc < 0)
++ return rc;
++
++ return 0;
++}
++
++static int kexec_ping(uint64_t transport_handle, uint32_t host_no,
++ struct sockaddr *addr, uint32_t iface_num,
++ uint32_t iface_type, uint32_t size)
++{
++ struct pollfd pfd;
++ struct timeval ping_timer;
++ int timeout, fd, rc;
++ uint32_t pid;
++
++ fd = ipc->ctldev_open();
++ if (fd < 0) {
++ log_error("Could not open netlink socket.");
++ return ISCSI_ERR;
++ }
++
++ /* prepare to poll */
++ memset(&pfd, 0, sizeof(pfd));
++ pfd.fd = fd;
++ pfd.events = POLLIN | POLLPRI;
++
++ /* get unique ping id */
++ pid = rand();
++
++ rc = ksend_ping(transport_handle, host_no, addr, iface_num,
++ iface_type, pid, size);
++ if (rc != 0) {
++ switch (rc) {
++ case -ENOSYS:
++ rc = ISCSI_ERR_OP_NOT_SUPP;
++ break;
++ case -EINVAL:
++ rc = ISCSI_ERR_INVAL;
++ break;
++ default:
++ rc = ISCSI_ERR;
++ }
++ goto close_nl;
++ }
++
++ ping_event.host_no = -1;
++ ping_event.pid = -1;
++ ping_event.status = -1;
++ ping_event.active = -1;
++
++ iscsi_timer_set(&ping_timer, 30);
++
++ timeout = iscsi_timer_msecs_until(&ping_timer);
++
++ while (1) {
++ pfd.revents = 0;
++ rc = poll(&pfd, 1, timeout);
++
++ if (iscsi_timer_expired(&ping_timer)) {
++ rc = ISCSI_ERR_TRANS_TIMEOUT;
++ break;
++ }
++
++ if (rc > 0) {
++ if (pfd.revents & (POLLIN | POLLPRI)) {
++ timeout = iscsi_timer_msecs_until(&ping_timer);
++ rc = ipc->ctldev_handle();
++
++ if (ping_event.active != 1)
++ continue;
++
++ if (pid != ping_event.pid)
++ continue;
++
++ if (ping_event.status == 0)
++ rc = 0;
++ else
++ rc = ISCSI_ERR;
++ break;
++ }
++
++ if (pfd.revents & POLLHUP) {
++ rc = ISCSI_ERR_TRANS;
++ break;
++ }
++
++ if (pfd.revents & POLLNVAL) {
++ rc = ISCSI_ERR_INTERNAL;
++ break;
++ }
++
++ if (pfd.revents & POLLERR) {
++ rc = ISCSI_ERR_INTERNAL;
++ break;
++ }
++ } else if (rc < 0) {
++ rc = ISCSI_ERR_INTERNAL;
++ break;
++ }
++ }
++
++close_nl:
++ ipc->ctldev_close();
++ return rc;
++}
++
++static int kget_chap(uint64_t transport_handle, uint32_t host_no,
++ uint16_t chap_tbl_idx, uint32_t num_entries,
++ char *chap_buf, uint32_t *valid_chap_entries)
++{
++ int rc = 0;
++ int ev_size;
++ struct iscsi_uevent ev;
++ struct iovec iov[2];
++ char nlm_ev[NLMSG_SPACE(sizeof(struct iscsi_uevent))];
++ struct nlmsghdr *nlh;
++
++ memset(&ev, 0, sizeof(struct iscsi_uevent));
++
++ ev.type = ISCSI_UEVENT_GET_CHAP;
++ ev.transport_handle = transport_handle;
++ ev.u.get_chap.host_no = host_no;
++ ev.u.get_chap.chap_tbl_idx = chap_tbl_idx;
++ ev.u.get_chap.num_entries = num_entries;
++
++ iov[1].iov_base = &ev;
++ iov[1].iov_len = sizeof(ev);
++ rc = __kipc_call(iov, 2);
++ if (rc < 0)
++ return rc;
++
++ if ((rc = nl_read(ctrl_fd, nlm_ev,
++ NLMSG_SPACE(sizeof(struct iscsi_uevent)),
++ MSG_PEEK)) < 0) {
++ log_error("can not read nlm_ev, error %d", rc);
++ return rc;
++ }
++
++ nlh = (struct nlmsghdr *)nlm_ev;
++ ev_size = nlh->nlmsg_len - NLMSG_ALIGN(sizeof(struct nlmsghdr));
++
++ if ((rc = nlpayload_read(ctrl_fd, (void *)chap_buf, ev_size, 0)) < 0) {
++ log_error("can not read from NL socket, error %d", rc);
++ return rc;
++ }
++
++ *valid_chap_entries = ev.u.get_chap.num_entries;
++
++ return rc;
++}
++
++static int kdelete_chap(uint64_t transport_handle, uint32_t host_no,
++ uint16_t chap_tbl_idx)
++{
++ int rc = 0;
++ struct iscsi_uevent ev;
++ struct iovec iov[2];
++
++ memset(&ev, 0, sizeof(struct iscsi_uevent));
++
++ ev.type = ISCSI_UEVENT_DELETE_CHAP;
++ ev.transport_handle = transport_handle;
++ ev.u.delete_chap.host_no = host_no;
++ ev.u.delete_chap.chap_tbl_idx = chap_tbl_idx;
++
++ iov[1].iov_base = &ev;
++ iov[1].iov_len = sizeof(ev);
++
++ rc = __kipc_call(iov, 2);
++ if (rc < 0)
++ return rc;
++
++ return rc;
++}
++
+ static void drop_data(struct nlmsghdr *nlh)
+ {
+ int ev_size;
+@@ -1041,7 +1269,7 @@ static int ctldev_handle(void)
+ char nlm_ev[NLMSG_SPACE(sizeof(struct iscsi_uevent))];
+ struct nlmsghdr *nlh;
+ struct iscsi_ev_context *ev_context;
+- uint32_t sid = 0, cid = 0, state = 0;
++ uint32_t sid = 0, cid = 0;
+
+ log_debug(7, "in %s", __FUNCTION__);
+
+@@ -1060,11 +1288,17 @@ static int ctldev_handle(void)
+ /* old kernels sent ISCSI_UEVENT_CREATE_SESSION on creation */
+ case ISCSI_UEVENT_CREATE_SESSION:
+ drop_data(nlh);
++ if (!ipc_ev_clbk)
++ return 0;
++
+ if (ipc_ev_clbk->create_session)
+ ipc_ev_clbk->create_session(ev->r.c_session_ret.host_no,
+ ev->r.c_session_ret.sid);
+ return 0;
+ case ISCSI_KEVENT_DESTROY_SESSION:
++ if (!ipc_ev_clbk)
++ return 0;
++
+ drop_data(nlh);
+ if (ipc_ev_clbk->destroy_session)
+ ipc_ev_clbk->destroy_session(ev->r.d_session.host_no,
+@@ -1081,7 +1315,6 @@ static int ctldev_handle(void)
+ case ISCSI_KEVENT_CONN_LOGIN_STATE:
+ sid = ev->r.conn_login.sid;
+ cid = ev->r.conn_login.cid;
+- state = ev->r.conn_login.state;
+ break;
+ case ISCSI_KEVENT_UNBIND_SESSION:
+ sid = ev->r.unbind_session.sid;
+@@ -1106,6 +1339,14 @@ static int ctldev_handle(void)
+
+ drop_data(nlh);
+ return 0;
++ case ISCSI_KEVENT_PING_COMP:
++ ping_event.host_no = ev->r.ping_comp.host_no;
++ ping_event.pid = ev->r.ping_comp.pid;
++ ping_event.status = ev->r.ping_comp.status;
++ ping_event.active = 1;
++
++ drop_data(nlh);
++ return 0;
+ default:
+ if ((ev->type > ISCSI_UEVENT_MAX && ev->type < KEVENT_BASE) ||
+ (ev->type > ISCSI_KEVENT_MAX))
+@@ -1299,6 +1540,9 @@ struct iscsi_ipc nl_ipc = {
+ .recv_pdu_end = krecv_pdu_end,
+ .set_net_config = kset_net_config,
+ .recv_conn_state = krecv_conn_state,
++ .exec_ping = kexec_ping,
++ .get_chap = kget_chap,
++ .delete_chap = kdelete_chap,
+ };
+ struct iscsi_ipc *ipc = &nl_ipc;
+
diff --git a/iscsi-initiator-utils-sync-iscsi.patch b/iscsi-initiator-utils-sync-iscsi.patch
index bde2f24..3d52d45 100644
--- a/iscsi-initiator-utils-sync-iscsi.patch
+++ b/iscsi-initiator-utils-sync-iscsi.patch
@@ -1,6 +1,6 @@
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/Changelog open-iscsi-2.0-872-rc4-bnx2i.sync/Changelog
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/Changelog open-iscsi-2.0-872-rc4-bnx2i.work/Changelog
--- open-iscsi-2.0-872-rc4-bnx2i/Changelog 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/Changelog 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/Changelog 2012-03-05 23:02:46.000000000 -0600
@@ -1,132 +1,114 @@
-open-iscsi-2.0-871 - open-iscsi-2.0.870
+open-iscsi-2.0-872 - open-iscsi-2.0.871
@@ -243,9 +243,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/Changelog open-iscsi-2.0-872-rc4-bnx2i.
+Wulf C. Krueger (1):
+ Use DESTDIR when generating an InitiatorName.
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/doc/iscsiadm.8 open-iscsi-2.0-872-rc4-bnx2i.sync/doc/iscsiadm.8
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/doc/iscsiadm.8 open-iscsi-2.0-872-rc4-bnx2i.work/doc/iscsiadm.8
--- open-iscsi-2.0-872-rc4-bnx2i/doc/iscsiadm.8 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/doc/iscsiadm.8 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/doc/iscsiadm.8 2012-03-05 23:02:46.000000000 -0600
@@ -10,13 +10,13 @@ iscsiadm \- open-iscsi administration ut
\fBiscsiadm\fR \-m node [ \-hV ] [ \-d debug_level ] [ \-P printlevel ] [ \-L all,manual,automatic ] [ \-U all,manual,automatic ] [ \-S ] [ [ \-T targetname \-p ip:port \-I iface ] [ \-l | \-u | \-R | \-s] ]
[ [ \-o operation ] [ \-n name ] [ \-v value ] [ \-p ip:port ] ]
@@ -475,10 +475,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/doc/iscsiadm.8 open-iscsi-2.0-872-rc4-b
.SH EXAMPLES
.nf
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/doc/iscsid.8 open-iscsi-2.0-872-rc4-bnx2i.sync/doc/iscsid.8
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/doc/iscsid.8 open-iscsi-2.0-872-rc4-bnx2i.work/doc/iscsid.8
--- open-iscsi-2.0-872-rc4-bnx2i/doc/iscsid.8 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/doc/iscsid.8 2011-08-14 16:48:25.000000000 -0500
-@@ -35,6 +35,9 @@ run under user ID \fIuid\fR (default is
++++ open-iscsi-2.0-872-rc4-bnx2i.work/doc/iscsid.8 2012-03-05 23:02:46.000000000 -0600
+@@ -35,6 +35,9 @@ run under user ID \fIuid\fR (default is
.BI [-g|--gid=]\fIgid\fP
run under user group ID \fIgid\fR (default is the current user group ID).
.TP
@@ -488,9 +488,23 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/doc/iscsid.8 open-iscsi-2.0-872-rc4-bnx
.BI [-p|--pid=]\fIpid\-file\fP
write process ID to \fIpid\-file\fR rather than the default
\fI/var/run/iscsid.pid\fR
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/iface.example open-iscsi-2.0-872-rc4-bnx2i.sync/etc/iface.example
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/doc/iscsistart.8 open-iscsi-2.0-872-rc4-bnx2i.work/doc/iscsistart.8
+--- open-iscsi-2.0-872-rc4-bnx2i/doc/iscsistart.8 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/doc/iscsistart.8 2012-03-05 23:06:00.000000000 -0600
+@@ -51,6 +51,10 @@ Bring up the network as specified by iBF
+ .BI [-f|--fwparam_print]
+ Print the iBFT or OF info to STDOUT
+ .TP
++.BI [-P|--param=]\fINAME=VALUE\fP
++Set the parameter with the name NAME to VALUE. NAME is one of the settings
++in the node record or iscsid.conf. Multiple params can be passed in.
++.TP
+ .BI [-h|--help]
+ Display this help and exit
+ .TP
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/iface.example open-iscsi-2.0-872-rc4-bnx2i.work/etc/iface.example
--- open-iscsi-2.0-872-rc4-bnx2i/etc/iface.example 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/etc/iface.example 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/etc/iface.example 2012-03-05 23:02:46.000000000 -0600
@@ -60,3 +60,138 @@
# the same subnet.
# iface.net_ifacename = eth0
@@ -630,9 +644,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/iface.example open-iscsi-2.0-872-rc
+# iface.vlan = <empty>
+# iface.iface_num = 0
+# END RECORD
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/initd/boot.suse open-iscsi-2.0-872-rc4-bnx2i.sync/etc/initd/boot.suse
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/initd/boot.suse open-iscsi-2.0-872-rc4-bnx2i.work/etc/initd/boot.suse
--- open-iscsi-2.0-872-rc4-bnx2i/etc/initd/boot.suse 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/etc/initd/boot.suse 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/etc/initd/boot.suse 2012-03-05 23:02:46.000000000 -0600
@@ -4,36 +4,37 @@
#
### BEGIN INIT INFO
@@ -713,9 +727,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/initd/boot.suse open-iscsi-2.0-872-
exit 1
;;
esac
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/initd/initd.suse open-iscsi-2.0-872-rc4-bnx2i.sync/etc/initd/initd.suse
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/initd/initd.suse open-iscsi-2.0-872-rc4-bnx2i.work/etc/initd/initd.suse
--- open-iscsi-2.0-872-rc4-bnx2i/etc/initd/initd.suse 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/etc/initd/initd.suse 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/etc/initd/initd.suse 2012-03-05 23:02:46.000000000 -0600
@@ -5,20 +5,22 @@
### BEGIN INIT INFO
# Provides: iscsi
@@ -1262,9 +1276,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/initd/initd.suse open-iscsi-2.0-872
exit 1
;;
esac
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/iscsid.conf open-iscsi-2.0-872-rc4-bnx2i.sync/etc/iscsid.conf
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/iscsid.conf open-iscsi-2.0-872-rc4-bnx2i.work/etc/iscsid.conf
--- open-iscsi-2.0-872-rc4-bnx2i/etc/iscsid.conf 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/etc/iscsid.conf 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/etc/iscsid.conf 2012-03-05 23:02:46.000000000 -0600
@@ -39,6 +39,10 @@ iscsid.startup = /sbin/iscsid
# To manually startup the session set to "manual". The default is manual.
node.startup = manual
@@ -1288,9 +1302,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/etc/iscsid.conf open-iscsi-2.0-872-rc4-
#************
# Workarounds
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_err.h open-iscsi-2.0-872-rc4-bnx2i.sync/include/iscsi_err.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_err.h open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_err.h
--- open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_err.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/include/iscsi_err.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_err.h 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,69 @@
+/*
+ * Return codes used by iSCSI tools.
@@ -1361,9 +1375,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_err.h open-iscsi-2.0-872-
+extern char *iscsi_err_to_str(int err);
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-rc4-bnx2i.sync/include/iscsi_if.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_if.h
--- open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/include/iscsi_if.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_if.h 2012-03-05 23:06:18.000000000 -0600
@@ -64,6 +64,9 @@ enum iscsi_uevent_e {
ISCSI_UEVENT_TRANSPORT_EP_CONNECT_THROUGH_HOST = UEVENT_BASE + 19,
@@ -1374,17 +1388,32 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
/* up events */
ISCSI_KEVENT_RECV_PDU = KEVENT_BASE + 1,
-@@ -75,6 +78,9 @@ enum iscsi_uevent_e {
+@@ -75,6 +78,10 @@ enum iscsi_uevent_e {
ISCSI_KEVENT_PATH_REQ = KEVENT_BASE + 7,
ISCSI_KEVENT_IF_DOWN = KEVENT_BASE + 8,
+ ISCSI_KEVENT_CONN_LOGIN_STATE = KEVENT_BASE + 9,
++ ISCSI_KEVENT_HOST_EVENT = KEVENT_BASE + 10,
+
-+ ISCSI_KEVENT_MAX = ISCSI_KEVENT_CONN_LOGIN_STATE,
++ ISCSI_KEVENT_MAX = ISCSI_KEVENT_HOST_EVENT,
};
enum iscsi_tgt_dscvr {
-@@ -177,6 +183,10 @@ struct iscsi_uevent {
+@@ -83,6 +90,13 @@ enum iscsi_tgt_dscvr {
+ ISCSI_TGT_DSCVR_SLP = 3,
+ };
+
++enum iscsi_host_event_code {
++ ISCSI_EVENT_LINKUP = 1,
++ ISCSI_EVENT_LINKDOWN,
++ /* must always be last */
++ ISCSI_EVENT_MAX,
++};
++
+ struct iscsi_uevent {
+ uint32_t type; /* k/u events type */
+ uint32_t iferror; /* carries interface or resource errors */
+@@ -177,6 +191,10 @@ struct iscsi_uevent {
struct msg_set_path {
uint32_t host_no;
} set_path;
@@ -1395,7 +1424,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
} u;
union {
/* messages k -> u */
-@@ -198,6 +208,11 @@ struct iscsi_uevent {
+@@ -198,6 +216,11 @@ struct iscsi_uevent {
uint32_t cid;
uint64_t recv_handle;
} recv_req;
@@ -1407,7 +1436,15 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
struct msg_conn_error {
uint32_t sid;
uint32_t cid;
-@@ -219,6 +234,21 @@ struct iscsi_uevent {
+@@ -216,9 +239,29 @@ struct iscsi_uevent {
+ struct msg_notify_if_down {
+ uint32_t host_no;
+ } notify_if_down;
++ struct msg_host_event {
++ uint32_t host_no;
++ uint32_t data_size;
++ enum iscsi_host_event_code code;
++ } host_event;
} r;
} __attribute__ ((aligned (sizeof(uint64_t))));
@@ -1429,7 +1466,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
/*
* To keep the struct iscsi_uevent size the same for userspace code
* compatibility, the main structure for ISCSI_UEVENT_PATH_UPDATE and
-@@ -242,6 +272,70 @@ struct iscsi_path {
+@@ -242,6 +285,71 @@ struct iscsi_path {
uint16_t pmtu;
} __attribute__ ((aligned (sizeof(uint64_t))));
@@ -1481,10 +1518,11 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
+ ISCSI_NET_PARAM_VLAN_ID = 13,
+ ISCSI_NET_PARAM_VLAN_PRIORITY = 14,
+ ISCSI_NET_PARAM_VLAN_ENABLED = 15,
-+ ISCSI_NET_PARAM_IFACE_TYPE = 16,
-+ ISCSI_NET_PARAM_IFACE_NAME = 17,
-+ ISCSI_NET_PARAM_MTU = 18,
-+ ISCSI_NET_PARAM_PORT = 19,
++ ISCSI_NET_PARAM_VLAN_TAG = 16,
++ ISCSI_NET_PARAM_IFACE_TYPE = 17,
++ ISCSI_NET_PARAM_IFACE_NAME = 18,
++ ISCSI_NET_PARAM_MTU = 19,
++ ISCSI_NET_PARAM_PORT = 20,
+};
+
+enum iscsi_conn_state {
@@ -1500,7 +1538,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
/*
* Common error codes
*/
-@@ -268,6 +362,7 @@ enum iscsi_err {
+@@ -268,6 +376,7 @@ enum iscsi_err {
ISCSI_ERR_INVALID_HOST = ISCSI_ERR_BASE + 18,
ISCSI_ERR_XMIT_FAILED = ISCSI_ERR_BASE + 19,
ISCSI_ERR_TCP_CONN_CLOSE = ISCSI_ERR_BASE + 20,
@@ -1508,7 +1546,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
};
/*
-@@ -296,7 +391,7 @@ enum iscsi_param {
+@@ -296,7 +405,7 @@ enum iscsi_param {
ISCSI_PARAM_PERSISTENT_PORT,
ISCSI_PARAM_SESS_RECOVERY_TMO,
@@ -1517,7 +1555,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
ISCSI_PARAM_CONN_PORT,
ISCSI_PARAM_CONN_ADDRESS,
-@@ -318,6 +413,7 @@ enum iscsi_param {
+@@ -318,6 +427,7 @@ enum iscsi_param {
ISCSI_PARAM_INITIATOR_NAME,
ISCSI_PARAM_TGT_RESET_TMO,
@@ -1525,7 +1563,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
/* must always be last */
ISCSI_PARAM_MAX,
};
-@@ -358,6 +454,7 @@ enum iscsi_param {
+@@ -358,6 +468,7 @@ enum iscsi_param {
#define ISCSI_ISID (1ULL << ISCSI_PARAM_ISID)
#define ISCSI_INITIATOR_NAME (1ULL << ISCSI_PARAM_INITIATOR_NAME)
#define ISCSI_TGT_RESET_TMO (1ULL << ISCSI_PARAM_TGT_RESET_TMO)
@@ -1533,7 +1571,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
/* iSCSI HBA params */
enum iscsi_host_param {
-@@ -394,6 +491,7 @@ enum iscsi_host_param {
+@@ -394,6 +505,7 @@ enum iscsi_host_param {
#define CAP_DIGEST_OFFLOAD 0x1000 /* offload hdr and data digests */
#define CAP_PADDING_OFFLOAD 0x2000 /* offload padding insertion, removal,
and verification */
@@ -1541,9 +1579,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_if.h open-iscsi-2.0-872-r
/*
* These flags describes reason of stop_conn() call
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/Makefile open-iscsi-2.0-872-rc4-bnx2i.sync/Makefile
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/Makefile open-iscsi-2.0-872-rc4-bnx2i.work/Makefile
--- open-iscsi-2.0-872-rc4-bnx2i/Makefile 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/Makefile 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/Makefile 2012-03-05 23:04:27.000000000 -0600
@@ -24,10 +24,10 @@ IFACEFILES = etc/iface.example
# using '$(MAKE)' instead of just 'make' allows make to run in parallel
# over multiple makefile.
@@ -1551,13 +1589,24 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/Makefile open-iscsi-2.0-872-rc4-bnx2i.s
-all: user kernel
+all: user
- user: ;
+-user: ;
- cd utils/open-isns; ./configure; $(MAKE)
-+ cd utils/open-isns; ./configure --with-security=no; $(MAKE)
++user: utils/open-isns/Makefile
++ $(MAKE) -C utils/open-isns
$(MAKE) -C utils/sysdeps
$(MAKE) -C utils/fwparam_ibft
$(MAKE) -C usr
-@@ -68,7 +68,7 @@ clean:
+@@ -41,6 +41,9 @@ user: ;
+ @echo
+ @echo "Read README file for detailed information."
+
++utils/open-isns/Makefile: utils/open-isns/configure utils/open-isns/Makefile.in
++ cd utils/open-isns; ./configure CFLAGS="$(OPTFLAGS)" --with-security=no
++
+ kernel: force
+ $(MAKE) -C kernel
+ @echo "Kernel Compilation complete Output file"
+@@ -68,7 +71,7 @@ clean:
install_initd_suse install_initd_redhat install_initd_debian \
install_etc install_iface install_doc install_kernel install_iname
@@ -1566,9 +1615,18 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/Makefile open-iscsi-2.0-872-rc4-bnx2i.s
install_initd install_iname install_iface
install_user: install_programs install_doc install_etc \
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/README open-iscsi-2.0-872-rc4-bnx2i.sync/README
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/README open-iscsi-2.0-872-rc4-bnx2i.work/README
--- open-iscsi-2.0-872-rc4-bnx2i/README 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/README 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/README 2012-03-05 23:03:47.000000000 -0600
+@@ -166,7 +166,7 @@ term node to refer to a portal on a targ
+ require that --targetname and --portal argument be used when in node mode.
+
+ For session mode, a session id (sid) is used. The sid of a session can be
+-found by running iscsiadm -m session -i. The session id is not currently
++found by running iscsiadm -m session -P 1. The session id is not currently
+ persistent and is partially determined by when the session is setup.
+
+ Note that some of the iSCSI Node and iSCSI Discovery operations
@@ -371,9 +371,10 @@ Usage: iscsiadm [OPTION]
iscsi_ifacename.
@@ -1719,418 +1777,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/README open-iscsi-2.0-872-rc4-bnx2i.syn
- iSCSI Login to a specific portal through the NIC setup as iface0:
./iscsiadm -m node -T iqn.2005-03.com.max -p 192.168.0.4:3260 \
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/TODO open-iscsi-2.0-872-rc4-bnx2i.sync/TODO
---- open-iscsi-2.0-872-rc4-bnx2i/TODO 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/TODO 2011-08-14 16:48:25.000000000 -0500
-@@ -0,0 +1,404 @@
-+iSCSI DEVELOPMENT HOWTO AND TODO
-+--------------------------------
-+July 7th 2011
-+
-+
-+If you are admin or user and just want to send a fix, just send the fix any
-+way you can. We can port the patch to the proper tree and fix up the patch
-+for you. Engineers that would like to do more advanced development then the
-+following guideline should be followed.
-+
-+Submitting Patches
-+------------------
-+Code should follow the Linux kernel codying style doc:
-+http://www.kernel.org/doc/Documentation/CodingStyle
-+
-+Patches should be submitted to the open-iscsi list open-iscsi at googlegroups.com.
-+They should be made with "git diff" or "diff -up" or "diff -uprN", and
-+kernel patches must have a "Signed-off-by" line. See section 12
-+http://www.kernel.org/doc/Documentation/SubmittingPatches for more
-+information on the the signed off line.
-+
-+Getting the Code
-+----------------
-+Kernel patches should be made against the linux-2.6-iscsi tree. This can
-+be downloaded from kernel.org with git with the following commands:
-+
-+git clone git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git
-+
-+Userspace patches should be made against the open-iscsi git tree:
-+
-+git clone git://git.kernel.org/pub/scm/linux/kernel/git/mnc/open-iscsi.git
-+
-+
-+
-+KERNEL TODO ITEMS
-+-----------------
-+
-+1. Make iSCSI log messages humanly readable. In many cases the iscsi tools
-+and modules will log a error number value. The most well known is conn
-+error 1011. Users should not have to search on google for what this means.
-+
-+We should:
-+
-+1. Write a simple table to convert the error values to a string and print
-+them out.
-+
-+2. Document the values, how you commonly hit them and common solutions
-+in the iSCSI docs.
-+
-+See scsi_transport_iscsi.c:iscsi_conn_error_event for where the evil
-+"detected conn error 1011" is printed. See the enum iscsi_err in iscsi_if.h
-+for a definition of the error code values.
-+
-+---------------------------------------------------------------------------
-+
-+2. Implement iSCSI dev loss support.
-+
-+Currently if a session is down for longer than replacement/recovery_timeout
-+seconds, the iscsi layer will unblock the devices and fail IO. Other
-+transport, like FC and SAS, will do something similar. FC has a
-+fast_io_fail tmo which will unblock devices and fail IO, then it has a
-+dev_loss_tmo which will delete the devices accessed through that port.
-+
-+iSCSI needs to implement dev_loss_tmo behavior, because apps are beginning
-+to expect this behavior. An initial path was made here:
-+http://groups.google.com/group/open-iscsi/msg/031510ab4cecccfd?dmode=source
-+
-+Since all drivers want this behavior we want to make it common. We need to
-+change the patch in that link to add a dev_loss_tmo handler callback to the
-+scsi_transport_template struct, and add some common sysfs and helpers
-+functions to manage the dev_loss_tmo variable.
-+
-+
-+*Being worked on by Vikek S
-+
-+---------------------------------------------------------------------------
-+
-+3. Reduce locking contention between session lock.
-+
-+The session lock is basically one big lock that protects everything
-+in the iscsi_session. This lock could be broken down into smaller locks
-+and maybe even replaced with something that would not require a lock.
-+
-+For example:
-+
-+1. The session lock serializes access to the current R2T the initiator is
-+handling (a R2T from the target or the initialR2T if being used). libiscsi/
-+libiscsi_tcp will call iscsi_tcp_get_curr_r2t and grab the session lock in
-+the xmit path from the xmit thread and then in the recv path
-+libiscsi_tcp/iscsi_tcp will call iscsi_tcp_r2t_rsp (this function is called
-+with the session lock held). We could add a new per iscsi_task lock and
-+use that to gaurd the R2T.
-+
-+2. For iscsi_tcp and cxgb*i, libiscsi uses the session->cmdqueue linked list
-+and the session lock to queue IO from the queuecommand function (run from
-+scsi softirq or kblockd context) to the iscsi xmit thread. Once the task is
-+sent from that thread, it is deleted from the list.
-+
-+It seems we should be able to remove the linked list use here. The tasks
-+are all preallocated in the session->cmds array. We can access that
-+array and check the task->state (see fail_scsi_tasks for an example).
-+We just need to come up with a way to safely set the task state,
-+wake the xmit thread and make sure that tasks are executed in the order
-+that the scsi layer sent them to our queuecommand function.
-+
-+A starting point on the queueing:
-+We might be able to create a workqueue per processor, queue the work,
-+which in this case is the execution of the task, from the queuecommand,
-+then rely on the work queue synchronization and serialization code.
-+Not 100% sure about this.
-+
-+Alternative to changing the threading:
-+Can we figure out a way to just remove the xmit thread? We currently
-+cannot because the network may only be able to send 1000 bytes, but
-+to send the current command we need to send 2000. We cannot sleep
-+from the queuecommand context until another 1000 bytes frees up and for
-+iscsi_tcp we cannot sleep from the recv conext (this happens because we
-+could have got a R2T from target and are handling it from the recv path).
-+
-+
-+Note: that for iser and offload drivers like bnx2i and be2iscsi their
-+is no xmit thread used.
-+
-+Note2: cxgb*i does not actually need the xmit thread so a side project
-+could be to convert that driver.
-+
-+
-+---------------------------------------------------------------------------
-+
-+4. Make memory access more efficient on multi-processor machines.
-+We are moving twords per process queues in the block layer, so it would
-+be a good idea to move the iscsi structs to be allocated on a per process
-+basis.
-+
-+---------------------------------------------------------------------------
-+
-+5. Make blk_iopoll support (see block/blk-iopoll.c and be2iscsi for an
-+example) being able to round robin IO across processors or complete
-+on the processor it was queued on
-+(today it always completes the IO on the processor the softirq was raised on),
-+and convert bnx2i, ib_iser and cxgb*i to it.
-+
-+Not sure if it will help iscsi_tcp and cxgb, because their completion is done
-+from the network softirq which does polling already. With irq balancing it
-+can also be spread over all processors too.
-+
-+---------------------------------------------------------------------------
-+
-+6. Replace iscsi_get_next_target_id with idr use.
-+
-+iscsi_tcp and ib_iser allocate a session per host, so the target_id is
-+always just 0. The offload drivers allocate a host per pci resource, so they
-+will have multiple sessions for each host. When a session is added,
-+iscsi_add_session will try to find a target_id to use by looping over
-+all the targets on the host. We could replace that loop with idr.
-+
-+
-+* Being worked on by John Jose.
-+
-+---------------------------------------------------------------------------
-+
-+7. When userspace calls into the kernel using the iscsi netlink interface
-+to execute oprations like creating/destroying a session, create a connection
-+to a target, etc the rx_queue_mutex is held the entire time (see
-+iscsi_if_rx for the iscsi netlink interface entry point). This means
-+if the driver should block every thing will be held up.
-+
-+iscsi_tcp does not block, but some offload drivers might for a couple seconds
-+to 10 or 15 secs while it figures out what is going on or cleans up. This a
-+major problem for things like multipath where one connection blocking up the
-+recovery of every other connection will delay IO from re-flowing quickly.
-+
-+We should looking into breaking up the rx_queue_mutex into finer grained
-+locks or making it multi threaded. For the latter we could queue operations
-+into workqueues.
-+
-+---------------------------------------------------------------------------
-+
-+7. Add tracing support to iscsi modules. See the scsi layer's
-+trace_scsi_dispatch_cmd_start for an example.
-+
-+Well, actually in general look into all the tracing stuff available
-+(trace_printk/ftrace, etc) and use one.
-+
-+See http://lwn.net/Articles/291091/ for some details on what is out
-+there. We can only use something that is upstream though.
-+
-+---------------------------------------------------------------------------
-+
-+8. Improve the iscsi driver logging. Each driver has a different
-+way to control logging. We should unify them and make it managable
-+by iscsiadm. So each driver would use a common format, there would
-+be a common kernel interface to set the logging level, etc.
-+
-+---------------------------------------------------------------------------
-+
-+9. Implement more features from the iSCSI RFC if they are worth it.
-+
-+- Error Recovery Level (ERL) 1 support - will help tape support.
-+- Multi R2T support - Might improve write performance.
-+- OutOfOrder support - Might imrpove performance.
-+
-+---------------------------------------------------------------------------
-+
-+10. Add support for digest/CRC offload.
-+
-+---------------------------------------------------------------------------
-+
-+11. Finish intel IOAT support. I started this here:
-+http://groups.google.com/group/open-iscsi/msg/2626b8606edbe690?dmode=source
-+but could only test on boxes with 1 gig interfaces which showed no
-+difference in performance. Intel had said they saw significant throughput
-+gains when using 10 gig.
-+
-+---------------------------------------------------------------------------
-+
-+12. Remove the login buffer preallocated buffer. Storage drivers must be able
-+to make forward process, so that they can always write out a page incase the
-+kernel needs to allocate the page to another process. If the connection were
-+to be disconnected and the initiator needed to relogin to the target at this
-+time, we might not be abe to allocate a page for the login commands buffer.
-+
-+To work around the problem the initiator prealloctes a 8K (sometimes
-+more depending on the page size) buffer for each session (see iscsi_conn_setup'
-+s __get_free_pages call). This is obviously very wasteful since it will be
-+a rate occurance. Can we think of a way to allow multiple sessions to
-+be relogged in at the same time, but not have to preallocate so many
-+buffers?
-+
-+---------------------------------------------------------------------------
-+
-+13. Support iSCSI over swap safely.
-+
-+Basically just need to hook iscsi_tcp into the patches that
-+were submitted here for NBD.
-+
-+https://lwn.net/Articles/446831/
-+
-+
-+---------------------------------------------------------------------------
-+
-+
-+
-+
-+
-+USERSPACE TODO ITEMS
-+--------------------
-+1. The iscsi tools, iscsid, iscsiadm and iscsid, have a debug flag, -d N, that
-+allows the user to control the amount of output that is logged. The argument
-+N is a integer from 1 to 8, with 8 printing out the most output.
-+
-+The problem is that the values from 1 to 8 do not really mean much. It would
-+helpful if we could replace them with something that controls what exactly
-+the iscsi tools and kernel modules log.
-+
-+For example, if we made the debug level argument a bitmap then
-+
-+iscsiadm -m node --login -d LOGIN_ERRS,PDUS,FUNCTION
-+
-+might print out extended iscsi login error information (LOGIN_ERRS),
-+the iSCSI packets that were sent/receieved (PDUS), and the functions
-+that were run (FUNCTION). Note, the use of a bitmapp and the debug
-+levels are just an example. Feel free to do something else.
-+
-+
-+We would want to be able to have iscsiadm control the iscsi kernel
-+logging as well. There are interfaces like
-+/sys/module/libiscsi/paramters/*debug*
-+/sys/module/libiscsi_tcp/paramters/*debug*
-+/sys/module/iscsi_tcp/paramters/*debug*
-+/sys/module/scsi_transport_iscsi/paramters/*debug*
-+
-+but we would want to extend the debugging options to be finer grained
-+and we would want to make it supportable by all iscsi drivers.
-+(see #8 on the kernel todo).
-+
-+---------------------------------------------------------------------------
-+
-+2. "iscsiadm -m session -P 3" can print out a lot of information about the
-+session, but not all configuration values are printed.
-+
-+iscsiadm should be modified to print out other settings like timeouts,
-+Chap settings, the iSCSI values that were requested vs negotiated for, etc.
-+
-+---------------------------------------------------------------------------
-+
-+3. iscsiadm cannot update a setting of a running session. If you want
-+to change a timeout you have to run the iscsiadm logout command,
-+then update the record value, then login:
-+
-+iscsiadm -m node -T target -p ip -u
-+iscsidm -m node -T target -p ip -o update -n node.session.timeo.replacement_timeout -v 30
-+iscsiadm -m node -T target -p ip -l
-+
-+iscsiadm should be modified to allow updating of a setting without having
-+to run the iscsiadm command.
-+
-+Note that for some settings like iSCSI ones (ImmediateData, FirstBurstLength,
-+etc) that must be negotiated with the target we will have to logout the
-+target then re-login, but we should not have to completely destroy the session
-+and scsi devices like is done when running the iscsiadm logout command. We
-+should be able to pass iscsid the new values and then have iscsid logout and
-+relogin.
-+
-+Other settings like the abort timeout will not need a logout/login. We can
-+just pass those to the kernel or iscsid to use.
-+
-+
-+*Being worked on by Tomoaki Nishimura
-+
-+---------------------------------------------------------------------------
-+
-+4. iscsiadm will attempt to perform logins/logouts in parallel. Running
-+iscsiadm -m node -L, will cause iscsiadm to login to all portals with
-+the startup=automatic field set at the same time.
-+
-+To log into a target, iscsiadm opens a socket to iscsid, sends iscsid a
-+request to login to a target, iscsid performs the iSCSI login operation,
-+then iscsid sends iscsiadm a reply.
-+
-+To perform multiple logins iscsiadm will open a socket for each login
-+request, then wait for a reply. This is a problem because for 1000s of targets
-+we will have 1000s of sockets open. There is a rlimit to control how many
-+files a process can have open and iscsiadm currently runs setrlimit to
-+increase this.
-+
-+With users creating lots of virtual iscsi interfaces on the target and
-+initiator with each having multiple paths it beomes inefficient to open
-+a socket for each requests.
-+
-+At the very least we want to handle setrlimit RLIMIT_NOFILE limit better,
-+and it would be best to just stop openening a socket per login request.
-+
-+---------------------------------------------------------------------------
-+
-+5. Make iSCSI log messages humanly readable. In many cases the iscsi tools
-+will log a error number value. The most well known is conn error 1011.
-+Users should not have to search on google for what this means.
-+
-+We should:
-+
-+1. Write a simple table to convert the error values to a string and print
-+them out.
-+
-+2. Document the values, how you commonly hit them and common solutions
-+in the iSCSI docs.
-+
-+
-+See session_conn_error and __check_iscsi_status_class as a start.
-+
-+---------------------------------------------------------------------------
-+
-+6. Implement broadcast/multicasts support, so the initiator can
-+find iSNS servers without the user having to set the iSNS server address.
-+
-+See
-+5.6.5.14. Name Service Heartbeat (Heartbeat)
-+in
-+http://tools.ietf.org/html//rfc4171
-+
-+---------------------------------------------------------------------------
-+
-+7. Open-iscsi uses the open-isns iSNS library. The library might be a little
-+too complicated and a little too heavy for what we need. Investigate
-+replacing it.
-+
-+Also explore merging the open-isns and linux-isns projects, so we do not have
-+to support multiple isns clients/servers in linux.
-+
-+---------------------------------------------------------------------------
-+
-+8. Implement the DHCP iSNS option support, so we the initiator can
-+find the iSNS sever without the user having to set the iSNS server address.
-+See:
-+http://www.ietf.org/rfc/rfc4174.txt
-+
-+---------------------------------------------------------------------------
-+
-+9. Some iscsiadm/iscsid operations that access the iscsi DB and sysfs can be
-+up to Big O(N^2). Some of the code was written when we thought 64 sessions
-+would be a lot and the norm would be 4 or 8. Due to virtualization, cloud use,
-+and targets like equallogic that do a target per logical unit (device) we can
-+see 1000s of sessions.
-+
-+- We should look into making the record DB more efficient. Maybe
-+time to use a real DB (something small simple and efficient since this
-+needs to run in places like the initramfs).
-+
-+- Rewrite code to look up a running session so we do not have loop
-+over every session in sysfs.
-+
-+
-+---------------------------------------------------------------------------
-+
-+10. Look into using udev's libudev for our sysfs access in iscsiadm/iscsid/
-+iscsistart.
-+
-+---------------------------------------------------------------------------
-+
-+11. iSCSI lib.
-+
-+I am working on this one. Hopefully it should be done soon.
-+
-+---------------------------------------------------------------------------
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/actor.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/actor.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/actor.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/actor.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/actor.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/actor.c 2011-08-14 16:48:25.000000000 -0500
-@@ -113,14 +113,13 @@ actor_schedule_private(actor_t *thread,
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/actor.c 2012-03-05 23:02:46.000000000 -0600
+@@ -113,14 +113,13 @@ actor_schedule_private(actor_t *thread,
* state to scheduled, else add current time to ttschedule and
* insert in the queue at the correct point */
if (delay_time == 0) {
@@ -2151,9 +1801,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/actor.c open-iscsi-2.0-872-rc4-bnx2
} else {
thread->state = ACTOR_SCHEDULED;
if (head)
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/auth.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/auth.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/auth.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/auth.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/auth.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/auth.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/auth.c 2012-03-05 23:02:46.000000000 -0600
@@ -194,27 +194,20 @@ get_random_bytes(unsigned char *data, un
fd = open("/dev/urandom", O_RDONLY);
while (length > 0) {
@@ -2185,9 +1835,18 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/auth.c open-iscsi-2.0-872-rc4-bnx2i
r = r ^ (r >> 8);
r = r ^ (r >> 5);
n = (n << 2) | (r & 0x3);
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/config.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/config.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/config.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/config.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/config.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/config.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/config.h 2012-03-05 23:03:29.000000000 -0600
+@@ -73,7 +73,7 @@ struct iscsi_connection_timeout_config {
+ int noop_out_timeout;
+ };
+
+-/* all per-connection timeouts go in this structure.
++/* all per-session timeouts go in this structure.
+ * this structure is per-session, and can be configured
+ * by TargetName but not by Subnet.
+ */
@@ -141,7 +141,8 @@ struct iscsi_sendtargets_config {
int discoveryd_poll_inval;
struct iscsi_auth_config auth;
@@ -2253,9 +1912,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/config.h open-iscsi-2.0-872-rc4-bnx
session_rec_t session;
conn_rec_t conn[ISCSI_CONN_MAX];
iface_rec_t iface;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgb3i.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/cxgb3i.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgb3i.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/cxgb3i.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/cxgb3i.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/cxgb3i.c 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/cxgb3i.c 1969-12-31 18:00:00.000000000 -0600
@@ -1,24 +0,0 @@
-/*
- * cxgb3i helpers
@@ -2281,9 +1940,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgb3i.c open-iscsi-2.0-872-rc4-bnx
- if (conn->max_recv_dlength > 8192)
- conn->max_recv_dlength = 8192;
-}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgb3i.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/cxgb3i.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgb3i.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/cxgb3i.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/cxgb3i.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/cxgb3i.h 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/cxgb3i.h 1969-12-31 18:00:00.000000000 -0600
@@ -1,8 +0,0 @@
-#ifndef CXGB3I_TRANSPORT
-#define CXGB3I_TRANSPORT
@@ -2293,9 +1952,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgb3i.h open-iscsi-2.0-872-rc4-bnx
-extern void cxgb3i_create_conn(struct iscsi_conn *conn);
-
-#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgbi.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/cxgbi.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgbi.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/cxgbi.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/cxgbi.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/cxgbi.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/cxgbi.c 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,24 @@
+/*
+ * cxgb3i/cxgb4i helpers
@@ -2321,9 +1980,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgbi.c open-iscsi-2.0-872-rc4-bnx2
+ if (conn->max_recv_dlength > 8192)
+ conn->max_recv_dlength = 8192;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgbi.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/cxgbi.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgbi.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/cxgbi.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/cxgbi.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/cxgbi.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/cxgbi.h 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,8 @@
+#ifndef CXGBI_TRANSPORT
+#define CXGBI_TRANSPORT
@@ -2333,9 +1992,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/cxgbi.h open-iscsi-2.0-872-rc4-bnx2
+extern void cxgbi_create_conn(struct iscsi_conn *conn);
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/dcb_app.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/dcb_app.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/dcb_app.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/dcb_app.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/dcb_app.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/dcb_app.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/dcb_app.c 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,387 @@
+/*******************************************************************************
+
@@ -2724,9 +2383,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/dcb_app.c open-iscsi-2.0-872-rc4-bn
+ return get_app_pri(ifname, DCB_APP_IDTYPE_ETHTYPE, ethtype,
+ IEEE_SMASK_ETHTYPE);
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/dcb_app.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/dcb_app.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/dcb_app.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/dcb_app.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/dcb_app.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/dcb_app.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/dcb_app.h 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,41 @@
+/*******************************************************************************
+
@@ -2769,9 +2428,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/dcb_app.h open-iscsi-2.0-872-rc4-bn
+int get_dcb_app_pri_by_port_sel(const char *ifname, int port, int sel);
+
+#endif /* _DCB_APP_H_ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/dcbnl.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/dcbnl.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/dcbnl.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/dcbnl.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/dcbnl.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/dcbnl.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/dcbnl.h 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,653 @@
+/*
+ * Local copy of the kernel's dcbnl.h
@@ -3426,9 +3085,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/dcbnl.h open-iscsi-2.0-872-rc4-bnx2
+};
+
+#endif /* __LINUX_DCBNL_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/discovery.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/discovery.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/discovery.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/discovery.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/discovery.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/discovery.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/discovery.c 2012-03-05 23:02:46.000000000 -0600
@@ -43,6 +43,12 @@
#include "fw_context.h"
#include "iscsid_req.h"
@@ -4874,9 +4533,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/discovery.c open-iscsi-2.0-872-rc4-
return rc;
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/discoveryd.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/discoveryd.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/discoveryd.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/discoveryd.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/discoveryd.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/discoveryd.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/discoveryd.c 2012-03-05 23:02:46.000000000 -0600
@@ -44,6 +44,7 @@
#include "isns.h"
#include "paths.h"
@@ -5120,9 +4779,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/discoveryd.c open-iscsi-2.0-872-rc4
fork_disc(data, drec, drec->u.isns.discoveryd_poll_inval, start_isns);
return 0;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/event_poll.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/event_poll.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/event_poll.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/event_poll.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/event_poll.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/event_poll.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/event_poll.c 2012-03-05 23:02:46.000000000 -0600
@@ -35,6 +35,7 @@
#include "iscsi_ipc.h"
#include "actor.h"
@@ -5138,9 +4797,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/event_poll.c open-iscsi-2.0-872-rc4
- mgmt_ipc_write_rsp(shutdown_qtask, MGMT_IPC_OK);
+ mgmt_ipc_write_rsp(shutdown_qtask, ISCSI_SUCCESS);
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/host.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/host.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/host.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/host.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/host.c 2012-03-05 23:04:22.000000000 -0600
@@ -33,6 +33,7 @@
#include "transport.h"
#include "initiator.h"
@@ -5149,7 +4808,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.c open-iscsi-2.0-872-rc4-bnx2i
static int match_host_to_session(void *data, struct session_info *info)
{
-@@ -117,6 +118,47 @@ static int host_info_print_flat(void *da
+@@ -117,6 +118,92 @@ static int host_info_print_flat(void *da
return 0;
}
@@ -5167,22 +4826,67 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.c open-iscsi-2.0-872-rc4-bnx2i
+ printf("%sIPaddress: %s\n", prefix, UNKNOWN_VALUE);
+ else if (strchr(iface->ipaddress, '.')) {
+ printf("%sIPaddress: %s\n", prefix, iface->ipaddress);
-+ printf("%sGateway: %s\n", prefix, iface->gateway);
-+ printf("%sSubnet: %s\n", prefix, iface->subnet_mask);
-+ printf("%sBootProto: %s\n", prefix, iface->bootproto);
++
++ if (!strlen(iface->gateway))
++ printf("%sGateway: %s\n", prefix, UNKNOWN_VALUE);
++ else
++ printf("%sGateway: %s\n", prefix, iface->gateway);
++ if (!strlen(iface->subnet_mask))
++ printf("%sSubnet: %s\n", prefix, UNKNOWN_VALUE);
++ else
++ printf("%sSubnet: %s\n", prefix, iface->subnet_mask);
++ if (!strlen(iface->bootproto))
++ printf("%sBootProto: %s\n", prefix, UNKNOWN_VALUE);
++ else
++ printf("%sBootProto: %s\n", prefix, iface->bootproto);
+ } else {
+ printf("%sIPaddress: [%s]\n", prefix, iface->ipaddress);
-+ printf("%sIPaddress Autocfg: %s\n", prefix, iface->ipv6_autocfg);
-+ printf("%sLink Local Address: [%s]\n", prefix,
-+ iface->ipv6_linklocal);
-+ printf("%sLink Local Autocfg: %s\n", prefix,
-+ iface->linklocal_autocfg);
-+ printf("%sRouter Address: [%s]\n", prefix, iface->ipv6_router);
++
++ if (!strlen(iface->ipv6_autocfg))
++ printf("%sIPaddress Autocfg: %s\n", prefix,
++ UNKNOWN_VALUE);
++ else
++ printf("%sIPaddress Autocfg: %s\n", prefix,
++ iface->ipv6_autocfg);
++ if (!strlen(iface->ipv6_linklocal))
++ printf("%sLink Local Address: %s\n", prefix,
++ UNKNOWN_VALUE);
++ else
++ printf("%sLink Local Address: [%s]\n", prefix,
++ iface->ipv6_linklocal);
++ if (!strlen(iface->linklocal_autocfg))
++ printf("%sLink Local Autocfg: %s\n", prefix,
++ UNKNOWN_VALUE);
++ else
++ printf("%sLink Local Autocfg: %s\n", prefix,
++ iface->linklocal_autocfg);
++ if (!strlen(iface->ipv6_router))
++ printf("%sRouter Address: %s\n", prefix,
++ UNKNOWN_VALUE);
++ else
++ printf("%sRouter Address: [%s]\n", prefix,
++ iface->ipv6_router);
+ }
+
-+ printf("%sMTU: %u\n", prefix, iface->mtu);
-+ printf("%svlan ID: %u\n", prefix, iface->vlan_id);
-+ printf("%svlan priority: %u\n", prefix, iface->vlan_priority);
++ if (!iface->port)
++ printf("%sPort: %s\n", prefix, UNKNOWN_VALUE);
++ else
++ printf("%sPort: %u\n", prefix, iface->port);
++
++ if (!iface->mtu)
++ printf("%sMTU: %s\n", prefix, UNKNOWN_VALUE);
++ else
++ printf("%sMTU: %u\n", prefix, iface->mtu);
++
++ if (iface->vlan_id == UINT16_MAX)
++ printf("%sVLAN ID: %s\n", prefix, UNKNOWN_VALUE);
++ else
++ printf("%sVLAN ID: %u\n", prefix, iface->vlan_id);
++
++ if (iface->vlan_priority == UINT8_MAX)
++ printf("%sVLAN priority: %s\n", prefix, UNKNOWN_VALUE);
++ else
++ printf("%sVLAN priority: %u\n", prefix, iface->vlan_priority);
+ return 0;
+}
+
@@ -5197,7 +4901,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.c open-iscsi-2.0-872-rc4-bnx2i
static int host_info_print_tree(void *data, struct host_info *hinfo)
{
struct list_head sessions;
-@@ -127,6 +169,7 @@ static int host_info_print_tree(void *da
+@@ -127,6 +214,7 @@ static int host_info_print_tree(void *da
INIT_LIST_HEAD(&sessions);
@@ -5205,7 +4909,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.c open-iscsi-2.0-872-rc4-bnx2i
printf("Host Number: %u\n", hinfo->host_no);
if (!iscsi_sysfs_get_host_state(state, hinfo->host_no))
printf("\tState: %s\n", state);
-@@ -134,6 +177,8 @@ static int host_info_print_tree(void *da
+@@ -134,6 +222,8 @@ static int host_info_print_tree(void *da
printf("\tState: Unknown\n");
print_host_info(&hinfo->iface, "\t");
@@ -5214,7 +4918,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.c open-iscsi-2.0-872-rc4-bnx2i
if (!session_info_flags)
return 0;
-@@ -150,7 +195,7 @@ static int host_info_print_tree(void *da
+@@ -150,7 +240,7 @@ static int host_info_print_tree(void *da
printf("\tSessions:\n");
printf("\t*********\n");
@@ -5223,7 +4927,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.c open-iscsi-2.0-872-rc4-bnx2i
session_info_free_list(&sessions);
return 0;
}
-@@ -200,13 +245,16 @@ int host_info_print(int info_level, uint
+@@ -200,13 +290,16 @@ int host_info_print(int info_level, uint
break;
default:
log_error("Invalid info level %d. Try 0 - 4.", info_level);
@@ -5243,9 +4947,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/host.c open-iscsi-2.0-872-rc4-bnx2i
+ }
return 0;
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/idbm.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/idbm.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.c 2012-03-05 23:06:00.000000000 -0600
@@ -40,6 +40,7 @@
#include "iface.h"
#include "sysdeps.h"
@@ -5301,7 +5005,40 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
/*
* Note: because we do not add the iface.iscsi_ifacename to
* sysfs iscsiadm does some weird matching. We can change the iface
-@@ -247,6 +272,8 @@ idbm_recinfo_node(node_rec_t *r, recinfo
+@@ -230,6 +255,32 @@ idbm_recinfo_node(node_rec_t *r, recinfo
+ __recinfo_str(IFACE_TRANSPORTNAME, ri, r, iface.transport_name,
+ IDBM_SHOW, num, 1);
+ __recinfo_str(IFACE_INAME, ri, r, iface.iname, IDBM_SHOW, num, 1);
++ __recinfo_str(IFACE_BOOT_PROTO, ri, r, iface.bootproto, IDBM_SHOW,
++ num, 1);
++ __recinfo_str(IFACE_SUBNET_MASK, ri, r, iface.subnet_mask,
++ IDBM_SHOW, num, 1);
++ __recinfo_str(IFACE_GATEWAY, ri, r, iface.gateway, IDBM_SHOW, num, 1);
++ __recinfo_str(IFACE_IPV6_AUTOCFG, ri, r, iface.ipv6_autocfg,
++ IDBM_SHOW, num, 1);
++ __recinfo_str(IFACE_LINKLOCAL_AUTOCFG, ri, r, iface.linklocal_autocfg,
++ IDBM_SHOW, num, 1);
++ __recinfo_str(IFACE_ROUTER_AUTOCFG, ri, r, iface.router_autocfg,
++ IDBM_SHOW, num, 1);
++ __recinfo_str(IFACE_LINKLOCAL, ri, r, iface.ipv6_linklocal,
++ IDBM_SHOW, num, 1);
++ __recinfo_str(IFACE_ROUTER, ri, r, iface.ipv6_router, IDBM_SHOW, num,
++ 1);
++ __recinfo_str(IFACE_STATE, ri, r, iface.state, IDBM_SHOW, num, 1);
++ __recinfo_uint16(IFACE_VLAN_ID, ri, r, iface.vlan_id, IDBM_SHOW, num,
++ 1);
++ __recinfo_uint8(IFACE_VLAN_PRIORITY, ri, r, iface.vlan_priority,
++ IDBM_SHOW, num, 1);
++ __recinfo_str(IFACE_VLAN_STATE, ri, r, iface.vlan_state, IDBM_SHOW,
++ num, 1);
++ __recinfo_int(IFACE_NUM, ri, r, iface.iface_num, IDBM_SHOW, num, 1);
++ __recinfo_uint16(IFACE_MTU, ri, r, iface.mtu, IDBM_SHOW, num, 1);
++ __recinfo_uint16(IFACE_PORT, ri, r, iface.port, IDBM_SHOW, num, 1);
++
+ __recinfo_str(NODE_DISC_ADDR, ri, r, disc_address, IDBM_SHOW,
+ num, 0);
+ __recinfo_int(NODE_DISC_PORT, ri, r, disc_port, IDBM_SHOW,
+@@ -247,6 +298,8 @@ idbm_recinfo_node(node_rec_t *r, recinfo
session.cmds_max, IDBM_SHOW, num, 1);
__recinfo_int(SESSION_QDEPTH, ri, r,
session.queue_depth, IDBM_SHOW, num, 1);
@@ -5310,7 +5047,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
__recinfo_int_o2(SESSION_AUTH_METHOD, ri, r, session.auth.authmethod,
IDBM_SHOW, "None", "CHAP", num, 1);
__recinfo_str(SESSION_USERNAME, ri, r,
-@@ -369,6 +396,27 @@ void idbm_recinfo_iface(iface_rec_t *r,
+@@ -369,6 +422,27 @@ void idbm_recinfo_iface(iface_rec_t *r,
__recinfo_str(IFACE_TRANSPORTNAME, ri, r, transport_name,
IDBM_SHOW, num, 1);
__recinfo_str(IFACE_INAME, ri, r, iname, IDBM_SHOW, num, 1);
@@ -5338,7 +5075,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
recinfo_t *idbm_recinfo_alloc(int max_keys)
-@@ -426,6 +474,31 @@ void idbm_print(int type, void *rec, int
+@@ -426,6 +500,31 @@ void idbm_print(int type, void *rec, int
}
static void
@@ -5370,7 +5107,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
idbm_discovery_setup_defaults(discovery_rec_t *rec, discovery_type_e type)
{
memset(rec, 0, sizeof(discovery_rec_t));
-@@ -443,7 +516,10 @@ idbm_discovery_setup_defaults(discovery_
+@@ -443,7 +542,10 @@ idbm_discovery_setup_defaults(discovery_
rec->u.sendtargets.conn_timeo.login_timeout=15;
rec->u.sendtargets.conn_timeo.auth_timeout = 45;
rec->u.sendtargets.conn_timeo.active_timeout=30;
@@ -5382,7 +5119,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
DEF_INI_DISC_MAX_RECV_SEG_LEN;
break;
case DISCOVERY_TYPE_SLP:
-@@ -485,6 +561,20 @@ setup_passwd_len:
+@@ -485,6 +587,20 @@ setup_passwd_len:
*(int*)info[i].data =
strtoul(value, NULL, 10);
goto updated;
@@ -5403,7 +5140,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
} else if (info[i].type == TYPE_STR) {
if (!info[i].data)
continue;
-@@ -515,7 +605,7 @@ setup_passwd_len:
+@@ -515,7 +631,7 @@ setup_passwd_len:
}
}
@@ -5412,7 +5149,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
updated:
strlcpy((char*)info[i].value, value, VALUE_MAXVAL);
-@@ -556,12 +646,12 @@ int idbm_verify_param(recinfo_t *info, c
+@@ -556,12 +672,12 @@ int idbm_verify_param(recinfo_t *info, c
else {
log_error("Cannot modify %s. It is used to look up "
"the record and cannot be changed.", name);
@@ -5427,7 +5164,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
void idbm_recinfo_config(recinfo_t *info, FILE *f)
-@@ -627,7 +717,7 @@ void idbm_recinfo_config(recinfo_t *info
+@@ -627,7 +743,7 @@ void idbm_recinfo_config(recinfo_t *info
}
*(value+i) = 0;
@@ -5436,7 +5173,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
} while (line);
}
-@@ -781,19 +871,19 @@ get_params_from_disc_link(char *link, ch
+@@ -781,19 +897,19 @@ get_params_from_disc_link(char *link, ch
(*target) = link;
*address = strchr(*target, ',');
if (!(*address))
@@ -5460,7 +5197,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
*(*ifaceid)++ = '\0';
return 0;
}
-@@ -809,8 +899,9 @@ int idbm_lock(void)
+@@ -809,8 +925,9 @@ int idbm_lock(void)
if (access(LOCK_DIR, F_OK) != 0) {
if (mkdir(LOCK_DIR, 0660) != 0) {
@@ -5472,7 +5209,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
}
-@@ -827,7 +918,7 @@ int idbm_lock(void)
+@@ -827,7 +944,7 @@ int idbm_lock(void)
log_error("Maybe you are not root?");
log_error("Could not lock discovery DB: %s: %s",
LOCK_WRITE_FILE, strerror(errno));
@@ -5481,7 +5218,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
} else if (i == 0)
log_debug(2, "Waiting for discovery DB lock");
-@@ -880,7 +971,7 @@ static int __idbm_rec_read(node_rec_t *o
+@@ -880,7 +997,7 @@ static int __idbm_rec_read(node_rec_t *o
info = idbm_recinfo_alloc(MAX_KEYS);
if (!info)
@@ -5490,7 +5227,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
rc = idbm_lock();
if (rc)
-@@ -888,8 +979,9 @@ static int __idbm_rec_read(node_rec_t *o
+@@ -888,8 +1005,9 @@ static int __idbm_rec_read(node_rec_t *o
f = fopen(conf, "r");
if (!f) {
@@ -5502,7 +5239,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto unlock;
}
-@@ -916,7 +1008,7 @@ idbm_rec_read(node_rec_t *out_rec, char
+@@ -916,7 +1034,7 @@ idbm_rec_read(node_rec_t *out_rec, char
portal = calloc(1, PATH_MAX);
if (!portal)
@@ -5511,7 +5248,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
/* try old style portal as config */
snprintf(portal, PATH_MAX, "%s/%s/%s,%d", NODE_CONFIG_DIR,
-@@ -929,14 +1021,14 @@ idbm_rec_read(node_rec_t *out_rec, char
+@@ -929,14 +1047,14 @@ idbm_rec_read(node_rec_t *out_rec, char
targetname, ip, port, tpgt, iface->name);
log_debug(5, "rec read looking for config file %s.", portal);
if (!strlen(iface->name)) {
@@ -5529,7 +5266,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
read:
-@@ -1073,22 +1165,16 @@ int idbm_for_each_isns_drec(void *data,
+@@ -1073,22 +1191,16 @@ int idbm_for_each_isns_drec(void *data,
static int __idbm_print_all_by_drec(void *data, struct discovery_rec *drec)
{
int info_level = *(int *)data;
@@ -5555,7 +5292,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
static int idbm_print_all_st(int info_level)
-@@ -1168,11 +1254,23 @@ int idbm_print_all_discovery(int info_le
+@@ -1168,11 +1280,23 @@ int idbm_print_all_discovery(int info_le
return found;
}
@@ -5583,7 +5320,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
idbm_iface_op_fn *fn,
char *targetname, int tpgt, char *ip, int port)
{
-@@ -1185,7 +1283,7 @@ int idbm_for_each_iface(int *found, void
+@@ -1185,7 +1309,7 @@ int idbm_for_each_iface(int *found, void
portal = calloc(1, PATH_MAX);
if (!portal)
@@ -5592,7 +5329,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
if (tpgt >= 0)
goto read_iface;
-@@ -1195,7 +1293,7 @@ int idbm_for_each_iface(int *found, void
+@@ -1195,7 +1319,7 @@ int idbm_for_each_iface(int *found, void
ip, port);
if (stat(portal, &statb)) {
log_error("iface iter could not stat %s.", portal);
@@ -5601,7 +5338,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto free_portal;
}
-@@ -1217,11 +1315,13 @@ read_iface:
+@@ -1217,11 +1341,13 @@ read_iface:
iface_dirfd = opendir(portal);
if (!iface_dirfd) {
log_error("iface iter could not read dir %s.", portal);
@@ -5616,7 +5353,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
if (!strcmp(iface_dent->d_name, ".") ||
!strcmp(iface_dent->d_name, ".."))
continue;
-@@ -1233,14 +1333,12 @@ read_iface:
+@@ -1233,14 +1359,12 @@ read_iface:
if (__idbm_rec_read(&rec, portal))
continue;
@@ -5635,7 +5372,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
closedir(iface_dirfd);
-@@ -1263,17 +1361,18 @@ int idbm_for_each_portal(int *found, voi
+@@ -1263,17 +1387,18 @@ int idbm_for_each_portal(int *found, voi
portal = calloc(1, PATH_MAX);
if (!portal)
@@ -5656,7 +5393,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
if (!strcmp(portal_dent->d_name, ".") ||
!strcmp(portal_dent->d_name, ".."))
-@@ -1288,11 +1387,12 @@ int idbm_for_each_portal(int *found, voi
+@@ -1288,11 +1413,12 @@ int idbm_for_each_portal(int *found, voi
if (tmp_tpgt)
*tmp_tpgt++ = '\0';
@@ -5672,7 +5409,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
closedir(portal_dirfd);
done:
-@@ -1314,14 +1414,17 @@ int idbm_for_each_node(int *found, void
+@@ -1314,14 +1440,17 @@ int idbm_for_each_node(int *found, void
return 0;
while ((node_dent = readdir(node_dirfd))) {
@@ -5693,7 +5430,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
closedir(node_dirfd);
-@@ -1376,17 +1479,17 @@ idbm_discovery_read(discovery_rec_t *out
+@@ -1376,17 +1505,17 @@ idbm_discovery_read(discovery_rec_t *out
FILE *f;
if (drec_type > 1)
@@ -5714,7 +5451,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto free_info;
}
-@@ -1402,8 +1505,9 @@ idbm_discovery_read(discovery_rec_t *out
+@@ -1402,8 +1531,9 @@ idbm_discovery_read(discovery_rec_t *out
f = idbm_open_rec_r(portal,
disc_type_to_config_vals[drec_type].config_name);
if (!f) {
@@ -5726,7 +5463,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto unlock;
}
-@@ -1474,14 +1578,15 @@ static int idbm_rec_write(node_rec_t *re
+@@ -1474,14 +1604,15 @@ static int idbm_rec_write(node_rec_t *re
portal = malloc(PATH_MAX);
if (!portal) {
log_error("Could not alloc portal\n");
@@ -5745,7 +5482,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto free_portal;
}
}
-@@ -1489,8 +1594,9 @@ static int idbm_rec_write(node_rec_t *re
+@@ -1489,8 +1620,9 @@ static int idbm_rec_write(node_rec_t *re
snprintf(portal, PATH_MAX, "%s/%s", NODE_CONFIG_DIR, rec->name);
if (access(portal, F_OK) != 0) {
if (mkdir(portal, 0660) != 0) {
@@ -5757,7 +5494,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto free_portal;
}
}
-@@ -1531,13 +1637,13 @@ static int idbm_rec_write(node_rec_t *re
+@@ -1531,13 +1663,13 @@ static int idbm_rec_write(node_rec_t *re
* Old style portal as a file, but with tpgt. Let's update it.
*/
if (unlink(portal)) {
@@ -5775,7 +5512,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto unlock;
}
-@@ -1546,9 +1652,9 @@ mkdir_portal:
+@@ -1546,9 +1678,9 @@ mkdir_portal:
rec->name, rec->conn[0].address, rec->conn[0].port, rec->tpgt);
if (stat(portal, &statb)) {
if (mkdir(portal, 0660) != 0) {
@@ -5788,7 +5525,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto unlock;
}
}
-@@ -1559,8 +1665,8 @@ mkdir_portal:
+@@ -1559,8 +1691,8 @@ mkdir_portal:
open_conf:
f = fopen(portal, "w");
if (!f) {
@@ -5799,7 +5536,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto unlock;
}
-@@ -1581,12 +1687,12 @@ idbm_discovery_write(discovery_rec_t *re
+@@ -1581,12 +1713,12 @@ idbm_discovery_write(discovery_rec_t *re
int rc = 0;
if (rec->type > 1)
@@ -5814,7 +5551,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
rc = idbm_lock();
-@@ -1597,8 +1703,9 @@ idbm_discovery_write(discovery_rec_t *re
+@@ -1597,8 +1729,9 @@ idbm_discovery_write(discovery_rec_t *re
disc_type_to_config_vals[rec->type].config_root);
if (access(portal, F_OK) != 0) {
if (mkdir(portal, 0660) != 0) {
@@ -5826,7 +5563,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto unlock;
}
}
-@@ -1610,8 +1717,8 @@ idbm_discovery_write(discovery_rec_t *re
+@@ -1610,8 +1743,8 @@ idbm_discovery_write(discovery_rec_t *re
f = idbm_open_rec_w(portal,
disc_type_to_config_vals[rec->type].config_name);
if (!f) {
@@ -5837,7 +5574,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto unlock;
}
-@@ -1655,9 +1762,9 @@ static int setup_disc_to_node_link(char
+@@ -1655,9 +1788,9 @@ static int setup_disc_to_node_link(char
case DISCOVERY_TYPE_FW:
if (access(FW_CONFIG_DIR, F_OK) != 0) {
if (mkdir(FW_CONFIG_DIR, 0660) != 0) {
@@ -5850,7 +5587,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
}
-@@ -1669,9 +1776,9 @@ static int setup_disc_to_node_link(char
+@@ -1669,9 +1802,9 @@ static int setup_disc_to_node_link(char
case DISCOVERY_TYPE_STATIC:
if (access(STATIC_CONFIG_DIR, F_OK) != 0) {
if (mkdir(STATIC_CONFIG_DIR, 0660) != 0) {
@@ -5863,7 +5600,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
}
-@@ -1683,9 +1790,9 @@ static int setup_disc_to_node_link(char
+@@ -1683,9 +1816,9 @@ static int setup_disc_to_node_link(char
case DISCOVERY_TYPE_ISNS:
if (access(ISNS_CONFIG_DIR, F_OK) != 0) {
if (mkdir(ISNS_CONFIG_DIR, 0660) != 0) {
@@ -5876,7 +5613,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
}
-@@ -1732,7 +1839,7 @@ static int setup_disc_to_node_link(char
+@@ -1732,7 +1865,7 @@ static int setup_disc_to_node_link(char
break;
case DISCOVERY_TYPE_SLP:
default:
@@ -5885,7 +5622,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
return rc;
-@@ -1773,7 +1880,7 @@ int idbm_add_node(node_rec_t *newrec, di
+@@ -1773,7 +1906,7 @@ int idbm_add_node(node_rec_t *newrec, di
node_portal = calloc(2, PATH_MAX);
if (!node_portal)
@@ -5894,7 +5631,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
disc_portal = node_portal + PATH_MAX;
snprintf(node_portal, PATH_MAX, "%s/%s/%s,%d,%d", NODE_CONFIG_DIR,
-@@ -1795,9 +1902,10 @@ int idbm_add_node(node_rec_t *newrec, di
+@@ -1795,9 +1928,10 @@ int idbm_add_node(node_rec_t *newrec, di
log_debug(7, "link from %s to %s exists", node_portal,
disc_portal);
else {
@@ -5907,7 +5644,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
}
idbm_unlock();
-@@ -1812,10 +1920,12 @@ static int idbm_bind_iface_to_nodes(idbm
+@@ -1812,10 +1946,12 @@ static int idbm_bind_iface_to_nodes(idbm
{
struct node_rec *rec, *tmp;
struct list_head new_recs;
@@ -5922,7 +5659,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
list_for_each_entry_safe(rec, tmp, &new_recs, list) {
list_del_init(&rec->list);
-@@ -1825,6 +1935,20 @@ static int idbm_bind_iface_to_nodes(idbm
+@@ -1825,6 +1961,20 @@ static int idbm_bind_iface_to_nodes(idbm
return 0;
}
@@ -5943,7 +5680,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
int idbm_bind_ifaces_to_nodes(idbm_disc_nodes_fn *disc_node_fn,
void *data, struct list_head *ifaces,
struct list_head *bound_recs)
-@@ -1856,7 +1980,7 @@ int idbm_bind_ifaces_to_nodes(idbm_disc_
+@@ -1856,7 +2006,7 @@ int idbm_bind_ifaces_to_nodes(idbm_disc_
rc = idbm_bind_iface_to_nodes(disc_node_fn, data, iface,
bound_recs);
free(iface);
@@ -5952,7 +5689,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto fail;
found = 1;
}
-@@ -1883,7 +2007,7 @@ int idbm_bind_ifaces_to_nodes(idbm_disc_
+@@ -1883,7 +2033,7 @@ int idbm_bind_ifaces_to_nodes(idbm_disc_
rc = idbm_bind_iface_to_nodes(disc_node_fn, data, iface,
bound_recs);
@@ -5961,7 +5698,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto fail;
}
}
-@@ -1960,7 +2084,7 @@ int idbm_delete_discovery(discovery_rec_
+@@ -1960,7 +2110,7 @@ int idbm_delete_discovery(discovery_rec_
portal = calloc(1, PATH_MAX);
if (!portal)
@@ -5970,7 +5707,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
snprintf(portal, PATH_MAX, "%s/%s,%d",
disc_type_to_config_vals[drec->type].config_root,
-@@ -2017,7 +2141,7 @@ static int idbm_remove_disc_to_node_link
+@@ -2017,7 +2167,7 @@ static int idbm_remove_disc_to_node_link
tmprec = malloc(sizeof(*tmprec));
if (!tmprec)
@@ -5979,7 +5716,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
memset(portal, 0, PATH_MAX);
snprintf(portal, PATH_MAX, "%s/%s/%s,%d,%d/%s", NODE_CONFIG_DIR,
-@@ -2045,9 +2169,9 @@ static int idbm_remove_disc_to_node_link
+@@ -2045,9 +2195,9 @@ static int idbm_remove_disc_to_node_link
if (!stat(portal, &statb)) {
if (unlink(portal)) {
@@ -5992,7 +5729,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
} else
log_debug(7, "rmd %s", portal);
} else
-@@ -2073,7 +2197,7 @@ int idbm_delete_node(node_rec_t *rec)
+@@ -2073,7 +2223,7 @@ int idbm_delete_node(node_rec_t *rec)
portal = calloc(1, PATH_MAX);
if (!portal)
@@ -6001,7 +5738,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
rc = idbm_remove_disc_to_node_link(rec, portal);
if (rc)
-@@ -2100,15 +2224,15 @@ int idbm_delete_node(node_rec_t *rec)
+@@ -2100,15 +2250,15 @@ int idbm_delete_node(node_rec_t *rec)
if (!stat(portal, &statb))
goto rm_conf;
@@ -6022,7 +5759,46 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
goto unlock;
}
-@@ -2178,7 +2302,7 @@ int idbm_node_set_param(void *data, node
+@@ -2170,6 +2320,38 @@ idbm_slp_defaults(struct iscsi_slp_confi
+ sizeof(struct iscsi_slp_config));
+ }
+
++int idbm_parse_param(char *param, struct node_rec *rec)
++{
++ char *name, *value;
++ recinfo_t *info;
++ int rc;
++
++ name = param;
++
++ value = strchr(param, '=');
++ if (!value) {
++ log_error("Invalid --param %s. Missing setting.\n", param);
++ return ISCSI_ERR_INVAL;
++ }
++ *value = '\0';
++ value++;
++
++ info = idbm_recinfo_alloc(MAX_KEYS);
++ if (!info) {
++ log_error("Could not allocate memory to setup params.\n");
++ return ISCSI_ERR_NOMEM;
++ }
++
++ idbm_recinfo_node(rec, info);
++
++ rc = idbm_rec_update_param(info, name, value, 0);
++ if (rc)
++ log_error("Could not set %s to %s. Check that %s is a "
++ "valid parameter.\n", name, value, name);
++ free(info);
++ return rc;
++}
++
+ int idbm_node_set_param(void *data, node_rec_t *rec)
+ {
+ struct db_set_param *param = data;
+@@ -2178,7 +2360,7 @@ int idbm_node_set_param(void *data, node
info = idbm_recinfo_alloc(MAX_KEYS);
if (!info)
@@ -6031,7 +5807,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
idbm_recinfo_node(rec, info);
-@@ -2207,7 +2331,7 @@ int idbm_discovery_set_param(void *data,
+@@ -2207,7 +2389,7 @@ int idbm_discovery_set_param(void *data,
info = idbm_recinfo_alloc(MAX_KEYS);
if (!info)
@@ -6040,7 +5816,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
idbm_recinfo_discovery((discovery_rec_t *)rec, info);
-@@ -2242,7 +2366,7 @@ int idbm_init(idbm_get_config_file_fn *f
+@@ -2242,7 +2424,7 @@ int idbm_init(idbm_get_config_file_fn *f
db = malloc(sizeof(idbm_t));
if (!db) {
log_error("out of memory on idbm allocation");
@@ -6049,7 +5825,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
memset(db, 0, sizeof(idbm_t));
db->get_config_file = fn;
-@@ -2348,10 +2472,12 @@ void idbm_node_setup_defaults(node_rec_t
+@@ -2348,10 +2530,12 @@ void idbm_node_setup_defaults(node_rec_t
rec->tpgt = PORTAL_GROUP_TAG_UNKNOWN;
rec->disc_type = DISCOVERY_TYPE_STATIC;
@@ -6062,7 +5838,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
rec->session.initial_login_retry_max = DEF_INITIAL_LOGIN_RETRIES_MAX;
rec->session.reopen_max = 32;
rec->session.auth.authmethod = 0;
-@@ -2362,16 +2488,10 @@ void idbm_node_setup_defaults(node_rec_t
+@@ -2362,16 +2546,10 @@ void idbm_node_setup_defaults(node_rec_t
rec->session.err_timeo.tgt_reset_timeout = DEF_TGT_RESET_TIMEO;
rec->session.err_timeo.host_reset_timeout = DEF_HOST_RESET_TIMEO;
rec->session.timeo.replacement_timeout = DEF_REPLACEMENT_TIMEO;
@@ -6083,7 +5859,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
for (i=0; i<ISCSI_CONN_MAX; i++) {
rec->conn[i].startup = ISCSI_STARTUP_MANUAL;
-@@ -2385,13 +2505,7 @@ void idbm_node_setup_defaults(node_rec_t
+@@ -2385,13 +2563,7 @@ void idbm_node_setup_defaults(node_rec_t
rec->conn[i].timeo.noop_out_interval = DEF_NOOP_OUT_INTERVAL;
rec->conn[i].timeo.noop_out_timeout = DEF_NOOP_OUT_TIMEO;
@@ -6098,7 +5874,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
}
iface_setup_defaults(&rec->iface);
-@@ -2404,7 +2518,8 @@ idbm_find_rec_in_list(struct list_head *
+@@ -2404,7 +2576,8 @@ idbm_find_rec_in_list(struct list_head *
struct node_rec *rec;
list_for_each_entry(rec, rec_list, list) {
@@ -6108,9 +5884,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.c open-iscsi-2.0-872-rc4-bnx2i
return rec;
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm_fields.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/idbm_fields.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm_fields.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm_fields.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/idbm_fields.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/idbm_fields.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm_fields.h 2012-03-05 23:02:46.000000000 -0600
@@ -10,6 +10,7 @@
#define NODE_NAME "node.name"
#define NODE_TPGT "node.tpgt"
@@ -6147,9 +5923,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm_fields.h open-iscsi-2.0-872-rc
/* discovery fields */
#define DISC_STARTUP "discovery.startup"
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/idbm.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/idbm.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/idbm.h 2012-03-05 23:06:00.000000000 -0600
@@ -39,6 +39,8 @@
#define TYPE_INT 0
#define TYPE_INT_O 1
@@ -6169,9 +5945,17 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/idbm.h open-iscsi-2.0-872-rc4-bnx2i
extern int idbm_for_each_portal(int *found, void *data,
idbm_portal_op_fn *fn, char *targetname);
extern int idbm_for_each_node(int *found, void *data,
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iface.c
+@@ -140,6 +139,7 @@ extern int idbm_discovery_read(discovery
+ extern int idbm_rec_read(node_rec_t *out_rec, char *target_name,
+ int tpgt, char *addr, int port,
+ struct iface_rec *iface);
++extern int idbm_parse_param(char *param, struct node_rec *rec);
+ extern int idbm_node_set_param(void *data, node_rec_t *rec);
+ extern int idbm_discovery_set_param(void *data, discovery_rec_t *rec);
+ extern void idbm_node_setup_defaults(node_rec_t *rec);
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iface.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iface.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iface.c 2012-03-05 23:05:52.000000000 -0600
@@ -26,6 +26,7 @@
#include <unistd.h>
#include <sys/types.h>
@@ -6180,15 +5964,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
#include "log.h"
#include "list.h"
-@@ -39,6 +40,7 @@
+@@ -39,6 +40,8 @@
#include "host.h"
#include "fw_context.h"
#include "sysdeps.h"
+#include "iscsi_err.h"
++#include "iscsi_netlink.h"
/*
* Default ifaces for use with transports that do not bind to hardware
-@@ -101,13 +103,13 @@ struct iface_rec *iface_alloc(char *ifna
+@@ -101,13 +104,13 @@ struct iface_rec *iface_alloc(char *ifna
struct iface_rec *iface;
if (!strlen(ifname) || strlen(ifname) + 1 > ISCSI_MAX_IFACE_LEN) {
@@ -6204,7 +5989,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
return NULL;
}
-@@ -125,11 +127,11 @@ static int __iface_conf_read(struct ifac
+@@ -125,11 +128,11 @@ static int __iface_conf_read(struct ifac
iface_conf = calloc(1, PATH_MAX);
if (!iface_conf)
@@ -6218,7 +6003,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
goto free_conf;
}
-@@ -147,7 +149,7 @@ static int __iface_conf_read(struct ifac
+@@ -147,7 +150,7 @@ static int __iface_conf_read(struct ifac
iface_setup_defaults(iface);
rc = 0;
} else
@@ -6227,7 +6012,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
goto free_info;
}
-@@ -213,12 +215,12 @@ int iface_conf_delete(struct iface_rec *
+@@ -213,12 +216,12 @@ int iface_conf_delete(struct iface_rec *
if (def_iface) {
log_error("iface %s is a special interface and "
"cannot be deleted.\n", iface->name);
@@ -6242,7 +6027,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
sprintf(iface_conf, "%s/%s", IFACE_CONFIG_DIR, iface->name);
rc = idbm_lock();
-@@ -226,7 +228,7 @@ int iface_conf_delete(struct iface_rec *
+@@ -226,7 +229,7 @@ int iface_conf_delete(struct iface_rec *
goto free_conf;
if (unlink(iface_conf))
@@ -6251,7 +6036,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
idbm_unlock();
free_conf:
-@@ -246,17 +248,17 @@ int iface_conf_write(struct iface_rec *i
+@@ -246,17 +249,17 @@ int iface_conf_write(struct iface_rec *i
log_error("iface %s is a special interface and "
"is not stored in %s.\n", iface->name,
IFACE_CONFIG_DIR);
@@ -6272,7 +6057,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
goto free_conf;
}
-@@ -285,12 +287,12 @@ int iface_conf_update(struct db_set_para
+@@ -285,12 +288,12 @@ int iface_conf_update(struct db_set_para
if (def_iface) {
log_error("iface %s is a special interface and "
"cannot be modified.\n", iface->name);
@@ -6287,7 +6072,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
idbm_recinfo_iface(iface, info);
rc = idbm_verify_param(info, param->name);
-@@ -298,10 +300,8 @@ int iface_conf_update(struct db_set_para
+@@ -298,10 +301,8 @@ int iface_conf_update(struct db_set_para
goto free_info;
rc = idbm_rec_update_param(info, param->name, param->value, 0);
@@ -6299,7 +6084,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
rc = iface_conf_write(iface);
free_info:
-@@ -309,6 +309,7 @@ free_info:
+@@ -309,6 +310,7 @@ free_info:
return rc;
}
@@ -6307,7 +6092,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
static int iface_get_next_id(void)
{
struct stat statb;
-@@ -346,6 +347,7 @@ static int iface_get_next_id(void)
+@@ -346,6 +348,7 @@ static int iface_get_next_id(void)
free(iface_conf);
return rc;
}
@@ -6315,7 +6100,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
struct iface_search {
struct iface_rec *pattern;
-@@ -362,7 +364,8 @@ static int __iface_get_by_net_binding(vo
+@@ -362,7 +365,8 @@ static int __iface_get_by_net_binding(vo
}
if (iface_is_bound_by_hwaddr(search->pattern)) {
@@ -6325,26 +6110,148 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
iface_copy(search->found, iface);
return 1;
} else
-@@ -418,7 +421,7 @@ int iface_get_by_net_binding(struct ifac
+@@ -418,15 +422,64 @@ int iface_get_by_net_binding(struct ifac
__iface_get_by_net_binding);
if (rc == 1)
return 0;
- return ENODEV;
+ return ISCSI_ERR_NO_OBJS_FOUND;
++}
++
++static int iface_get_iptype(struct iface_rec *iface)
++{
++ if (strcmp(iface->bootproto, "dhcp") && !strstr(iface->ipaddress, "."))
++ return ISCSI_IFACE_TYPE_IPV6;
++ else
++ return ISCSI_IFACE_TYPE_IPV4;
++}
++
++static int iface_setup_binding_from_kern_iface(void *data,
++ struct iface_rec *kern_iface)
++{
++ struct host_info *hinfo = data;
++ struct iface_rec iface;
++
++ if (!strlen(hinfo->iface.hwaddress)) {
++ log_error("Invalid offload iSCSI host %u. Missing "
++ "hwaddress. Try upgrading %s driver.\n",
++ hinfo->host_no, hinfo->iface.transport_name);
++ return 0;
++ }
++
++ memset(&iface, 0, sizeof(struct iface_rec));
++ strcpy(iface.hwaddress, hinfo->iface.hwaddress);
++ strcpy(iface.transport_name, hinfo->iface.transport_name);
++
++ if (kern_iface) {
++ iface.iface_num = kern_iface->iface_num;
++
++ snprintf(iface.name, sizeof(iface.name), "%s.%s.%s.%u",
++ kern_iface->transport_name,
++ kern_iface->hwaddress,
++ iface_get_iptype(kern_iface) == ISCSI_IFACE_TYPE_IPV4 ?
++ "ipv4" : "ipv6", kern_iface->iface_num);
++ } else {
++ snprintf(iface.name, sizeof(iface.name), "%s.%s",
++ hinfo->iface.transport_name, hinfo->iface.hwaddress);
++ }
++
++ if (iface_conf_read(&iface)) {
++ /* not found so create it */
++ if (iface_conf_write(&iface)) {
++ log_error("Could not create default iface conf %s.",
++ iface.name);
++ /* fall through - will not be persistent */
++ }
++ }
++
++ return 0;
}
static int __iface_setup_host_bindings(void *data, struct host_info *hinfo)
-@@ -438,7 +441,8 @@ static int __iface_setup_host_bindings(v
+ {
+ struct iface_rec *def_iface;
+- struct iface_rec iface;
+ struct iscsi_transport *t;
+- int i = 0;
++ int i = 0, nr_found;
+
+ t = iscsi_sysfs_get_transport_by_hba(hinfo->host_no);
+ if (!t)
+@@ -438,25 +491,12 @@ static int __iface_setup_host_bindings(v
return 0;
}
- if (iface_get_by_net_binding(&hinfo->iface, &iface) == ENODEV) {
-+ if (iface_get_by_net_binding(&hinfo->iface, &iface) ==
-+ ISCSI_ERR_NO_OBJS_FOUND) {
- /* Must be a new port */
- if (!strlen(hinfo->iface.hwaddress)) {
- log_error("Invalid offload iSCSI host %u. Missing "
-@@ -704,7 +708,7 @@ int iface_for_each_iface(void *data, int
+- /* Must be a new port */
+- if (!strlen(hinfo->iface.hwaddress)) {
+- log_error("Invalid offload iSCSI host %u. Missing "
+- "hwaddress. Try upgrading %s driver.\n",
+- hinfo->host_no, t->name);
+- return 0;
+- }
+-
+- memset(&iface, 0, sizeof(struct iface_rec));
+- strcpy(iface.hwaddress, hinfo->iface.hwaddress);
+- strcpy(iface.transport_name, hinfo->iface.transport_name);
+- snprintf(iface.name, sizeof(iface.name), "%s.%s",
+- t->name, hinfo->iface.hwaddress);
+- if (iface_conf_write(&iface))
+- log_error("Could not create default iface conf %s.",
+- iface.name);
+- /* fall through - will not be persistent */
+- }
++ nr_found = 0;
++ iscsi_sysfs_for_each_iface_on_host(hinfo, hinfo->host_no,
++ &nr_found,
++ iface_setup_binding_from_kern_iface);
++ if (!nr_found)
++ iface_setup_binding_from_kern_iface(hinfo, NULL);
+ return 0;
+ }
+
+@@ -492,10 +532,40 @@ void iface_copy(struct iface_rec *dst, s
+ {
+ if (strlen(src->name))
+ strcpy(dst->name, src->name);
++ if (src->iface_num)
++ dst->iface_num = src->iface_num;
+ if (strlen(src->netdev))
+ strcpy(dst->netdev, src->netdev);
+ if (strlen(src->ipaddress))
+ strcpy(dst->ipaddress, src->ipaddress);
++ if (strlen(src->subnet_mask))
++ strcpy(dst->subnet_mask, src->subnet_mask);
++ if (strlen(src->gateway))
++ strcpy(dst->gateway, src->gateway);
++ if (strlen(src->bootproto))
++ strcpy(dst->bootproto, src->bootproto);
++ if (strlen(src->ipv6_linklocal))
++ strcpy(dst->ipv6_linklocal, src->ipv6_linklocal);
++ if (strlen(src->ipv6_router))
++ strcpy(dst->ipv6_router, src->ipv6_router);
++ if (strlen(src->ipv6_autocfg))
++ strcpy(dst->ipv6_autocfg, src->ipv6_autocfg);
++ if (strlen(src->linklocal_autocfg))
++ strcpy(dst->linklocal_autocfg, src->linklocal_autocfg);
++ if (strlen(src->router_autocfg))
++ strcpy(dst->router_autocfg, src->router_autocfg);
++ if (src->vlan_id)
++ dst->vlan_id = src->vlan_id;
++ if (src->vlan_priority)
++ dst->vlan_priority = src->vlan_priority;
++ if (strlen(src->vlan_state))
++ strcpy(dst->vlan_state, src->vlan_state);
++ if (strlen(src->state))
++ strcpy(dst->state, src->state);
++ if (src->mtu)
++ dst->mtu = src->mtu;
++ if (src->port)
++ dst->port = src->port;
+ if (strlen(src->hwaddress))
+ strcpy(dst->hwaddress, src->hwaddress);
+ if (strlen(src->transport_name))
+@@ -704,7 +774,7 @@ int iface_for_each_iface(void *data, int
iface_dent->d_name);
iface = iface_alloc(iface_dent->d_name, &err);
if (!iface || err) {
@@ -6353,7 +6260,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
log_error("Invalid iface name %s. Must be "
"from 1 to %d characters.",
iface_dent->d_name,
-@@ -756,7 +760,7 @@ static int iface_link(void *data, struct
+@@ -756,7 +826,7 @@ static int iface_link(void *data, struct
iface_copy = calloc(1, sizeof(*iface_copy));
if (!iface_copy)
@@ -6362,7 +6269,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
memcpy(iface_copy, iface, sizeof(*iface_copy));
INIT_LIST_HEAD(&iface_copy->list);
-@@ -788,42 +792,54 @@ void iface_link_ifaces(struct list_head
+@@ -788,46 +858,57 @@ void iface_link_ifaces(struct list_head
int iface_setup_from_boot_context(struct iface_rec *iface,
struct boot_context *context)
{
@@ -6435,7 +6342,11 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
memset(iface->name, 0, sizeof(iface->name));
snprintf(iface->name, sizeof(iface->name), "%s.%s",
iface->transport_name, context->mac);
-@@ -885,3 +901,821 @@ fail:
+-
+ strlcpy(iface->hwaddress, context->mac,
+ sizeof(iface->hwaddress));
+ strlcpy(iface->ipaddress, context->ipaddr,
+@@ -885,3 +966,841 @@ fail:
}
return rc;
}
@@ -6459,9 +6370,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+ if (strcmp(iface_params->primary->hwaddress, iface->hwaddress))
+ return 0;
+
-+ if (strcmp(iface->bootproto, "dhcp") && !strstr(iface->ipaddress, "."))
-+ iptype = ISCSI_IFACE_TYPE_IPV6;
-+
++ iptype = iface_get_iptype(iface);
+ if (iptype == ISCSI_IFACE_TYPE_IPV4) {
+
+ if (strcmp(iface->state, "disable")) {
@@ -6651,14 +6560,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+ int len;
+ struct iscsi_iface_param_info *net_param;
+ uint16_t port = 3260;
++ struct nlattr *attr;
+
-+ len = sizeof(struct iscsi_iface_param_info) + 2;
-+ iov->iov_base = calloc(len, sizeof(char));
-+ if (!(iov->iov_base))
++ len = sizeof(struct iscsi_iface_param_info) + sizeof(port);
++ iov->iov_base = iscsi_nla_alloc(ISCSI_NET_PARAM_PORT, len);
++ if (!iov->iov_base)
+ return 1;
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = ISCSI_NET_PARAM_PORT;
+ net_param->iface_type = iface_type;
+ net_param->iface_num = iface->iface_num;
@@ -6676,14 +6587,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+ int len;
+ struct iscsi_iface_param_info *net_param;
+ uint16_t mtu = 0;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 2;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(ISCSI_NET_PARAM_MTU, len);
+ if (!(iov->iov_base))
+ return 1;
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = ISCSI_NET_PARAM_MTU;
+ net_param->iface_type = iface_type;
+ net_param->iface_num = iface->iface_num;
@@ -6701,15 +6614,17 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+ int len;
+ struct iscsi_iface_param_info *net_param;
+ uint16_t vlan = 0;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 2;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(ISCSI_NET_PARAM_VLAN_TAG, len);
+ if (!(iov->iov_base))
+ return 1;
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
-+ net_param->param = ISCSI_NET_PARAM_VLAN_ID;
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
++ net_param->param = ISCSI_NET_PARAM_VLAN_TAG;
+ net_param->iface_type = iface_type;
+ net_param->iface_num = iface->iface_num;
+ net_param->param_type = ISCSI_NET_PARAM;
@@ -6732,14 +6647,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+{
+ int len;
+ struct iscsi_iface_param_info *net_param;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 1;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(ISCSI_NET_PARAM_VLAN_ENABLED, len);
+ if (!(iov->iov_base))
+ return 1;
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = ISCSI_NET_PARAM_VLAN_ENABLED;
+ net_param->iface_type = iface_type;
+ net_param->iface_num = iface->iface_num;
@@ -6758,14 +6675,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+{
+ int len;
+ struct iscsi_iface_param_info *net_param;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 1;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(ISCSI_NET_PARAM_IFACE_ENABLE, len);
+ if (!(iov->iov_base))
+ return 1;
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = ISCSI_NET_PARAM_IFACE_ENABLE;
+ net_param->iface_type = iface_type;
+ net_param->iface_num = iface->iface_num;
@@ -6783,14 +6702,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+{
+ int len;
+ struct iscsi_iface_param_info *net_param;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 1;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(ISCSI_NET_PARAM_IPV4_BOOTPROTO, len);
+ if (!(iov->iov_base))
+ return 1;
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = ISCSI_NET_PARAM_IPV4_BOOTPROTO;
+ net_param->iface_type = ISCSI_IFACE_TYPE_IPV4;
+ net_param->iface_num = iface->iface_num;
@@ -6808,14 +6729,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+{
+ int len;
+ struct iscsi_iface_param_info *net_param;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 1;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(ISCSI_NET_PARAM_IPV6_ADDR_AUTOCFG, len);
+ if (!(iov->iov_base))
+ return 1;
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = ISCSI_NET_PARAM_IPV6_ADDR_AUTOCFG;
+ net_param->iface_type = ISCSI_IFACE_TYPE_IPV6;
+ net_param->param_type = ISCSI_NET_PARAM;
@@ -6837,14 +6760,17 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+{
+ int len;
+ struct iscsi_iface_param_info *net_param;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 1;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(ISCSI_NET_PARAM_IPV6_LINKLOCAL_AUTOCFG,
++ len);
+ if (!(iov->iov_base))
+ return 1;
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = ISCSI_NET_PARAM_IPV6_LINKLOCAL_AUTOCFG;
+ net_param->iface_type = ISCSI_IFACE_TYPE_IPV6;
+ net_param->param_type = ISCSI_NET_PARAM;
@@ -6863,14 +6789,17 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+{
+ int len;
+ struct iscsi_iface_param_info *net_param;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 1;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(ISCSI_NET_PARAM_IPV6_ROUTER_AUTOCFG,
++ len);
+ if (!(iov->iov_base))
+ return 1;
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = ISCSI_NET_PARAM_IPV6_ROUTER_AUTOCFG;
+ net_param->iface_type = ISCSI_IFACE_TYPE_IPV6;
+ net_param->param_type = ISCSI_NET_PARAM;
@@ -6891,14 +6820,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+ int rc = 1;
+ int len;
+ struct iscsi_iface_param_info *net_param;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 4;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(param, len);
+ if (!(iov->iov_base))
+ return 1;
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = param;
+ net_param->iface_type = ISCSI_IFACE_TYPE_IPV4;
+ net_param->iface_num = iface->iface_num;
@@ -6945,14 +6876,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+ int rc;
+ int len;
+ struct iscsi_iface_param_info *net_param;
++ struct nlattr *attr;
+
+ len = sizeof(struct iscsi_iface_param_info) + 16;
-+ iov->iov_base = calloc(len, sizeof(char));
++ iov->iov_base = iscsi_nla_alloc(param, len);
+ if (!(iov->iov_base))
+ return 1;
+
-+ iov->iov_len = len;
-+ net_param = (struct iscsi_iface_param_info *)(iov->iov_base);
++ attr = iov->iov_base;
++ iov->iov_len = NLA_ALIGN(attr->nla_len);
++ net_param = (struct iscsi_iface_param_info *)ISCSI_NLA_DATA(attr);
+ net_param->param = param;
+ net_param->iface_type = ISCSI_IFACE_TYPE_IPV6;
+ net_param->iface_num = iface->iface_num;
@@ -7004,12 +6937,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+ if (strcmp(net_config->primary->hwaddress, iface->hwaddress))
+ return 0;
+
-+ if (strcmp(iface->bootproto, "dhcp") && !strstr(iface->ipaddress, "."))
-+ iptype = ISCSI_IFACE_TYPE_IPV6;
-+
+ /* start at 2, because 0 is for nlmsghdr and 1 for event */
+ iov = net_config->iovs + 2;
+
++ iptype = iface_get_iptype(iface);
+ if (iptype == ISCSI_IFACE_TYPE_IPV4) {
+ if (!strcmp(iface->state, "disable")) {
+ if (!iface_fill_net_state(&iov[net_config->count],
@@ -7257,9 +7188,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.c open-iscsi-2.0-872-rc4-bnx2
+ rc, net_config.count);
+ return net_config.count;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iface.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iface.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iface.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iface.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iface.h 2012-03-05 23:02:46.000000000 -0600
@@ -54,6 +54,10 @@ extern int iface_setup_from_boot_context
struct boot_context *context);
extern int iface_create_ifaces_from_boot_contexts(struct list_head *ifaces,
@@ -7271,18 +7202,19 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iface.h open-iscsi-2.0-872-rc4-bnx2
#define iface_fmt "[hw=%s,ip=%s,net_if=%s,iscsi_if=%s]"
#define iface_str(_iface) \
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/initiator.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/initiator.c 2011-08-14 16:48:25.000000000 -0500
-@@ -46,6 +46,7 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator.c 2012-03-05 23:05:40.000000000 -0600
+@@ -46,6 +46,8 @@
#include "iscsi_settings.h"
#include "iface.h"
#include "sysdeps.h"
+#include "iscsi_err.h"
++#include "kern_err_table.h"
#define ISCSI_CONN_ERR_REOPEN_DELAY 3
#define ISCSI_INTERNAL_ERR_REOPEN_DELAY 5
-@@ -53,31 +54,17 @@
+@@ -53,31 +55,17 @@
#define PROC_DIR "/proc"
static void iscsi_login_timedout(void *data);
@@ -7319,7 +7251,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
ipc->ctldev_bufmax);
if (!conn->context_pool[i]) {
int j;
-@@ -91,7 +78,7 @@ static int iscsi_conn_context_alloc(iscs
+@@ -91,7 +79,7 @@ static int iscsi_conn_context_alloc(iscs
return 0;
}
@@ -7328,7 +7260,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
{
int i;
-@@ -107,10 +94,10 @@ static void iscsi_conn_context_free(iscs
+@@ -107,10 +95,10 @@ static void iscsi_conn_context_free(iscs
}
}
@@ -7342,7 +7274,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
int i;
if (ev_size > ipc->ctldev_bufmax)
-@@ -121,26 +108,26 @@ struct iscsi_conn_context *iscsi_conn_co
+@@ -121,26 +109,26 @@ struct iscsi_conn_context *iscsi_conn_co
continue;
if (!conn->context_pool[i]->allocated) {
@@ -7380,7 +7312,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
}
static void session_online_devs(int host_no, int sid)
-@@ -205,11 +192,11 @@ __check_iscsi_status_class(iscsi_session
+@@ -205,11 +193,11 @@ __check_iscsi_status_class(iscsi_session
log_error("session %d login rejected: Initiator "
"failed authentication with target",
session->id);
@@ -7394,7 +7326,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
case ISCSI_LOGIN_STATUS_TGT_NOT_FOUND:
log_error("conn %d login rejected: initiator "
"error - target not found (%02x/%02x)",
-@@ -250,183 +237,6 @@ __check_iscsi_status_class(iscsi_session
+@@ -250,183 +238,6 @@ __check_iscsi_status_class(iscsi_session
return CONN_LOGIN_FAILED;
}
@@ -7578,7 +7510,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
static int
__session_conn_create(iscsi_session_t *session, int cid)
{
-@@ -434,12 +244,12 @@ __session_conn_create(iscsi_session_t *s
+@@ -434,12 +245,12 @@ __session_conn_create(iscsi_session_t *s
conn_rec_t *conn_rec = &session->nrec.conn[cid];
int err;
@@ -7594,7 +7526,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
conn->session = session;
/*
* TODO: we must export the socket_fd/transport_eph from sysfs
-@@ -486,14 +296,15 @@ __session_conn_create(iscsi_session_t *s
+@@ -486,14 +297,15 @@ __session_conn_create(iscsi_session_t *s
conn->noop_out_interval = DEF_NOOP_OUT_INTERVAL;
}
@@ -7612,7 +7544,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
if (err)
return err;
return 0;
-@@ -506,7 +317,7 @@ session_release(iscsi_session_t *session
+@@ -506,7 +318,7 @@ session_release(iscsi_session_t *session
if (session->target_alias)
free(session->target_alias);
@@ -7621,7 +7553,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
free(session);
}
-@@ -524,11 +335,10 @@ __session_create(node_rec_t *rec, struct
+@@ -524,11 +336,10 @@ __session_create(node_rec_t *rec, struct
log_debug(2, "Allocted session %p", session);
INIT_LIST_HEAD(&session->list);
@@ -7634,7 +7566,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
/* save node record. we might need it for redirection */
memcpy(&session->nrec, rec, sizeof(node_rec_t));
-@@ -570,7 +380,7 @@ __session_create(node_rec_t *rec, struct
+@@ -570,7 +381,7 @@ __session_create(node_rec_t *rec, struct
session->isid[5] = 0;
/* setup authentication variables for the session*/
@@ -7643,7 +7575,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
session->param_mask = ~0ULL;
if (!(t->caps & CAP_MULTI_R2T))
-@@ -601,18 +411,18 @@ __session_create(node_rec_t *rec, struct
+@@ -601,18 +412,18 @@ __session_create(node_rec_t *rec, struct
static void iscsi_flush_context_pool(struct iscsi_session *session)
{
@@ -7667,7 +7599,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
}
}
}
-@@ -633,15 +443,16 @@ conn_delete_timers(iscsi_conn_t *conn)
+@@ -633,15 +444,16 @@ conn_delete_timers(iscsi_conn_t *conn)
actor_delete(&conn->nop_out_timer);
}
@@ -7687,7 +7619,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
if (session->id == -1)
goto cleanup;
-@@ -649,15 +460,15 @@ session_conn_shutdown(iscsi_conn_t *conn
+@@ -649,15 +461,15 @@ session_conn_shutdown(iscsi_conn_t *conn
if (!iscsi_sysfs_session_has_leadconn(session->id))
goto cleanup;
@@ -7707,7 +7639,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
}
}
-@@ -665,16 +476,18 @@ session_conn_shutdown(iscsi_conn_t *conn
+@@ -665,16 +477,17 @@ session_conn_shutdown(iscsi_conn_t *conn
if (ipc->destroy_conn(session->t->handle, session->id,
conn->id)) {
log_error("can not safely destroy connection %d", conn->id);
@@ -7718,10 +7650,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
cleanup:
if (session->id != -1) {
log_debug(2, "kdestroy session %u", session->id);
-- if (ipc->destroy_session(session->t->handle, session->id)) {
+ session->r_stage = R_STAGE_SESSION_DESTOYED;
-+ err = ipc->destroy_session(session->t->handle, session->id);
-+ if (err) {
+ if (ipc->destroy_session(session->t->handle, session->id)) {
log_error("can not safely destroy session %d",
session->id);
- return MGMT_IPC_ERR_INTERNAL;
@@ -7957,7 +7887,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
log_debug(1, "ignoring conn error in CLEANUP_WAIT. "
"let connection stop");
return;
-@@ -1020,19 +843,19 @@ __conn_error_handle(iscsi_session_t *ses
+@@ -1020,19 +843,20 @@ __conn_error_handle(iscsi_session_t *ses
static void session_conn_error(void *data)
{
@@ -7969,10 +7899,13 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
+ iscsi_conn_t *conn = ev_context->conn;
iscsi_session_t *session = conn->session;
- log_warning("Kernel reported iSCSI connection %d:%d error (%d) "
+- log_warning("Kernel reported iSCSI connection %d:%d error (%d) "
++ log_warning("Kernel reported iSCSI connection %d:%d error (%d - %s) "
"state (%d)", session->id, conn->id, error,
- conn->state);
+- conn->state);
- iscsi_conn_context_put(conn_context);
++ kern_err_code_to_string(error), conn->state);
++
+ iscsi_ev_context_put(ev_context);
switch (error) {
@@ -7982,7 +7915,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
log_error("BUG: Could not shutdown session.");
break;
default:
-@@ -1046,14 +869,14 @@ static void iscsi_login_timedout(void *d
+@@ -1046,14 +870,14 @@ static void iscsi_login_timedout(void *d
struct iscsi_conn *conn = qtask->conn;
switch (conn->state) {
@@ -8002,7 +7935,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
break;
}
}
-@@ -1125,7 +948,7 @@ static void conn_send_nop_out(void *data
+@@ -1125,7 +949,7 @@ static void conn_send_nop_out(void *data
* we cannot start new request during logout and the logout timer
* will figure things out.
*/
@@ -8011,7 +7944,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
return;
__send_nopout(conn);
-@@ -1136,17 +959,6 @@ static void conn_send_nop_out(void *data
+@@ -1136,17 +960,6 @@ static void conn_send_nop_out(void *data
&conn->nop_out_timer, conn->noop_out_timeout);
}
@@ -8029,7 +7962,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
void free_initiator(void)
{
struct iscsi_transport *t;
-@@ -1170,7 +982,7 @@ static void session_scan_host(struct isc
+@@ -1170,7 +983,7 @@ static void session_scan_host(struct isc
pid = iscsi_sysfs_scan_host(hostno, 1);
if (pid == 0) {
@@ -8038,7 +7971,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
if (session)
iscsi_sysfs_for_each_device(
-@@ -1185,306 +997,37 @@ static void session_scan_host(struct isc
+@@ -1185,306 +998,37 @@ static void session_scan_host(struct isc
free(qtask);
}
} else
@@ -8298,7 +8231,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
- MGMT_IPC_ERR_LOGIN_FAILURE);
- return;
- }
--
+
- if (rc == -ENOSYS) {
- switch (conntbl[i].param) {
- case ISCSI_PARAM_PING_TMO:
@@ -8314,7 +8247,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
- break;
- }
- }
-
+-
- print_param_value(conntbl[i].param, conntbl[i].value,
- conntbl[i].type);
+ if (iscsi_session_set_params(conn)) {
@@ -8355,7 +8288,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
if (session->r_stage == R_STAGE_NO_CHANGE ||
session->r_stage == R_STAGE_SESSION_REDIRECT) {
/*
-@@ -1501,10 +1044,10 @@ setup_full_feature_phase(iscsi_conn_t *c
+@@ -1501,10 +1045,10 @@ setup_full_feature_phase(iscsi_conn_t *c
session->nrec.conn[conn->id].port,
session->nrec.iface.name);
} else {
@@ -8368,7 +8301,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
log_warning("connection%d:%d is operational after recovery "
"(%d attempts)", session->id, conn->id,
session->reopen_cnt);
-@@ -1527,12 +1070,12 @@ setup_full_feature_phase(iscsi_conn_t *c
+@@ -1527,12 +1071,12 @@ setup_full_feature_phase(iscsi_conn_t *c
static void iscsi_logout_timedout(void *data)
{
@@ -8385,7 +8318,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
* was some nasty error
*/
log_debug(3, "logout timeout, dropping conn...\n");
-@@ -1542,9 +1085,9 @@ static void iscsi_logout_timedout(void *
+@@ -1542,9 +1086,9 @@ static void iscsi_logout_timedout(void *
static int iscsi_send_logout(iscsi_conn_t *conn)
{
struct iscsi_logout hdr;
@@ -8397,7 +8330,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
return EINVAL;
memset(&hdr, 0, sizeof(struct iscsi_logout));
-@@ -1556,14 +1099,14 @@ static int iscsi_send_logout(iscsi_conn_
+@@ -1556,14 +1100,14 @@ static int iscsi_send_logout(iscsi_conn_
if (!iscsi_io_send_pdu(conn, (struct iscsi_hdr*)&hdr,
ISCSI_DIGEST_NONE, NULL, ISCSI_DIGEST_NONE, 0))
return EIO;
@@ -8416,7 +8349,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
conn->logout_timeout,
EV_CONN_LOGOUT_TIMER);
log_debug(3, "logout timeout timer %u\n",
-@@ -1575,16 +1118,18 @@ static int iscsi_send_logout(iscsi_conn_
+@@ -1575,16 +1119,18 @@ static int iscsi_send_logout(iscsi_conn_
static void iscsi_stop(void *data)
{
@@ -8441,7 +8374,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
if (rc)
log_error("BUG: Could not shutdown session.");
}
-@@ -1683,6 +1228,7 @@ static void iscsi_recv_login_rsp(struct
+@@ -1683,6 +1229,7 @@ static void iscsi_recv_login_rsp(struct
{
struct iscsi_session *session = conn->session;
iscsi_login_context_t *c = &conn->login_context;
@@ -8449,7 +8382,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
if (iscsi_login_rsp(session, c)) {
log_debug(1, "login_rsp ret (%d)", c->ret);
-@@ -1703,6 +1249,9 @@ static void iscsi_recv_login_rsp(struct
+@@ -1703,6 +1250,9 @@ static void iscsi_recv_login_rsp(struct
switch (__check_iscsi_status_class(session, conn->id,
c->status_class,
c->status_detail)) {
@@ -8459,7 +8392,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
case CONN_LOGIN_FAILED:
goto failed;
case CONN_LOGIN_IMM_REDIRECT_RETRY:
-@@ -1718,10 +1267,9 @@ static void iscsi_recv_login_rsp(struct
+@@ -1718,10 +1268,9 @@ static void iscsi_recv_login_rsp(struct
if (conn->current_stage != ISCSI_FULL_FEATURE_PHASE) {
/* more nego. needed! */
@@ -8472,7 +8405,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
return;
}
} else
-@@ -1730,36 +1278,35 @@ static void iscsi_recv_login_rsp(struct
+@@ -1730,36 +1279,35 @@ static void iscsi_recv_login_rsp(struct
return;
retry:
/* retry if not initial login or initial login has not timed out */
@@ -8521,7 +8454,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
switch (hdr.opcode & ISCSI_OPCODE_MASK) {
case ISCSI_OP_NOOP_IN:
-@@ -1776,18 +1323,18 @@ static void session_conn_recv_pdu(void *
+@@ -1776,18 +1324,18 @@ static void session_conn_recv_pdu(void *
break;
}
break;
@@ -8545,7 +8478,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
log_error("Invalid state. Dropping PDU.\n");
}
}
-@@ -1908,35 +1455,66 @@ retry_create:
+@@ -1908,35 +1456,72 @@ retry_create:
return err;
}
@@ -8570,9 +8503,15 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
+ conn->state = ISCSI_CONN_STATE_IN_LOGIN;
+ if (ipc->start_conn(session->t->handle, session->id, conn->id,
+ &rc) || rc) {
-+ log_error("can't start connection %d:%d retcode %d (%d)",
-+ session->id, conn->id, rc, errno);
-+ iscsi_login_eh(conn, c->qtask, ISCSI_ERR_INTERNAL);
++ if (rc == -EEXIST) {
++ log_error("Session already exists.");
++ session_conn_shutdown(conn, c->qtask,
++ ISCSI_ERR_SESS_EXISTS);
++ } else {
++ log_error("can't start connection %d:%d retcode (%d)",
++ session->id, conn->id, rc);
++ iscsi_login_eh(conn, c->qtask, ISCSI_ERR_INTERNAL);
++ }
+ return;
+ }
+
@@ -8623,7 +8562,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
} else if (rc > 0) {
/* connected! */
memset(c, 0, sizeof(iscsi_login_context_t));
-@@ -1945,26 +1523,26 @@ static void session_conn_poll(void *data
+@@ -1945,26 +1530,26 @@ static void session_conn_poll(void *data
if (session->id == -1) {
if (conn->id == 0 && session_ipc_create(session)) {
log_error("Can't create session.");
@@ -8658,7 +8597,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
/*
* TODO: use the iface number or some other value
* so this will be persistent
-@@ -1977,7 +1555,7 @@ static void session_conn_poll(void *data
+@@ -1977,7 +1562,7 @@ static void session_conn_poll(void *data
log_error("can't bind conn %d:%d to session %d, "
"retcode %d (%d)", session->id, conn->id,
session->id, rc, errno);
@@ -8667,7 +8606,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
return;
}
log_debug(3, "bound iSCSI connection %d:%d to session %d",
-@@ -1990,14 +1568,19 @@ static void session_conn_poll(void *data
+@@ -1990,14 +1575,19 @@ static void session_conn_poll(void *data
conn->exp_statsn = iscsi_sysfs_get_exp_statsn(session->id);
@@ -8690,7 +8629,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
return;
}
} else {
-@@ -2011,70 +1594,125 @@ cleanup:
+@@ -2011,70 +1601,126 @@ cleanup:
session_conn_shutdown(conn, qtask, err);
}
@@ -8738,9 +8677,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
+ session->nrec.conn[conn->id].address,
+ session->nrec.conn[conn->id].port,
+ session->nrec.iface.name);
-+ } else
++ } else {
+ session->notify_qtask = NULL;
-+
++ mgmt_ipc_write_rsp(c->qtask, ISCSI_SUCCESS);
++ }
+
+ /*
+ * reset ERL=0 reopen counter
@@ -8853,7 +8793,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
}
static iscsi_session_t* session_find_by_rec(node_rec_t *rec)
-@@ -2087,7 +1725,8 @@ static iscsi_session_t* session_find_by_
+@@ -2087,7 +1733,8 @@ static iscsi_session_t* session_find_by_
if (__iscsi_match_session(rec, session->nrec.name,
session->nrec.conn[0].address,
session->nrec.conn[0].port,
@@ -8863,7 +8803,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
return session;
}
}
-@@ -2111,65 +1750,24 @@ static int session_is_running(node_rec_t
+@@ -2111,65 +1758,24 @@ static int session_is_running(node_rec_t
return 0;
}
@@ -8937,7 +8877,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
if ((!(t->caps & CAP_RECOVERY_L0) &&
rec->session.iscsi.ERL != 0) ||
-@@ -2222,27 +1820,22 @@ session_login_task(node_rec_t *rec, queu
+@@ -2222,27 +1828,22 @@ session_login_task(node_rec_t *rec, queu
session = __session_create(rec, t);
if (!session)
@@ -8971,7 +8911,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
}
if (gettimeofday(&conn->initial_connect_time, NULL))
-@@ -2250,26 +1843,37 @@ session_login_task(node_rec_t *rec, queu
+@@ -2250,26 +1851,37 @@ session_login_task(node_rec_t *rec, queu
"login errors iscsid may give up the initial "
"login early. You should manually login.");
@@ -9015,7 +8955,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
iscsi_sync_session(node_rec_t *rec, queue_task_t *qtask, uint32_t sid)
{
iscsi_session_t *session;
-@@ -2278,38 +1882,32 @@ iscsi_sync_session(node_rec_t *rec, queu
+@@ -2278,38 +1890,32 @@ iscsi_sync_session(node_rec_t *rec, queu
t = iscsi_sysfs_get_transport_by_name(rec->iface.transport_name);
if (!t)
@@ -9061,7 +9001,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
return 0;
destroy_session:
-@@ -2329,37 +1927,35 @@ static int session_unbind(struct iscsi_s
+@@ -2329,37 +1935,35 @@ static int session_unbind(struct iscsi_s
return err;
}
@@ -9106,7 +9046,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
if (conn->logout_qtask)
goto invalid_state;
-@@ -2368,41 +1964,45 @@ invalid_state:
+@@ -2368,41 +1972,45 @@ invalid_state:
conn->logout_qtask = qtask;
switch (conn->state) {
@@ -9164,7 +9104,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
}
/*
-@@ -2412,7 +2012,7 @@ iscsi_host_send_targets(queue_task_t *qt
+@@ -2412,7 +2020,7 @@ iscsi_host_send_targets(queue_task_t *qt
* the card will have sessions preset in the FLASH and will log into them
* automaotically then send us notification that a session is setup.
*/
@@ -9173,7 +9113,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
{
struct iscsi_transport *transport;
-@@ -2428,7 +2028,20 @@ void iscsi_async_session_creation(uint32
+@@ -2428,7 +2036,20 @@ void iscsi_async_session_creation(uint32
session_scan_host(NULL, host_no, NULL);
}
@@ -9195,9 +9135,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-
+{
+ ipc_register_ev_callback(&ipc_clbk);
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator_common.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/initiator_common.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator_common.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator_common.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/initiator_common.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/initiator_common.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator_common.c 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,607 @@
+/*
+ * Common code for setting up discovery and normal sessions.
@@ -9806,9 +9746,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator_common.c open-iscsi-2.0-8
+ }
+ return 0;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/initiator.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/initiator.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator.h 2012-03-05 23:02:46.000000000 -0600
@@ -39,25 +39,18 @@
#define INITIATOR_NAME_FILE ISCSI_CONFIG_ROOT"initiatorname.iscsi"
@@ -9976,9 +9916,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.h open-iscsi-2.0-872-rc4-
+extern int iscsi_setup_portal(struct iscsi_conn *conn, char *address, int port);
#endif /* INITIATOR_H */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/io.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/io.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/io.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/io.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/io.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/io.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/io.c 2012-03-05 23:02:46.000000000 -0600
@@ -26,11 +26,14 @@
#include <fcntl.h>
#include <sys/poll.h>
@@ -10408,9 +10348,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/io.c open-iscsi-2.0-872-rc4-bnx2i.s
}
return h_bytes + ahs_bytes + d_bytes;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsiadm.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsiadm.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsiadm.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsiadm.c 2012-03-05 23:02:46.000000000 -0600
@@ -4,6 +4,7 @@
* Copyright (C) 2004 Dmitry Yusupov, Alex Aizman
* Copyright (C) 2006 Mike Christie
@@ -10553,7 +10493,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
}
return err;
-@@ -313,7 +324,7 @@ static int link_recs(void *data, struct
+@@ -313,7 +324,7 @@ static int link_recs(void *data, struct
rec_copy = calloc(1, sizeof(*rec_copy));
if (!rec_copy)
@@ -10830,7 +10770,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
{
struct rec_op_data op_data;
int nr_found = 0, rc;
-@@ -475,30 +591,51 @@ static int for_each_rec(struct node_rec
+@@ -475,30 +591,51 @@ static int for_each_rec(struct node_rec
op_data.match_rec = rec;
op_data.fn = fn;
@@ -11004,7 +10944,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
}
return idbm_delete_node(rec);
-@@ -822,18 +954,18 @@ static int delete_stale_rec(void *data,
+@@ -822,18 +954,18 @@ static int delete_stale_rec(void *data,
* if we are not from the same discovery source
* ignore it
*/
@@ -11028,7 +10968,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
}
static int
-@@ -918,8 +1050,12 @@ do_software_sendtargets(discovery_rec_t
+@@ -918,8 +1050,12 @@ do_software_sendtargets(discovery_rec_t
rc = idbm_bind_ifaces_to_nodes(discovery_sendtargets, drec, ifaces,
&rec_list);
if (rc) {
@@ -11486,7 +11426,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
*/
static int exec_discover(int disc_type, char *ip, int port,
struct list_head *ifaces, int info_level,
-@@ -1506,15 +1776,16 @@ static int exec_discover(int disc_type,
+@@ -1506,15 +1776,16 @@ static int exec_discover(int disc_type,
if (ip == NULL) {
log_error("Please specify portal as <ipaddr>[:<ipport>]");
@@ -11506,7 +11446,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
} else {
printf("New discovery record for [%s,%d] added.\n", ip,
port);
-@@ -1527,7 +1798,7 @@ static int exec_discover(int disc_type,
+@@ -1527,7 +1798,7 @@ static int exec_discover(int disc_type,
if (!do_discover) {
log_error("Discovery record [%s,%d] not found.",
ip, port);
@@ -11515,7 +11455,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
}
/* Just add default rec for user */
-@@ -1539,11 +1810,11 @@ static int exec_discover(int disc_type,
+@@ -1539,11 +1810,11 @@ static int exec_discover(int disc_type,
if (rc) {
log_error("Could not add new discovery "
"record.");
@@ -11529,7 +11469,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
rc = 0;
switch (disc_type) {
-@@ -1563,9 +1834,7 @@ static int exec_discover(int disc_type,
+@@ -1563,9 +1834,7 @@ static int exec_discover(int disc_type,
break;
}
@@ -11540,7 +11480,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
}
static int exec_disc2_op(int disc_type, char *ip, int port,
-@@ -1587,12 +1856,12 @@ static int exec_disc2_op(int disc_type,
+@@ -1587,12 +1856,12 @@ static int exec_disc2_op(int disc_type,
rc = exec_discover(disc_type, ip, port, ifaces, info_level,
do_login, do_discover, op, &drec);
@@ -11555,7 +11495,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
goto done;
case DISCOVERY_TYPE_ISNS:
if (port < 0)
-@@ -1600,29 +1869,30 @@ static int exec_disc2_op(int disc_type,
+@@ -1600,29 +1869,30 @@ static int exec_disc2_op(int disc_type,
rc = exec_discover(disc_type, ip, port, ifaces, info_level,
do_login, do_discover, op, &drec);
@@ -12004,9 +11944,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsiadm.c open-iscsi-2.0-872-rc4-b
}
break;
default:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsid.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsid.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid.c 2012-03-05 23:05:31.000000000 -0600
@@ -31,6 +31,8 @@
#include <sys/utsname.h>
#include <sys/types.h>
@@ -12070,7 +12010,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
/*
* Just rescan the device in case this is the first startup.
-@@ -213,7 +213,8 @@ static int sync_session(void *data, stru
+@@ -213,13 +213,17 @@ static int sync_session(void *data, stru
host_no = iscsi_sysfs_get_host_no_from_sid(info->sid, &err);
if (err) {
log_error("Could not get host no from sid %u. Can not "
@@ -12080,7 +12020,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
return 0;
}
iscsi_sysfs_scan_host(host_no, 0);
-@@ -272,7 +273,7 @@ static int sync_session(void *data, stru
+ return 0;
+ }
+
++ if (!iscsi_sysfs_session_user_created(info->sid))
++ return 0;
++
+ memset(&rec, 0, sizeof(node_rec_t));
+ /*
+ * We might get the local ip address for software. We do not
+@@ -272,7 +276,7 @@ static int sync_session(void *data, stru
retry:
rc = iscsid_exec_req(&req, &rsp, 0);
@@ -12089,7 +12038,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
retries++;
sleep(1);
goto retry;
-@@ -302,7 +303,12 @@ static void iscsid_shutdown(void)
+@@ -302,7 +306,12 @@ static void iscsid_shutdown(void)
static void catch_signal(int signo)
{
@@ -12103,7 +12052,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
switch (signo) {
case SIGTERM:
iscsid_shutdown();
-@@ -318,7 +324,7 @@ static void missing_iname_warn(char *ini
+@@ -318,7 +327,7 @@ static void missing_iname_warn(char *ini
log_error("Warning: InitiatorName file %s does not exist or does not "
"contain a properly formated InitiatorName. If using "
"software iscsi (iscsi_tcp or ib_iser) or partial offload "
@@ -12112,7 +12061,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
"into or discover targets. Please create a file %s that "
"contains a sting with the format: InitiatorName="
"iqn.yyyy-mm.<reversed domain name>[:identifier].\n\n"
-@@ -337,17 +343,10 @@ int main(int argc, char *argv[])
+@@ -337,17 +346,10 @@ int main(int argc, char *argv[])
uid_t uid = 0;
struct sigaction sa_old;
struct sigaction sa_new;
@@ -12132,7 +12081,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
&longindex)) >= 0) {
switch (ch) {
case 'c':
-@@ -368,6 +367,9 @@ int main(int argc, char *argv[])
+@@ -368,6 +370,9 @@ int main(int argc, char *argv[])
case 'g':
gid = strtoul(optarg, NULL, 10);
break;
@@ -12142,7 +12091,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
case 'p':
pid_file = optarg;
break;
-@@ -388,17 +390,25 @@ int main(int argc, char *argv[])
+@@ -388,17 +393,25 @@ int main(int argc, char *argv[])
log_pid = log_init(program_name, DEFAULT_AREA_SIZE,
daemonize ? log_do_log_daemon : log_do_log_std, NULL);
if (log_pid < 0)
@@ -12171,7 +12120,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
}
umask(0177);
-@@ -410,24 +420,26 @@ int main(int argc, char *argv[])
+@@ -410,24 +423,26 @@ int main(int argc, char *argv[])
if ((mgmt_ipc_fd = mgmt_ipc_listen()) < 0) {
log_close(log_pid);
@@ -12206,7 +12155,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
} else if (pid) {
log_error("iSCSI daemon with pid=%d started!", pid);
exit(0);
-@@ -435,18 +447,29 @@ int main(int argc, char *argv[])
+@@ -435,18 +450,29 @@ int main(int argc, char *argv[])
if ((control_fd = ipc->ctldev_open()) < 0) {
log_close(log_pid);
@@ -12245,7 +12194,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
daemon_init();
} else {
-@@ -498,6 +521,7 @@ int main(int argc, char *argv[])
+@@ -498,6 +524,7 @@ int main(int argc, char *argv[])
} else
reap_inc();
@@ -12253,7 +12202,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
increase_max_files();
discoveryd_start(daemon_config.initiator_name);
-@@ -509,7 +533,7 @@ int main(int argc, char *argv[])
+@@ -509,7 +536,7 @@ int main(int argc, char *argv[])
if (mlockall(MCL_CURRENT | MCL_FUTURE)) {
log_error("failed to mlockall, exiting...");
log_close(log_pid);
@@ -12262,9 +12211,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.c open-iscsi-2.0-872-rc4-bnx
}
actor_init();
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsid.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsid.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid.h 2012-03-05 23:02:46.000000000 -0600
@@ -31,6 +31,5 @@ struct iscsi_daemon_config {
char *initiator_alias;
};
@@ -12272,9 +12221,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid.h open-iscsi-2.0-872-rc4-bnx
-extern int control_fd;
#endif /* ISCSID_H */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsid_req.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid_req.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsid_req.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid_req.c 2012-03-05 23:02:46.000000000 -0600
@@ -31,6 +31,7 @@
#include "mgmt_ipc.h"
#include "iscsi_util.h"
@@ -12405,9 +12354,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.c open-iscsi-2.0-872-rc4
- };
- log_error("initiator reported error (%d - %s)", err, err_msgs[err]);
-}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsid_req.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid_req.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsid_req.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid_req.h 2012-03-05 23:02:46.000000000 -0600
@@ -27,7 +27,6 @@ struct node_rec;
extern int iscsid_exec_req(struct iscsiadm_req *req, struct iscsiadm_rsp *rsp,
@@ -12416,9 +12365,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.h open-iscsi-2.0-872-rc4
extern int iscsid_req_wait(int cmd, int fd);
extern int iscsid_req_by_rec_async(int cmd, struct node_rec *rec, int *fd);
extern int iscsid_req_by_rec(int cmd, struct node_rec *rec);
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_err.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_err.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_err.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_err.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_err.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_err.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_err.c 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,72 @@
+/*
+ * iSCSI error helpers
@@ -12492,9 +12441,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_err.c open-iscsi-2.0-872-rc4-
+ log_error("initiator reported error (%d - %s)", err,
+ iscsi_err_msgs[err]);
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_ipc.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_ipc.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_ipc.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_ipc.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_ipc.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_ipc.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_ipc.h 2012-03-05 23:02:46.000000000 -0600
@@ -34,6 +34,26 @@ enum {
};
@@ -12534,21 +12483,58 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_ipc.h open-iscsi-2.0-872-rc4-
};
#endif /* ISCSI_IPC_H */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_net_util.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_net_util.c
---- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_net_util.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_net_util.c 2011-08-14 16:48:25.000000000 -0500
-@@ -41,6 +41,7 @@ struct iscsi_net_driver {
- static struct iscsi_net_driver net_drivers[] = {
- #ifdef OFFLOAD_BOOT_SUPPORTED
- {"cxgb3", "cxgb3i" },
-+ {"cxgb4", "cxgb4i" },
- {"bnx2", "bnx2i" },
- {"bnx2x", "bnx2i"},
- #endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsistart.c
---- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsistart.c 2011-08-14 16:48:25.000000000 -0500
-@@ -47,6 +47,7 @@
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_netlink.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_netlink.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_netlink.h 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_netlink.h 2012-03-05 23:04:01.000000000 -0600
+@@ -0,0 +1,33 @@
++/*
++ * iSCSI Netlink attr helpers
++ *
++ * Copyright (C) 2011 Red Hat, Inc. All rights reserved.
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published
++ * by the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ *
++ * This program is distributed in the hope that it will be useful, but
++ * WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
++ * General Public License for more details.
++ *
++ * See the file COPYING included with this distribution for more details.
++ */
++
++#ifndef ISCSI_NLA_H
++#define ISCSI_NLA_H
++
++#include <linux/netlink.h>
++
++struct iovec;
++
++#define ISCSI_NLA_HDRLEN ((int) NLA_ALIGN(sizeof(struct nlattr)))
++#define ISCSI_NLA_DATA(nla) ((void *)((char*)(nla) + ISCSI_NLA_HDRLEN))
++#define ISCSI_NLA_LEN(len) ((len) + NLA_ALIGN(ISCSI_NLA_HDRLEN))
++#define ISCSI_NLA_TOTAL_LEN(len) (NLA_ALIGN(ISCSI_NLA_LEN(len)))
++
++extern struct nlattr *iscsi_nla_alloc(uint16_t type, uint16_t len);
++
++#endif
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_net_util.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_net_util.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_net_util.c 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_net_util.c 2012-03-05 23:02:46.000000000 -0600
+@@ -41,6 +41,7 @@ struct iscsi_net_driver {
+ static struct iscsi_net_driver net_drivers[] = {
+ #ifdef OFFLOAD_BOOT_SUPPORTED
+ {"cxgb3", "cxgb3i" },
++ {"cxgb4", "cxgb4i" },
+ {"bnx2", "bnx2i" },
+ {"bnx2x", "bnx2i"},
+ #endif
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsistart.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsistart.c 2012-03-05 23:06:04.000000000 -0600
+@@ -47,6 +47,7 @@
#include "iface.h"
#include "sysdeps.h"
#include "iscsid_req.h"
@@ -12556,8 +12542,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
/* global config info */
/* initiator needs initiator name/alias */
-@@ -57,10 +58,8 @@ static node_rec_t config_rec;
+@@ -55,12 +56,16 @@ struct iscsi_daemon_config *dconfig = &d
+
+ static node_rec_t config_rec;
static LIST_HEAD(targets);
++static LIST_HEAD(user_params);
++
++struct user_param {
++ struct list_head list;
++ char *param_string;
++};
static char program_name[] = "iscsistart";
-static int mgmt_ipc_fd;
@@ -12567,7 +12561,20 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
extern struct iscsi_ipc *ipc;
static struct option const long_options[] = {
-@@ -108,7 +107,7 @@ Open-iSCSI initiator.\n\
+@@ -77,6 +82,7 @@ static struct option const long_options[
+ {"fwparam_connect", no_argument, NULL, 'b'},
+ {"fwparam_network", no_argument, NULL, 'N'},
+ {"fwparam_print", no_argument, NULL, 'f'},
++ {"param", required_argument, NULL, 'P'},
+ {"help", no_argument, NULL, 'h'},
+ {"version", no_argument, NULL, 'v'},
+ {NULL, 0, NULL, 0},
+@@ -104,11 +110,12 @@ Open-iSCSI initiator.\n\
+ -b, --fwparam_connect create a session to the target using iBFT or OF\n\
+ -N, --fwparam_network bring up the network as specified by iBFT or OF\n\
+ -f, --fwparam_print print the iBFT or OF info to STDOUT \n\
++ -P, --param=NAME=VALUE set parameter with the name NAME to VALUE\n\
+ -h, --help display this help and exit\n\
-v, --version display version and exit\n\
");
}
@@ -12576,7 +12583,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
}
static int stop_event_loop(void)
-@@ -121,7 +120,7 @@ static int stop_event_loop(void)
+@@ -121,26 +128,75 @@ static int stop_event_loop(void)
req.command = MGMT_IPC_IMMEDIATE_STOP;
rc = iscsid_exec_req(&req, &rsp, 0);
if (rc) {
@@ -12585,7 +12592,83 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
log_error("Could not stop event_loop\n");
}
return rc;
-@@ -155,12 +154,12 @@ retry:
+ }
+
++static int apply_params(struct node_rec *rec)
++{
++ struct user_param *param;
++ int rc;
++
++ /* Must init this so we can check if user overrode them */
++ rec->session.initial_login_retry_max = -1;
++ rec->conn[0].timeo.noop_out_interval = -1;
++ rec->conn[0].timeo.noop_out_timeout = -1;
++
++ list_for_each_entry(param, &user_params, list) {
++ rc = idbm_parse_param(param->param_string, rec);
++ if (rc)
++ return rc;
++ }
++
++ /*
++ * For root boot we could not change this in older versions so
++ * if user did not override then use the defaults.
++ *
++ * Increase to account for boot using static setup.
++ */
++ if (rec->session.initial_login_retry_max == -1)
++ rec->session.initial_login_retry_max = 30;
++ /* we used to not be able to answer so turn off */
++ if (rec->conn[0].timeo.noop_out_interval == -1)
++ rec->conn[0].timeo.noop_out_interval = 0;
++ if (rec->conn[0].timeo.noop_out_timeout == -1)
++ rec->conn[0].timeo.noop_out_timeout = 0;
++
++ return 0;
++}
++
++static int alloc_param(char *param_string)
++{
++ struct user_param *param;
++
++ param = calloc(1, sizeof(*param));
++ if (!param) {
++ printf("Could not allocate for param.\n");
++ return ISCSI_ERR_NOMEM;
++ }
++
++ INIT_LIST_HEAD(¶m->list);
++ param->param_string = strdup(param_string);
++ if (!param->param_string) {
++ printf("Could not allocate for param.\n");
++ free(param);
++ return ISCSI_ERR_NOMEM;
++ }
++ list_add(¶m->list, &user_params);
++ return 0;
++}
+
+ static int login_session(struct node_rec *rec)
+ {
+ iscsiadm_req_t req;
+ iscsiadm_rsp_t rsp;
+ int rc, retries = 0;
+- /*
+- * For root boot we cannot change this so increase to account
+- * for boot using static setup.
+- */
+- rec->session.initial_login_retry_max = 30;
+- /* we cannot answer so turn off */
+- rec->conn[0].timeo.noop_out_interval = 0;
+- rec->conn[0].timeo.noop_out_timeout = 0;
++
++ rc = apply_params(rec);
++ if (rc)
++ exit(rc);
+
+ printf("%s: Logging into %s %s:%d,%d\n", program_name, rec->name,
+ rec->conn[0].address, rec->conn[0].port,
+@@ -155,12 +211,12 @@ retry:
* handle race where iscsid proc is starting up while we are
* trying to connect.
*/
@@ -12600,7 +12683,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
return rc;
}
-@@ -229,7 +228,7 @@ do { \
+@@ -229,7 +285,7 @@ do { \
if (strlen(str) > max_len) { \
printf("%s: invalid %s %s. Max %s length is %d.\n", \
program_name, param, str, param, max_len); \
@@ -12609,24 +12692,27 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
} \
} while (0);
-@@ -242,6 +241,7 @@ int main(int argc, char *argv[])
+@@ -242,6 +298,7 @@ int main(int argc, char *argv[])
struct boot_context *context, boot_context;
struct sigaction sa_old;
struct sigaction sa_new;
-+ int control_fd, mgmt_ipc_fd;
++ int control_fd, mgmt_ipc_fd, err;
pid_t pid;
idbm_node_setup_defaults(&config_rec);
-@@ -260,7 +260,7 @@ int main(int argc, char *argv[])
+@@ -260,9 +317,9 @@ int main(int argc, char *argv[])
sysfs_init();
if (iscsi_sysfs_check_class_version())
- exit(1);
+ exit(ISCSI_ERR_SYSFS_LOOKUP);
- while ((ch = getopt_long(argc, argv, "i:t:g:a:p:d:u:w:U:W:bNfvh",
+- while ((ch = getopt_long(argc, argv, "i:t:g:a:p:d:u:w:U:W:bNfvh",
++ while ((ch = getopt_long(argc, argv, "P:i:t:g:a:p:d:u:w:U:W:bNfvh",
long_options, &longindex)) >= 0) {
-@@ -316,25 +316,24 @@ int main(int argc, char *argv[])
+ switch (ch) {
+ case 'i':
+@@ -316,25 +373,24 @@ int main(int argc, char *argv[])
ret = fw_get_entry(&boot_context);
if (ret) {
printf("Could not get boot entry.\n");
@@ -12656,7 +12742,19 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
}
list_for_each_entry(context, &targets, list)
-@@ -350,18 +349,18 @@ int main(int argc, char *argv[])
+@@ -342,6 +398,11 @@ int main(int argc, char *argv[])
+
+ fw_free_targets(&targets);
+ exit(0);
++ case 'P':
++ err = alloc_param(optarg);
++ if (err)
++ exit(err);
++ break;
+ case 'v':
+ printf("%s version %s\n", program_name,
+ ISCSI_VERSION_STR);
+@@ -350,18 +411,18 @@ int main(int argc, char *argv[])
usage(0);
break;
default:
@@ -12678,7 +12776,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
} else if (pid) {
int status, rc, rc2;
-@@ -376,7 +375,7 @@ int main(int argc, char *argv[])
+@@ -376,7 +437,7 @@ int main(int argc, char *argv[])
waitpid(pid, &status, WUNTRACED);
if (rc || rc2)
@@ -12687,7 +12785,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
log_debug(1, "iscsi parent done");
exit(0);
-@@ -385,12 +384,12 @@ int main(int argc, char *argv[])
+@@ -385,12 +446,12 @@ int main(int argc, char *argv[])
mgmt_ipc_fd = mgmt_ipc_listen();
if (mgmt_ipc_fd < 0) {
log_error("Could not setup mgmt ipc\n");
@@ -12702,7 +12800,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
memset(&daemon_config, 0, sizeof (daemon_config));
daemon_config.initiator_name = initiatorname;
-@@ -420,6 +419,7 @@ int main(int argc, char *argv[])
+@@ -420,6 +481,7 @@ int main(int argc, char *argv[])
/*
* Start Main Event Loop
*/
@@ -12710,9 +12808,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsistart.c open-iscsi-2.0-872-rc4
actor_init();
event_loop(ipc, control_fd, mgmt_ipc_fd);
ipc->ctldev_close();
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_sysfs.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_sysfs.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_sysfs.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_sysfs.c 2012-03-05 23:05:31.000000000 -0600
@@ -36,6 +36,7 @@
#include "iface.h"
#include "session_info.h"
@@ -12748,7 +12846,37 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
if (list_empty(&t->list))
-@@ -238,7 +243,7 @@ uint32_t iscsi_sysfs_get_host_no_from_si
+@@ -226,6 +231,29 @@ void iscsi_sysfs_get_negotiated_session_
+ &conf->MaxOutstandingR2T);
+ }
+
++/*
++ * iscsi_sysfs_session_user_created - return if session was setup by userspace
++ * @sid: id of session to test
++ *
++ * Returns -1 if we could not tell due to kernel not supporting the
++ * feature. 0 is returned if kernel created it. And 1 is returned
++ * if userspace created it.
++ */
++int iscsi_sysfs_session_user_created(int sid)
++{
++ char id[NAME_SIZE];
++ pid_t pid;
++
++ snprintf(id, sizeof(id), ISCSI_SESSION_ID, sid);
++ if (sysfs_get_int(id, ISCSI_SESSION_SUBSYS, "creator", &pid))
++ return -1;
++
++ if (pid == -1)
++ return 0;
++ else
++ return 1;
++}
++
+ uint32_t iscsi_sysfs_get_host_no_from_sid(uint32_t sid, int *err)
+ {
+ struct sysfs_device *session_dev, *host_dev;
+@@ -238,7 +266,7 @@ uint32_t iscsi_sysfs_get_host_no_from_si
ISCSI_SESSION_SUBSYS, id)) {
log_error("Could not lookup devpath for %s. Possible sysfs "
"incompatibility.\n", id);
@@ -12757,7 +12885,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
return 0;
}
-@@ -246,7 +251,7 @@ uint32_t iscsi_sysfs_get_host_no_from_si
+@@ -246,7 +274,7 @@ uint32_t iscsi_sysfs_get_host_no_from_si
if (!session_dev) {
log_error("Could not get dev for %s. Possible sysfs "
"incompatibility.\n", id);
@@ -12766,7 +12894,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
return 0;
}
-@@ -271,7 +276,7 @@ uint32_t iscsi_sysfs_get_host_no_from_si
+@@ -271,7 +299,7 @@ uint32_t iscsi_sysfs_get_host_no_from_si
if (!host_dev) {
log_error("Could not get host dev for %s. Possible "
"sysfs incompatibility.\n", id);
@@ -12775,7 +12903,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
return 0;
}
}
-@@ -301,7 +306,7 @@ static uint32_t get_host_no_from_netdev(
+@@ -301,7 +329,7 @@ static uint32_t get_host_no_from_netdev(
info = calloc(1, sizeof(*info));
if (!info) {
@@ -12784,7 +12912,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
return -1;
}
strcpy(info->iface.netdev, netdev);
-@@ -311,7 +316,7 @@ static uint32_t get_host_no_from_netdev(
+@@ -311,7 +339,7 @@ static uint32_t get_host_no_from_netdev(
if (local_rc == 1)
host_no = info->host_no;
else
@@ -12793,7 +12921,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
free(info);
return host_no;
}
-@@ -320,14 +325,14 @@ static int __get_host_no_from_hwaddress(
+@@ -320,14 +348,14 @@ static int __get_host_no_from_hwaddress(
{
struct host_info *ret_info = data;
@@ -12810,7 +12938,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
{
uint32_t host_no = -1;
struct host_info *info;
-@@ -337,17 +342,17 @@ static uint32_t get_host_no_from_hwaddre
+@@ -337,17 +365,17 @@ static uint32_t get_host_no_from_hwaddre
info = calloc(1, sizeof(*info));
if (!info) {
@@ -12831,7 +12959,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
free(info);
return host_no;
}
-@@ -374,7 +379,7 @@ static uint32_t get_host_no_from_ipaddre
+@@ -374,7 +402,7 @@ static uint32_t get_host_no_from_ipaddre
info = calloc(1, sizeof(*info));
if (!info) {
@@ -12840,7 +12968,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
return -1;
}
strcpy(info->iface.ipaddress, address);
-@@ -384,7 +389,7 @@ static uint32_t get_host_no_from_ipaddre
+@@ -384,7 +412,7 @@ static uint32_t get_host_no_from_ipaddre
if (local_rc == 1)
host_no = info->host_no;
else
@@ -12849,7 +12977,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
free(info);
return host_no;
}
-@@ -396,7 +401,8 @@ uint32_t iscsi_sysfs_get_host_no_from_hw
+@@ -396,7 +424,8 @@ uint32_t iscsi_sysfs_get_host_no_from_hw
if (strlen(iface->hwaddress) &&
strcasecmp(iface->hwaddress, DEFAULT_HWADDRESS))
@@ -12859,7 +12987,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
else if (strlen(iface->netdev) &&
strcasecmp(iface->netdev, DEFAULT_NETDEV))
host_no = get_host_no_from_netdev(iface->netdev, &tmp_rc);
-@@ -404,7 +410,7 @@ uint32_t iscsi_sysfs_get_host_no_from_hw
+@@ -404,7 +433,7 @@ uint32_t iscsi_sysfs_get_host_no_from_hw
strcasecmp(iface->ipaddress, DEFAULT_IPADDRESS))
host_no = get_host_no_from_ipaddress(iface->ipaddress, &tmp_rc);
else
@@ -12868,7 +12996,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
*rc = tmp_rc;
return host_no;
-@@ -417,9 +423,9 @@ uint32_t iscsi_sysfs_get_host_no_from_hw
+@@ -417,11 +446,12 @@ uint32_t iscsi_sysfs_get_host_no_from_hw
* qla4xxx.
*/
static int iscsi_sysfs_read_iface(struct iface_rec *iface, int host_no,
@@ -12876,11 +13004,15 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
+ char *session, char *iface_kern_id)
{
- char id[NAME_SIZE];
++ uint32_t tmp_host_no, iface_num;
+ char host_id[NAME_SIZE];
struct iscsi_transport *t;
- int ret;
+- int ret;
++ int ret, iface_type;
-@@ -430,26 +436,31 @@ static int iscsi_sysfs_read_iface(struct
+ t = iscsi_sysfs_get_transport_by_hba(host_no);
+ if (!t)
+@@ -430,26 +460,31 @@ static int iscsi_sysfs_read_iface(struct
else
strcpy(iface->transport_name, t->name);
@@ -12918,7 +13050,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
iface->netdev, sizeof(iface->netdev));
if (ret)
log_debug(7, "could not read netdev for host%d\n", host_no);
-@@ -459,7 +470,7 @@ static int iscsi_sysfs_read_iface(struct
+@@ -459,7 +494,7 @@ static int iscsi_sysfs_read_iface(struct
* host level because we cannot create different initiator ports
* (cannot set isid either). The LLD also exports the iname at the
* hba level so apps can see it, but we no longer set the iname for
@@ -12927,7 +13059,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
* initiator names and of course software iscsi can support anything.
*/
ret = 1;
-@@ -481,7 +492,7 @@ static int iscsi_sysfs_read_iface(struct
+@@ -481,7 +516,7 @@ static int iscsi_sysfs_read_iface(struct
}
if (ret) {
@@ -12936,7 +13068,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
iface->iname, sizeof(iface->iname));
if (ret)
/*
-@@ -493,6 +504,8 @@ static int iscsi_sysfs_read_iface(struct
+@@ -493,6 +528,8 @@ static int iscsi_sysfs_read_iface(struct
*/
log_debug(7, "Could not read initiatorname for "
"host%d\n", host_no);
@@ -12945,7 +13077,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
/*
-@@ -523,12 +536,63 @@ static int iscsi_sysfs_read_iface(struct
+@@ -523,12 +560,67 @@ static int iscsi_sysfs_read_iface(struct
iface_str(iface));
}
}
@@ -12974,28 +13106,32 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
+ "link_local_addr", iface->ipv6_linklocal,
+ sizeof(iface->ipv6_linklocal));
+
-+ if (sysfs_get_str(iface_kern_id, ISCSI_IFACE_SUBSYS,
-+ "linklocal_autocfg",
-+ iface->linklocal_autocfg,
-+ sizeof(iface->linklocal_autocfg))) {
-+ /* misspelled in some test kernels */
-+ sysfs_get_str(iface_kern_id, ISCSI_IFACE_SUBSYS,
-+ "link_local_autocfg",
-+ iface->linklocal_autocfg,
-+ sizeof(iface->linklocal_autocfg));
-+ }
++ sysfs_get_str(iface_kern_id, ISCSI_IFACE_SUBSYS,
++ "link_local_autocfg", iface->linklocal_autocfg,
++ sizeof(iface->linklocal_autocfg));
+
+ sysfs_get_str(iface_kern_id, ISCSI_IFACE_SUBSYS, "router_addr",
+ iface->ipv6_router,
+ sizeof(iface->ipv6_router));
+ }
+
-+ sysfs_get_uint16(iface_kern_id, ISCSI_IFACE_SUBSYS, "mtu",
-+ &iface->mtu);
-+ sysfs_get_uint16(iface_kern_id, ISCSI_IFACE_SUBSYS, "vlan",
-+ &iface->vlan_id);
-+ sysfs_get_uint8(iface_kern_id, ISCSI_IFACE_SUBSYS, "vlan_priority",
-+ &iface->vlan_priority);
++ if (sysfs_get_uint16(iface_kern_id, ISCSI_IFACE_SUBSYS, "port",
++ &iface->port))
++ iface->port = 0;
++ if (sysfs_get_uint16(iface_kern_id, ISCSI_IFACE_SUBSYS, "mtu",
++ &iface->mtu))
++ iface->mtu = 0;
++ if (sysfs_get_uint16(iface_kern_id, ISCSI_IFACE_SUBSYS, "vlan_id",
++ &iface->vlan_id))
++ iface->vlan_id = UINT16_MAX;
++
++ if (sysfs_get_uint8(iface_kern_id, ISCSI_IFACE_SUBSYS, "vlan_priority",
++ &iface->vlan_priority))
++ iface->vlan_priority = UINT8_MAX;
++
++ if (sscanf(iface_kern_id, "ipv%d-iface-%u-%u", &iface_type,
++ &tmp_host_no, &iface_num) == 3)
++ iface->iface_num = iface_num;
+done:
+ if (ret)
+ return ISCSI_ERR_SYSFS_LOOKUP;
@@ -13011,7 +13147,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
int iscsi_sysfs_for_each_host(void *data, int *nr_found,
-@@ -540,7 +604,7 @@ int iscsi_sysfs_for_each_host(void *data
+@@ -540,7 +632,7 @@ int iscsi_sysfs_for_each_host(void *data
info = malloc(sizeof(*info));
if (!info)
@@ -13020,7 +13156,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
n = scandir(ISCSI_HOST_DIR, &namelist, trans_filter,
alphasort);
-@@ -572,6 +636,50 @@ free_info:
+@@ -572,6 +664,50 @@ free_info:
return rc;
}
@@ -13071,7 +13207,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
/**
* sysfs_session_has_leadconn - checks if session has lead conn in kernel
* @sid: session id
-@@ -631,7 +739,7 @@ int iscsi_sysfs_get_sid_from_path(char *
+@@ -631,7 +767,7 @@ int iscsi_sysfs_get_sid_from_path(char *
if (!dev) {
log_error("Could not get dev for %s. Possible sysfs "
"incompatibility.\n", devpath);
@@ -13080,7 +13216,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
if (!strncmp(dev->kernel, "session", 7))
-@@ -645,8 +753,7 @@ int iscsi_sysfs_get_sid_from_path(char *
+@@ -645,8 +781,7 @@ int iscsi_sysfs_get_sid_from_path(char *
}
log_error("Unable to find sid in path %s", session);
@@ -13090,7 +13226,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
int iscsi_sysfs_get_sessioninfo_by_id(struct session_info *info, char *session)
-@@ -657,21 +764,65 @@ int iscsi_sysfs_get_sessioninfo_by_id(st
+@@ -657,21 +792,65 @@ int iscsi_sysfs_get_sessioninfo_by_id(st
if (sscanf(session, "session%d", &info->sid) != 1) {
log_error("invalid session '%s'", session);
@@ -13160,7 +13296,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
snprintf(id, sizeof(id), ISCSI_CONN_ID, info->sid);
-@@ -727,13 +878,13 @@ int iscsi_sysfs_get_sessioninfo_by_id(st
+@@ -727,13 +906,13 @@ int iscsi_sysfs_get_sessioninfo_by_id(st
ret = 0;
host_no = iscsi_sysfs_get_host_no_from_sid(info->sid, &ret);
if (ret) {
@@ -13178,7 +13314,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
log_debug(7, "found targetname %s address %s pers address %s port %d "
"pers port %d driver %s iface name %s ipaddress %s "
"netdev %s hwaddress %s iname %s",
-@@ -745,7 +896,7 @@ int iscsi_sysfs_get_sessioninfo_by_id(st
+@@ -745,7 +924,7 @@ int iscsi_sysfs_get_sessioninfo_by_id(st
info->iface.iname);
return 0;
}
@@ -13187,7 +13323,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
int iscsi_sysfs_for_each_session(void *data, int *nr_found,
iscsi_sysfs_session_op_fn *fn)
{
-@@ -755,7 +906,7 @@ int iscsi_sysfs_for_each_session(void *d
+@@ -755,7 +934,7 @@ int iscsi_sysfs_for_each_session(void *d
info = calloc(1, sizeof(*info));
if (!info)
@@ -13196,7 +13332,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
n = scandir(ISCSI_SESSION_DIR, &namelist, trans_filter,
alphasort);
-@@ -797,8 +948,10 @@ int iscsi_sysfs_get_session_state(char *
+@@ -797,8 +976,10 @@ int iscsi_sysfs_get_session_state(char *
char id[NAME_SIZE];
snprintf(id, sizeof(id), ISCSI_SESSION_ID, sid);
@@ -13209,7 +13345,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
int iscsi_sysfs_get_host_state(char *state, int host_no)
-@@ -806,8 +959,10 @@ int iscsi_sysfs_get_host_state(char *sta
+@@ -806,8 +987,10 @@ int iscsi_sysfs_get_host_state(char *sta
char id[NAME_SIZE];
snprintf(id, sizeof(id), ISCSI_HOST_ID, host_no);
@@ -13222,7 +13358,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
int iscsi_sysfs_get_device_state(char *state, int host_no, int target, int lun)
-@@ -818,7 +973,7 @@ int iscsi_sysfs_get_device_state(char *s
+@@ -818,7 +1001,7 @@ int iscsi_sysfs_get_device_state(char *s
if (sysfs_get_str(id, SCSI_SUBSYS, "state", state,
SCSI_MAX_STATE_VALUE)) {
log_debug(3, "Could not read attr state for %s\n", id);
@@ -13231,7 +13367,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
return 0;
-@@ -828,7 +983,6 @@ char *iscsi_sysfs_get_blockdev_from_lun(
+@@ -828,7 +1011,6 @@ char *iscsi_sysfs_get_blockdev_from_lun(
{
char devpath[PATH_SIZE];
char path_full[PATH_SIZE];
@@ -13239,7 +13375,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
char id[NAME_SIZE];
DIR *dirfd;
struct dirent *dent;
-@@ -845,9 +999,8 @@ char *iscsi_sysfs_get_blockdev_from_lun(
+@@ -845,9 +1027,8 @@ char *iscsi_sysfs_get_blockdev_from_lun(
}
sysfs_len = strlcpy(path_full, sysfs_path, sizeof(path_full));
@@ -13250,7 +13386,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
strlcat(path_full, devpath, sizeof(path_full));
dirfd = opendir(path_full);
-@@ -912,14 +1065,13 @@ static uint32_t get_target_no_from_sid(u
+@@ -912,14 +1093,13 @@ static uint32_t get_target_no_from_sid(u
{
char devpath[PATH_SIZE];
char path_full[PATH_SIZE];
@@ -13266,7 +13402,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
snprintf(id, sizeof(id), "session%u", sid);
if (!sysfs_lookup_devpath_by_subsys_id(devpath, sizeof(devpath),
-@@ -935,9 +1087,8 @@ static uint32_t get_target_no_from_sid(u
+@@ -935,9 +1115,8 @@ static uint32_t get_target_no_from_sid(u
* /class/iscsi_session/sessionX/device.
*/
sysfs_len = strlcpy(path_full, sysfs_path, sizeof(path_full));
@@ -13277,7 +13413,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
strlcat(path_full, devpath, sizeof(path_full));
strlcat(path_full, "/device", sizeof(devpath));
-@@ -970,7 +1121,8 @@ struct iscsi_transport *iscsi_sysfs_get_
+@@ -970,7 +1149,8 @@ struct iscsi_transport *iscsi_sysfs_get_
struct iscsi_transport *t;
/* sync up kernel and userspace */
@@ -13287,7 +13423,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
/* check if the transport is loaded and matches */
list_for_each_entry(t, &transports, list) {
-@@ -1043,6 +1195,19 @@ int iscsi_sysfs_get_exp_statsn(int sid)
+@@ -1043,6 +1223,19 @@ int iscsi_sysfs_get_exp_statsn(int sid)
return exp_statsn;
}
@@ -13307,7 +13443,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
int iscsi_sysfs_for_each_device(void *data, int host_no, uint32_t sid,
void (* fn)(void *data, int host_no,
int target, int lun))
-@@ -1061,7 +1226,7 @@ int iscsi_sysfs_for_each_device(void *da
+@@ -1061,7 +1254,7 @@ int iscsi_sysfs_for_each_device(void *da
ISCSI_SESSION_SUBSYS, id)) {
log_debug(3, "Could not lookup devpath for %s %s\n",
ISCSI_SESSION_SUBSYS, id);
@@ -13316,9 +13452,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.c open-iscsi-2.0-872-rc
}
snprintf(path_full, sizeof(path_full), "%s%s/device/target%d:0:%d",
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_sysfs.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_sysfs.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_sysfs.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_sysfs.h 2012-03-05 23:05:31.000000000 -0600
@@ -43,7 +43,11 @@ extern int iscsi_sysfs_session_has_leadc
typedef int (iscsi_sysfs_session_op_fn)(void *, struct session_info *);
@@ -13339,17 +13475,18 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_sysfs.h open-iscsi-2.0-872-rc
extern int iscsi_sysfs_get_hostinfo_by_host_no(struct host_info *hinfo);
extern int iscsi_sysfs_get_sid_from_path(char *session);
extern char *iscsi_sysfs_get_blockdev_from_lun(int hostno, int target, int sid);
-@@ -84,6 +89,7 @@ extern struct iscsi_transport *iscsi_sys
+@@ -84,6 +89,8 @@ extern struct iscsi_transport *iscsi_sys
extern struct iscsi_transport *iscsi_sysfs_get_transport_by_session(char *sys_session);
extern struct iscsi_transport *iscsi_sysfs_get_transport_by_sid(uint32_t sid);
extern struct iscsi_transport *iscsi_sysfs_get_transport_by_name(char *transport_name);
+extern int iscsi_sysfs_session_supports_nop(int sid);
++extern int iscsi_sysfs_session_user_created(int sid);
extern struct list_head transports;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_timer.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_timer.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_timer.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_timer.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_timer.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_timer.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_timer.c 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,86 @@
+/*
+ * iSCSI timer
@@ -13437,9 +13574,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_timer.c open-iscsi-2.0-872-rc
+
+ return msecs;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_timer.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_timer.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_timer.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_timer.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_timer.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_timer.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_timer.h 2012-03-05 23:02:46.000000000 -0600
@@ -0,0 +1,28 @@
+/*
+ * iSCSI timer
@@ -13469,9 +13606,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_timer.h open-iscsi-2.0-872-rc
+extern int iscsi_timer_msecs_until(struct timeval *timer);
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_util.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_util.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_util.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_util.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_util.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_util.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_util.c 2012-03-05 23:02:46.000000000 -0600
@@ -25,12 +25,15 @@
#include <string.h>
#include <errno.h>
@@ -13665,9 +13802,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_util.c open-iscsi-2.0-872-rc4
+ info->persistent_port, NULL,
+ MATCH_ANY_SID);
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_util.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_util.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_util.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_util.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_util.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/iscsi_util.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_util.h 2012-03-05 23:02:46.000000000 -0600
@@ -14,9 +14,14 @@ extern int increase_max_files(void);
extern char *str_to_ipport(char *str, int *port, int *tgpt);
@@ -13684,9 +13821,161 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_util.h open-iscsi-2.0-872-rc4
extern char *strstrip(char *s);
extern char *cfg_get_string_param(char *pathname, const char *key);
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/log.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/log.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iser.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iser.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iser.c 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iser.c 2012-03-05 23:06:13.000000000 -0600
+@@ -0,0 +1,22 @@
++/*
++ * iser helpers
++ *
++ * Copyright (C) 2012 Red Hat, Inc. All rights reserved.
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published
++ * by the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ *
++ * This program is distributed in the hope that it will be useful, but
++ * WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
++ * General Public License for more details.
++ */
++#include "initiator.h"
++
++void iser_create_conn(struct iscsi_conn *conn)
++{
++ /* header digests not supported in iser */
++ conn->hdrdgst_en = ISCSI_DIGEST_NONE;
++}
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iser.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iser.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iser.h 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iser.h 2012-03-05 23:06:13.000000000 -0600
+@@ -0,0 +1,8 @@
++#ifndef ISER_TRANSPORT
++#define ISER_TRANSPORT
++
++struct iscsi_conn;
++
++extern void iser_create_conn(struct iscsi_conn *conn);
++
++#endif
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/kern_err_table.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/kern_err_table.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/kern_err_table.c 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/kern_err_table.c 2012-03-05 23:03:56.000000000 -0600
+@@ -0,0 +1,83 @@
++/*
++ * Copyright (C) 2011 Aastha Mehta
++ * Copyright (C) 2011 Mike Christie
++ *
++ * maintained by open-iscsi at googlegroups.com
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published
++ * by the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ *
++ * This program is distributed in the hope that it will be useful, but
++ * WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
++ * General Public License for more details.
++ *
++ * See the file COPYING included with this distribution for more details.
++ */
++#include <stdio.h>
++#include <stdlib.h>
++#include <string.h>
++#include "iscsi_if.h"
++
++#include "kern_err_table.h"
++
++const char *kern_err_code_to_string(int err)
++{
++ switch (err){
++ case ISCSI_OK:
++ return "ISCSI_OK: operation successful";
++ case ISCSI_ERR_DATASN:
++ return "ISCSI_ERR_DATASN: Received invalid data sequence "
++ "number from target";
++ case ISCSI_ERR_DATA_OFFSET:
++ return "ISCSI_ERR_DATA_OFFSET: Seeking offset beyond the size "
++ "of the iSCSI segment";
++ case ISCSI_ERR_MAX_CMDSN:
++ return "ISCSI_ERR_MAX_CMDSN: Received invalid command sequence "
++ "number from target";
++ case ISCSI_ERR_EXP_CMDSN:
++ return "ISCSI_ERR_EXP_CMDSN: Received invalid expected command " "sequence number from target";
++ case ISCSI_ERR_BAD_OPCODE:
++ return "ISCSI_ERR_BAD_OPCODE: Received an invalid iSCSI opcode";
++ case ISCSI_ERR_DATALEN:
++ return "ISCSI_ERR_DATALEN: Invalid data length value";
++ case ISCSI_ERR_AHSLEN:
++ return "ISCSI_ERR_AHSLEN: Received an invalid AHS length";
++ case ISCSI_ERR_PROTO:
++ return "ISCSI_ERR_PROTO: iSCSI protocol violation";
++ case ISCSI_ERR_LUN:
++ return "ISCSI_ERR_LUN: LUN mismatch";
++ case ISCSI_ERR_BAD_ITT:
++ return "ISCSI_ERR_BAD_ITT: Received invalid initiator task tag " "from target";
++ case ISCSI_ERR_CONN_FAILED:
++ return "ISCSI_ERR_CONN_FAILED: iSCSI connection failed";
++ case ISCSI_ERR_R2TSN:
++ return "ISCSI_ERR_R2TSN: Received invalid R2T (Ready to "
++ "Transfer) data sequence number from target";
++ case ISCSI_ERR_SESSION_FAILED:
++ return "ISCSI_ERR_SESSION_FAILED: iSCSI session failed";
++ case ISCSI_ERR_HDR_DGST:
++ return "ISCSI_ERR_HDR_DGST: Header digest mismatch";
++ case ISCSI_ERR_DATA_DGST:
++ return "ISCSI_ERR_DATA_DGST: Data digest mismatch";
++ case ISCSI_ERR_PARAM_NOT_FOUND:
++ return "ISCSI_ERR_PARAM_NOT_FOUND: Parameter not found";
++ case ISCSI_ERR_NO_SCSI_CMD:
++ return "ISCSI_ERR_NO_SCSI_CMD: Could not look up SCSI command";
++ case ISCSI_ERR_INVALID_HOST:
++ return "ISCSI_ERR_INVALID_HOST: iSCSI host is in an invalid "
++ "state";
++ case ISCSI_ERR_XMIT_FAILED:
++ return "ISCSI_ERR_XMIT_FAILED: Transmission of iSCSI packet "
++ "failed";
++ case ISCSI_ERR_TCP_CONN_CLOSE:
++ return "ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed";
++ case ISCSI_ERR_SCSI_EH_SESSION_RST:
++ return "ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as "
++ "a result of SCSI error recovery";
++ default:
++ return "Invalid or unknown error code";
++ }
++}
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/kern_err_table.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/kern_err_table.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/kern_err_table.h 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/kern_err_table.h 2012-03-05 23:03:56.000000000 -0600
+@@ -0,0 +1,23 @@
++/*
++ * Copyright (C) 2011 Aastha Mehta
++ * Copyright (C) 2011 Mike Christie
++ *
++ * maintained by open-iscsi at googlegroups.com
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License as published
++ * by the Free Software Foundation; either version 2 of the License, or
++ * (at your option) any later version.
++ *
++ * This program is distributed in the hope that it will be useful, but
++ * WITHOUT ANY WARRANTY; without even the implied warranty of
++ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
++ * General Public License for more details.
++ *
++ * See the file COPYING included with this distribution for more details.
++ */
++#ifndef __KERN_ERR_TABLE_H__
++#define __KERN_ERR_TABLE_H__
++
++extern const char *kern_err_code_to_string(int);
++#endif
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/log.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/log.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/log.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/log.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/log.c 2012-03-05 23:02:46.000000000 -0600
@@ -326,6 +326,7 @@ void log_info(const char *fmt, ...)
va_end(ap);
}
@@ -13714,9 +14003,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/log.c open-iscsi-2.0-872-rc4-bnx2i.
+ waitpid(pid, &status, 0);
+ }
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/login.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/login.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/login.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/login.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/login.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/login.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/login.c 2012-03-05 23:02:46.000000000 -0600
@@ -27,11 +27,14 @@
#include <stdio.h>
#include <stdlib.h>
@@ -13849,9 +14138,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/login.c open-iscsi-2.0-872-rc4-bnx2
} while (conn->current_stage != ISCSI_FULL_FEATURE_PHASE);
c->ret = LOGIN_OK;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/Makefile open-iscsi-2.0-872-rc4-bnx2i.sync/usr/Makefile
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/Makefile open-iscsi-2.0-872-rc4-bnx2i.work/usr/Makefile
--- open-iscsi-2.0-872-rc4-bnx2i/usr/Makefile 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/Makefile 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/Makefile 2012-03-05 23:06:13.000000000 -0600
@@ -21,10 +21,12 @@ ifeq ($(OSNAME),Linux)
endif
endif
@@ -13874,12 +14163,12 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/Makefile open-iscsi-2.0-872-rc4-bnx
- iscsid_req.o $(SYSDEPS_SRCS)
+ISCSI_LIB_SRCS = iscsi_util.o io.o auth.o iscsi_timer.o login.o log.o md5.o \
+ sha1.o iface.o idbm.o sysfs.o host.o session_info.o iscsi_sysfs.o \
-+ iscsi_net_util.o iscsid_req.o transport.o cxgbi.o be2iscsi.o \
++ iscsi_net_util.o iscsid_req.o transport.o iser.o cxgbi.o be2iscsi.o \
+ initiator_common.o iscsi_err.o $(IPC_OBJ) $(SYSDEPS_SRCS) $(DCB_OBJ)
# core initiator files
-INITIATOR_SRCS = initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o \
- transport.o cxgb3i.o be2iscsi.o
-+INITIATOR_SRCS = initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o
++INITIATOR_SRCS = initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o kern_err_table.o
+
# fw boot files
FW_BOOT_SRCS = $(wildcard ../utils/fwparam_ibft/*.o)
@@ -13903,9 +14192,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/Makefile open-iscsi-2.0-872-rc4-bnx
iscsistart.o statics.o
$(CC) $(CFLAGS) -static $^ -o $@
clean:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/mgmt_ipc.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/mgmt_ipc.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/mgmt_ipc.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/mgmt_ipc.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/mgmt_ipc.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/mgmt_ipc.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/mgmt_ipc.c 2012-03-05 23:02:46.000000000 -0600
@@ -35,6 +35,7 @@
#include "transport.h"
#include "sysdeps.h"
@@ -14172,7 +14461,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/mgmt_ipc.c open-iscsi-2.0-872-rc4-b
{
if (!qtask)
return;
-@@ -446,7 +435,8 @@ mgmt_ipc_write_rsp(queue_task_t *qtask,
+@@ -446,7 +435,8 @@ mgmt_ipc_write_rsp(queue_task_t *qtask,
}
qtask->rsp.err = err;
@@ -14214,9 +14503,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/mgmt_ipc.c open-iscsi-2.0-872-rc4-b
}
err:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/mgmt_ipc.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/mgmt_ipc.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/mgmt_ipc.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/mgmt_ipc.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/mgmt_ipc.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/mgmt_ipc.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/mgmt_ipc.h 2012-03-05 23:02:46.000000000 -0600
@@ -26,30 +26,6 @@
#define ISCSIADM_NAMESPACE "ISCSIADM_ABSTRACT_NAMESPACE"
#define PEERUSER_MAX 64
@@ -14286,10 +14575,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/mgmt_ipc.h open-iscsi-2.0-872-rc4-b
int mgmt_ipc_listen(void);
void mgmt_ipc_close(int fd);
void mgmt_ipc_handle(int accept_fd);
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/netlink.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/netlink.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/netlink.c 2011-08-14 16:48:25.000000000 -0500
-@@ -33,7 +33,6 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/netlink.c 2012-03-05 23:06:18.000000000 -0600
+@@ -33,12 +33,12 @@
#include "types.h"
#include "iscsi_if.h"
@@ -14297,7 +14586,13 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
#include "log.h"
#include "iscsi_ipc.h"
#include "initiator.h"
-@@ -50,23 +49,25 @@ static void *nlm_sendbuf;
+ #include "iscsi_sysfs.h"
+ #include "transport.h"
++#include "iscsi_netlink.h"
+
+ static int ctrl_fd;
+ static struct sockaddr_nl src_addr, dest_addr;
+@@ -50,23 +50,38 @@ static void *nlm_sendbuf;
static void *nlm_recvbuf;
static void *pdu_sendbuf;
static void *setparam_buf;
@@ -14311,17 +14606,29 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
+#define NLM_BUF_DEFAULT_MAX (NLMSG_SPACE(ISCSI_DEF_MAX_RECV_SEG_LEN + \
+ sizeof(struct iscsi_uevent) + \
+ sizeof(struct iscsi_hdr)))
-+
+
+-#define PDU_SENDBUF_DEFAULT_MAX \
+- (ISCSI_DEF_MAX_RECV_SEG_LEN + sizeof(struct iscsi_hdr))
+#define PDU_SENDBUF_DEFAULT_MAX (ISCSI_DEF_MAX_RECV_SEG_LEN + \
+ sizeof(struct iscsi_uevent) + \
+ sizeof(struct iscsi_hdr))
--#define PDU_SENDBUF_DEFAULT_MAX \
-- (ISCSI_DEF_MAX_RECV_SEG_LEN + sizeof(struct iscsi_hdr))
--
-#define NLM_SETPARAM_DEFAULT_MAX \
- (NI_MAXHOST + 1 + sizeof(struct iscsi_uevent))
+#define NLM_SETPARAM_DEFAULT_MAX (NI_MAXHOST + 1 + sizeof(struct iscsi_uevent))
++
++struct nlattr *iscsi_nla_alloc(uint16_t type, uint16_t len)
++{
++ struct nlattr *attr;
++
++ attr = calloc(1, ISCSI_NLA_TOTAL_LEN(len));
++ if (!attr)
++ return NULL;
++
++ attr->nla_len = ISCSI_NLA_LEN(len);
++ attr->nla_type = type;
++ return attr;
++}
static int
kread(char *data, int count)
@@ -14332,7 +14639,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
memcpy(data, recvbuf + recvlen, count);
recvlen += count;
-@@ -107,6 +108,12 @@ nlpayload_read(int ctrl_fd, char *data,
+@@ -107,6 +122,12 @@ nlpayload_read(int ctrl_fd, char *data,
iov.iov_base = nlm_recvbuf;
iov.iov_len = NLMSG_SPACE(count);
@@ -14345,7 +14652,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
memset(iov.iov_base, 0, iov.iov_len);
memset(&msg, 0, sizeof(msg));
-@@ -142,7 +149,8 @@ nlpayload_read(int ctrl_fd, char *data,
+@@ -142,7 +163,8 @@ nlpayload_read(int ctrl_fd, char *data,
*/
rc = recvmsg(ctrl_fd, &msg, flags);
@@ -14355,7 +14662,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return rc;
}
-@@ -153,7 +161,6 @@ kwritev(enum iscsi_uevent_e type, struct
+@@ -153,7 +175,6 @@ kwritev(enum iscsi_uevent_e type, struct
int i, rc;
struct nlmsghdr *nlh;
struct msghdr msg;
@@ -14363,19 +14670,19 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
int datalen = 0;
log_debug(7, "in %s", __FUNCTION__);
-@@ -172,27 +179,25 @@ kwritev(enum iscsi_uevent_e type, struct
+@@ -172,27 +193,25 @@ kwritev(enum iscsi_uevent_e type, struct
}
nlh = nlm_sendbuf;
- memset(nlh, 0, NLMSG_SPACE(datalen));
+ memset(nlh, 0, NLMSG_SPACE(0));
-
-- nlh->nlmsg_len = NLMSG_SPACE(datalen);
++
+ datalen = 0;
+ for (i = 1; i < count; i++)
+ datalen += iovp[i].iov_len;
-+
-+ nlh->nlmsg_len = NLMSG_ALIGN(datalen);
+
+- nlh->nlmsg_len = NLMSG_SPACE(datalen);
++ nlh->nlmsg_len = datalen + sizeof(*nlh);
nlh->nlmsg_pid = getpid();
nlh->nlmsg_flags = 0;
nlh->nlmsg_type = type;
@@ -14401,7 +14708,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
do {
/*
-@@ -253,19 +258,15 @@ kwritev(enum iscsi_uevent_e type, struct
+@@ -253,19 +272,15 @@ kwritev(enum iscsi_uevent_e type, struct
* cleanup. (Dima)
*/
static int
@@ -14424,7 +14731,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
do {
if ((rc = nlpayload_read(ctrl_fd, (void*)ev,
-@@ -325,6 +326,7 @@ ksendtargets(uint64_t transport_handle,
+@@ -325,6 +340,7 @@ ksendtargets(uint64_t transport_handle,
{
int rc, addrlen;
struct iscsi_uevent *ev;
@@ -14432,7 +14739,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -346,7 +348,9 @@ ksendtargets(uint64_t transport_handle,
+@@ -346,7 +362,9 @@ ksendtargets(uint64_t transport_handle,
}
memcpy(setparam_buf + sizeof(*ev), addr, addrlen);
@@ -14443,7 +14750,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
if (rc < 0) {
log_error("sendtargets failed rc%d\n", rc);
return rc;
-@@ -361,6 +365,7 @@ kcreate_session(uint64_t transport_handl
+@@ -361,6 +379,7 @@ kcreate_session(uint64_t transport_handl
{
int rc;
struct iscsi_uevent ev;
@@ -14451,7 +14758,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -381,9 +386,11 @@ kcreate_session(uint64_t transport_handl
+@@ -381,9 +400,11 @@ kcreate_session(uint64_t transport_handl
ev.u.c_bound_session.ep_handle = ep_handle;
}
@@ -14465,7 +14772,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
*hostno = ev.r.c_session_ret.host_no;
*out_sid = ev.r.c_session_ret.sid;
-@@ -396,6 +403,7 @@ kdestroy_session(uint64_t transport_hand
+@@ -396,6 +417,7 @@ kdestroy_session(uint64_t transport_hand
{
int rc;
struct iscsi_uevent ev;
@@ -14473,7 +14780,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -405,9 +413,11 @@ kdestroy_session(uint64_t transport_hand
+@@ -405,9 +427,11 @@ kdestroy_session(uint64_t transport_hand
ev.transport_handle = transport_handle;
ev.u.d_session.sid = sid;
@@ -14487,7 +14794,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return 0;
}
-@@ -417,6 +427,7 @@ kunbind_session(uint64_t transport_handl
+@@ -417,6 +441,7 @@ kunbind_session(uint64_t transport_handl
{
int rc;
struct iscsi_uevent ev;
@@ -14495,7 +14802,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -426,9 +437,11 @@ kunbind_session(uint64_t transport_handl
+@@ -426,9 +451,11 @@ kunbind_session(uint64_t transport_handl
ev.transport_handle = transport_handle;
ev.u.d_session.sid = sid;
@@ -14509,7 +14816,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return 0;
}
-@@ -439,6 +452,7 @@ kcreate_conn(uint64_t transport_handle,
+@@ -439,6 +466,7 @@ kcreate_conn(uint64_t transport_handle,
{
int rc;
struct iscsi_uevent ev;
@@ -14517,7 +14824,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -449,7 +463,10 @@ kcreate_conn(uint64_t transport_handle,
+@@ -449,7 +477,10 @@ kcreate_conn(uint64_t transport_handle,
ev.u.c_conn.cid = cid;
ev.u.c_conn.sid = sid;
@@ -14529,7 +14836,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "returned %d", rc);
return rc;
}
-@@ -466,6 +483,7 @@ kdestroy_conn(uint64_t transport_handle,
+@@ -466,6 +497,7 @@ kdestroy_conn(uint64_t transport_handle,
{
int rc;
struct iscsi_uevent ev;
@@ -14537,7 +14844,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -476,9 +494,11 @@ kdestroy_conn(uint64_t transport_handle,
+@@ -476,9 +508,11 @@ kdestroy_conn(uint64_t transport_handle,
ev.u.d_conn.sid = sid;
ev.u.d_conn.cid = cid;
@@ -14551,7 +14858,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return 0;
}
-@@ -489,6 +509,7 @@ kbind_conn(uint64_t transport_handle, ui
+@@ -489,6 +523,7 @@ kbind_conn(uint64_t transport_handle, ui
{
int rc;
struct iscsi_uevent ev;
@@ -14559,7 +14866,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -501,9 +522,11 @@ kbind_conn(uint64_t transport_handle, ui
+@@ -501,9 +536,11 @@ kbind_conn(uint64_t transport_handle, ui
ev.u.b_conn.transport_eph = transport_eph;
ev.u.b_conn.is_leading = is_leading;
@@ -14573,7 +14880,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
*retcode = ev.r.retcode;
-@@ -515,6 +538,7 @@ ksend_pdu_begin(uint64_t transport_handl
+@@ -515,6 +552,7 @@ ksend_pdu_begin(uint64_t transport_handl
int hdr_size, int data_size)
{
struct iscsi_uevent *ev;
@@ -14581,7 +14888,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -523,8 +547,13 @@ ksend_pdu_begin(uint64_t transport_handl
+@@ -523,8 +561,13 @@ ksend_pdu_begin(uint64_t transport_handl
exit(-EIO);
}
@@ -14596,7 +14903,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
xmitlen = sizeof(*ev);
ev = xmitbuf;
memset(ev, 0, sizeof(*ev));
-@@ -545,7 +574,7 @@ ksend_pdu_end(uint64_t transport_handle,
+@@ -545,7 +588,7 @@ ksend_pdu_end(uint64_t transport_handle,
{
int rc;
struct iscsi_uevent *ev;
@@ -14605,7 +14912,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -559,10 +588,11 @@ ksend_pdu_end(uint64_t transport_handle,
+@@ -559,10 +602,11 @@ ksend_pdu_end(uint64_t transport_handle,
exit(-EIO);
}
@@ -14620,7 +14927,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
goto err;
if (ev->r.retcode) {
*retcode = ev->r.retcode;
-@@ -592,6 +622,7 @@ kset_host_param(uint64_t transport_handl
+@@ -592,6 +636,7 @@ kset_host_param(uint64_t transport_handl
struct iscsi_uevent *ev;
char *param_str;
int rc, len;
@@ -14628,7 +14935,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -618,9 +649,11 @@ kset_host_param(uint64_t transport_handl
+@@ -618,9 +663,11 @@ kset_host_param(uint64_t transport_handl
}
ev->u.set_host_param.len = len = strlen(param_str) + 1;
@@ -14642,7 +14949,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return 0;
}
-@@ -632,6 +665,7 @@ kset_param(uint64_t transport_handle, ui
+@@ -632,6 +679,7 @@ kset_param(uint64_t transport_handle, ui
struct iscsi_uevent *ev;
char *param_str;
int rc, len;
@@ -14650,7 +14957,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -659,9 +693,11 @@ kset_param(uint64_t transport_handle, ui
+@@ -659,9 +707,11 @@ kset_param(uint64_t transport_handle, ui
}
ev->u.set_param.len = len = strlen(param_str) + 1;
@@ -14664,7 +14971,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return 0;
}
-@@ -671,6 +707,7 @@ kstop_conn(uint64_t transport_handle, ui
+@@ -671,6 +721,7 @@ kstop_conn(uint64_t transport_handle, ui
{
int rc;
struct iscsi_uevent ev;
@@ -14672,7 +14979,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -682,9 +719,11 @@ kstop_conn(uint64_t transport_handle, ui
+@@ -682,9 +733,11 @@ kstop_conn(uint64_t transport_handle, ui
ev.u.stop_conn.cid = cid;
ev.u.stop_conn.flag = flag;
@@ -14686,7 +14993,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return 0;
}
-@@ -695,6 +734,7 @@ kstart_conn(uint64_t transport_handle, u
+@@ -695,6 +748,7 @@ kstart_conn(uint64_t transport_handle, u
{
int rc;
struct iscsi_uevent ev;
@@ -14694,7 +15001,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -705,9 +745,11 @@ kstart_conn(uint64_t transport_handle, u
+@@ -705,9 +759,11 @@ kstart_conn(uint64_t transport_handle, u
ev.u.start_conn.sid = sid;
ev.u.start_conn.cid = cid;
@@ -14708,7 +15015,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
*retcode = ev.r.retcode;
return 0;
-@@ -716,18 +758,34 @@ kstart_conn(uint64_t transport_handle, u
+@@ -716,18 +772,34 @@ kstart_conn(uint64_t transport_handle, u
static int
krecv_pdu_begin(struct iscsi_conn *conn)
{
@@ -14746,7 +15053,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return 0;
}
-@@ -744,7 +802,7 @@ krecv_pdu_end(struct iscsi_conn *conn)
+@@ -744,7 +816,7 @@ krecv_pdu_end(struct iscsi_conn *conn)
log_debug(3, "recv PDU finished for pdu handle 0x%p",
recvbuf);
@@ -14755,7 +15062,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
conn->recv_context = NULL;
recvbuf = NULL;
return 0;
-@@ -756,6 +814,7 @@ ktransport_ep_connect(iscsi_conn_t *conn
+@@ -756,6 +828,7 @@ ktransport_ep_connect(iscsi_conn_t *conn
int rc, addrlen;
struct iscsi_uevent *ev;
struct sockaddr *dst_addr = (struct sockaddr *)&conn->saddr;
@@ -14763,7 +15070,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -783,7 +842,10 @@ ktransport_ep_connect(iscsi_conn_t *conn
+@@ -783,7 +856,10 @@ ktransport_ep_connect(iscsi_conn_t *conn
}
memcpy(setparam_buf + sizeof(*ev), dst_addr, addrlen);
@@ -14775,7 +15082,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return rc;
if (!ev->r.ep_connect_ret.handle)
-@@ -801,6 +863,7 @@ ktransport_ep_poll(iscsi_conn_t *conn, i
+@@ -801,6 +877,7 @@ ktransport_ep_poll(iscsi_conn_t *conn, i
{
int rc;
struct iscsi_uevent ev;
@@ -14783,7 +15090,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -811,7 +874,10 @@ ktransport_ep_poll(iscsi_conn_t *conn, i
+@@ -811,7 +888,10 @@ ktransport_ep_poll(iscsi_conn_t *conn, i
ev.u.ep_poll.ep_handle = conn->transport_ep_handle;
ev.u.ep_poll.timeout_ms = timeout_ms;
@@ -14795,7 +15102,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return rc;
return ev.r.retcode;
-@@ -822,6 +888,7 @@ ktransport_ep_disconnect(iscsi_conn_t *c
+@@ -822,6 +902,7 @@ ktransport_ep_disconnect(iscsi_conn_t *c
{
int rc;
struct iscsi_uevent ev;
@@ -14803,7 +15110,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -834,7 +901,10 @@ ktransport_ep_disconnect(iscsi_conn_t *c
+@@ -834,7 +915,10 @@ ktransport_ep_disconnect(iscsi_conn_t *c
ev.transport_handle = conn->session->t->handle;
ev.u.ep_disconnect.ep_handle = conn->transport_ep_handle;
@@ -14815,7 +15122,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_error("connnection %d:%d transport disconnect failed for "
"ep %" PRIu64 " with error %d.", conn->session->id,
conn->id, conn->transport_ep_handle, rc);
-@@ -851,6 +921,7 @@ kget_stats(uint64_t transport_handle, ui
+@@ -851,6 +935,7 @@ kget_stats(uint64_t transport_handle, ui
struct iscsi_uevent ev;
char nlm_ev[NLMSG_SPACE(sizeof(struct iscsi_uevent))];
struct nlmsghdr *nlh;
@@ -14823,7 +15130,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -861,9 +932,11 @@ kget_stats(uint64_t transport_handle, ui
+@@ -861,9 +946,11 @@ kget_stats(uint64_t transport_handle, ui
ev.u.get_stats.sid = sid;
ev.u.get_stats.cid = cid;
@@ -14837,7 +15144,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
if ((rc = nl_read(ctrl_fd, nlm_ev,
NLMSG_SPACE(sizeof(struct iscsi_uevent)), MSG_PEEK)) < 0) {
-@@ -889,12 +962,60 @@ kget_stats(uint64_t transport_handle, ui
+@@ -889,12 +976,60 @@ kget_stats(uint64_t transport_handle, ui
return 0;
}
@@ -14899,7 +15206,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
}
static int ctldev_handle(void)
-@@ -905,8 +1026,8 @@ static int ctldev_handle(void)
+@@ -905,8 +1040,8 @@ static int ctldev_handle(void)
iscsi_conn_t *conn = NULL;
char nlm_ev[NLMSG_SPACE(sizeof(struct iscsi_uevent))];
struct nlmsghdr *nlh;
@@ -14910,7 +15217,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_debug(7, "in %s", __FUNCTION__);
-@@ -925,13 +1046,15 @@ static int ctldev_handle(void)
+@@ -925,13 +1060,15 @@ static int ctldev_handle(void)
/* old kernels sent ISCSI_UEVENT_CREATE_SESSION on creation */
case ISCSI_UEVENT_CREATE_SESSION:
drop_data(nlh);
@@ -14930,7 +15237,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
return 0;
case ISCSI_KEVENT_RECV_PDU:
sid = ev->r.recv_req.sid;
-@@ -941,22 +1064,41 @@ static int ctldev_handle(void)
+@@ -941,22 +1078,59 @@ static int ctldev_handle(void)
sid = ev->r.connerror.sid;
cid = ev->r.connerror.cid;
break;
@@ -14944,6 +15251,24 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
/* session wide event so cid is 0 */
cid = 0;
break;
++ case ISCSI_KEVENT_HOST_EVENT:
++ switch (ev->r.host_event.code) {
++ case ISCSI_EVENT_LINKUP:
++ log_warning("Host%u: Link Up.\n",
++ ev->r.host_event.host_no);
++ break;
++ case ISCSI_EVENT_LINKDOWN:
++ log_warning("Host%u: Link Down.\n",
++ ev->r.host_event.host_no);
++ break;
++ default:
++ log_debug(7, "Host%u: Unknwon host event: %u.\n",
++ ev->r.host_event.host_no,
++ ev->r.host_event.code);
++ }
++
++ drop_data(nlh);
++ return 0;
default:
- log_error("Unknown kernel event %d. You may want to upgrade "
- "your iscsi tools.", ev->type);
@@ -14976,7 +15301,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
"event.\n", sid, cid);
drop_data(nlh);
return -ENXIO;
-@@ -964,19 +1106,20 @@ static int ctldev_handle(void)
+@@ -964,19 +1138,20 @@ static int ctldev_handle(void)
conn = &session->conn[0];
ev_size = nlh->nlmsg_len - NLMSG_ALIGN(sizeof(struct nlmsghdr));
@@ -15002,7 +15327,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
log_error("can not read from NL socket, error %d", rc);
/* retry later */
return rc;
-@@ -988,26 +1131,34 @@ static int ctldev_handle(void)
+@@ -988,26 +1163,34 @@ static int ctldev_handle(void)
*/
switch (ev->type) {
case ISCSI_KEVENT_RECV_PDU:
@@ -15046,7 +15371,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
}
static int
-@@ -1114,5 +1265,12 @@ struct iscsi_ipc nl_ipc = {
+@@ -1114,5 +1297,12 @@ struct iscsi_ipc nl_ipc = {
.read = kread,
.recv_pdu_begin = krecv_pdu_begin,
.recv_pdu_end = krecv_pdu_end,
@@ -15059,9 +15384,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/netlink.c open-iscsi-2.0-872-rc4-bn
+{
+ ipc_ev_clbk = ev_clbk;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_info.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/session_info.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_info.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/session_info.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/session_info.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/session_info.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/session_info.c 2012-03-05 23:02:46.000000000 -0600
@@ -13,6 +13,7 @@
#include "initiator.h"
#include "iface.h"
@@ -15223,9 +15548,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_info.c open-iscsi-2.0-872-r
+ }
return 0;
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_info.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/session_info.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_info.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/session_info.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/session_info.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/session_info.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/session_info.h 2012-03-05 23:02:46.000000000 -0600
@@ -9,12 +9,29 @@
struct list;
@@ -15273,9 +15598,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_info.h open-iscsi-2.0-872-r
+ unsigned int flags, int do_show);
#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/session_mgmt.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/session_mgmt.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/session_mgmt.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/session_mgmt.c 2012-03-05 23:02:46.000000000 -0600
@@ -3,7 +3,7 @@
*
* Copyright (C) 2010 Mike Christie
@@ -15456,7 +15781,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.c open-iscsi-2.0-872-r
struct node_rec *))
{
struct node_rec *curr_rec, *tmp;
-@@ -191,7 +256,6 @@ int iscsi_login_portals(void *data, int
+@@ -191,7 +256,6 @@ int iscsi_login_portals(void *data, int
if (!err)
(*nr_found)++;
}
@@ -15464,7 +15789,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.c open-iscsi-2.0-872-r
if (wait) {
err = iscsid_login_reqs_wait(&login_list);
if (err && !ret)
-@@ -199,13 +263,50 @@ int iscsi_login_portals(void *data, int
+@@ -199,13 +263,50 @@ int iscsi_login_portals(void *data, int
} else
iscsid_reqs_close(&login_list);
@@ -15584,9 +15909,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.c open-iscsi-2.0-872-r
session_info_free_list(&session_list);
return ret;
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/session_mgmt.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/session_mgmt.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/session_mgmt.h 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/session_mgmt.h 2012-03-05 23:02:46.000000000 -0600
@@ -10,7 +10,11 @@ extern int iscsi_login_portal(void *data
extern int iscsi_login_portal_nowait(struct node_rec *rec);
extern int iscsi_login_portals(void *data, int *nr_found, int wait,
@@ -15600,9 +15925,33 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/session_mgmt.h open-iscsi-2.0-872-r
struct node_rec *));
extern int iscsi_logout_portal(struct session_info *info,
struct list_head *list);
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/sysfs.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/sysfs.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/strings.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/strings.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/strings.c 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/strings.c 2012-03-05 23:03:42.000000000 -0600
+@@ -97,11 +97,17 @@ int str_enlarge_data(struct str_buffer *
+
+ void str_remove_initial(struct str_buffer *s, int length)
+ {
+- char *remaining = s->buffer + length;
+- int amount = s->data_length - length;
++ char *remaining;
++ int amount;
+
+ if (s && length) {
+- memmove(s->buffer, remaining, amount);
++ remaining = s->buffer + length;
++ amount = s->data_length - length;
++
++ if (amount < 0)
++ amount = 0;
++ if (amount)
++ memmove(s->buffer, remaining, amount);
+ s->data_length = amount;
+ s->buffer[amount] = '\0';
+ }
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/sysfs.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/sysfs.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/sysfs.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/sysfs.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/sysfs.c 2012-03-05 23:02:46.000000000 -0600
@@ -547,7 +547,7 @@ found:
}
@@ -15656,10 +16005,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/sysfs.c open-iscsi-2.0-872-rc4-bnx2
int sysfs_set_param(char *id, char *subsys, char *attr_name,
char *write_buf, ssize_t buf_size)
{
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/sysfs.h open-iscsi-2.0-872-rc4-bnx2i.sync/usr/sysfs.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/sysfs.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/sysfs.h
--- open-iscsi-2.0-872-rc4-bnx2i/usr/sysfs.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/sysfs.h 2011-08-14 16:48:25.000000000 -0500
-@@ -51,14 +51,18 @@ extern char *sysfs_attr_get_value(const
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/sysfs.h 2012-03-05 23:02:46.000000000 -0600
+@@ -51,14 +51,18 @@ extern char *sysfs_attr_get_value(const
extern int sysfs_resolve_link(char *path, size_t size);
extern int sysfs_lookup_devpath_by_subsys_id(char *devpath, size_t len, const char *subsystem, const char *id);
@@ -15680,19 +16029,29 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/sysfs.h open-iscsi-2.0-872-rc4-bnx2
extern int sysfs_set_param(char *id, char *subsys, char *attr_name,
char *write_buf, ssize_t buf_size);
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/transport.c open-iscsi-2.0-872-rc4-bnx2i.sync/usr/transport.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/transport.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/transport.c
--- open-iscsi-2.0-872-rc4-bnx2i/usr/transport.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/usr/transport.c 2011-08-14 16:48:25.000000000 -0500
-@@ -25,7 +25,7 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/transport.c 2012-03-05 23:06:13.000000000 -0600
+@@ -25,8 +25,9 @@
#include "log.h"
#include "iscsi_util.h"
#include "iscsi_sysfs.h"
-#include "cxgb3i.h"
+#include "cxgbi.h"
#include "be2iscsi.h"
++#include "iser.h"
struct iscsi_transport_template iscsi_tcp = {
-@@ -49,7 +49,16 @@ struct iscsi_transport_template cxgb3i =
+ .name = "tcp",
+@@ -41,6 +42,7 @@ struct iscsi_transport_template iscsi_is
+ .ep_connect = ktransport_ep_connect,
+ .ep_poll = ktransport_ep_poll,
+ .ep_disconnect = ktransport_ep_disconnect,
++ .create_conn = iser_create_conn,
+ };
+
+ struct iscsi_transport_template cxgb3i = {
+@@ -49,7 +51,16 @@ struct iscsi_transport_template cxgb3i =
.ep_connect = ktransport_ep_connect,
.ep_poll = ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
@@ -15710,7 +16069,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/transport.c open-iscsi-2.0-872-rc4-
};
struct iscsi_transport_template bnx2i = {
-@@ -70,12 +79,17 @@ struct iscsi_transport_template be2iscsi
+@@ -70,12 +81,17 @@ struct iscsi_transport_template be2iscsi
struct iscsi_transport_template qla4xxx = {
.name = "qla4xxx",
@@ -15728,7 +16087,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/transport.c open-iscsi-2.0-872-rc4-
&bnx2i,
&qla4xxx,
&be2iscsi,
-@@ -97,6 +111,7 @@ int set_transport_template(struct iscsi_
+@@ -97,6 +113,7 @@ int set_transport_template(struct iscsi_
}
}
@@ -15737,9 +16096,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/transport.c open-iscsi-2.0-872-rc4-
+ "is probably needed.\n", t->name);
return ENOSYS;
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fw_entry.c open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/fw_entry.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fw_entry.c open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/fw_entry.c
--- open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fw_entry.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/fw_entry.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/fw_entry.c 2012-03-05 23:02:46.000000000 -0600
@@ -34,6 +34,7 @@
#include "fwparam.h"
#include "idbm_fields.h"
@@ -15778,9 +16137,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fw_entry.c open-iscs
if (strlen(context->iface))
printf("%s = %s\n", IFACE_NETNAME, context->iface);
}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_ppc.c open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/fwparam_ppc.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_ppc.c open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/fwparam_ppc.c
--- open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_ppc.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/fwparam_ppc.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/fwparam_ppc.c 2012-03-05 23:02:46.000000000 -0600
@@ -30,6 +30,7 @@
#include "iscsi_obp.h"
#include "prom_parse.h"
@@ -15882,9 +16241,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_ppc.c open-i
else {
fill_context(context, ofwdevs[0]);
list_add_tail(&context->list, list);
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_sysfs.c open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/fwparam_sysfs.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_sysfs.c open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/fwparam_sysfs.c
--- open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_sysfs.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/fwparam_sysfs.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/fwparam_sysfs.c 2012-03-05 23:02:46.000000000 -0600
@@ -36,6 +36,7 @@
#include "fwparam.h"
#include "sysdeps.h"
@@ -15917,7 +16276,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_sysfs.c open
done:
closedir(dirfd);
return rc;
-@@ -401,12 +402,12 @@ static int get_targets(struct list_head
+@@ -401,12 +402,12 @@ static int get_targets(struct list_head
rc = fill_tgt_context(subsys, target_list[i], context);
if (rc)
@@ -15932,7 +16291,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_sysfs.c open
for (nic = 0; nic < nic_cnt; nic++) {
int id;
-@@ -420,21 +421,31 @@ static int get_targets(struct list_head
+@@ -420,21 +421,31 @@ static int get_targets(struct list_head
if (nic == nic_cnt) {
printf("Invalid nic-assoc of %d. Max id %d.\n",
nic_idx, nic_cnt);
@@ -16000,9 +16359,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/fwparam_sysfs.c open
if (rc)
fw_free_targets(list);
return rc;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.c open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/prom_lex.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.c open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/prom_lex.c
--- open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/prom_lex.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/prom_lex.c 2012-03-05 23:02:46.000000000 -0600
@@ -8,7 +8,7 @@
#define FLEX_SCANNER
#define YY_FLEX_MAJOR_VERSION 2
@@ -16395,7 +16754,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.c open-iscs
/* zero only the new slots.*/
memset((yy_buffer_stack) + (yy_buffer_stack_max), 0, grow_size * sizeof(struct yy_buffer_state*));
-@@ -2025,7 +2038,7 @@ YY_BUFFER_STATE yy_scan_buffer (char *
+@@ -2025,7 +2038,7 @@ YY_BUFFER_STATE yy_scan_buffer (char *
/** Setup the input buffer state to scan a string. The next call to yylex() will
* scan from a @e copy of @a str.
@@ -16404,7 +16763,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.c open-iscs
*
* @return the newly allocated buffer state object.
* @note If you want to scan bytes that may contain NUL values, then use
-@@ -2039,8 +2052,8 @@ YY_BUFFER_STATE yy_scan_string (yyconst
+@@ -2039,8 +2052,8 @@ YY_BUFFER_STATE yy_scan_string (yyconst
/** Setup the input buffer state to scan the given bytes. The next call to yylex() will
* scan from a @e copy of @a bytes.
@@ -16424,9 +16783,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.c open-iscs
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.l open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/prom_lex.l
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.l open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/prom_lex.l
--- open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.l 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/fwparam_ibft/prom_lex.l 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/fwparam_ibft/prom_lex.l 2012-03-05 23:02:46.000000000 -0600
@@ -43,6 +43,8 @@ void dbgprint(const char *item) { fprint
%option noyywrap
@@ -16436,9 +16795,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/fwparam_ibft/prom_lex.l open-iscs
VDEVICE vdevice
VDEVINST gscsi
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/client.c open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/client.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/client.c open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/client.c
--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/client.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/client.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/client.c 2012-03-05 23:02:46.000000000 -0600
@@ -123,8 +123,10 @@ static isns_security_t *
__create_security_context(const char *name, const char *auth_key,
const char *server_key)
@@ -16450,9 +16809,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/client.c open-iscsi-2.0
if (!isns_config.ic_security)
return NULL;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/db-file.c open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/db-file.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/db-file.c open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/db-file.c
--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/db-file.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/db-file.c 2011-08-14 16:48:25.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/db-file.c 2012-03-05 23:02:46.000000000 -0600
@@ -310,7 +310,7 @@ __dbe_file_load_object(const char *filen
/* Stash away the parent's index; we resolve them later on
@@ -16471,46 +16830,27687 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/db-file.c open-iscsi-2.
isns_object_t *parent;
if (index == 0)
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/Makefile.in
---- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/Makefile.in 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/Makefile.in 2011-08-14 16:48:25.000000000 -0500
-@@ -32,7 +32,6 @@ LIBOBJS = server.o \
- security.o \
- authblock.o \
- policy.o \
-- pki.o \
- register.o \
- query.o \
- getnext.o \
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/objects.h open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/objects.h
---- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/objects.h 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/objects.h 2011-08-14 16:48:25.000000000 -0500
-@@ -83,6 +83,7 @@ struct isns_object {
-
- isns_attr_list_t ie_attrs;
- isns_object_t * ie_container;
-+ uint32_t ie_container_idx;
- isns_object_template_t *ie_template;
-
- isns_relation_t * ie_relation;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/socket.c open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/socket.c
---- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/socket.c 2010-07-11 04:05:58.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.sync/utils/open-isns/socket.c 2011-08-14 16:48:25.000000000 -0500
-@@ -562,7 +562,7 @@ void
- isns_net_stream_accept(isns_socket_t *sock)
- {
- isns_socket_t *child;
-- size_t optlen;
-+ socklen_t optlen;
- int fd, passcred = 0;
-
- fd = accept(sock->is_desc, NULL, NULL);
-@@ -805,7 +805,7 @@ isns_net_stream_xmit(isns_socket_t *sock
- void
- isns_net_stream_hup(isns_socket_t *sock)
- {
-- sock->is_poll_mask &= ~POLLIN;
-+ sock->is_poll_mask &= ~(POLLIN|POLLOUT);
- /* POLLHUP while connecting means we failed */
- if (sock->is_state == ISNS_SOCK_CONNECTING)
- isns_net_stream_error(sock, ECONNREFUSED);
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/db-policy.c open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/db-policy.c
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/db-policy.c 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/db-policy.c 2012-03-05 23:03:38.000000000 -0600
+@@ -7,8 +7,10 @@
+ #include <sys/stat.h>
+ #include <string.h>
+ #include <unistd.h>
++#ifdef WITH_SECURITY
+ #include <openssl/pem.h>
+ #include <openssl/err.h>
++#endif
+ #include "isns.h"
+ #include "security.h"
+ #include "objects.h"
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc2608.txt open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc2608.txt
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc2608.txt 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc2608.txt 1969-12-31 18:00:00.000000000 -0600
+@@ -1,3027 +0,0 @@
+-
+-
+-
+-
+-
+-
+-Network Working Group E. Guttman
+-Request for Comments: 2608 C. Perkins
+-Updates: 2165 Sun Microsystems
+-Category: Standards Track J. Veizades
+- @Home Network
+- M. Day
+- Vinca Corporation
+- June 1999
+-
+-
+- Service Location Protocol, Version 2
+-
+-Status of This Memo
+-
+- This document specifies an Internet standards track protocol for the
+- Internet community, and requests discussion and suggestions for
+- improvements. Please refer to the current edition of the "Internet
+- Official Protocol Standards" (STD 1) for the standardization state
+- and status of this protocol. Distribution of this memo is unlimited.
+-
+-Copyright Notice
+-
+- Copyright (C) The Internet Society (1999). All Rights Reserved.
+-
+-Abstract
+-
+- The Service Location Protocol provides a scalable framework for the
+- discovery and selection of network services. Using this protocol,
+- computers using the Internet need little or no static configuration
+- of network services for network based applications. This is
+- especially important as computers become more portable, and users
+- less tolerant or able to fulfill the demands of network system
+- administration.
+-
+-Table of Contents
+-
+- 1. Introduction 3
+- 1.1. Applicability Statement . . . . . . . . . . . . . . . 3
+- 2. Terminology 4
+- 2.1. Notation Conventions . . . . . . . . . . . . . . . . . 4
+- 3. Protocol Overview 5
+- 4. URLs used with Service Location 8
+- 4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . 9
+- 4.2. Naming Authorities . . . . . . . . . . . . . . . . . 10
+- 4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . 10
+- 5. Service Attributes 10
+- 6. Required Features 12
+- 6.1. Use of Ports, UDP, and Multicast . . . . . . . . . . 13
+-
+-
+-
+-Guttman, et al. Standards Track [Page 1]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- 6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . 14
+- 6.3. Retransmission of SLP messages . . . . . . . . . . . 15
+- 6.4. Strings in SLP messages . . . . . . . . . . . . . . . 16
+- 6.4.1. Scope Lists in SLP . . . . . . . . . . . . . . 16
+- 7. Errors 17
+- 8. Required SLP Messages 17
+- 8.1. Service Request . . . . . . . . . . . . . . . . . . . 19
+- 8.2. Service Reply . . . . . . . . . . . . . . . . . . . . 21
+- 8.3. Service Registration . . . . . . . . . . . . . . . . . 22
+- 8.4. Service Acknowledgment . . . . . . . . . . . . . . . . 23
+- 8.5. Directory Agent Advertisement. . . . . . . . . . . . . 24
+- 8.6. Service Agent Advertisement. . . . . . . . . . . . . . 25
+- 9. Optional Features 26
+- 9.1. Service Location Protocol Extensions . . . . . . . . . 27
+- 9.2. Authentication Blocks . . . . . . . . . . . . . . . . 28
+- 9.2.1. SLP Message Authentication Rules . . . . . . . 29
+- 9.2.2. DSA with SHA-1 in Authentication Blocks . . . 30
+- 9.3. Incremental Service Registration . . . . . . . . . . 30
+- 9.4. Tag Lists . . . . . . . . . . . . . . . . . . . . . . 31
+- 10. Optional SLP Messages 32
+- 10.1. Service Type Request . . . . . . . . . . . . . . . . 32
+- 10.2. Service Type Reply . . . . . . . . . . . . . . . . . 32
+- 10.3. Attribute Request . . . . . . . . . . . . . . . . . . 33
+- 10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . 34
+- 10.5. Attribute Request/Reply Examples . . . . . . . . . . . 34
+- 10.6. Service Deregistration . . . . . . . . . . . . . . . 36
+- 11. Scopes 37
+- 11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . 37
+- 11.2. Administrative and User Selectable Scopes. . . . . . . 38
+- 12. Directory Agents 38
+- 12.1. Directory Agent Rules . . . . . . . . . . . . . . . . 39
+- 12.2. Directory Agent Discovery . . . . . . . . . . . . . . 39
+- 12.2.1. Active DA Discovery . . . . . . . . . . . . . 40
+- 12.2.2. Passive DA Advertising . . . . . . . . . . . . 40
+- 12.3. Reliable Unicast to DAs and SAs. . . . . . . . . . . . 41
+- 12.4. DA Scope Configuration . . . . . . . . . . . . . . . 41
+- 12.5. DAs and Authentication Blocks. . . . . . . . . . . . . 41
+- 13. Protocol Timing Defaults 42
+- 14. Optional Configuration 43
+- 15. IANA Considerations 44
+- 16. Internationalization Considerations 45
+- 17. Security Considerations 46
+- A. Appendix: Changes to the Service Location Protocol from
+- v1 to v2 48
+- B. Appendix: Service Discovery by Type: Minimal SLPv2 Features 48
+- C. Appendix: DAAdverts with arbitrary URLs 49
+- D. Appendix: SLP Protocol Extensions 50
+- D.1. Required Attribute Missing Option . . . . . . . . . . 50
+-
+-
+-
+-Guttman, et al. Standards Track [Page 2]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- E. Acknowledgments 50
+- F. References 51
+- G. Authors' Addresses 53
+- H. Full Copyright Statement 54
+-
+-1. Introduction
+-
+- The Service Location Protocol (SLP) provides a flexible and scalable
+- framework for providing hosts with access to information about the
+- existence, location, and configuration of networked services.
+- Traditionally, users have had to find services by knowing the name of
+- a network host (a human readable text string) which is an alias for a
+- network address. SLP eliminates the need for a user to know the name
+- of a network host supporting a service. Rather, the user supplies
+- the desired type of service and a set of attributes which describe
+- the service. Based on that description, the Service Location
+- Protocol resolves the network address of the service for the user.
+-
+- SLP provides a dynamic configuration mechanism for applications in
+- local area networks. Applications are modeled as clients that need
+- to find servers attached to any of the available networks within an
+- enterprise. For cases where there are many different clients and/or
+- services available, the protocol is adapted to make use of nearby
+- Directory Agents that offer a centralized repository for advertised
+- services.
+-
+- This document updates SLPv1 [RFC 2165], correcting protocol errors,
+- adding some enhancements and removing some requirements. This
+- specification has two parts. The first describes the required
+- features of the protocol. The second describes the extended features
+- of the protocol which are optional, and allow greater scalability.
+-
+-1.1. Applicability Statement
+-
+- SLP is intended to function within networks under cooperative
+- administrative control. Such networks permit a policy to be
+- implemented regarding security, multicast routing and organization of
+- services and clients into groups which are not be feasible on the
+- scale of the Internet as a whole.
+-
+- SLP has been designed to serve enterprise networks with shared
+- services, and it may not necessarily scale for wide-area service
+- discovery throughout the global Internet, or in networks where there
+- are hundreds of thousands of clients or tens of thousands of
+- services.
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 3]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-2. Terminology
+-
+- User Agent (UA)
+- A process working on the user's behalf to establish
+- contact with some service. The UA retrieves service
+- information from the Service Agents or Directory Agents.
+-
+- Service Agent (SA) A process working on the behalf of one or more
+- services to advertise the services.
+-
+- Directory Agent (DA) A process which collects service
+- advertisements. There can only be one DA present per
+- given host.
+-
+- Service Type Each type of service has a unique Service Type
+- string.
+-
+- Naming Authority The agency or group which catalogues given
+- Service Types and Attributes. The default Naming
+- Authority is IANA.
+-
+- Scope A set of services, typically making up a logical
+- administrative group.
+-
+- URL A Universal Resource Locator [8].
+-
+-2.1. Notation Conventions
+-
+- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+- document are to be interpreted as described in RFC 2119 [9].
+-
+- Syntax Syntax for string based protocols follow the
+- conventions defined for ABNF [11].
+-
+- Strings All strings are encoded using the UTF-8 [23]
+- transformation of the Unicode [6] character set and
+- are NOT null terminated when transmitted. Strings
+- are preceded by a two byte length field.
+-
+- <string-list> A comma delimited list of strings with the
+- following syntax:
+-
+- string-list = string / string `,' string-list
+-
+- In format diagrams, any field ending with a \ indicates a variable
+- length field, given by a prior length field in the protocol.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 4]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-3. Protocol Overview
+-
+- The Service Location Protocol supports a framework by which client
+- applications are modeled as 'User Agents' and services are advertised
+- by 'Service Agents.' A third entity, called a 'Directory Agent'
+- provides scalability to the protocol.
+-
+- The User Agent issues a 'Service Request' (SrvRqst) on behalf of the
+- client application, specifying the characteristics of the service
+- which the client requires. The User Agent will receive a Service
+- Reply (SrvRply) specifying the location of all services in the
+- network which satisfy the request.
+-
+- The Service Location Protocol framework allows the User Agent to
+- directly issue requests to Service Agents. In this case the request
+- is multicast. Service Agents receiving a request for a service which
+- they advertise unicast a reply containing the service's location.
+-
+- +------------+ ----Multicast SrvRqst----> +---------------+
+- | User Agent | | Service Agent |
+- +------------+ <----Unicast SrvRply------ +---------------+
+-
+- In larger networks, one or more Directory Agents are used. The
+- Directory Agent functions as a cache. Service Agents send register
+- messages (SrvReg) containing all the services they advertise to
+- Directory Agents and receive acknowledgements in reply (SrvAck).
+- These advertisements must be refreshed with the Directory Agent or
+- they expire. User Agents unicast requests to Directory Agents
+- instead of Service Agents if any Directory Agents are known.
+-
+- +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
+- | User | | Directory | |Service |
+- | Agent | | Agent | | Agent |
+- +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+
+-
+- User and Service Agents discover Directory Agents two ways. First,
+- they issue a multicast Service Request for the 'Directory Agent'
+- service when they start up. Second, the Directory Agent sends an
+- unsolicited advertisement infrequently, which the User and Service
+- Agents listen for. In either case the Agents receive a DA
+- Advertisement (DAAdvert).
+-
+- +---------------+ --Multicast SrvRqst-> +-----------+
+- | User or | <--Unicast DAAdvert-- | Directory |
+- | Service Agent | | Agent |
+- +---------------+ <-Multicast DAAdvert- +-----------+
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 5]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- Services are grouped together using 'scopes'. These are strings
+- which identify services which are administratively identified. A
+- scope could indicate a location, administrative grouping, proximity
+- in a network topology or some other category. Service Agents and
+- Directory Agents are always assigned a scope string.
+-
+- A User Agent is normally assigned a scope string (in which case the
+- User Agent will only be able to discover that particular grouping of
+- services). This allows a network administrator to 'provision'
+- services to users. Alternatively, the User Agent may be configured
+- with no scope at all. In that case, it will discover all available
+- scopes and allow the client application to issue requests for any
+- service available on the network.
+-
+- +---------+ Multicast +-----------+ Unicast +-----------+
+- | Service | <--SrvRqst-- | User | --SrvRqst-> | Directory |
+- | Agent | | Agent | | Agent |
+- | Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y |
+- +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+
+-
+- In the above illustration, the User Agent is configured with scopes X
+- and Y. If a service is sought in scope X, the request is multicast.
+- If it is sought in scope Y, the request is unicast to the DA.
+- Finally, if the request is to be made in both scopes, the request
+- must be both unicast and multicast.
+-
+- Service Agents and User Agents may verify digital signatures provided
+- with DAAdverts. User Agents and Directory Agents may verify service
+- information registered by Service Agents. The keying material to use
+- to verify digital signatures is identified using a SLP Security
+- Parameter Index, or SLP SPI.
+-
+- Every host configured to generate a digital signature includes the
+- SLP SPI used to verify it in the Authentication Block it transmits.
+- Every host which can verify a digital signature must be configured
+- with keying material and other parameters corresponding with the SLP
+- SPI such that it can perform verifying calculations.
+-
+- SAs MUST accept multicast service requests and unicast service
+- requests. SAs MAY accept other requests (Attribute and Service Type
+- Requests). SAs MUST listen for multicast DA Advertisements.
+-
+- The features described up to this point are required to implement. A
+- minimum implementation consists of a User Agent, Service Agent or
+- both.
+-
+- There are several optional features in the protocol. Note that DAs
+- MUST support all these message types, but DA support is itself
+-
+-
+-
+-Guttman, et al. Standards Track [Page 6]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- optional to deploy on networks using SLP. UAs and SAs MAY support
+- these message types. These operations are primarily for interactive
+- use (browsing or selectively updating service registrations.) UAs
+- and SAs either support them or not depending on the requirements and
+- constraints of the environment where they will be used.
+-
+- Service Type Request A request for all types of service on the
+- network. This allows generic service browsers
+- to be built.
+-
+- Service Type Reply A reply to a Service Type Request.
+-
+- Attribute Request A request for attributes of a given type of
+- service or attributes of a given service.
+-
+- Attribute Reply A reply to an Attribute Request.
+-
+- Service Deregister A request to deregister a service or some
+- attributes of a service.
+-
+- Service Update A subsequent SrvRqst to an advertisement.
+- This allows individual dynamic attributes to
+- be updated.
+-
+- SA Advertisement In the absence of Directory Agents, a User
+- agent may request Service Agents in order
+- to discover their scope configuration. The
+- User Agent may use these scopes in requests.
+-
+- In the absence of Multicast support, Broadcast MAY be used. The
+- location of DAs may be staticly configured, discovered using SLP as
+- described above, or configured using DHCP. If a message is too large,
+- it may be unicast using TCP.
+-
+- A SLPv2 implementation SHOULD support SLPv1 [22]. This support
+- includes:
+-
+- 1. SLPv2 DAs are deployed, phasing out SLPv1 DAs.
+-
+- 2. Unscoped SLPv1 requests are considered to be of DEFAULT scope.
+- SLPv1 UAs MUST be reconfigured to have a scope if possible.
+-
+- 3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1
+- DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.
+-
+- 4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2
+- requests with SLPv2 replies.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 7]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- 5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same
+- way. That is, incoming requests from agents using either version
+- of the protocol will be matched against this common set of
+- registered services.
+-
+- 6. SLPv2 registrations which use Language Tags which are greater
+- than 2 characters long will be inaccessible to SLPv1 UAs.
+-
+- 7. SLPv2 DAs MUST return only service type strings in SrvTypeRply
+- messages which conform to SLPv1 service type string syntax, ie.
+- they MUST NOT return Service Type strings for abstract service
+- types.
+-
+- 8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service
+- URLs with abstract service types. They only match Service URLs
+- with concrete service types.
+-
+- SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will
+- not receive replies from SLPv1 SAs. In order to interoperate UAs and
+- SAs of different versions require a SLPv2 DA to be present on the
+- network which supports both protocols.
+-
+- The use of abstract service types in SLPv2 presents a backward
+- compatibility issue for SLPv1. It is possible that a SLPv1 UA will
+- request a service type which is actually an abstract service type.
+- Based on the rules above, the SLPv1 UA will never receive an abstract
+- Service URL reply. For example, the service type 'service:x' in a
+- SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'.
+- If the request was made with SLPv2, it would return the attributes of
+- this service.
+-
+-4. URLs used with Service Location
+-
+- A Service URL indicates the location of a service. This URL may be
+- of the service: scheme [13] (reviewed in section 4.1), or any other
+- URL scheme conforming to the URI standard [8], except that URLs
+- without address specifications SHOULD NOT be advertised by SLP. The
+- service type for an 'generic' URL is its scheme name. For example,
+- the service type string for "http://www.srvloc.org" would be "http".
+-
+- Reserved characters in URLs follow the rules in RFC 2396 [8].
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 8]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-4.1. Service: URLs
+-
+- Service URL syntax and semantics are defined in [13]. Any network
+- service may be encoded in a Service URL.
+-
+- This section provides an introduction to Service URLs and an example
+- showing a simple application of them, representing standard network
+- services.
+-
+- A Service URL may be of the form:
+-
+- "service:"<srvtype>"://"<addrspec>
+-
+- The Service Type of this service: URL is defined to be the string up
+- to (but not including) the final `:' before <addrspec>, the address
+- specification.
+-
+- <addrspec> is a hostname (which should be used if possible) or dotted
+- decimal notation for a hostname, followed by an optional `:' and
+- port number.
+-
+- A service: scheme URL may be formed with any standard protocol name
+- by concatenating "service:" and the reserved port [1] name. For
+- example, "service:tftp://myhost" would indicate a tftp service. A
+- tftp service on a nonstandard port could be
+- "service:tftp://bad.glad.org:8080".
+-
+- Service Types SHOULD be defined by a "Service Template" [13], which
+- provides expected attributes, values and protocol behavior. An
+- abstract service type (also described in [13]) has the form
+-
+- "service:<abstract-type>:<concrete-type>".
+-
+- The service type string "service:<abstract-type>" matches all
+- services of that abstract type. If the concrete type is included
+- also, only these services match the request. For example: a SrvRqst
+- or AttrRqst which specifies "service:printer" as the Service Type
+- will match the URL service:printer:lpr://hostname and
+- service:printer:http://hostname. If the requests specified
+- "service:printer:http" they would match only the latter URL.
+-
+- An optional substring MAY follow the last `.' character in the
+- <srvtype> (or <abstract-type> in the case of an abstract service type
+- URL). This substring is the Naming Authority, as described in Section
+- 9.6. Service types with different Naming Authorities are quite
+- distinct. In other words, service:x.one and service:x.two are
+- different service types, as are service:abstract.one:y and
+- service:abstract.two:y.
+-
+-
+-
+-Guttman, et al. Standards Track [Page 9]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-4.2. Naming Authorities
+-
+- A Naming Authority MAY optionally be included as part of the Service
+- Type string. The Naming Authority of a service defines the meaning
+- of the Service Types and attributes registered with and provided by
+- Service Location. The Naming Authority itself is typically a string
+- which uniquely identifies an organization. IANA is the implied
+- Naming Authority when no string is appended. "IANA" itself MUST NOT
+- be included explicitly.
+-
+- Naming Authorities may define Service Types which are experimental,
+- proprietary or for private use. Using a Naming Authority, one may
+- either simply ignore attributes upon registration or create a local-
+- use only set of attributes for one's site. The procedure to use is
+- to create a 'unique' Naming Authority string and then specify the
+- Standard Attribute Definitions as described above. This Naming
+- Authority will accompany registration and queries, as described in
+- Sections 8.1 and 8.3. Service Types SHOULD be registered with IANA
+- to allow for Internet-wide interoperability.
+-
+-4.3. URL Entries
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Reserved | Lifetime | URL Length |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- |URL len, contd.| URL (variable length) \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- |# of URL auths | Auth. blocks (if any) \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- SLP stores URLs in protocol elements called URL Entries, which
+- associate a length, a lifetime, and possibly authentication
+- information along with the URL. URL Entries, defined as shown above,
+- are used in Service Replies and Service Registrations.
+-
+-5. Service Attributes
+-
+- A service advertisement is often accompanied by Service Attributes.
+- These attributes are used by UAs in Service Requests to select
+- appropriate services.
+-
+- The allowable attributes which may be used are typically specified by
+- a Service Template [13] for a particular service type. Services
+- which are advertised according to a standard template MUST register
+- all service attributes which the standard template requires. URLs
+- with schemes other than "service:" MAY be registered with attributes.
+-
+-
+-
+-Guttman, et al. Standards Track [Page 10]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- Non-standard attribute names SHOULD begin with "x-", because no
+- standard attribute name will ever have those initial characters.
+-
+- An attribute list is a string encoding of the attributes of a
+- service. The following ABNF [11] grammar defines attribute lists:
+-
+- attr-list = attribute / attribute `,' attr-list
+- attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
+- attr-val-list = attr-val / attr-val `,' attr-val-list
+- attr-tag = 1*safe-tag
+- attr-val = intval / strval / boolval / opaque
+- intval = [-]1*DIGIT
+- strval = 1*safe-val
+- boolval = "true" / "false"
+- opaque = "\FF" 1*escape-val
+- safe-val = ; Any character except reserved.
+- safe-tag = ; Any character except reserved, star and bad-tag.
+- reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
+- escape-val = `\' HEXDIG HEXDIG
+- bad-tag = CR / LF / HTAB / `_'
+- star = `*'
+-
+- The <attr-list>, if present, MUST be scanned prior to evaluation for
+- all occurrences of the escape character `\'. Reserved characters
+- MUST be escaped (other characters MUST NOT be escaped). All escaped
+- characters must be restored to their value before attempting string
+- matching. For Opaque values, escaped characters are not converted -
+- they are interpreted as bytes.
+-
+- Boolean Strings which have the form "true" or "false" can
+- only take one value and may only be compared with
+- '='. Booleans are case insensitive when compared.
+-
+- Integer Strings which take the form [-] 1*<digit> and fall
+- in the range "-2147483648" to "2147483647" are
+- considered to be Integers. These are compared using
+- integer comparison.
+-
+- String All other Strings are matched using strict lexical
+- ordering (see Section 6.4).
+-
+- Opaque Opaque values are sequences of bytes. These are
+- distinguished from Strings since they begin with
+- the sequence "\FF". This, unescaped, is an illegal
+- UTF-8 encoding, indicating that what follows is a
+- sequence of bytes expressed in escape notation which
+- constitute the binary value. For example, a '0' byte
+- is encoded "\FF\00".
+-
+-
+-
+-Guttman, et al. Standards Track [Page 11]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- A string which contains escaped values other than from the reserved
+- set of characters is illegal. If such a string is included in an
+- <attr-list>, <tag-list> or search filter, the SA or DA which receives
+- it MUST return a PARSE_ERROR to the message.
+-
+- A keyword has only an <attr-tag>, and no values. Attributes can have
+- one or multiple values. All values are expressed as strings.
+-
+- When values have been advertised by a SA or are registered in a DA,
+- they can take on implicit typing rules for matching incoming
+- requests.
+-
+- Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is
+- disallowed. A DA or SA receiving such an <attr-list> MUST return an
+- INVALID_REGISTRATION error.
+-
+-6. Required Features
+-
+- This section defines the minimal implementation requirements for SAs
+- and UAs as well as their interaction with DAs. A DA is not required
+- for SLP to function, but if it is present, the UA and SA MUST
+- interact with it as defined below.
+-
+- A minimal implementation may consist of either a UA or SA or both.
+- The only required features of a UA are that it can issue SrvRqsts
+- according to the rules below and interpret DAAdverts, SAAdverts and
+- SrvRply messages. The UA MUST issue requests to DAs as they are
+- discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or
+- SAAdvert messages. The SA MUST also register with DAs as they are
+- discovered.
+-
+- UAs perform discovery by issuing Service Request messages. SrvRqst
+- messages are issued, using UDP, following these prioritized rules:
+-
+- 1. A UA issues a request to a DA which it has been configured with
+- by DHCP.
+-
+- 2. A UA issues requests to DAs which it has been statically
+- configured with.
+-
+- 3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses
+- that set of DAs. A UA that does not know of any DAs SHOULD retry
+- DA discovery, increasing the waiting interval between subsequent
+- attempts exponentially (doubling the wait interval each time.)
+- The recommended minimum waiting interval is CONFIG_DA_FIND
+- seconds.
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 12]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- 4. A UA with no knowledge of DAs sends requests using multicast
+- convergence to SAs. SAs unicast replies to UAs according to the
+- multicast convergence algorithm.
+-
+- UAs and SAs are configured with a list of scopes to use according to
+- these prioritized rules:
+-
+- 1. With DHCP.
+-
+- 2. With static configuration. The static configuration may be
+- explicitly set to NO SCOPE for UAs, if the User Selectable Scope
+- model is used. See section 11.2.
+-
+- 3. In the absence of configuration, the agent's scope is "DEFAULT".
+-
+- A UA MUST issue requests with one or more of the scopes it has been
+- configured to use.
+-
+- A UA which has been statically configured with NO SCOPE LIST will use
+- DA or SA discovery to determine its scope list dynamically. In this
+- case it uses an empty scope list to discover DAs and possibly SAs.
+- Then it uses the scope list it obtains from DAAdverts and possibly
+- SAAdverts in subsequent requests.
+-
+- The SA MUST register all its services with any DA it discovers, if
+- the DA advertises any of the scopes it has been configured with. A
+- SA obtains information about DAs as a UA does. In addition, the SA
+- MUST listen for multicast unsolicited DAAdverts. The SA registers by
+- sending SrvReg messages to DAs, which reply with SrvReg messages to
+- indicate success. SAs register in ALL the scopes they were
+- configured to use.
+-
+-6.1. Use of Ports, UDP, and Multicast
+-
+- DAs MUST accept unicast requests and multicast directory agent
+- discovery service requests (for the service type "service:directory-
+- agent").
+-
+- SAs MUST accept multicast requests and unicast requests both. The SA
+- can distinguish between them by whether the REQUEST MCAST flag is set
+- in the SLP Message header.
+-
+- The Service Location Protocol uses multicast for discovering DAs and
+- for issuing requests to SAs by default.
+-
+- The reserved listening port for SLP is 427. This is the destination
+- port for all SLP messages. SLP messages MAY be transmitted on an
+- ephemeral port. Replies and acknowledgements are sent to the port
+-
+-
+-
+-Guttman, et al. Standards Track [Page 13]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- from which the request was issued. The default maximum transmission
+- unit for UDP messages is 1400 bytes excluding UDP and other headers.
+-
+- If a SLP message does not fit into a UDP datagram it MUST be
+- truncated to fit, and the OVERFLOW flag is set in the reply message.
+- A UA which receives a truncated message MAY open a TCP connection
+- (see section 6.2) with the DA or SA and retransmit the request, using
+- the same XID. It MAY also attempt to make use of the truncated reply
+- or reformulate a more restrictive request which will result in a
+- smaller reply.
+-
+- SLP Requests messages are multicast to The Administratively Scoped
+- SLP Multicast [17] address, which is 239.255.255.253. The default
+- TTL to use for multicast is 255.
+-
+- In isolated networks, broadcasts will work in place of multicast. To
+- that end, SAs SHOULD and DAs MUST listen for broadcast Service
+- Location messages at port 427. This allows UAs which do not support
+- multicast the use of Service Location on isolated networks.
+-
+- Setting multicast TTL to less than 255 (the default) limits the range
+- of SLP discovery in a network, and localizes service information in
+- the network.
+-
+-6.2. Use of TCP
+-
+- A SrvReg or SrvDeReg may be too large to fit into a datagram. To
+- send such large SLP messages, a TCP (unicast) connection MUST be
+- established.
+-
+- To avoid the need to implement TCP, one MUST insure that:
+-
+- - UAs never issue requests larger than the Path MTU. SAs can omit
+- TCP support only if they never have to receive unicast requests
+- longer than the path MTU.
+-
+- - UAs can accept replies with the 'OVERFLOW' flag set, and make use
+- of the first result included, or reformulate the request.
+-
+- - Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in
+- a single datagram. This means limiting the size of URLs,
+- the number of attributes and the number of authenticators
+- transmitted.
+-
+- DAs MUST be able to respond to UDP and TCP requests, as well as
+- multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP
+- unless the SA will NEVER receive a request or send a reply which will
+- exceed a datagram in size (e.g., some embedded systems).
+-
+-
+-
+-Guttman, et al. Standards Track [Page 14]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- A TCP connection MAY be used for a single SLP transaction, or for
+- multiple transactions. Since there are length fields in the message
+- headers, SLP Agents can send multiple requests along a connection and
+- read the return stream for acknowledgments and replies.
+-
+- The initiating agent SHOULD close the TCP connection. The DA SHOULD
+- wait at least CONFIG_CLOSE_CONN seconds before closing an idle
+- connection. DAs and SAs SHOULD close an idle TCP connection after
+- CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the
+- initiating agent neglects to close it. See Section 13 for timing
+- rules.
+-
+-6.3. Retransmission of SLP messages
+-
+- Requests which fail to elicit a response are retransmitted. The
+- initial retransmission occurs after a CONFIG_RETRY wait period.
+- Retransmissions MUST be made with exponentially increasing wait
+- intervals (doubling the wait each time). This applies to unicast as
+- well as multicast SLP requests.
+-
+- Unicast requests to a DA or SA should be retransmitted until either a
+- response (which might be an error) has been obtained, or for
+- CONFIG_RETRY_MAX seconds.
+-
+- Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds
+- until a result has been obtained. UAs need only wait till they
+- obtain the first reply which matches their request. That is,
+- retransmission is not required if the requesting agent is prepared to
+- use the 'first reply' instead of 'as many replies as possible within
+- a bounded time interval.'
+-
+- When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast,
+- they contain a <PRList> of previous responders. Initially the
+- <PRList> is empty. When these requests are unicast, the <PRList> is
+- always empty.
+-
+- Any DA or SA which sees its address in the <PRList> MUST NOT respond
+- to the request.
+-
+- The message SHOULD be retransmitted until the <PRList> causes no
+- further responses to be elicited or the previous responder list and
+- the request will not fit into a single datagram or until
+- CONFIG_MC_MAX seconds elapse.
+-
+- UAs which retransmit a request use the same XID. This allows a DA or
+- SA to cache its reply to the original request and then send it again,
+- should a duplicate request arrive. This cached information should
+- only be held very briefly. XIDs SHOULD be randomly chosen to avoid
+-
+-
+-
+-Guttman, et al. Standards Track [Page 15]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- duplicate XIDs in requests if UAs restart frequently.
+-
+-6.4. Strings in SLP messages
+-
+- The escape character is a backslash (UTF-8 0x5c) followed by the two
+- hexadecimal digits of the escaped character. Only reserved
+- characters are escaped. For example, a comma (UTF-8 0x29) is escaped
+- as `\29', and a backslash `\' is escaped as `\5c'. String lists used
+- in SLP define the comma to be the delimiter between list elements, so
+- commas in data strings must be escaped in this manner. Backslashes
+- are the escape character so they also must always be escaped when
+- included in a string literally.
+-
+- String comparison for order and equality in SLP MUST be case
+- insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds
+- to ASCII character encoding). Case insensitivity SHOULD be supported
+- throughout the entire UTF-8 encoded Unicode [6] character set.
+-
+- The case insensitivity rule applies to all string matching in SLPv2,
+- including Scope strings, SLP SPI strings, service types, attribute
+- tags and values in query handling, language tags, previous responder
+- lists. Comparisons of URL strings, however, is case sensitive.
+-
+- White space (SPACE, CR, LF, TAB) internal to a string value is folded
+- to a single SPACE character for the sake of string comparisons.
+- White space preceding or following a string value is ignored for the
+- purposes of string comparison. For example, " Some String "
+- matches "SOME STRING".
+-
+- String comparisons (using comparison operators such as `<=' or `>=')
+- are done using lexical ordering in UTF-8 encoded characters, not
+- using any language specific rules.
+-
+- The reserved character `*' may precede, follow or be internal to a
+- string value in order to indicate substring matching. The query
+- including this character matches any character sequence which
+- conforms to the letters which are not wildcarded.
+-
+-6.4.1. Scope Lists in SLP
+-
+- Scope Lists in SLPv2 have the following grammar:
+-
+- scope-list = scope-val / scope-val `,' scope-list
+- scope-val = 1*safe
+- safe = ; Any character except reserved.
+- reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
+- / `;' / `*' / `+'
+- escape-val = `\' HEXDIG HEXDIG
+-
+-
+-
+-Guttman, et al. Standards Track [Page 16]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- Scopes which include any reserved characters must replace the escaped
+- character with the escaped-val format.
+-
+-7. Errors
+-
+- If the Error Code in a SLP reply message is nonzero, the rest of the
+- message MAY be truncated. No data is necessarily transmitted or
+- should be expected after the header and the error code, except
+- possibly for some optional extensions to clarify the error, for
+- example as in section D.1.
+-
+- Errors are only returned for unicast requests. Multicast requests
+- are silently discarded if they result in an error.
+-
+- LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in
+- the scope in the AttrRqst or SrvRqst, but not in the requested
+- language.
+- PARSE_ERROR = 2: The message fails to obey SLP syntax.
+- INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero
+- lifetime or an omitted Language Tag.
+- SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in
+- its <scope-list> supported by the SA or DA.
+- AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an
+- unsupported SLP SPI.
+- AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR
+- authentication in the SrvReg and did not receive it.
+- AUTHENTICATION_FAILED = 7: The DA detected an authentication error in
+- an Authentication block.
+- VER_NOT_SUPPORTED = 9: Unsupported version number in message header.
+- INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond.
+- DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off.
+- OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option
+- from the mandatory range (see section 9.1).
+- INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for
+- an unregistered service or with inconsistent Service Types.
+- MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst
+- and does not support it.
+- REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a
+- DA more frequently than the DA's min-refresh-interval.
+-
+-8. Required SLP Messages
+-
+- All length fields in SLP messages are in network byte order. Where '
+- tuples' are defined, these are sequences of bytes, in the precise
+- order listed, in network byte order.
+-
+- SLP messages all begin with the following header:
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 17]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Version | Function-ID | Length |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Length, contd.|O|F|R| reserved |Next Ext Offset|
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Next Extension Offset, contd.| XID |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Language Tag Length | Language Tag \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- Message Type Abbreviation Function-ID
+-
+- Service Request SrvRqst 1
+- Service Reply SrvRply 2
+- Service Registration SrvReg 3
+- Service Deregister SrvDeReg 4
+- Service Acknowledge SrvAck 5
+- Attribute Request AttrRqst 6
+- Attribute Reply AttrRply 7
+- DA Advertisement DAAdvert 8
+- Service Type Request SrvTypeRqst 9
+- Service Type Reply SrvTypeRply 10
+- SA Advertisement SAAdvert 11
+-
+- SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST
+- also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support
+- for other messages are OPTIONAL.
+-
+- - Length is the length of the entire SLP message, header included.
+- - The flags are: OVERFLOW (0x80) is set when a message's length
+- exceeds what can fit into a datagram. FRESH (0x40) is set on
+- every new SrvReg. REQUEST MCAST (0x20) is set when multicasting
+- or broadcasting requests. Reserved bits MUST be 0.
+- - Next Extension Offset is set to 0 unless extensions are used.
+- The first extension begins at 'offset' bytes, from the message's
+- beginning. It is placed after the SLP message data. See
+- Section 9.1 for how to interpret unrecognized SLP Extensions.
+- - XID is set to a unique value for each unique request. If the
+- request is retransmitted, the same XID is used. Replies set
+- the XID to the same value as the xid in the request. Only
+- unsolicited DAAdverts are sent with an XID of 0.
+- - Lang Tag Length is the length in bytes of the Language Tag field.
+- - Language Tag conforms to [7]. The Language Tag in a reply MUST
+- be the same as the Language Tag in the request. This field must
+- be encoded 1*8ALPHA *("-" 1*8ALPHA).
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 18]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- If an option is specified, and not included in the message, the
+- receiver MUST respond with a PARSE_ERROR.
+-
+-8.1. Service Request
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = SrvRqst = 1) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of <PRList> | <PRList> String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of <service-type> | <service-type> String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of <scope-list> | <scope-list> String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of predicate string | Service Request <predicate> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of <SLP SPI> string | <SLP SPI> String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- In order for a Service to match a SrvRqst, it must belong to at least
+- one requested scope, support the requested service type, and match
+- the predicate. If the predicate is present, the language of the
+- request (ignoring the dialect part of the Language Tag) must match
+- the advertised service.
+-
+- <PRList> is the Previous Responder List. This <string-list> contains
+- dotted decimal notation IP (v4) addresses, and is iteratively
+- multicast to obtain all possible results (see Section 6.3). UAs
+- SHOULD implement this discovery algorithm. SAs MUST use this to
+- discover all available DAs in their scope, if they are not already
+- configured with DA addresses by some other means.
+-
+- A SA silently drops all requests which include the SA's address in
+- the <PRList>. An SA which has multiple network interfaces MUST check
+- if any of the entries in the <PRList> equal any of its interfaces.
+- An entry in the PRList which does not conform to an IPv4 dotted
+- decimal address is ignored: The rest of the <PRList> is processed
+- normally and an error is not returned.
+-
+- Once a <PRList> plus the request exceeds the path MTU, multicast
+- convergence stops. This algorithm is not intended to find all
+- instances; it finds 'enough' to provide useful results.
+-
+- The <scope-list> is a <string-list> of configured scope names. SAs
+- and DAs which have been configured with any of the scopes in this
+- list will respond. DAs and SAs MUST reply to unicast requests with a
+-
+-
+-
+-Guttman, et al. Standards Track [Page 19]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- SCOPE_NOT_SUPPORTED error if the <scope-list> is omitted or fails to
+- include a scope they support (see Section 11). The only exceptions
+- to this are described in Section 11.2.
+-
+- The <service-type> string is discussed in Section 4. Normally, a
+- SrvRqst elicits a SrvRply. There are two exceptions: If the
+- <service-type> is set to "service:directory-agent", DAs respond to
+- the SrvRqst with a DAAdvert (see Section 8.5.) If set to
+- "service:service-agent", SAs respond with a SAAdvert (see Section
+- 8.6.) If this field is omitted, a PARSE_ERROR is returned - as this
+- field is REQUIRED.
+-
+- The <predicate> is a LDAPv3 search filter [14]. This field is
+- OPTIONAL. Services may be discovered simply by type and scope.
+- Otherwise, services are discovered which satisfy the <predicate>. If
+- present, it is compared to each registered service. If the attribute
+- in the filter has been registered with multiple values, the filter is
+- compared to each value and the results are ORed together, i.e.,
+- "(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" matches
+- (y=0,1) since Y can be nonzero. Note the matching is case
+- insensitive. Keywords (i.e., attributes without values) are matched
+- with a "presence" filter, as in "(keyword=*)".
+-
+- An incoming request term MUST have the same type as the attribute in
+- a registration in order to match. Thus, "(x=33)" will not match '
+- x=true', etc. while "(y=foo)" will match 'y=FOO'.
+- "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be
+- satisfied, because of the `|' (boolean disjunction).
+-
+- Wildcard matching MUST be done with the '=' filter. In any other
+- case, a PARSE_ERROR is returned. Request terms which include
+- wildcards are interpreted to be Strings. That is, (x=34*) would
+- match 'x=34foo', but not 'x=3432' since the first value is a String
+- while the second value is an Integer; Strings don't match Integers.
+-
+- Examples of Predicates follow. <t> indicates the service type of the
+- SrvRqst, <s> gives the <scope-list> and <p> is the predicate string.
+-
+- <t>=service:http <s>=DEFAULT <p>= (empty string)
+- This is a minimal request string. It matches all http
+- services advertised with the default scope.
+-
+- <t>=service:pop3 <s>=SALES,DEFAULT <p>=(user=wump)
+- This is a request for all pop3 services available in
+- the SALES or DEFAULT scope which serve mail to the user
+- `wump'.
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 20]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- <t>=service:backup <s>=BLDG 32 <p>=(&(q<=3)(speed>=1000))
+- This returns the backup service which has a queue length
+- less than 3 and a speed greater than 1000. It will
+- return this only for services registered with the BLDG 32
+- scope.
+-
+- <t>=service:directory-agent <s>=DEFAULT <p>=
+- This returns DAAdverts for all DAs in the DEFAULT scope.
+-
+- DAs are discovered by sending a SrvRqst with the service type set to
+- "service:directory-agent". If a predicate is included in the
+- SrvRqst, the DA SHOULD respond only if the predicate can be satisfied
+- with the DA's attributes. The <scope-list> MUST contain all scopes
+- configured for the UA or SA which is discovering DAs.
+-
+- The <SLP SPI> string indicates a SLP SPI that the requester has been
+- configured with. If this string is omitted, the responder does not
+- include any Authentication Blocks in its reply. If it is included,
+- the responder MUST return a reply which has an associated
+- authentication block with the SLP SPI in the SrvRqst. If no replies
+- may be returned because the SLP SPI is not supported, the responder
+- returns an AUTHENTICATION_UNKNOWN error.
+-
+-8.2. Service Reply
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = SrvRply = 2) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Error Code | URL Entry count |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | <URL Entry 1> ... <URL Entry N> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- The service reply contains zero or more URL entries (see Section
+- 4.3). A service reply with zero URL entries MUST be returned in
+- response to a unicast Service Request, if no matching URLs are
+- present. A service reply with zero URL entries MUST NOT be sent in
+- response to a multicast or broadcast service request (instead, if
+- there was no match found or an error processing the request, the
+- service reply should not be generated at all).
+-
+- If the reply overflows, the UA MAY simply use the first URL Entry in
+- the list. A URL obtained by SLP may not be cached longer than
+- Lifetime seconds, unless there is a URL Authenticator block present.
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 21]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- In that case, the cache lifetime is indicated by the Timestamp in the
+- URL Authenticator (see Section 9.2).
+-
+- An authentication block is returned in the URL Entries, including the
+- SLP SPI in the SrvRqst. If no SLP SPI was included in the request,
+- no Authentication Blocks are returned in the reply. URL
+- Authentication Blocks are defined in Section 9.2.1.
+-
+- If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless
+- it fits entirely without truncation.
+-
+-8.3. Service Registration
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = SrvReg = 3) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | <URL-Entry> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of service type string | <service-type> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of <scope-list> | <scope-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of attr-list string | <attr-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- |# of AttrAuths |(if present) Attribute Authentication Blocks...\
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- The <entry> is a URL Entry (see section 4.3). The Lifetime defines
+- how long a DA can cache the registration. SAs SHOULD reregister
+- before this lifetime expires (but SHOULD NOT more often than once per
+- second). The Lifetime MAY be set to any value between 0 and 0xffff
+- (maximum, around 18 hours). Long-lived registrations remain stale
+- longer if the service fails and the SA does not deregister the
+- service.
+-
+- The <service-type> defines the service type of the URL to be
+- registered, regardless of the scheme of the URL. The <scope-list>
+- MUST contain the names of all scopes configured for the SA, which the
+- DA it is registering with supports. The default value for the
+- <scope-list> is "DEFAULT" (see Section 11).
+-
+- The SA MUST register consistently with all DAs. If a SA is
+- configured with scopes X and Y and there are three DAs, whose scopes
+- are "X", "Y" and "X,Y" respectively, the SA will register the with
+- all three DAs in their respective scopes. All future updates and
+- deregistrations of the service must be sent to the same set of DAs in
+-
+-
+-
+-Guttman, et al. Standards Track [Page 22]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- the same scopes the service was initially registered in.
+-
+- The <attr-list>, if present, specifies the attributes and values to
+- be associated with the URL by the DA (see Section 5).
+-
+- A SA configured with the ability to sign service registrations MUST
+- sign each of the URLs and Attribute Lists using each of the keys it
+- is configured to use, and the DA it is registering with accepts.
+- (The SA MUST acquire DAAdverts for all DAs it will register with to
+- obtain the DA's SLP SPI list and attributes, as described in Section
+- 8.5). The SA supplies a SLP SPI in each authentication block
+- indicating the SLP SPI configuration required to verify the digital
+- signature. The format of the digital signatures used is defined in
+- section 9.2.1.
+-
+- Subsequent registrations of previously registered services MUST
+- contain the same list of SLP SPIs as previous ones or else DAs will
+- reject them, replying with an AUTHENTICATION_ABSENT error.
+-
+- A registration with the FRESH flag set will replace *entirely* any
+- previous registration for the same URL in the same language. If the
+- FRESH flag is not set, the registration is an "incremental"
+- registration (see Section 9.3).
+-
+-8.4. Service Acknowledgment
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = SrvAck = 5) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Error Code |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- A DA returns a SrvAck to an SA after a SrvReg. It carries only a two
+- byte Error Code (see Section 7).
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 23]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-8.5. Directory Agent Advertisement
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = DAAdvert = 8) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Error Code | DA Stateless Boot Timestamp |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- |DA Stateless Boot Time,, contd.| Length of URL |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- \ URL \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Length of <scope-list> | <scope-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Length of <attr-list> | <attr-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Length of <SLP SPI List> | <SLP SPI List> String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | # Auth Blocks | Authentication block (if any) \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- The Error Code is set to 0 when the DAAdvert is multicast. If the
+- DAAdvert is being returned due to a unicast SrvRqst (ie. a request
+- without the REQUEST MCAST flag set) the DA returns the same errors a
+- SrvRply would.
+-
+- The <scope-list> of the SrvRqst must either be omitted or include a
+- scope which the DA supports. The DA Stateless Boot Timestamp
+- indicates the state of the DA (see section 12.1).
+-
+- The DA MAY include a list of its attributes in the DAAdvert. This
+- list SHOULD be kept short, as the DAAdvert must fit into a datagram
+- in order to be multicast.
+-
+- A potential scaling problem occurs in SLPv2 if SAs choose too low a
+- Lifetime. In this case, an onerous amount of reregistration occurs
+- as more services are deployed. SLPv2 allows DAs to control SAs
+- frequency of registration. A DA MAY reissue a DAAdvert with a new
+- set of attributes at any time, to change the reregistration behavior
+- of SAs. These apply only to subsequent registrations; existing
+- service registrations with the DA retain their registered lifetimes.
+-
+- If the DAAdvert includes the attribute "min-refresh-interval" it MUST
+- be set to a single Integer value indicating a number of seconds. If
+- this attribute is present SAs MUST NOT refresh any particular service
+- advertisement more frequently than this value. If SrvReg with the
+- FRESH FLAG not set or SrvDereg with a non-empty tag list updating a
+-
+-
+-
+-Guttman, et al. Standards Track [Page 24]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- particular service are received more often than the value for the
+- DA's advertised "min-refresh-interval" attribute the DA SHOULD reject
+- the message and return a REFRESH_REJECTED error in the SrvAck.
+-
+- The URL is "service:directory-agent://"<addr> of the DA, where <addr>
+- is the dotted decimal numeric address of the DA. The <scope-list> of
+- the DA MUST NOT be NULL.
+-
+- The SLP SPI List is the list of SPIs that the DA is capable of
+- verifying. SAs MUST NOT register services with authentication blocks
+- for those SLP SPIs which are not on the list. DAs will reject
+- service registrations which they cannot verify, returning an
+- AUTHENTICATION_UNKNOWN error.
+-
+- The format of DAAdvert signatures is defined in Section 9.2.1.
+-
+- The SLP SPI which is used to verify the DAAdvert is included in the
+- Authentication Block. When DAAdverts are multicast, they may have to
+- transmit multiple DAAdvert Authentication Blocks. If the DA is
+- configured to be able to generate signatures for more than one SPI,
+- the DA MUST include one Authentication Block for each SPI. If all
+- these Authentication Blocks do not fit in a single datagram (to
+- multicast or broadcast) the DA MUST send separate DAAdverts so that
+- Authentication Blocks for all the SPIs the DA is capable of
+- generating are sent.
+-
+- If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert
+- contains only the authentication block with the SLP SPI in the
+- SrvRqst, if the DA is configured to be able to produce digital
+- signatures using that SLP SPI. If the SrvRqst is unicast to the DA
+- (the REQUEST MCAST flag in the header is not set) and an unsupported
+- SLP SPI is included, the DA replies with a DAAdvert with the Error
+- Code set to an AUTHENTICATION_UNKNOWN error.
+-
+- UAs SHOULD be configured with SLP SPIs that will allow them to verify
+- DA Advertisements. If the UA is configured with SLP SPIs and
+- receives a DAAdvert which fails to be verified using one of them, the
+- UA MUST discard it.
+-
+-8.6. Service Agent Advertisement
+-
+- User Agents MUST NOT solicit SA Advertisements if they have been
+- configured to use a particular DA, if they have been configured with
+- a <scope-list> or if DAs have been discovered. UAs solicit SA
+- Advertisements only when they are explicitly configured to use User
+- Selectable scopes (see Section 11.2) in order to discover the scopes
+- that SAs support. This allows UAs without scope configuration to
+- make use of either DAs or SAs without any functional difference
+-
+-
+-
+-Guttman, et al. Standards Track [Page 25]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- except performance.
+-
+- A SA MAY be configured with attributes, and SHOULD support the
+- attribute 'service-type' whose value is all the service types of
+- services represented by the SA. SAs MUST NOT respond if the SrvRqst
+- predicate is not satisfied. For example, only SAs offering 'nfs'
+- services SHOULD respond with a SAAdvert to a SrvRqst for service type
+- "service:service-agent" which includes a predicate "(service-
+- type=nfs)".
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = SAAdvert = 11) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Length of URL | URL \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Length of <scope-list> | <scope-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Length of <attr-list> | <attr-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | # auth blocks | authentication block (if any) \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- The SA responds only to multicast SA discovery requests which either
+- include no <scope-list> or a scope which they are configured to use.
+-
+- The SAAdvert MAY include a list of attributes the SA supports. This
+- attribute list SHOULD be kept short so that the SAAdvert will not
+- exceed the path MTU in size.
+-
+- The URL is "service:service-agent://"<addr> of the SA, where <addr>
+- is the dotted decimal numeric address of the SA. The <scope-list> of
+- the SA MUST NOT be null.
+-
+- The SAAdvert contains one SAAdvert Authentication block for each SLP
+- SPI the SA can produce Authentication Blocks for. If the UA can
+- verify the Authentication Block of the SAAdvert, and the SAAdvert
+- fails to be verified, the UA MUST discard it.
+-
+-9. Optional Features
+-
+- The features described in this section are not mandatory. Some are
+- useful for interactive use of SLP (where a user rather than a program
+- will select services, using a browsing interface for example) and for
+- scalability of SLP to larger networks.
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 26]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-9.1. Service Location Protocol Extensions
+-
+- The format of a Service Location Extension is:
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Extension ID | Next Extension Offset |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Offset, contd.| Extension Data \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- Extension IDs are assigned in the following way:
+-
+- 0x0000-0x3FFF Standardized. Optional to implement. Ignore if
+- unrecognized.
+- 0x4000-0x7FFF Standardized. Mandatory to implement. A UA or SA
+- which receives this option in a reply and does not understand
+- it MUST silently discard the reply. A DA or SA which receives
+- this option in a request and does not understand it MUST return
+- an OPTION_NOT_UNDERSTOOD error.
+- 0x8000-0x8FFF For private use (not standardized). Optional to
+- implement. Ignore if unrecognized.
+- 0x9000-0xFFFF Reserved.
+-
+- The three byte offset to next extension indicates the position of the
+- next extension as offset from the beginning of the SLP message.
+-
+- The offset value is 0 if there are no extensions following the
+- current extension.
+-
+- If the offset is 0, the length of the current Extension Data is
+- determined by subtracting total length of the SLP message as given in
+- the SLP message header minus the offset of the current extension.
+-
+- Extensions defined in this document are in Section D. See section 15
+- for procedures that are required when specifying new SLP extensions.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 27]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-9.2. Authentication Blocks
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Block Structure Descriptor | Authentication Block Length |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Timestamp |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | SLP SPI String Length | SLP SPI String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Structured Authentication Block ... \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- Authentication blocks are returned with certain SLP messages to
+- verify that the contents have not been modified, and have been
+- transmitted by an authorized agent. The authentication data
+- (contained in the Structured Authentication Block) is typically case
+- sensitive. Even though SLP registration data (e.g., attribute
+- values) are typically are not case sensitive, the case of the
+- registration data has to be preserved by the registering DA so that
+- UAs will be able to verify the data used for calculating digital
+- signature data.
+-
+- The Block Structure Descriptor (BSD) identifies the format of the
+- Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained
+- by IANA. BSDs 0x8000-0x8FFF are for private use.
+-
+- The Authentication Block Length is the length of the entire block,
+- starting with the BSD.
+-
+- The Timestamp is the time that the authenticator expires (to prevent
+- replay attacks.) The Timestamp is a 32-bit unsigned fixed-point
+- number of seconds relative to 0h on 1 January 1970. SAs use this
+- value to indicate when the validity of the digital signature expires.
+- This Timestamp will wrap back to 0 in the year 2106. Once the value
+- of the Timestamp wraps, the time at which the Timestamp is relative
+- to resets. For example, after 06h28 and 16 seconds 5 February 2106,
+- all Timestamp values will be relative to that epoch date.
+-
+- The SLP Security Parameters Index (SPI) string identifies the key
+- length, algorithm parameters and keying material to be used by agents
+- to verify the signature data in the Structured Authentication Block.
+- The SLP SPI string has the same grammar as the <scope-val> defined in
+- Section 6.4.1.
+-
+- Reserved characters in SLP SPI strings must be escaped using the same
+- convention as used throughout SLPv2.
+-
+-
+-
+-Guttman, et al. Standards Track [Page 28]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- SLP SPIs deployed in a site MUST be unique. An SLP SPI used for
+- BSD=0x0002 must not be the same as used for some other BSD.
+-
+- All SLP agents MUST implement DSA [20] (BSD=0x0002). SAs MUST
+- register services with DSA authentication blocks, and they MAY
+- register them with other authentication blocks using other
+- algorithms. SAs MUST use DSA authentication blocks in SrvDeReg
+- messages and DAs MUST use DSA authentication blocks in unsolicited
+- DAAdverts.
+-
+-9.2.1. SLP Message Authentication Rules
+-
+- The sections below define how to calculate the value to apply to the
+- algorithm identified by the BSD value. The components listed are
+- used as if they were a contiguous single byte aligned buffer in the
+- order given.
+-
+- URL
+- 16-bit Length of SLP SPI String, SLP SPI String.
+- 16-bit Length of URL, URL,
+- 32-bit Timestamp.
+-
+- Attribute List
+- 16-bit Length of SLP SPI String, SLP SPI String,
+- 16-bit length of <attr-list>, <attr-list>,
+- 32-bit Timestamp.
+-
+- DAAdvert
+- 16-bit Length of SLP SPI String, SLP SPI String,
+- 32-bit DA Stateless Boot Timestamp,
+- 16-bit Length of URL, URL,
+- 16-bit Length of <attr-list>, <attr-list>,
+- 16-bit Length of DA's <scope-list>, DA's <scope-list>,
+- 16-bit Length of DA's <SLP SPI List>, DA's <SLP SPI List>,
+- 32-bit Timestamp.
+-
+- The first SLP SPI is the SLP SPI in the Authentication
+- Block. This SLP SPI indicates the keying material and other
+- parameters to use to verify the DAAdvert. The SLP SPI List is
+- the list of SLP SPIs the DA itself supports, and is able to
+- verify.
+-
+- SAAdvert
+- 16-bit Length of SLP SPI String, SLP SPI String,
+- 16-bit Length of URL, URL,
+- 16-bit Length of <attr-list>, <attr-list>,
+- 16-bit Length of <scope-list>, <scope-list>,
+- 32-bit Timestamp.
+-
+-
+-
+-Guttman, et al. Standards Track [Page 29]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-9.2.2 DSA with SHA-1 in Authentication Blocks
+-
+- BSD=0x0002 is defined to be DSA with SHA-1. The signature
+- calculation is defined by [20]. The signature format conforms to
+- that in the X.509 v3 certificate:
+-
+- 1. The signature algorithm identifier (an OID)
+- 2. The signature value (an octet string)
+- 3. The certificate path.
+-
+- All data is represented in ASN.1 encoding:
+-
+- id-dsa-with-sha1 ID ::= {
+- iso(1) member-body(2) us(840) x9-57 (10040)
+- x9cm(4) 3 }
+-
+- i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately
+- by:
+-
+- Dss-Sig-Value ::= SEQUENCE {
+- r INTEGER,
+- s INTEGER }
+-
+- i.e., the binary ASN.1 encoding of r and s computed using DSA and
+- SHA-1. This is followed by a certificate path, as defined by X.509
+- [10], [2], [3], [4], [5].
+-
+- Authentication Blocks for BSD=0x0002 have the following format. In
+- the future, BSDs may be assigned which have different formats.
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | ASN.1 encoded DSA signature \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+-9.3. Incremental Service Registration
+-
+- Incremental registrations update attribute values for a previously
+- registered service. Incremental service registrations are useful
+- when only a single attribute has changed, for instance. In an
+- incremental registration, the FRESH flag in the SrvReg header is NOT
+- set.
+-
+- The new registration's attributes replace the previous
+- registration's, but do not affect attributes which were included
+- previously and are not present in the update.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 30]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- For example, suppose service:x://a.org has been registered with
+- attributes A=1, B=2, C=3. If an incremental registration comes for
+- service:x://a.org with attributes C=30, D=40, then the attributes for
+- the service after the update are A=1, B=2, C=30, D=40.
+-
+- Incremental registrations MUST NOT be performed for services
+- registered with Authentication Blocks. These must be registered with
+- ALL attributes, with the FRESH flag in the SrvReg header set. DAs
+- which receive such registration messages return an
+- AUTHENTICATION_FAILED error.
+-
+- If the FRESH flag is not set and the DA does not have a prior
+- registration for the service, the incremental registration fails with
+- error code INVALID_UPDATE.
+-
+- The SA MUST use the same <scope-list> in an update message as was
+- used in the prior registration. If this is not done, the DA returns
+- a SCOPE_NOT_SUPPORTED error. In order to change the scope of a
+- service advertisement it MUST be deregistered first and reregistered
+- with a new <scope-list>.
+-
+- The SA MUST use the same <service-type> in an update message as was
+- used in a prior registration of the same URL. If this is not done,
+- the DA returns an INVALID_UPDATE error.
+-
+-9.4. Tag Lists
+-
+- Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a
+- <tag-list> item is:
+-
+- tag-filter = simple-tag / substring
+- simple-tag = 1*filt-char
+- substring = [initial] any [final]
+- initial = 1*filt-char
+- any = `*' *(filt-char `*')
+- final = 1*filt-char
+- filt-char = Any character excluding <reserved> and <bad-tag> (see
+- grammar in Section 5).
+-
+- Wild card characters in a <tag-list> item match arbitrary sequences
+- of characters. For instance "*bob*" matches "some bob I know",
+- "bigbob", "bobby" and "bob".
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 31]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-10. Optional SLP Messages
+-
+- The additional requests provide features for user interaction and for
+- efficient updating of service advertisements with dynamic attributes.
+-
+-10.1. Service Type Request
+-
+- The Service Type Request (SrvTypeRqst) allows a UA to discover all
+- types of service on a network. This is useful for general purpose
+- service browsers.
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = SrvTypeRqst = 9) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of PRList | <PRList> String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of Naming Authority | <Naming Authority String> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of <scope-list> | <scope-list> String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- The <PRList> list and <scope-list> are interpreted as in Section 8.1.
+-
+- The Naming Authority string, if present in the request, will limit
+- the reply to Service Type strings with the specified Naming
+- Authority. If the Naming Authority string is absent, the IANA
+- registered service types will be returned. If the length of the
+- Naming Authority is set to 0xFFFF, the Naming Authority string is
+- omitted and ALL Service Types are returned, regardless of Naming
+- Authority.
+-
+-10.2. Service Type Reply
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = SrvTypeRply = 10) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Error Code | length of <srvType-list> |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | <srvtype--list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- The service-type Strings (as described in Section 4.1) are provided
+- in <srvtype-list>, which is a <string-list>.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 32]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- If a service type has a Naming Authority other than IANA it MUST be
+- returned following the service type string and a `.' character.
+- Service types with the IANA Naming Authority do not include a Naming
+- Authority string.
+-
+-10.3. Attribute Request
+-
+- The Attribute Request (AttrRqst) allows a UA to discover attributes
+- of a given service (by supplying its URL) or for an entire service
+- type. The latter feature allows the UA to construct a query for an
+- available service by selecting desired features. The UA may request
+- that all attributes are returned, or only a subset of them.
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = AttrRqst = 6) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of PRList | <PRList> String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of URL | URL \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of <scope-list> | <scope-list> string \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of <tag-list> string | <tag-list> string \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | length of <SLP SPI> string | <SLP SPI> string \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- The <PRList>, <scope-list> and <SLP SPI> string are interpreted as in
+- Section 8.1.
+-
+- The URL field can take two forms. It can simply be a Service Type
+- (see Section 4.1), such as "http" or "service:tftp". In this case,
+- all attributes and the full range of values for each attribute of all
+- services of the given Service Type is returned.
+-
+- The URL field may alternatively be a full URL, such as
+- "service:printer:lpr://igore.wco.ftp.com:515/draft" or
+- "nfs://max.net/znoo". In this, only the registered attributes for
+- the specified URL are returned.
+-
+- The <tag-list> field is a <string-list> of attribute tags, as defined
+- in Section 9.4 which indicates the attributes to return in the
+- AttrRply. If <tag-list> is omitted, all attributes are returned.
+- <tag-list> MUST be omitted and a full URL MUST be included when
+- attributes when a SLP SPI List string is included, otherwise the DA
+- will reply with an AUTHENTICATION_FAILED error.
+-
+-
+-
+-Guttman, et al. Standards Track [Page 33]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-10.4. Attribute Reply
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = AttrRply = 7) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Error Code | length of <attr-list> |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | <attr-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- |# of AttrAuths | Attribute Authentication Block (if present) \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- The format of the <attr-list> and the Authentication Block is as
+- specified for SrvReg (see Section 9.2.1).
+-
+- Attribute replies SHOULD be returned with the original case of the
+- string registration intact, as they are likely to be human readable.
+- In the case where the AttrRqst was by service type, all attributes
+- defined for the service type, and all their values are returned.
+-
+- Although white space is folded for string matching, attribute tags
+- and values MUST be returned with their original white space
+- preserved.
+-
+- Only one copy of each attribute tag or String value should be
+- returned, arbitrarily choosing one version (with respect to upper and
+- lower case and white space internal to the strings): Duplicate
+- attributes and values SHOULD be removed. An arbitrary version of the
+- string value and tag name is chosen for the merge. For example:
+- "(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)".
+-
+-10.5. Attribute Request/Reply Examples
+-
+- Suppose that printer services have been registered as follows:
+-
+- Registered Service:
+- URL = service:printer:lpr://igore.wco.ftp.com/draft
+- scope-list = Development
+- Lang. Tag = en
+- Attributes = (Name=Igore),(Description=For developers only),
+- (Protocol=LPR),(location-description=12th floor),
+- (Operator=James Dornan \3cdornan at monster\3e),
+- (media-size=na-letter),(resolution=res-600),x-OK
+-
+- URL = service:printer:lpr://igore.wco.ftp.com/draft
+- scope-list = Development
+-
+-
+-
+-Guttman, et al. Standards Track [Page 34]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- Lang. Tag = de
+- Attributes = (Name=Igore),(Description=Nur fuer Entwickler),
+- (Protocol=LPR),(location-description=13te Etage),
+- (Operator=James Dornan \3cdornan at monster\3e),
+- (media-size=na-letter),(resolution=res-600),x-OK
+-
+- URL = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn
+- scope-list = Development
+- Lang. Tag = en
+- Attributes = (Name=Not),(Description=Experimental IPP printer),
+- (Protocol=http),(location-description=QA bench),
+- (media-size=na-letter),(resolution=other),x-BUSY
+-
+- Notice the first printer, "Igore" is registered in both English and
+- German. The `<' and `>' characters in the Operator attribute value
+- which are part of the Email address had to be escaped, as they are
+- reserved characters for values.
+-
+- Attribute tags are not translated, though attribute values may be,
+- see [13].
+-
+- The attribute Request:
+-
+- URL = service:printer:lpr://igore.wco.ftp.com/draft
+- scope-list = Development
+- Lang. Tag = de
+- tag-list = resolution,loc*
+-
+- receives the Attribute Reply:
+-
+- (location-description=13te Etage),(resolution=res-600)
+-
+- The attribute Request:
+-
+- URL = service:printer
+- scope-list = Development
+- Lang. Tag = en
+- tag-list = x-*,resolution,protocol
+-
+- receives an Attribute Reply containing:
+-
+- (protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY
+-
+- The first request is by service instance and returns the requested
+- values, in German. The second request is by abstract service type
+- (see Section 4) and returns values from both "Igore" and "Not".
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 35]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- An attribute Authentication Block is returned if an authentication
+- block with the SLP SPI in the AttrRqst can be returned. Note that
+- the <attr-list> returned from a DA with an Authentication Block MUST
+- be identical to the <attr-list> registered by a SA, in order for the
+- authentication verification calculations to be possible.
+-
+- A SA or DA only returns an Attribute Authentication Block if the
+- AttrRqst included a full URL in the request and no tag list.
+-
+- If an SLP SPI is specified in a unicast request (the REQUEST MCAST
+- flag in the header is not set) and the SA or DA cannot return an
+- Authentication Block with that SLP SPI, an AUTHENTICATION_UNKNOWN
+- error is returned. The # of Attr Auths field is set to 0 if there no
+- Authentication Block is included, or 1 if an Authentication Block
+- follows.
+-
+-10.6. Service Deregistration
+-
+- A DA deletes a service registration when its Lifetime expires.
+- Services SHOULD be deregistered when they are no longer available,
+- rather than leaving the registrations to time out.
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Service Location header (function = SrvDeReg = 4) |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Length of <scope-list> | <scope-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | URL Entry \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Length of <tag-list> | <tag-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- The <scope-list> is a <string-list> (see section 2.1).
+-
+- The SA MUST retry if there is no response from the DA, see Section
+- 12.3. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA
+- receives an acknowledgment indicating success, the service and/or
+- attributes are no longer advertised by the DA. The DA deregisters the
+- service or service attributes from every scope specified in the
+- SrvDeReg which it was previously registered in.
+-
+- The SA MUST deregister all services with the same scope list used to
+- register the service with a DA. If this is not done in the SrvDeReg
+- message, the DA returns a SCOPE_NOT_SUPPORTED error. The Lifetime
+- field in the URL Entry is ignored for the purposes of the SrvDeReg.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 36]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- The <tag-list> is a <string-list> of attribute tags to deregister as
+- defined in Section 9.4. If no <tag-list> is present, the SrvDeReg
+- deregisters the service in all languages it has been registered in.
+- If the <tag-list> is present, the SrvDeReg deregisters the attributes
+- whose tags are listed in the tag spec. Services registered with
+- Authentication Blocks MUST NOT include a <tag-list> in a SrvDeReg
+- message: A DA will respond with an AUTHENTICATION_FAILED error in
+- this case.
+-
+- If the service to be deregistered was registered with an
+- authentication block or blocks, a URL authentication block for each
+- of the SLP SPIs registered must be included in the SrvDeReg.
+- Otherwise, the DA returns an AUTHENTICATION_ABSENT error. If the
+- message fails to be verified by the DA, an AUTHENTICATION_FAILED
+- error is returned by the DA.
+-
+-11. Scopes
+-
+- Scopes are sets of services. The primary use of Scopes is to provide
+- the ability to create administrative groupings of services. A set of
+- services may be assigned a scope by network administrators. A client
+- seeking services is configured to use one or more scopes. The user
+- will only discover those services which have been configured for him
+- or her to use. By configuring UAs and SAs with scopes,
+- administrators may provision services. Scopes strings are case
+- insensitive. The default SCOPE string is "DEFAULT".
+-
+- Scopes are the primary means an administrator has to scale SLP
+- deployments to larger networks. When DAs with NON-DEFAULT scopes are
+- present on the network, further gains can be had by configuring UAs
+- and SAs to have a predefined non-default scope. These agents can
+- then perform DA discovery and make requests using their scope. This
+- will limit the number of replies.
+-
+-11.1. Scope Rules
+-
+- SLP messages which fail to contain a scope that the receiving Agent
+- is configured to use are dropped (if the request was multicast) or a
+- SCOPE_NOT_SUPPORTED error is returned (if the request was unicast).
+- Every SrvRqst (except for DA and SA discovery requests), SrvReg,
+- AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a
+- <scope-list>.
+-
+- A UA MUST unicast its SLP messages to a DA which supports the desired
+- scope, in preference to multicasting a request to SAs. A UA MAY
+- multicast the request if no DA is available in the scope it is
+- configured to use.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 37]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-11.2. Administrative and User Selectable Scopes
+-
+- All requests and services are scoped. The two exceptions are
+- SrvRqsts for "service:directory-agent" and "service:service-agent".
+- These MAY have a zero-length <scope-list> when used to enable the
+- user to make scope selections. In this case UAs obtain their scope
+- list from DAAdverts (or if DAs are not available, from SAAdverts.)
+-
+- Otherwise, if SAs and UAs are to use any scope other than the default
+- (i.e., "DEFAULT"), the UAs and SAs are configured with lists of
+- scopes to use by system administrators, perhaps automatically by way
+- of DHCP option 78 or 79 [21]. Such administrative scoping allows
+- services to be provisioned, so that users will only see services they
+- are intended to see.
+-
+- User configurable scopes allow a user to discover any service, but
+- require them to do their own selection of scope. This is similar to
+- the way AppleTalk [12] and SMB [19] networking allow user selection
+- of AppleTalk Zone or workgroups.
+-
+- Note that the two configuration choices are not compatible. One
+- model allows administrators control over service provision. The
+- other delegates this to users (who may not be prepared to do any
+- configuration of their system).
+-
+-12. Directory Agents
+-
+- DAs cache service location and attribute information. They exist to
+- enhance the performance and scalability of SLP. Multiple DAs provide
+- further scalability and robustness of operation, since they can each
+- store service information for the same SAs, in case one of the DAs
+- fails.
+-
+- A DA provides a centralized store for service information. This is
+- useful in a network with several subnets or with many SLP Agents.
+- The DA address can be dynamically configured with UAs and SAs using
+- DHCP, or by using static configuration.
+-
+- SAs configured to use DAs with DHCP or static configuration MUST
+- unicast a SrvRqst to the DA, when the SA is initialized. The SrvRqst
+- omits the scope list and sets the service type of the request to
+- "service:directory-agent". The DA will return a DAAdvert with its
+- attributes, SLP SPI list, and other parameters which are essential
+- for proper SA to DA communication.
+-
+- Passive detection of DAs by SAs enables services to be advertised
+- consistently among DAs of the same scope. Advertisements expire if
+- not renewed, leaving only transient stale registrations in DAs, even
+-
+-
+-
+-Guttman, et al. Standards Track [Page 38]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- in the case of a failure of a SA.
+-
+- A single DA can support many UAs. UAs send the same requests to DAs
+- that they would send to SAs and expect the same results. DAs reduce
+- the load on SAs, making simpler implementations of SAs possible.
+-
+- UAs MUST be prepared for the possibility that the service information
+- they obtain from DAs is stale.
+-
+-12.1. Directory Agent Rules
+-
+- When DAs are present, each SA MUST register its services with DAs
+- that support one or more of its scope(s).
+-
+- UAs MUST unicast requests directly to a DA (when scoping rules
+- allow), hence avoiding using the multicast convergence algorithm, to
+- obtain service information. This decreases network utilization and
+- increases the speed at which UAs can obtain service information.
+-
+- DAs MUST flush service advertisements once their lifetime expires or
+- their URL Authentication Block "Timestamp" of expiration is past.
+-
+- DAAdverts MUST include DA Stateless Boot Timestamp, in the same
+- format as the Authentication Block (see Section 9.2). The Timestamp
+- in the Authentication Block indicates the time at which all previous
+- registrations were lost (i.e., the last stateless reboot). The
+- Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the DA
+- is going down. DAs MUST NOT use equal or lesser Boot Timestamps to
+- previous ones, if they go down and restart without service
+- registration state. This would mislead SAs to not reregister with
+- the DA.
+-
+- DAs which receive a multicast SrvRqst for the service type
+- "service:directory-agent" MUST silently discard it if the <scope-
+- list> is (a) not omitted and (b) does not include a scope they are
+- configured to use. Otherwise the DA MUST respond with a DAAdvert.
+-
+- DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are
+- OPTIONAL only for SAs, not DAs.)
+-
+-12.2. Directory Agent Discovery
+-
+- UAs can discover DAs using static configuration, DHCP options 78 and
+- 79, or by multicasting (or broadcasting) Service Requests using the
+- convergence algorithm in Section 6.3.
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 39]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- See Section 6 regarding unsolicited DAAdverts. Section 12.2.2
+- describes how SAs may reduce the number of times they must reregister
+- with DAs in response to unsolicited DAAdverts.
+-
+- DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An
+- unsolicited DAAdvert has an XID of 0. SAs MUST listen for DAAdverts,
+- passively, as described in Section 8.5. UAs MAY do this. If they do
+- not listen for unsolicited DAAdverts, however, they will not discover
+- DAs as they become available. UAs SHOULD, in this case, do periodic
+- active DA discovery, see Section 6.
+-
+- A URL with the scheme "service:directory-agent" indicates the DA's
+- location as defined in Section 8.5. For example:
+- "service:directory-agent://foobawooba.org".
+-
+- The following sections suggest timing algorithms which enhance the
+- scalability of SLP.
+-
+-12.2.1. Active DA Discovery
+-
+- After a UA or SA restarts, its initial DA discovery request SHOULD be
+- delayed for some random time uniformly distributed from 0 to
+- CONFIG_START_WAIT seconds.
+-
+- The UA or SA sends the DA Discovery request using a SrvRqst, as
+- described in Section 8.1. DA Discovery requests MUST include a
+- Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT
+- be sent more than once per CONFIG_DA_FIND seconds.
+-
+- After discovering a new DA, a SA MUST wait a random time between 0
+- and CONFIG_REG_ACTIVE seconds before registering their services.
+-
+-12.2.2. Passive DA Advertising
+-
+- A DA MUST multicast (or broadcast) an unsolicited DAAdvert every
+- CONFIG_DA_BEAT seconds. CONFIG_DA_BEAT SHOULD be specified to
+- prevent DAAdverts from using more than 1% of the available bandwidth.
+-
+- All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine
+- its DA stateless Boot Timestamp. If it is set to 0, the DA is going
+- down and no further messages should be sent to it.
+-
+- If a SA detects a DA it has never encountered (with a nonzero
+- timestamp,) the SA must register with it. SAs MUST examine the
+- DAAdvert's timestamp to determine if the DA has had a stateless
+- reboot since the SA last registered with it. If so it registers with
+- the DA. SAs MUST wait a random interval between 0 and
+- CONFIG_REG_PASSIVE before beginning DA registration.
+-
+-
+-
+-Guttman, et al. Standards Track [Page 40]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-12.3. Reliable Unicast to DAs and SAs
+-
+- If a DA or SA fails to respond to a unicast UDP message in
+- CONFIG_RETRY seconds, the message should be retried. The wait
+- interval for each subsequent retransmission MUST exponentially
+- increase, doubling each time. If a DA or SA fails to respond after
+- CONFIG_RETRY_MAX seconds, the sender should consider the receiver to
+- have gone down. The UA should use a different DA. If no such DA
+- responds, DA discovery should be used to find a new DA. If no DA is
+- available, multicast requests to SAs are used.
+-
+-12.4. DA Scope Configuration
+-
+- By default, DAs are configured with the "DEFAULT" scope.
+- Administrators may add other configured scopes, in order to support
+- UAs and SAs in non default scopes. The default configuration MUST
+- NOT be removed from the DA unless:
+-
+- - There are other DAs which support the "DEFAULT" scope, or
+-
+- - All UAs and SAs have been configured with non-default scopes.
+-
+- Non-default scopes can be phased-in as the SLP deployment grows.
+- Default scopes should be phased out only when the non-default scopes
+- are universally configured.
+-
+- If a DA and SA are coresident on a host (quite possibly implemented
+- by the same process), configuration of the host is considerably
+- simplified if the SA supports only scopes also supported by the DA.
+- That is, the SA SHOULD NOT advertise services in any scopes which are
+- not supported by the coresident DA. This means that incoming requests
+- can be answered by a single data store; the SA and DA registrations
+- do not need to be kept separately.
+-
+-12.5. DAs and Authentication Blocks
+-
+- DAs are not configured to sign service registrations or attribute
+- lists. They simply cache services registered by Service Agents. DAs
+- MUST NOT accept registrations including authentication blocks for SLP
+- SPIs which it is not configured with, see Section 8.5.
+-
+- A DA protects registrations which are made with authentication blocks
+- using SLP SPIs it is configured to use. If a service S is
+- registered, a subsequent registration (which will replace the
+- adertisement) or a deregistration (which will remove it) MUST include
+- an Authentication Block with the corresponding SLP SPI, see Section
+- 8.3 and Section 10.6.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 41]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- Example:
+-
+- A DA is configured to be able to verify Authentication Blocks with
+- SLP SPIs "X,Y", that is X and Y.
+-
+- An SA registers a service with an Authentication Block with SPI "Z".
+- The DA stores the registration, but discards the Authentication
+- Block. If a UA requests a service with an SLP SPI string "Z", the DA
+- will respond with an AUTHENTICATION_UNKNOWN error.
+-
+- An SA registers a service S with Authentication Blocks including SLP
+- SPIs "X" and "Y". If a UA requests a service with an SLP SPI string
+- "X" the DA will be able to return S (if the service type, language,
+- scope and predicate of the SrvRqst match S) The DA will also return
+- the Authentication Block with SLP SPI set to "X". If the DA receives
+- a subsequent SrvDeReg for S (which will remove the advertisement) or
+- a subsequent SrvReg for S (which will replace it), the message must
+- include two URL Authentication Blocks, one each for SPIs "X" and "Y".
+- If either of these were absent, the DA would return an
+- AUTHENTICATION_ABSENT error.
+-
+-13. Protocol Timing Defaults
+-
+-Interval name Section Default Value Meaning
+-------------------- ------- ------------- ------------------------
+-CONFIG_MC_MAX 6.3 15 seconds Max time to wait for a
+- complete multicast query
+- response (all values.)
+-CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA
+- discovery on reboot.
+-CONFIG_RETRY 12.3 2 seconds Wait interval before
+- initial retransmission
+- of multicast or unicast
+- requests.
+-CONFIG_RETRY_MAX 12.3 15 seconds Give up on unicast
+- request retransmission.
+-CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs
+- passively detect new DAs.
+-CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait
+- before repeating Active
+- DA discovery.
+-CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services
+- on passive DA discovery.
+-CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services
+- on active DA discovery.
+-CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle
+- connections.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 42]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-14. Optional Configuration
+-
+- Broadcast Only
+- Any SLP agent SHOULD be configurable to use broadcast
+- only. See Sections 6.1 and 12.2.
+-
+- Predefined DA
+- A UA or SA SHOULD be configurable to use a predefined DA.
+-
+- No DA Discovery
+- The UA or SA SHOULD be configurable to ONLY use
+- predefined and DHCP-configured DAs and perform no active
+- or passive DA discovery.
+-
+- Multicast TTL
+- The default multicast TTL is 255. Agents SHOULD be
+- configurable to use other values. A lower value will
+- focus the multicast convergence algorithm on smaller
+- subnetworks, decreasing the number of responses and
+- increases the performance of service location. This
+- may result in UAs obtaining different results for the
+- identical requests depending on where they are connected
+- to the network.
+-
+- Timing Values
+- Time values other than the default MAY be configurable.
+- See Section 13.
+-
+- Scopes
+- A UA MAY be configurable to support User Selectable
+- scopes by omitting all predefined scopes. See
+- Section 11.2. A UA or SA MUST be configurable to use
+- specific scopes by default. Additionally, a UA or SA
+- MUST be configurable to use specific scopes for requests
+- for and registrations of specific service types. The
+- scope or scopes of a DA MUST be configurable. The
+- default value for a DA is to have the scope "DEFAULT" if
+- not otherwise configured.
+-
+- DHCP Configuration
+- DHCP options 78 and 79 may be used to configure SLP. If
+- DA locations are configured using DHCP, these SHOULD
+- be used in preference to DAs discovered actively or
+- passively. One or more of the scopes configured using
+- DHCP MUST be used in requests. The entire configured
+- <scope-list> MUST be used in registration and DA
+- configuration messages.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 43]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- Service Template
+- UAs and SAs MAY be configured by using Service Templates.
+- Besides simplifying the specification of attribute
+- values, this also allows them to enforce the inclusion
+- of 'required' attributes in SrvRqst, SrvReg and SrvDeReg
+- messages. DAs MAY be configured with templates to
+- allow them to WARN UAs and SAs in these cases. See
+- Section 10.4.
+-
+- SLP SPI for service discovery
+- Agents SHOULD be configurable to support SLP SPIs using
+- the following parameters: BSD=2 (DSA with SHA-1) and
+- a public key identified by the SLP SPI String. In
+- the future, when a Public Key Infrastructure exists,
+- SLP Agents may be able to obtain public keys and
+- cryptographic parameters corresponding to the names used
+- in SLP SPI Strings.
+-
+- Note that if the SLP SPI string chosen is identical
+- to a scope string, it is effectively the same as a
+- Protected Scope in SLPv1. Namely, every SA advertising
+- in that scope would be configured with the same Private
+- Key. Every DA and UA of that scope would be configured
+- with the appropriate Public Key to verify signatures
+- produced by those SAs. This is a convenient way to
+- configure SLP deployments in the absence of a Public Key
+- Infrastructure. Currently, it would be too difficult to
+- manage the keying of UAs and DAs if each SA had its own
+- key.
+-
+- SLP SPI for Directory Agent discovery
+- Agents SHOULD be configurable to support SLP SPIs as
+- above, to be used when discovering DAs. This SPI SHOULD
+- be sent in SrvRqsts to discover DAs and be used to verify
+- multicast DAAdvert messages.
+-
+- SA and DA Private Key
+- SAs and DAs which can generate digital signatures require
+- a Private Key and a corresponding SLP SPI indentifier
+- to include in the Authentication Block. The SLP SPI
+- identifies the Public Key to use to verify the digital
+- signature in the Authentication Block.
+-
+-15. IANA Considerations
+-
+- SLP includes four sets of identifiers which may be registered with
+- IANA. The policies for these registrations (See [18]) are noted in
+- each case.
+-
+-
+-
+-Guttman, et al. Standards Track [Page 44]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- The Block Structure Descriptor (BSD) identifies the format of the
+- Authenticator which follows. BSDs 0x8000-0x8FFF are for Private Use.
+-
+- Further Block Structured Descriptor (BSD) values, from the range
+- 0x0003-0x7FFF may be standardized in the future by submitting a
+- document which describes:
+-
+- - The data format of the Structured Authenticator block.
+-
+- - Which cryptographic algorithm to use (including a reference
+- to a technical specification of the algorithm.)
+-
+- - The format of any keying material required for
+- preconfiguring UAs, DAs and SAs. Also include any
+- considerations regarding key distribution.
+-
+- - Security considerations to alert others to the strengths and
+- weaknesses of the approach.
+-
+- The IANA will assign Cryptographic BSD numbers on the basis of IETF
+- Consenus.
+-
+- New function-IDs, in the range 12-255, may be standardized by the
+- method of IETF Consensus.
+-
+- New SLP Extensions with types in the range 2-65535 may be registered
+- following review by a Designated Expert.
+-
+- New error numbers in the range 15-65535 are assigned on the basis of
+- a Standards Action.
+-
+- Protocol elements used with Service Location Protocol may also
+- require IANA registration actions. SLP is used in conjunction with
+- "service:" URLs and Service Templates [13]. These are standardized
+- by review of a Designated Expert and a mailing list (See [13].)
+-
+-16. Internationalization Considerations
+-
+- SLP messages support the use of multiple languages by providing a
+- Language Tag field in the common message header (see Section 8).
+-
+- Services MAY be registered in multiple languages. This provides
+- attributes so that users with different language skills may select
+- services interactively.
+-
+- Attribute tags are not translated. Attribute values may be
+- translated unless the Service Template [13] defines the attribute
+- values to be 'literal'.
+-
+-
+-
+-Guttman, et al. Standards Track [Page 45]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- A service which is registered in multiple languages may be queried in
+- multiple languages. The language of the SrvRqst or AttrRqst is used
+- to satisfy the request. If the requested language is not supported,
+- a LANGUAGE_NOT_SUPPORTED error is returned. SrvRply and AttrRply
+- messages are always in the same language of the request.
+-
+- A DA or SA MAY be configured with translations of Service Templates
+- [13] for the same service type. This will allow the DA or SA to
+- translate a request (say in Italian) to the language of the service
+- advertisement (say in English) and then translate the reply back to
+- Italian. Similarly, a UA MAY use templates to translate outgoing
+- requests and incoming replies.
+-
+- The dialect field in the Language Tag MAY be used: Requests which
+- can be fulfilled by matching a language and dialect will be preferred
+- to those which match only the language portion. Otherwise, dialects
+- have no effect on matching requests.
+-
+-17. Security Considerations
+-
+- SLP provides for authentication of service URLs and service
+- attributes. This provides UAs and DAs with knowledge of the
+- integrity of service URLs and attributes included in SLP messages.
+- The only systems which can generate digital signatures are those
+- which have been configured by administrators in advance. Agents
+- which verify signed data may assume it is 'trustworthy' inasmuch as
+- administrators have ensured the cryptographic keying of SAs and DAs
+- reflects 'trustworthiness.'
+-
+- Service Location does not provide confidentiality. Because the
+- objective of this protocol is to advertise services to a community of
+- users, confidentiality might not generally be needed when this
+- protocol is used in non-sensitive environments. Specialized schemes
+- might be able to provide confidentiality, if needed in the future.
+- Sites requiring confidentiality should implement the IP Encapsulating
+- Security Payload (ESP) [3] to provide confidentiality for Service
+- Location messages.
+-
+- If Agents are not configured to generate Authentication Blocks and
+- Agents are not configured to verify them, an adversary might easily
+- use this protocol to advertise services on servers controlled by the
+- adversary and thereby gain access to users' private information.
+- Further, an adversary using this protocol will find it much easier to
+- engage in selective denial of service attacks. Sites that are in
+- potentially hostile environments (e.g., are directly connected to the
+- Internet) should consider the advantages of distributing keys
+- associated with SLP SPIs prior to deploying the sensitive directory
+- agents or service agents.
+-
+-
+-
+-Guttman, et al. Standards Track [Page 46]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- SLP is useful as a bootstrap protocol. It may be used in
+- environments in which no preconfiguration is possible. In such
+- situations, a certain amount of "blind faith" is required: Without
+- any prior configuration it is impossible to use any of the security
+- mechanisms described above. SLP will make use of the mechanisms
+- provided by the Security Area of the IETF for key distribution as
+- they become available. At this point it would only be possible to
+- gain the benefits associated with the use of Authentication Blocks if
+- cryptographic information and SLP SPIs can be preconfigured with the
+- end systems before they use SLP.
+-
+- SLPv2 enables a number of security policies with the mechanisms it
+- includes. A SLPv2 UA could, for instance, reject any SLP message
+- which did not carry an authentication block which it could verify.
+- This is not the only policy which is possible to implement.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 47]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-A. Appendix: Changes to the Service Location Protocol from v1 to v2
+-
+- SLP version 2 (SLPv2) corrects race conditions present in SLPv1 [22].
+- In addition, authentication has been reworked to provide more
+- flexibility and protection (especially for DA Advertisements). SLPv2
+- also changes the formats and definition of many flags and values and
+- reduces the number of 'required features.' SLPv2 clarifies and
+- changes the use of 'Scopes', eliminating support for 'unscoped
+- directory agents' and 'unscoped requests'. SLPv2 uses LDAPv3
+- compatible string encodings of attributes and search filters. Other
+- changes (such as Language and Character set handling) adopt practices
+- recommended by the Internet Engineering Steering Group.
+-
+- Effort has been made to make SLPv2 operate the same whether DAs are
+- present or not. For this reason, a new message (the SAAdvert) has
+- been added. This allows UAs to discover scope information in the
+- absence of administrative configuration and DAs. This was not
+- possible in SLPv1.
+-
+- SLPv2 is incompatible in some respects with SLPv1. If a DA which
+- supports both SLPv1 and SLPv2 with the same scope is present,
+- services advertised by SAs using either version of the protocol will
+- be available to both SLPv1 and SLPv2 UAs. SLPv1 DAs SHOULD be phased
+- out and replace with SLPv2 DAs which support both versions of the
+- protocol.
+-
+- SLPv1 allows services to be advertised and requested without a scope.
+- Further, DAs can be configured without a scope. This is incompatible
+- with SLPv2 and presents scalability problems. To facilitate this
+- forward migration, SLPv1 agents MUST use scopes for all registrations
+- and requests. SLPv1 DAs MUST be configured with a scope list. This
+- constitutes a revision of RFC 2165 [22].
+-
+-B. Appendix: Service Discovery by Type: Minimal SLPv2 Features
+-
+- Service Agents may advertise services without attributes. This will
+- enable only discovery of services by type. Service types discovered
+- this way will have a Service Template [13] defined which specifies
+- explicitly that no attributes are associated with the service
+- advertisement. Service types associated with Service Templates which
+- specify attributes MUST NOT be advertised by SAs which do not support
+- attributes.
+-
+- While discovery of service by service type is a subset of the
+- features possible using SLPv2 this form of discovery is consistent
+- with the current generation of products that allow simple browsing of
+- all services in a 'zone' or 'workgroup' by type. In some cases,
+- attribute discovery, security and feature negotiation is handled by
+-
+-
+-
+-Guttman, et al. Standards Track [Page 48]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- application layer protocols - all that is required is the basic
+- discovery of services that support a certain service.
+-
+- UAs requesting only service of that service type would only need to
+- support service type and scope fields of the Service Request. UAs
+- would still perform DA discovery and unicast SLPv2 SrvRqst messages
+- to DAs in their scope once they were discovered instead of
+- multicasting them.
+-
+- SAs would also perform DA discovery and use a SLPv2 SrvReg to
+- register all their advertised services with SLPv2 DAs in their scope.
+- These advertisements would needless to say contain no attribute
+- string.
+-
+- These minimal SAs could ignore the Language Tag in requests since
+- SrvRqst messages would contain no attributes, hence no strings would
+- be internationalized. Further, any non-null predicate string would
+- fail to match a service advertisement with no attributes, so these
+- SAs would not have to parse and interpret search filters. Overflow
+- will never occur in SrvRqst, SrvRply or SrvReg messages so TCP
+- message handling would not have to be implemented. Finally, all
+- AttrRqst messages could be dropped by the SA, since no attributes are
+- supported.
+-
+-C. Appendix: DAAdverts with arbitrary URLs
+-
+- Using Active DA Discovery, a SrvRqst with its service type field set
+- to "service:directory-agent". DAs will respond with a DAAdvert
+- containing a URL with the "service:directory-agent:" scheme. This is
+- the same DAAdvert that such a DA would multicast in unsolicited DA
+- advertisements.
+-
+- A UA or SA which receives an unsolicited DAAdvert MUST examine the
+- URL to determine if it has a recognized scheme. If the UA or SA does
+- not recognize the DAAdvert's URL scheme, the DAAdvert is silently
+- discarded. This document specifies only how to use URLs with the
+- "service:directory-agent:" scheme.
+-
+- This provides the possibility for forward compatibility with future
+- versions of SLP and enables other services to advertise their ability
+- to serve as a clearinghouse for service location information.
+-
+- For example, if LDAPv3 [15] is used for service registration and
+- discovery by a set of end systems, they could interpret a LDAP URL
+- [16] to passively discover the LDAP server to use for this purpose.
+- This document does not specify how this is done: SLPv2 agents
+- without further support would simply discard this DAAdvert.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 49]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-D. Appendix: SLP Protocol Extensions
+-
+-D.1. Required Attribute Missing Option
+-
+- 0 1 2 3
+- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Extension Type = 0x0001 | Extension Length |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- | Template IDVer Length | Template IDVer String \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+- |Required Attr <tag-list> Length| Required Attr <tag-list> \
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-
+- Required attributes and the format of the IDVer string are defined by
+- [13].
+-
+- If a SA or DA receives a SrvRqst or a SrvReg which fails to include a
+- Required Attribute for the requested Service Type (according to the
+- Service Template), it MAY return the Required Attribute Extension in
+- addition to the reply corresponding to the message. The sender
+- SHOULD reissue the message with a search filter including the
+- attributes listed in the returned Required Attribute Extension.
+- Similarly, the Required Attribute Extension may be returned in
+- response to a SrvDereg message that contains a required attribute
+- tag.
+-
+- The Template IDVer String is the name and version number string of
+- the Service Template which defines the given attribute as required.
+- It SHOULD be included, but can be omitted if a given SA or DA has
+- been individually configured to have 'required attributes.'
+-
+- The Required Attribute <tag-list> MUST NOT include wild cards.
+-
+-E. Acknowledgments
+-
+- This document incorporates ideas from work on several discovery
+- protocols, including RDP by Perkins and Harjono, and PDS by Michael
+- Day. We are grateful for contributions by Ye Gu and Peter Ford.
+- John Veizades was instrumental in the standardization of the Service
+- Location Protocol. Implementors at Novell, Axis Communications and
+- Sun Microsystems have contributed significantly to make this a much
+- clearer and more consistent document.
+-
+-
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 50]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-F. References
+-
+- [1] Port numbers, July 1997.
+- ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.
+-
+- [2] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
+- DAM 4 to ISO/IEC 9594-2, December 1996.
+-
+- [3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
+- DAM 2 to ISO/IEC 9594-6, December 1996.
+-
+- [4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
+- DAM 1 to ISO/IEC 9594-7, December 1996.
+-
+- [5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
+- DAM 1 to ISO/IEC 9594-8, December 1996.
+-
+- [6] Unicode Technical Report #8. The Unicode Standard, version 2.1.
+- Technical report, The Unicode Consortium, 1998.
+-
+- [7] Alvestrand, H., "Tags for the Identification of Languages",
+- RFC 1766, March 1995.
+-
+- [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+- Resource Identifiers (URI): Generic Syntax", RFC 2396,
+- August 1998.
+-
+- [9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
+- Levels", BCP 14, RFC 2119, March 1997.
+-
+- [10] CCITT. The Directory Authentication Framework. Recommendation
+- X.509, 1988.
+-
+- [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+- Specifications: ABNF", RFC 2234, November 1997.
+-
+- [12] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk.
+- Addison-Wesley, 1990.
+-
+- [13] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
+- service: Schemes", RFC 2609, June 1999.
+-
+- [14] Howes, T., "The String Representation of LDAP Search Filters",
+- RFC 2254, December 1997.
+-
+- [15] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+- Access Protocol (v3)", RFC 2251, December 1997.
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 51]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+- [16] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+- December 1997.
+-
+- [17] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
+- July 1998.
+-
+- [18] Narten, T. and H. Alvestrand, "Guidelines for Writing
+- an IANA Considerations Section in RFCs, BCP 26, RFC 2434,
+- October 1998.
+-
+- [19] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0,
+- Document Version 1.09, November 1989.
+-
+- [20] National Institute of Standards and Technology. Digital
+- signature standard. Technical Report NIST FIPS PUB 186, U.S.
+- Department of Commerce, May 1994.
+-
+- [21] Perkins, C. and E. Guttman, "DHCP Options for Service Location
+- Protocol", RFC 2610, June 1999.
+-
+- [22] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
+- Location Protocol", RFC 2165, July 1997.
+-
+- [23] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+- RFC 2279, January 1998.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 52]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-G. Authors' Addresses
+-
+- Erik Guttman
+- Sun Microsystems
+- Bahnstr. 2
+- 74915 Waibstadt
+- Germany
+-
+- Phone: +49 7263 911 701
+- EMail: Erik.Guttman at sun.com
+-
+-
+- Charles Perkins
+- Sun Microsystems
+- 901 San Antonio Road
+- Palo Alto, CA 94040
+- USA
+-
+- Phone: +1 650 786 6464
+- EMail: cperkins at sun.com
+-
+-
+- John Veizades
+- @Home Network
+- 425 Broadway
+- Redwood City, CA 94043
+- USA
+-
+- Phone: +1 650 569 5243
+- EMail: veizades at home.net
+-
+-
+- Michael Day
+- Vinca Corporation.
+- 1201 North 800 East
+- Orem, Utah 84097 USA
+-
+- Phone: +1 801 376-5083
+- EMail: mday at vinca.com
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 53]
+-
+-RFC 2608 Service Location Protocol, Version 2 June 1999
+-
+-
+-H. Full Copyright Statement
+-
+- Copyright (C) The Internet Society (1999). All Rights Reserved.
+-
+- This document and translations of it may be copied and furnished to
+- others, and derivative works that comment on or otherwise explain it
+- or assist in its implementation may be prepared, copied, published
+- and distributed, in whole or in part, without restriction of any
+- kind, provided that the above copyright notice and this paragraph are
+- included on all such copies and derivative works. However, this
+- document itself may not be modified in any way, such as by removing
+- the copyright notice or references to the Internet Society or other
+- Internet organizations, except as needed for the purpose of
+- developing Internet standards in which case the procedures for
+- copyrights defined in the Internet Standards process must be
+- followed, or as required to translate it into languages other than
+- English.
+-
+- The limited permissions granted above are perpetual and will not be
+- revoked by the Internet Society or its successors or assigns.
+-
+- This document and the information contained herein is provided on an
+- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+-
+-Acknowledgement
+-
+- Funding for the RFC Editor function is currently provided by the
+- Internet Society.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Guttman, et al. Standards Track [Page 54]
+-
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc3279.txt open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc3279.txt
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc3279.txt 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc3279.txt 1969-12-31 18:00:00.000000000 -0600
+@@ -1,1515 +0,0 @@
+-
+-
+-
+-
+-
+-
+-Network Working Group W. Polk
+-Request for Comments: 3279 NIST
+-Obsoletes: 2528 R. Housley
+-Category: Standards Track RSA Laboratories
+- L. Bassham
+- NIST
+- April 2002
+-
+- Algorithms and Identifiers for the
+- Internet X.509 Public Key Infrastructure
+- Certificate and Certificate Revocation List (CRL) Profile
+-
+-Status of this Memo
+-
+- This document specifies an Internet standards track protocol for the
+- Internet community, and requests discussion and suggestions for
+- improvements. Please refer to the current edition of the "Internet
+- Official Protocol Standards" (STD 1) for the standardization state
+- and status of this protocol. Distribution of this memo is unlimited.
+-
+-Copyright Notice
+-
+- Copyright (C) The Internet Society (2002). All Rights Reserved.
+-
+-Abstract
+-
+- This document specifies algorithm identifiers and ASN.1 encoding
+- formats for digital signatures and subject public keys used in the
+- Internet X.509 Public Key Infrastructure (PKI). Digital signatures
+- are used to sign certificates and certificate revocation list (CRLs).
+- Certificates include the public key of the named subject.
+-
+-Table of Contents
+-
+- 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2
+- 2 Algorithm Support . . . . . . . . . . . . . . . . . . . . 3
+- 2.1 One-Way Hash Functions . . . . . . . . . . . . . . . . 3
+- 2.1.1 MD2 One-Way Hash Functions . . . . . . . . . . . . . 3
+- 2.1.2 MD5 One-Way Hash Functions . . . . . . . . . . . . . 4
+- 2.1.3 SHA-1 One-Way Hash Functions . . . . . . . . . . . . 4
+- 2.2 Signature Algorithms . . . . . . . . . . . . . . . . . 4
+- 2.2.1 RSA Signature Algorithm . . . . . . . . . . . . . . . 5
+- 2.2.2 DSA Signature Algorithm . . . . . . . . . . . . . . . 6
+- 2.2.3 Elliptic Curve Digital Signature Algorithm . . . . . 7
+- 2.3 Subject Public Key Algorithms . . . . . . . . . . . . . 7
+- 2.3.1 RSA Keys . . . . . . . . . . . . . . . . . . . . . . 8
+- 2.3.2 DSA Signature Keys . . . . . . . . . . . . . . . . . 9
+- 2.3.3 Diffie-Hellman Key Exchange Keys . . . . . . . . . . 10
+-
+-
+-
+-Polk, et al. Standards Track [Page 1]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- 2.3.4 KEA Public Keys . . . . . . . . . . . . . . . . . . . 11
+- 2.3.5 ECDSA and ECDH Public Keys . . . . . . . . . . . . . 13
+- 3 ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 18
+- 4 References . . . . . . . . . . . . . . . . . . . . . . . 24
+- 5 Security Considerations . . . . . . . . . . . . . . . . . 25
+- 6 Intellectual Property Rights . . . . . . . . . . . . . . 26
+- 7 Author Addresses . . . . . . . . . . . . . . . . . . . . 26
+- 8 Full Copyright Statement . . . . . . . . . . . . . . . . 27
+-
+-1 Introduction
+-
+- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+- document are to be interpreted as described in [RFC 2119].
+-
+- This document specifies algorithm identifiers and ASN.1 [X.660]
+- encoding formats for digital signatures and subject public keys used
+- in the Internet X.509 Public Key Infrastructure (PKI). This
+- specification supplements [RFC 3280], "Internet X.509 Public Key
+- Infrastructure: Certificate and Certificate Revocation List (CRL)
+- Profile." Implementations of this specification MUST also conform to
+- RFC 3280.
+-
+- This specification defines the contents of the signatureAlgorithm,
+- signatureValue, signature, and subjectPublicKeyInfo fields within
+- Internet X.509 certificates and CRLs.
+-
+- This document identifies one-way hash functions for use in the
+- generation of digital signatures. These algorithms are used in
+- conjunction with digital signature algorithms.
+-
+- This specification describes the encoding of digital signatures
+- generated with the following cryptographic algorithms:
+-
+- * Rivest-Shamir-Adelman (RSA);
+- * Digital Signature Algorithm (DSA); and
+- * Elliptic Curve Digital Signature Algorithm (ECDSA).
+-
+- This document specifies the contents of the subjectPublicKeyInfo
+- field in Internet X.509 certificates. For each algorithm, the
+- appropriate alternatives for the the keyUsage extension are provided.
+- This specification describes encoding formats for public keys used
+- with the following cryptographic algorithms:
+-
+- * Rivest-Shamir-Adelman (RSA);
+- * Digital Signature Algorithm (DSA);
+- * Diffie-Hellman (DH);
+- * Key Encryption Algorithm (KEA);
+-
+-
+-
+-Polk, et al. Standards Track [Page 2]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- * Elliptic Curve Digital Signature Algorithm (ECDSA); and
+- * Elliptic Curve Diffie-Hellman (ECDH).
+-
+-2 Algorithm Support
+-
+- This section describes cryptographic algorithms which may be used
+- with the Internet X.509 certificate and CRL profile [RFC 3280]. This
+- section describes one-way hash functions and digital signature
+- algorithms which may be used to sign certificates and CRLs, and
+- identifies object identifiers (OIDs) for public keys contained in a
+- certificate.
+-
+- Conforming CAs and applications MUST, at a minimum, support digital
+- signatures and public keys for one of the specified algorithms. When
+- using any of the algorithms identified in this specification,
+- conforming CAs and applications MUST support them as described.
+-
+-2.1 One-way Hash Functions
+-
+- This section identifies one-way hash functions for use in the
+- Internet X.509 PKI. One-way hash functions are also called message
+- digest algorithms. SHA-1 is the preferred one-way hash function for
+- the Internet X.509 PKI. However, PEM uses MD2 for certificates [RFC
+- 1422] [RFC 1423] and MD5 is used in other legacy applications. For
+- these reasons, MD2 and MD5 are included in this profile. The data
+- that is hashed for certificate and CRL signing is fully described in
+- [RFC 3280].
+-
+-2.1.1 MD2 One-way Hash Function
+-
+- MD2 was developed by Ron Rivest for RSA Security. RSA Security has
+- recently placed the MD2 algorithm in the public domain. Previously,
+- RSA Data Security had granted license for use of MD2 for non-
+- commercial Internet Privacy-Enhanced Mail (PEM). MD2 may continue to
+- be used with PEM certificates, but SHA-1 is preferred. MD2 produces
+- a 128-bit "hash" of the input. MD2 is fully described in [RFC 1319].
+-
+- At the Selected Areas in Cryptography '95 conference in May 1995,
+- Rogier and Chauvaud presented an attack on MD2 that can nearly find
+- collisions [RC95]. Collisions occur when one can find two different
+- messages that generate the same message digest. A checksum operation
+- in MD2 is the only remaining obstacle to the success of the attack.
+- For this reason, the use of MD2 for new applications is discouraged.
+- It is still reasonable to use MD2 to verify existing signatures, as
+- the ability to find collisions in MD2 does not enable an attacker to
+- find new messages having a previously computed hash value.
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 3]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+-2.1.2 MD5 One-way Hash Function
+-
+- MD5 was developed by Ron Rivest for RSA Security. RSA Security has
+- placed the MD5 algorithm in the public domain. MD5 produces a 128-
+- bit "hash" of the input. MD5 is fully described in [RFC 1321].
+-
+- Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
+- but there are no other known cryptanalytic results. The use of MD5
+- for new applications is discouraged. It is still reasonable to use
+- MD5 to verify existing signatures.
+-
+-2.1.3 SHA-1 One-way Hash Function
+-
+- SHA-1 was developed by the U.S. Government. SHA-1 produces a 160-bit
+- "hash" of the input. SHA-1 is fully described in [FIPS 180-1]. RFC
+- 3174 [RFC 3174] also describes SHA-1, and it provides an
+- implementation of the algorithm.
+-
+-2.2 Signature Algorithms
+-
+- Certificates and CRLs conforming to [RFC 3280] may be signed with any
+- public key signature algorithm. The certificate or CRL indicates the
+- algorithm through an algorithm identifier which appears in the
+- signatureAlgorithm field within the Certificate or CertificateList.
+- This algorithm identifier is an OID and has optionally associated
+- parameters. This section identifies algorithm identifiers and
+- parameters that MUST be used in the signatureAlgorithm field in a
+- Certificate or CertificateList.
+-
+- Signature algorithms are always used in conjunction with a one-way
+- hash function.
+-
+- This section identifies OIDS for RSA, DSA, and ECDSA. The contents
+- of the parameters component for each algorithm vary; details are
+- provided for each algorithm.
+-
+- The data to be signed (e.g., the one-way hash function output value)
+- is formatted for the signature algorithm to be used. Then, a private
+- key operation (e.g., RSA encryption) is performed to generate the
+- signature value. This signature value is then ASN.1 encoded as a BIT
+- STRING and included in the Certificate or CertificateList in the
+- signature field.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 4]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+-2.2.1 RSA Signature Algorithm
+-
+- The RSA algorithm is named for its inventors: Rivest, Shamir, and
+- Adleman. This profile includes three signature algorithms based on
+- the RSA asymmetric encryption algorithm. The signature algorithms
+- combine RSA with either the MD2, MD5, or the SHA-1 one-way hash
+- functions.
+-
+- The signature algorithm with SHA-1 and the RSA encryption algorithm
+- is implemented using the padding and encoding conventions described
+- in PKCS #1 [RFC 2313]. The message digest is computed using the
+- SHA-1 hash algorithm.
+-
+- The RSA signature algorithm, as specified in PKCS #1 [RFC 2313]
+- includes a data encoding step. In this step, the message digest and
+- the OID for the one-way hash function used to compute the digest are
+- combined. When performing the data encoding step, the md2, md5, and
+- id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way
+- hash functions, respectively:
+-
+- md2 OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) US(840) rsadsi(113549)
+- digestAlgorithm(2) 2 }
+-
+- md5 OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) US(840) rsadsi(113549)
+- digestAlgorithm(2) 5 }
+-
+- id-sha1 OBJECT IDENTIFIER ::= {
+- iso(1) identified-organization(3) oiw(14) secsig(3)
+- algorithms(2) 26 }
+-
+- The signature algorithm with MD2 and the RSA encryption algorithm is
+- defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the
+- ASN.1 OID used to identify this signature algorithm is:
+-
+- md2WithRSAEncryption OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+- pkcs-1(1) 2 }
+-
+- The signature algorithm with MD5 and the RSA encryption algorithm is
+- defined in PKCS #1 [RFC 2313]. As defined in PKCS #1 [RFC 2313], the
+- ASN.1 OID used to identify this signature algorithm is:
+-
+- md5WithRSAEncryption OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+- pkcs-1(1) 4 }
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 5]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- The ASN.1 object identifier used to identify this signature algorithm
+- is:
+-
+- sha-1WithRSAEncryption OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+- pkcs-1(1) 5 }
+-
+- When any of these three OIDs appears within the ASN.1 type
+- AlgorithmIdentifier, the parameters component of that type SHALL be
+- the ASN.1 type NULL.
+-
+- The RSA signature generation process and the encoding of the result
+- is described in detail in PKCS #1 [RFC 2313].
+-
+-2.2.2 DSA Signature Algorithm
+-
+- The Digital Signature Algorithm (DSA) is defined in the Digital
+- Signature Standard (DSS). DSA was developed by the U.S. Government,
+- and DSA is used in conjunction with the SHA-1 one-way hash function.
+- DSA is fully described in [FIPS 186]. The ASN.1 OID used to identify
+- this signature algorithm is:
+-
+- id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) x9-57 (10040)
+- x9cm(4) 3 }
+-
+- When the id-dsa-with-sha1 algorithm identifier appears as the
+- algorithm field in an AlgorithmIdentifier, the encoding SHALL omit
+- the parameters field. That is, the AlgorithmIdentifier SHALL be a
+- SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.
+-
+- The DSA parameters in the subjectPublicKeyInfo field of the
+- certificate of the issuer SHALL apply to the verification of the
+- signature.
+-
+- When signing, the DSA algorithm generates two values. These values
+- are commonly referred to as r and s. To easily transfer these two
+- values as one signature, they SHALL be ASN.1 encoded using the
+- following ASN.1 structure:
+-
+- Dss-Sig-Value ::= SEQUENCE {
+- r INTEGER,
+- s INTEGER }
+-
+-
+-
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 6]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+-2.2.3 ECDSA Signature Algorithm
+-
+- The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
+- [X9.62]. The ASN.1 object identifiers used to identify ECDSA are
+- defined in the following arc:
+-
+- ansi-X9-62 OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) 10045 }
+-
+- id-ecSigType OBJECT IDENTIFIER ::= {
+- ansi-X9-62 signatures(4) }
+-
+- ECDSA is used in conjunction with the SHA-1 one-way hash function.
+- The ASN.1 object identifier used to identify ECDSA with SHA-1 is:
+-
+- ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
+- id-ecSigType 1 }
+-
+- When the ecdsa-with-SHA1 algorithm identifier appears as the
+- algorithm field in an AlgorithmIdentifier, the encoding MUST omit the
+- parameters field. That is, the AlgorithmIdentifier SHALL be a
+- SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1.
+-
+- The elliptic curve parameters in the subjectPublicKeyInfo field of
+- the certificate of the issuer SHALL apply to the verification of the
+- signature.
+-
+- When signing, the ECDSA algorithm generates two values. These values
+- are commonly referred to as r and s. To easily transfer these two
+- values as one signature, they MUST be ASN.1 encoded using the
+- following ASN.1 structure:
+-
+- Ecdsa-Sig-Value ::= SEQUENCE {
+- r INTEGER,
+- s INTEGER }
+-
+-2.3 Subject Public Key Algorithms
+-
+- Certificates conforming to [RFC 3280] may convey a public key for any
+- public key algorithm. The certificate indicates the algorithm
+- through an algorithm identifier. This algorithm identifier is an OID
+- and optionally associated parameters.
+-
+- This section identifies preferred OIDs and parameters for the RSA,
+- DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms. Conforming CAs
+- MUST use the identified OIDs when issuing certificates containing
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 7]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- public keys for these algorithms. Conforming applications supporting
+- any of these algorithms MUST, at a minimum, recognize the OID
+- identified in this section.
+-
+-2.3.1 RSA Keys
+-
+- The OID rsaEncryption identifies RSA public keys.
+-
+- pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
+- rsadsi(113549) pkcs(1) 1 }
+-
+- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}
+-
+- The rsaEncryption OID is intended to be used in the algorithm field
+- of a value of type AlgorithmIdentifier. The parameters field MUST
+- have ASN.1 type NULL for this algorithm identifier.
+-
+- The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey:
+-
+- RSAPublicKey ::= SEQUENCE {
+- modulus INTEGER, -- n
+- publicExponent INTEGER } -- e
+-
+- where modulus is the modulus n, and publicExponent is the public
+- exponent e. The DER encoded RSAPublicKey is the value of the BIT
+- STRING subjectPublicKey.
+-
+- This OID is used in public key certificates for both RSA signature
+- keys and RSA encryption keys. The intended application for the key
+- MAY be indicated in the key usage field (see [RFC 3280]). The use of
+- a single key for both signature and encryption purposes is not
+- recommended, but is not forbidden.
+-
+- If the keyUsage extension is present in an end entity certificate
+- which conveys an RSA public key, any combination of the following
+- values MAY be present:
+-
+- digitalSignature;
+- nonRepudiation;
+- keyEncipherment; and
+- dataEncipherment.
+-
+- If the keyUsage extension is present in a CA or CRL issuer
+- certificate which conveys an RSA public key, any combination of the
+- following values MAY be present:
+-
+- digitalSignature;
+- nonRepudiation;
+-
+-
+-
+-Polk, et al. Standards Track [Page 8]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- keyEncipherment;
+- dataEncipherment;
+- keyCertSign; and
+- cRLSign.
+-
+- However, this specification RECOMMENDS that if keyCertSign or cRLSign
+- is present, both keyEncipherment and dataEncipherment SHOULD NOT be
+- present.
+-
+-2.3.2 DSA Signature Keys
+-
+- The Digital Signature Algorithm (DSA) is defined in the Digital
+- Signature Standard (DSS) [FIPS 186]. The DSA OID supported by this
+- profile is:
+-
+- id-dsa OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
+-
+- The id-dsa algorithm syntax includes optional domain parameters.
+- These parameters are commonly referred to as p, q, and g. When
+- omitted, the parameters component MUST be omitted entirely. That is,
+- the AlgorithmIdentifier MUST be a SEQUENCE of one component: the
+- OBJECT IDENTIFIER id-dsa.
+-
+- If the DSA domain parameters are present in the subjectPublicKeyInfo
+- AlgorithmIdentifier, the parameters are included using the following
+- ASN.1 structure:
+-
+- Dss-Parms ::= SEQUENCE {
+- p INTEGER,
+- q INTEGER,
+- g INTEGER }
+-
+- The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
+- within a certificate where the parameters may be used. If the DSA
+- algorithm parameters are omitted from the subjectPublicKeyInfo
+- AlgorithmIdentifier and the CA signed the subject certificate using
+- DSA, then the certificate issuer's DSA parameters apply to the
+- subject's DSA key. If the DSA domain parameters are omitted from the
+- SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
+- subject certificate using a signature algorithm other than DSA, then
+- the subject's DSA domain parameters are distributed by other means.
+- If the subjectPublicKeyInfo AlgorithmIdentifier field omits the
+- parameters component, the CA signed the subject with a signature
+- algorithm other than DSA, and the subject's DSA parameters are not
+- available through other means, then clients MUST reject the
+- certificate.
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 9]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this
+- encoding shall be used as the contents (i.e., the value) of the
+- subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
+- data element.
+-
+- DSAPublicKey ::= INTEGER -- public key, Y
+-
+- If the keyUsage extension is present in an end entity certificate
+- which conveys a DSA public key, any combination of the following
+- values MAY be present:
+-
+- digitalSignature;
+- nonRepudiation;
+-
+- If the keyUsage extension is present in a CA or CRL issuer
+- certificate which conveys a DSA public key, any combination of the
+- following values MAY be present:
+-
+- digitalSignature;
+- nonRepudiation;
+- keyCertSign; and
+- cRLSign.
+-
+-2.3.3 Diffie-Hellman Key Exchange Keys
+-
+- The Diffie-Hellman OID supported by this profile is defined in
+- [X9.42].
+-
+- dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+- us(840) ansi-x942(10046) number-type(2) 1 }
+-
+- The dhpublicnumber OID is intended to be used in the algorithm field
+- of a value of type AlgorithmIdentifier. The parameters field of that
+- type, which has the algorithm-specific syntax ANY DEFINED BY
+- algorithm, have the ASN.1 type DomainParameters for this algorithm.
+-
+- DomainParameters ::= SEQUENCE {
+- p INTEGER, -- odd prime, p=jq +1
+- g INTEGER, -- generator, g
+- q INTEGER, -- factor of p-1
+- j INTEGER OPTIONAL, -- subgroup factor
+- validationParms ValidationParms OPTIONAL }
+-
+- ValidationParms ::= SEQUENCE {
+- seed BIT STRING,
+- pgenCounter INTEGER }
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 10]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- The fields of type DomainParameters have the following meanings:
+-
+- p identifies the prime p defining the Galois field;
+-
+- g specifies the generator of the multiplicative subgroup of order
+- g;
+-
+- q specifies the prime factor of p-1;
+-
+- j optionally specifies the value that satisfies the equation
+- p=jq+1 to support the optional verification of group parameters;
+-
+- seed optionally specifies the bit string parameter used as the
+- seed for the domain parameter generation process; and
+-
+- pgenCounter optionally specifies the integer value output as part
+- of the of the domain parameter prime generation process.
+-
+- If either of the domain parameter generation components (pgenCounter
+- or seed) is provided, the other MUST be present as well.
+-
+- The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER;
+- this encoding shall be used as the contents (i.e., the value) of the
+- subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
+- data element.
+-
+- DHPublicKey ::= INTEGER -- public key, y = g^x mod p
+-
+- If the keyUsage extension is present in a certificate which conveys a
+- DH public key, the following values may be present:
+-
+- keyAgreement;
+- encipherOnly; and
+- decipherOnly.
+-
+- If present, the keyUsage extension MUST assert keyAgreement and MAY
+- assert either encipherOnly and decipherOnly. The keyUsage extension
+- MUST NOT assert both encipherOnly and decipherOnly.
+-
+-2.3.4 KEA Public Keys
+-
+- This section identifies the preferred OID and parameters for the
+- inclusion of a KEA public key in a certificate. The Key Exchange
+- Algorithm (KEA) is a key agreement algorithm. Two parties may
+- generate a "pairwise key" if and only if they share the same KEA
+- parameters. The KEA parameters are not included in a certificate;
+- instead a domain identifier is supplied in the parameters field.
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 11]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- When the SubjectPublicKeyInfo field contains a KEA key, the algorithm
+- identifier and parameters SHALL be as defined in [SDN.701r]:
+-
+- id-keyExchangeAlgorithm OBJECT IDENTIFIER ::=
+- { 2 16 840 1 101 2 1 1 22 }
+-
+- KEA-Parms-Id ::= OCTET STRING
+-
+- CAs MUST populate the parameters field of the AlgorithmIdentifier
+- within the SubjectPublicKeyInfo field of each certificate containing
+- a KEA public key with an 80-bit parameter identifier (OCTET STRING),
+- also known as the domain identifier. The domain identifier is
+- computed in three steps:
+-
+- (1) the KEA domain parameters (p, q, and g) are DER encoded using
+- the Dss-Parms structure;
+-
+- (2) a 160-bit SHA-1 hash is generated from the parameters; and
+-
+- (3) the 160-bit hash is reduced to 80-bits by performing an
+- "exclusive or" of the 80 high order bits with the 80 low order
+- bits.
+-
+- The resulting value is encoded such that the most significant byte of
+- the 80-bit value is the first octet in the octet string. The Dss-
+- Parms is provided above in Section 2.3.2.
+-
+- A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
+- such that the most significant bit (MSB) of y becomes the MSB of the
+- BIT STRING value field and the least significant bit (LSB) of y
+- becomes the LSB of the BIT STRING value field. This results in the
+- following encoding:
+-
+- BIT STRING tag;
+- BIT STRING length;
+- 0 (indicating that there are zero unused bits in the final octet
+- of y); and
+- BIT STRING value field including y.
+-
+- The key usage extension may optionally appear in a KEA certificate.
+- If a KEA certificate includes the keyUsage extension, only the
+- following values may be asserted:
+-
+- keyAgreement;
+- encipherOnly; and
+- decipherOnly.
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 12]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- If present, the keyUsage extension MUST assert keyAgreement and MAY
+- assert either encipherOnly and decipherOnly. The keyUsage extension
+- MUST NOT assert both encipherOnly and decipherOnly.
+-
+-2.3.5 ECDSA and ECDH Keys
+-
+- This section identifies the preferred OID and parameter encoding for
+- the inclusion of an ECDSA or ECDH public key in a certificate. The
+- Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
+- [X9.62]. ECDSA is the elliptic curve mathematical analog of the
+- Digital Signature Algorithm [FIPS 186]. The Elliptic Curve Diffie
+- Hellman (ECDH) algorithm is a key agreement algorithm defined in
+- [X9.63].
+-
+- ECDH is the elliptic curve mathematical analog of the Diffie-Hellman
+- key agreement algorithm as specified in [X9.42]. The ECDSA and ECDH
+- specifications use the same OIDs and parameter encodings. The ASN.1
+- object identifiers used to identify these public keys are defined in
+- the following arc:
+-
+- ansi-X9-62 OBJECT IDENTIFIER ::=
+- { iso(1) member-body(2) us(840) 10045 }
+-
+- When certificates contain an ECDSA or ECDH public key, the
+- id-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKey
+- algorithm identifier is defined as follows:
+-
+- id-public-key-type OBJECT IDENTIFIER ::= { ansi-X9.62 2 }
+-
+- id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
+-
+- This OID is used in public key certificates for both ECDSA signature
+- keys and ECDH encryption keys. The intended application for the key
+- may be indicated in the key usage field (see [RFC 3280]). The use of
+- a single key for both signature and encryption purposes is not
+- recommended, but is not forbidden.
+-
+- ECDSA and ECDH require use of certain parameters with the public key.
+- The parameters may be inherited from the issuer, implicitly included
+- through reference to a "named curve," or explicitly included in the
+- certificate.
+-
+- EcpkParameters ::= CHOICE {
+- ecParameters ECParameters,
+- namedCurve OBJECT IDENTIFIER,
+- implicitlyCA NULL }
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 13]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- When the parameters are inherited, the parameters field SHALL contain
+- implictlyCA, which is the ASN.1 value NULL. When parameters are
+- specified by reference, the parameters field SHALL contain the
+- named-Curve choice, which is an object identifier. When the
+- parameters are explicitly included, they SHALL be encoded in the
+- ASN.1 structure ECParameters:
+-
+- ECParameters ::= SEQUENCE {
+- version ECPVer, -- version is always 1
+- fieldID FieldID, -- identifies the finite field over
+- -- which the curve is defined
+- curve Curve, -- coefficients a and b of the
+- -- elliptic curve
+- base ECPoint, -- specifies the base point P
+- -- on the elliptic curve
+- order INTEGER, -- the order n of the base point
+- cofactor INTEGER OPTIONAL -- The integer h = #E(Fq)/n
+- }
+-
+- ECPVer ::= INTEGER {ecpVer1(1)}
+-
+- Curve ::= SEQUENCE {
+- a FieldElement,
+- b FieldElement,
+- seed BIT STRING OPTIONAL }
+-
+- FieldElement ::= OCTET STRING
+-
+- ECPoint ::= OCTET STRING
+-
+- The value of FieldElement SHALL be the octet string representation of
+- a field element following the conversion routine in [X9.62], Section
+- 4.3.3. The value of ECPoint SHALL be the octet string representation
+- of an elliptic curve point following the conversion routine in
+- [X9.62], Section 4.3.6. Note that this octet string may represent an
+- elliptic curve point in compressed or uncompressed form.
+-
+- Implementations that support elliptic curve according to this
+- specification MUST support the uncompressed form and MAY support the
+- compressed form.
+-
+- The components of type ECParameters have the following meanings:
+-
+- version specifies the version number of the elliptic curve
+- parameters. It MUST have the value 1 (ecpVer1).
+-
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 14]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- fieldID identifies the finite field over which the elliptic curve
+- is defined. Finite fields are represented by values of the
+- parameterized type FieldID, constrained to the values of the
+- objects defined in the information object set FieldTypes.
+- Additional detail regarding fieldID is provided below.
+-
+- curve specifies the coefficients a and b of the elliptic curve E.
+- Each coefficient is represented as a value of type FieldElement,
+- an OCTET STRING. seed is an optional parameter used to derive the
+- coefficients of a randomly generated elliptic curve.
+-
+- base specifies the base point P on the elliptic curve. The base
+- point is represented as a value of type ECPoint, an OCTET STRING.
+-
+- order specifies the order n of the base point.
+-
+- cofactor is the integer h = #E(Fq)/n. This parameter is specified
+- as OPTIONAL. However, the cofactor MUST be included in ECDH
+- public key parameters. The cofactor is not required to support
+- ECDSA, except in parameter validation. The cofactor MAY be
+- included to support parameter validation for ECDSA keys.
+- Parameter validation is not required by this specification.
+-
+- The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place
+- within a certificate where the parameters may be used. If the
+- elliptic curve parameters are specified as implicitlyCA in the
+- SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
+- subject certificate using ECDSA, then the certificate issuer's ECDSA
+- parameters apply to the subject's ECDSA key. If the elliptic curve
+- parameters are specified as implicitlyCA in the SubjectPublicKeyInfo
+- AlgorithmIdentifier and the CA signed the certificate using a
+- signature algorithm other than ECDSA, then clients MUST not make use
+- of the elliptic curve public key.
+-
+- FieldID ::= SEQUENCE {
+- fieldType OBJECT IDENTIFIER,
+- parameters ANY DEFINED BY fieldType }
+-
+- FieldID is a SEQUENCE of two components, fieldType and parameters.
+- The fieldType contains an object identifier value that uniquely
+- identifies the type contained in the parameters.
+-
+- The object identifier id-fieldType specifies an arc containing the
+- object identifiers of each field type. It has the following value:
+-
+- id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 15]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- The object identifiers prime-field and characteristic-two-field name
+- the two kinds of fields defined in this Standard. They have the
+- following values:
+-
+- prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
+-
+- Prime-p ::= INTEGER -- Field size p (p in bits)
+-
+- characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
+-
+- Characteristic-two ::= SEQUENCE {
+- m INTEGER, -- Field size 2^m
+- basis OBJECT IDENTIFIER,
+- parameters ANY DEFINED BY basis }
+-
+- The object identifier id-characteristic-two-basis specifies an arc
+- containing the object identifiers for each type of basis for the
+- characteristic-two finite fields. It has the following value:
+-
+- id-characteristic-two-basis OBJECT IDENTIFIER ::= {
+- characteristic-two-field basisType(1) }
+-
+- The object identifiers gnBasis, tpBasis and ppBasis name the three
+- kinds of basis for characteristic-two finite fields defined by
+- [X9.62]. They have the following values:
+-
+- gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
+-
+- -- for gnBasis, the value of the parameters field is NULL
+-
+- tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
+-
+- -- type of parameters field for tpBasis is Trinomial
+-
+- Trinomial ::= INTEGER
+-
+- ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
+-
+- -- type of parameters field for ppBasis is Pentanomial
+-
+- Pentanomial ::= SEQUENCE {
+- k1 INTEGER,
+- k2 INTEGER,
+- k3 INTEGER }
+-
+-
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 16]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- The elliptic curve public key (an ECPoint which is an OCTET STRING)
+- is mapped to a subjectPublicKey (a BIT STRING) as follows: the most
+- significant bit of the OCTET STRING becomes the most significant bit
+- of the BIT STRING, and the least significant bit of the OCTET STRING
+- becomes the least significant bit of the BIT STRING. Note that this
+- octet string may represent an elliptic curve point in compressed or
+- uncompressed form. Implementations that support elliptic curve
+- according to this specification MUST support the uncompressed form
+- and MAY support the compressed form.
+-
+- If the keyUsage extension is present in a CA or CRL issuer
+- certificate which conveys an elliptic curve public key, any
+- combination of the following values MAY be present:
+-
+- digitalSignature;
+- nonRepudiation; and
+- keyAgreement.
+-
+- If the keyAgreement value is present, either of the following values
+- MAY be present:
+-
+- encipherOnly; and
+- decipherOnly.
+-
+- The keyUsage extension MUST NOT assert both encipherOnly and
+- decipherOnly.
+-
+- If the keyUsage extension is present in a CA certificate which
+- conveys an elliptic curve public key, any combination of the
+- following values MAY be present:
+-
+- digitalSignature;
+- nonRepudiation;
+- keyAgreement;
+- keyCertSign; and
+- cRLSign.
+-
+- As above, if the keyUsage extension asserts keyAgreement then it MAY
+- assert either encipherOnly and decipherOnly. However, this
+- specification RECOMMENDS that if keyCertSign or cRLSign is present,
+- keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 17]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+-3 ASN.1 Module
+-
+- PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6)
+- internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
+- id-mod-pkix1-algorithms(17) }
+-
+- DEFINITIONS EXPLICIT TAGS ::= BEGIN
+-
+- -- EXPORTS All;
+-
+- -- IMPORTS NONE;
+-
+- --
+- -- One-way Hash Functions
+- --
+-
+- md2 OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) rsadsi(113549)
+- digestAlgorithm(2) 2 }
+-
+- md5 OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) rsadsi(113549)
+- digestAlgorithm(2) 5 }
+-
+- id-sha1 OBJECT IDENTIFIER ::= {
+- iso(1) identified-organization(3) oiw(14) secsig(3)
+- algorithms(2) 26 }
+-
+- --
+- -- DSA Keys and Signatures
+- --
+-
+- -- OID for DSA public key
+-
+- id-dsa OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
+-
+- -- encoding for DSA public key
+-
+- DSAPublicKey ::= INTEGER -- public key, y
+-
+- Dss-Parms ::= SEQUENCE {
+- p INTEGER,
+- q INTEGER,
+- g INTEGER }
+-
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 18]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- -- OID for DSA signature generated with SHA-1 hash
+-
+- id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }
+-
+- -- encoding for DSA signature generated with SHA-1 hash
+-
+- Dss-Sig-Value ::= SEQUENCE {
+- r INTEGER,
+- s INTEGER }
+-
+- --
+- -- RSA Keys and Signatures
+- --
+-
+- -- arc for RSA public key and RSA signature OIDs
+-
+- pkcs-1 OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1 }
+-
+- -- OID for RSA public keys
+-
+- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
+-
+- -- OID for RSA signature generated with MD2 hash
+-
+- md2WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 2 }
+-
+- -- OID for RSA signature generated with MD5 hash
+-
+- md5WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 4 }
+-
+- -- OID for RSA signature generated with SHA-1 hash
+-
+- sha1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1 5 }
+-
+- -- encoding for RSA public key
+-
+- RSAPublicKey ::= SEQUENCE {
+- modulus INTEGER, -- n
+- publicExponent INTEGER } -- e
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 19]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- --
+- -- Diffie-Hellman Keys
+- --
+-
+- dhpublicnumber OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) ansi-x942(10046)
+- number-type(2) 1 }
+-
+- -- encoding for DSA public key
+-
+- DHPublicKey ::= INTEGER -- public key, y = g^x mod p
+-
+- DomainParameters ::= SEQUENCE {
+- p INTEGER, -- odd prime, p=jq +1
+- g INTEGER, -- generator, g
+- q INTEGER, -- factor of p-1
+- j INTEGER OPTIONAL, -- subgroup factor, j>= 2
+- validationParms ValidationParms OPTIONAL }
+-
+- ValidationParms ::= SEQUENCE {
+- seed BIT STRING,
+- pgenCounter INTEGER }
+-
+- --
+- -- KEA Keys
+- --
+-
+- id-keyExchangeAlgorithm OBJECT IDENTIFIER ::=
+- { 2 16 840 1 101 2 1 1 22 }
+-
+- KEA-Parms-Id ::= OCTET STRING
+-
+- --
+- -- Elliptic Curve Keys, Signatures, and Curves
+- --
+-
+- ansi-X9-62 OBJECT IDENTIFIER ::= {
+- iso(1) member-body(2) us(840) 10045 }
+-
+- FieldID ::= SEQUENCE { -- Finite field
+- fieldType OBJECT IDENTIFIER,
+- parameters ANY DEFINED BY fieldType }
+-
+- -- Arc for ECDSA signature OIDS
+-
+- id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 20]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- -- OID for ECDSA signatures with SHA-1
+-
+- ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }
+-
+- -- OID for an elliptic curve signature
+- -- format for the value of an ECDSA signature value
+-
+- ECDSA-Sig-Value ::= SEQUENCE {
+- r INTEGER,
+- s INTEGER }
+-
+- -- recognized field type OIDs are defined in the following arc
+-
+- id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }
+-
+- -- where fieldType is prime-field, the parameters are of type Prime-p
+-
+- prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
+-
+- Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime
+-
+- -- where fieldType is characteristic-two-field, the parameters are
+- -- of type Characteristic-two
+-
+- characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
+-
+- Characteristic-two ::= SEQUENCE {
+- m INTEGER, -- Field size 2^m
+- basis OBJECT IDENTIFIER,
+- parameters ANY DEFINED BY basis }
+-
+- -- recognized basis type OIDs are defined in the following arc
+-
+- id-characteristic-two-basis OBJECT IDENTIFIER ::= {
+- characteristic-two-field basisType(3) }
+-
+- -- gnbasis is identified by OID gnBasis and indicates
+- -- parameters are NULL
+-
+- gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
+-
+- -- parameters for this basis are NULL
+-
+- -- trinomial basis is identified by OID tpBasis and indicates
+- -- parameters of type Pentanomial
+-
+- tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 21]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- -- Trinomial basis representation of F2^m
+- -- Integer k for reduction polynomial xm + xk + 1
+-
+- Trinomial ::= INTEGER
+-
+- -- for pentanomial basis is identified by OID ppBasis and indicates
+- -- parameters of type Pentanomial
+-
+- ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
+-
+- -- Pentanomial basis representation of F2^m
+- -- reduction polynomial integers k1, k2, k3
+- -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1
+-
+- Pentanomial ::= SEQUENCE {
+- k1 INTEGER,
+- k2 INTEGER,
+- k3 INTEGER }
+-
+- -- The object identifiers gnBasis, tpBasis and ppBasis name
+- -- three kinds of basis for characteristic-two finite fields
+-
+- FieldElement ::= OCTET STRING -- Finite field element
+-
+- ECPoint ::= OCTET STRING -- Elliptic curve point
+-
+- -- Elliptic Curve parameters may be specified explicitly,
+- -- specified implicitly through a "named curve", or
+- -- inherited from the CA
+-
+- EcpkParameters ::= CHOICE {
+- ecParameters ECParameters,
+- namedCurve OBJECT IDENTIFIER,
+- implicitlyCA NULL }
+-
+- ECParameters ::= SEQUENCE { -- Elliptic curve parameters
+- version ECPVer,
+- fieldID FieldID,
+- curve Curve,
+- base ECPoint, -- Base point G
+- order INTEGER, -- Order n of the base point
+- cofactor INTEGER OPTIONAL } -- The integer h = #E(Fq)/n
+-
+- ECPVer ::= INTEGER {ecpVer1(1)}
+-
+-
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 22]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- Curve ::= SEQUENCE {
+- a FieldElement, -- Elliptic curve coefficient a
+- b FieldElement, -- Elliptic curve coefficient b
+- seed BIT STRING OPTIONAL }
+-
+- id-publicKeyType OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) }
+-
+- id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
+-
+- -- Named Elliptic Curves in ANSI X9.62.
+-
+- ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) }
+-
+- c-TwoCurve OBJECT IDENTIFIER ::= {
+- ellipticCurve characteristicTwo(0) }
+-
+- c2pnb163v1 OBJECT IDENTIFIER ::= { c-TwoCurve 1 }
+- c2pnb163v2 OBJECT IDENTIFIER ::= { c-TwoCurve 2 }
+- c2pnb163v3 OBJECT IDENTIFIER ::= { c-TwoCurve 3 }
+- c2pnb176w1 OBJECT IDENTIFIER ::= { c-TwoCurve 4 }
+- c2tnb191v1 OBJECT IDENTIFIER ::= { c-TwoCurve 5 }
+- c2tnb191v2 OBJECT IDENTIFIER ::= { c-TwoCurve 6 }
+- c2tnb191v3 OBJECT IDENTIFIER ::= { c-TwoCurve 7 }
+- c2onb191v4 OBJECT IDENTIFIER ::= { c-TwoCurve 8 }
+- c2onb191v5 OBJECT IDENTIFIER ::= { c-TwoCurve 9 }
+- c2pnb208w1 OBJECT IDENTIFIER ::= { c-TwoCurve 10 }
+- c2tnb239v1 OBJECT IDENTIFIER ::= { c-TwoCurve 11 }
+- c2tnb239v2 OBJECT IDENTIFIER ::= { c-TwoCurve 12 }
+- c2tnb239v3 OBJECT IDENTIFIER ::= { c-TwoCurve 13 }
+- c2onb239v4 OBJECT IDENTIFIER ::= { c-TwoCurve 14 }
+- c2onb239v5 OBJECT IDENTIFIER ::= { c-TwoCurve 15 }
+- c2pnb272w1 OBJECT IDENTIFIER ::= { c-TwoCurve 16 }
+- c2pnb304w1 OBJECT IDENTIFIER ::= { c-TwoCurve 17 }
+- c2tnb359v1 OBJECT IDENTIFIER ::= { c-TwoCurve 18 }
+- c2pnb368w1 OBJECT IDENTIFIER ::= { c-TwoCurve 19 }
+- c2tnb431r1 OBJECT IDENTIFIER ::= { c-TwoCurve 20 }
+-
+- primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }
+-
+- prime192v1 OBJECT IDENTIFIER ::= { primeCurve 1 }
+- prime192v2 OBJECT IDENTIFIER ::= { primeCurve 2 }
+- prime192v3 OBJECT IDENTIFIER ::= { primeCurve 3 }
+- prime239v1 OBJECT IDENTIFIER ::= { primeCurve 4 }
+- prime239v2 OBJECT IDENTIFIER ::= { primeCurve 5 }
+- prime239v3 OBJECT IDENTIFIER ::= { primeCurve 6 }
+- prime256v1 OBJECT IDENTIFIER ::= { primeCurve 7 }
+-
+- END
+-
+-
+-
+-Polk, et al. Standards Track [Page 23]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+-4 References
+-
+- [FIPS 180-1] Federal Information Processing Standards Publication
+- (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
+- [Supersedes FIPS PUB 180 dated 11 May 1993.]
+-
+- [FIPS 186-2] Federal Information Processing Standards Publication
+- (FIPS PUB) 186, Digital Signature Standard, 27 January
+- 2000. [Supersedes FIPS PUB 186-1 dated 15 December
+- 1998.]
+-
+- [P1363] IEEE P1363, "Standard Specifications for Public-Key
+- Cryptography", 2001.
+-
+- [RC95] Rogier, N. and Chauvaud, P., "The compression function
+- of MD2 is not collision free," Presented at Selected
+- Areas in Cryptography '95, May 1995.
+-
+- [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
+- Facilities", STD 13, RFC 1034, November 1987.
+-
+- [RFC 1319] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
+- 1319, April 1992.
+-
+- [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
+- 1321, April 1992.
+-
+- [RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic
+- Mail: Part II: Certificate-Based Key Management", RFC
+- 1422, February 1993.
+-
+- [RFC 1423] Balenson, D., "Privacy Enhancement for Internet
+- Electronic Mail: Part III: Algorithms, Modes, and
+- Identifiers", RFC 1423, February 1993.
+-
+- [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate
+- Requirement Levels", BCP 14, RFC 2119, March 1997.
+-
+- [RFC 2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
+- RFC 2313, March 1998.
+-
+- [RFC 2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet
+- X.509 Public Key Infrastructure: Certificate and CRL
+- Profile", RFC 2459, January, 1999.
+-
+- [RFC 3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+- (SHA1)", RFC 3174, September 2001.
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 24]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- [RFC 3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
+- X.509 Public Key Infrastructure Certificate and
+- Certificate Revocation List (CRL) Profile", RFC 3280,
+- April 2002.
+-
+- [SDN.701r] SDN.701, "Message Security Protocol 4.0", Revision A
+- 1997-02-06.
+-
+- [X.208] CCITT Recommendation X.208: Specification of Abstract
+- Syntax Notation One (ASN.1), 1988.
+-
+- [X.660] ITU-T Recommendation X.660 Information Technology -
+- ASN.1 encoding rules: Specification of Basic Encoding
+- Rules (BER), Canonical Encoding Rules (CER) and
+- Distinguished Encoding Rules (DER), 1997.
+-
+- [X9.42] ANSI X9.42-2000, "Public Key Cryptography for The
+- Financial Services Industry: Agreement of Symmetric
+- Keys Using Discrete Logarithm Cryptography", December,
+- 1999.
+-
+- [X9.62] X9.62-1998, "Public Key Cryptography For The Financial
+- Services Industry: The Elliptic Curve Digital
+- Signature Algorithm (ECDSA)", January 7, 1999.
+-
+- [X9.63] ANSI X9.63-2001, "Public Key Cryptography For The
+- Financial Services Industry: Key Agreement and Key
+- Transport Using Elliptic Curve Cryptography", Work in
+- Progress.
+-
+-5 Security Considerations
+-
+- This specification does not constrain the size of public keys or
+- their parameters for use in the Internet PKI. However, the key size
+- selected impacts the strength achieved when implementing
+- cryptographic services. Selection of appropriate key sizes is
+- critical to implementing appropriate security.
+-
+- This specification does not identify particular elliptic curves for
+- use in the Internet PKI. However, the particular curve selected
+- impact the strength of the digital signatures. Some curves are
+- cryptographically stronger than others!
+-
+- In general, use of "well-known" curves, such as the "named curves"
+- from ANSI X9.62, is a sound strategy. For additional information,
+- refer to X9.62 Appendix H.1.3, "Key Length Considerations" and
+- Appendix A.1, "Avoiding Cryptographically Weak Keys".
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 25]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+- This specification supplements RFC 3280. The security considerations
+- section of that document applies to this specification as well.
+-
+-6 Intellectual Property Rights
+-
+- The IETF has been notified of intellectual property rights claimed in
+- regard to some or all of the specification contained in this
+- document. For more information consult the online list of claimed
+- rights.
+-
+- The IETF takes no position regarding the validity or scope of any
+- intellectual property or other rights that might be claimed to
+- pertain to the implementation or use of the technology described in
+- this document or the extent to which any license under such rights
+- might or might not be available; neither does it represent that it
+- has made any effort to identify any such rights. Information on the
+- IETF's procedures with respect to rights in standards-track and
+- standards- related documentation can be found in BCP-11. Copies of
+- claims of rights made available for publication and any assurances of
+- licenses to be made available, or the result of an attempt made to
+- obtain a general license or permission for the use of such
+- proprietary rights by implementors or users of this specification can
+- be obtained from the IETF Secretariat.
+-
+-7 Author Addresses:
+-
+- Tim Polk
+- NIST
+- 100 Bureau Drive, Stop 8930
+- Gaithersburg, MD 20899-8930
+- USA
+- EMail: tim.polk at nist.gov
+-
+- Russell Housley
+- RSA Laboratories
+- 918 Spring Knoll Drive
+- Herndon, VA 20170
+- USA
+- EMail: rhousley at rsasecurity.com
+-
+- Larry Bassham
+- NIST
+- 100 Bureau Drive, Stop 8930
+- Gaithersburg, MD 20899-8930
+- USA
+- EMail: lbassham at nist.gov
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 26]
+-
+-RFC 3279 Algorithms and Identifiers April 2002
+-
+-
+-8. Full Copyright Statement
+-
+- Copyright (C) The Internet Society (2002). All Rights Reserved.
+-
+- This document and translations of it may be copied and furnished to
+- others, and derivative works that comment on or otherwise explain it
+- or assist in its implementation may be prepared, copied, published
+- and distributed, in whole or in part, without restriction of any
+- kind, provided that the above copyright notice and this paragraph are
+- included on all such copies and derivative works. However, this
+- document itself may not be modified in any way, such as by removing
+- the copyright notice or references to the Internet Society or other
+- Internet organizations, except as needed for the purpose of
+- developing Internet standards in which case the procedures for
+- copyrights defined in the Internet Standards process must be
+- followed, or as required to translate it into languages other than
+- English.
+-
+- The limited permissions granted above are perpetual and will not be
+- revoked by the Internet Society or its successors or assigns.
+-
+- This document and the information contained herein is provided on an
+- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+-
+-Acknowledgement
+-
+- Funding for the RFC Editor function is currently provided by the
+- Internet Society.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Polk, et al. Standards Track [Page 27]
+-
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc3720.txt open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc3720.txt
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc3720.txt 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc3720.txt 1969-12-31 18:00:00.000000000 -0600
+@@ -1,14395 +0,0 @@
+-
+-
+-
+-
+-
+-
+-Network Working Group J. Satran
+-Request for Comments: 3720 K. Meth
+-Category: Standards Track IBM
+- C. Sapuntzakis
+- Cisco Systems
+- M. Chadalapaka
+- Hewlett-Packard Co.
+- E. Zeidner
+- IBM
+- April 2004
+-
+-
+- Internet Small Computer Systems Interface (iSCSI)
+-
+-Status of this Memo
+-
+- This document specifies an Internet standards track protocol for the
+- Internet community, and requests discussion and suggestions for
+- improvements. Please refer to the current edition of the "Internet
+- Official Protocol Standards" (STD 1) for the standardization state
+- and status of this protocol. Distribution of this memo is unlimited.
+-
+-Copyright Notice
+-
+- Copyright (C) The Internet Society (2003). All Rights Reserved.
+-
+-Abstract
+-
+- This document describes a transport protocol for Internet Small
+- Computer Systems Interface (iSCSI) that works on top of TCP. The
+- iSCSI protocol aims to be fully compliant with the standardized SCSI
+- architecture model.
+-
+- SCSI is a popular family of protocols that enable systems to
+- communicate with I/O devices, especially storage devices. SCSI
+- protocols are request/response application protocols with a common
+- standardized architecture model and basic command set, as well as
+- standardized command sets for different device classes (disks, tapes,
+- media-changers etc.).
+-
+- As system interconnects move from the classical bus structure to a
+- network structure, SCSI has to be mapped to network transport
+- protocols. IP networks now meet the performance requirements of fast
+- system interconnects and as such are good candidates to "carry" SCSI.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 1]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Table of Contents
+-
+- 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 9
+- 2. Definitions and Acronyms. . . . . . . . . . . . . . . . . . . 10
+- 2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . 10
+- 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . 14
+- 2.3. Conventions. . . . . . . . . . . . . . . . . . . . . . 16
+- 2.3.1. Word Rule. . . . . . . . . . . . . . . . . . 16
+- 2.3.2. Half-Word Rule . . . . . . . . . . . . . . . 17
+- 2.3.3. Byte Rule. . . . . . . . . . . . . . . . . . 17
+- 3. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+- 3.1. SCSI Concepts. . . . . . . . . . . . . . . . . . . . . 17
+- 3.2. iSCSI Concepts and Functional Overview . . . . . . . . 18
+- 3.2.1. Layers and Sessions. . . . . . . . . . . . . 19
+- 3.2.2. Ordering and iSCSI Numbering . . . . . . . . 19
+- 3.2.2.1. Command Numbering and
+- Acknowledging . . . . . . . . . . 20
+- 3.2.2.2. Response/Status Numbering and
+- Acknowledging . . . . . . . . . . 23
+- 3.2.2.3. Data Sequencing . . . . . . . . 24
+- 3.2.3. iSCSI Login. . . . . . . . . . . . . . . . . 24
+- 3.2.4. iSCSI Full Feature Phase . . . . . . . . . . 25
+- 3.2.4.1. Command Connection Allegiance . . 26
+- 3.2.4.2. Data Transfer Overview. . . . . . 27
+- 3.2.4.3. Tags and Integrity Checks . . . . 28
+- 3.2.4.4. Task Management . . . . . . . . . 28
+- 3.2.5. iSCSI Connection Termination . . . . . . . . 29
+- 3.2.6. iSCSI Names. . . . . . . . . . . . . . . . . 29
+- 3.2.6.1. iSCSI Name Properties . . . . . . 30
+- 3.2.6.2. iSCSI Name Encoding . . . . . . . 31
+- 3.2.6.3. iSCSI Name Structure. . . . . . . 32
+- 3.2.6.3.1. Type "iqn." (iSCSI
+- Qualified Name) . . . 32
+- 3.2.6.3.2. Type "eui." (IEEE
+- EUI-64 format). . . . 34
+- 3.2.7. Persistent State . . . . . . . . . . . . . . 34
+- 3.2.8. Message Synchronization and Steering . . . . 35
+- 3.2.8.1. Sync/Steering and iSCSI PDU
+- Length . . . . . . . . . . . . . 36
+- 3.3. iSCSI Session Types. . . . . . . . . . . . . . . . . . 36
+- 3.4. SCSI to iSCSI Concepts Mapping Model . . . . . . . . . 37
+- 3.4.1. iSCSI Architecture Model . . . . . . . . . . 37
+- 3.4.2. SCSI Architecture Model. . . . . . . . . . . 39
+- 3.4.3. Consequences of the Model. . . . . . . . . . 41
+- 3.4.3.1. I_T Nexus State . . . . . . . . . 42
+- 3.5. Request/Response Summary . . . . . . . . . . . . . . . 42
+- 3.5.1. Request/Response Types Carrying SCSI Payload 43
+- 3.5.1.1. SCSI-Command . . . . . . . . . . 43
+-
+-
+-
+-Satran, et al. Standards Track [Page 2]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 3.5.1.2. SCSI-Response . . . . . . . . . 43
+- 3.5.1.3. Task Management Function Request. 44
+- 3.5.1.4. Task Management Function Response 44
+- 3.5.1.5. SCSI Data-Out and SCSI Data-In. . 44
+- 3.5.1.6. Ready To Transfer (R2T) . . . . . 45
+- 3.5.2. Requests/Responses carrying SCSI and iSCSI
+- Payload. . . . . . . . . . . . . . . . . . . 46
+- 3.5.2.1. Asynchronous Message. . . . . . . 46
+- 3.5.3. Requests/Responses Carrying iSCSI Only
+- Payload. . . . . . . . . . . . . . . . . . . 46
+- 3.5.3.1. Text Request and Text Response. . 46
+- 3.5.3.2. Login Request and Login Response. 47
+- 3.5.3.3. Logout Request and Response . . . 47
+- 3.5.3.4. SNACK Request . . . . . . . . . . 48
+- 3.5.3.5. Reject. . . . . . . . . . . . . . 48
+- 3.5.3.6. NOP-Out Request and NOP-In
+- Response . . . . . . . . . . . . 48
+- 4. SCSI Mode Parameters for iSCSI. . . . . . . . . . . . . . . . 48
+- 5. Login and Full Feature Phase Negotiation. . . . . . . . . . . 48
+- 5.1. Text Format. . . . . . . . . . . . . . . . . . . . . . 50
+- 5.2. Text Mode Negotiation. . . . . . . . . . . . . . . . . 53
+- 5.2.1. List negotiations. . . . . . . . . . . . . . 56
+- 5.2.2. Simple-value Negotiations. . . . . . . . . . 56
+- 5.3. Login Phase. . . . . . . . . . . . . . . . . . . . . . 57
+- 5.3.1. Login Phase Start. . . . . . . . . . . . . . 60
+- 5.3.2. iSCSI Security Negotiation . . . . . . . . . 62
+- 5.3.3. Operational Parameter Negotiation During
+- the Login Phase. . . . . . . . . . . . . . . 63
+- 5.3.4. Connection Reinstatement . . . . . . . . . . 64
+- 5.3.5. Session Reinstatement, Closure, and Timeout. 64
+- 5 5.3.5.1. Loss of Nexus
+- Notification. . . . . 65
+- 5.3.6. Session Continuation and Failure . . . . . . 65
+- 5.4. Operational Parameter Negotiation Outside the Login
+- Phase. . . . . . . . . . . . . . . . . . . . . . . . . 66
+- 6. iSCSI Error Handling and Recovery . . . . . . . . . . . . . . 67
+- 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 67
+- 6.1.1. Background . . . . . . . . . . . . . . . . . 67
+- 6.1.2. Goals. . . . . . . . . . . . . . . . . . . . 67
+- 6.1.3. Protocol Features and State Expectations . . 68
+- 6.1.4. Recovery Classes . . . . . . . . . . . . . . 69
+- 6.1.4.1. Recovery Within-command . . . . . 69
+- 6.1.4.2. Recovery Within-connection. . . . 70
+- 6.1.4.3. Connection Recovery . . . . . . . 71
+- 6.1.4.4. Session Recovery. . . . . . . . . 72
+- 6.1.5. Error Recovery Hierarchy . . . . . . . . . . . 72
+- 6.2. Retry and Reassign in Recovery . . . . . . . . . . . . 74
+- 6.2.1. Usage of Retry . . . . . . . . . . . . . . . 74
+-
+-
+-
+-Satran, et al. Standards Track [Page 3]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 6.2.2. Allegiance Reassignment. . . . . . . . . . . 75
+- 6.3. Usage Of Reject PDU in Recovery. . . . . . . . . . . . 76
+- 6.4. Connection Timeout Management. . . . . . . . . . . . . 76
+- 6.4.1. Timeouts on Transport Exception Events . . . 77
+- 6.4.2. Timeouts on Planned Decommissioning. . . . . 77
+- 6.5. Implicit Termination of Tasks. . . . . . . . . . . . . 77
+- 6.6. Format Errors. . . . . . . . . . . . . . . . . . . . . 78
+- 6.7. Digest Errors. . . . . . . . . . . . . . . . . . . . . 78
+- 6.8. Sequence Errors. . . . . . . . . . . . . . . . . . . . 80
+- 6.9. SCSI Timeouts. . . . . . . . . . . . . . . . . . . . . 81
+- 6.10. Negotiation Failures . . . . . . . . . . . . . . . . . 81
+- 6.11. Protocol Errors. . . . . . . . . . . . . . . . . . . . 82
+- 6.12. Connection Failures. . . . . . . . . . . . . . . . . . 82
+- 6.13. Session Errors . . . . . . . . . . . . . . . . . . . . 83
+- 7. State Transitions . . . . . . . . . . . . . . . . . . . . . . 84
+- 7.1. Standard Connection State Diagrams . . . . . . . . . . 84
+- 7.1.1. State Descriptions for Initiators and
+- Targets. . . . . . . . . . . . . . . . . . . 84
+- 7.1.2. State Transition Descriptions for Initiators
+- and Targets. . . . . . . . . . . . . . . . . 85
+- 7.1.3. Standard Connection State Diagram for an
+- Initiator. . . . . . . . . . . . . . . . . . 88
+- 7.1.4. Standard Connection State Diagram for a
+- Target . . . . . . . . . . . . . . . . . . . 90
+- 7.2. Connection Cleanup State Diagram for Initiators and
+- Targets. . . . . . . . . . . . . . . . . . . . . . . . 92
+- 7.2.1. State Descriptions for Initiators and
+- Targets. . . . . . . . . . . . . . . . . . . 94
+- 7.2.2. State Transition Descriptions for Initiators
+- and Targets. . . . . . . . . . . . . . . . . 94
+- 7.3. Session State Diagrams . . . . . . . . . . . . . . . . 95
+- 7.3.1. Session State Diagram for an Initiator . . . 95
+- 7.3.2. Session State Diagram for a Target . . . . . 96
+- 7.3.3. State Descriptions for Initiators and
+- Targets. . . . . . . . . . . . . . . . . . . 97
+- 7.3.4. State Transition Descriptions for Initiators
+- and Targets. . . . . . . . . . . . . . . . . 98
+- 8. Security Considerations . . . . . . . . . . . . . . . . . . . 99
+- 8.1. iSCSI Security Mechanisms. . . . . . . . . . . . . . . 100
+- 8.2. In-band Initiator-Target Authentication. . . . . . . . 100
+- 8.2.1. CHAP Considerations. . . . . . . . . . . . . 101
+- 8.2.2. SRP Considerations . . . . . . . . . . . . . 103
+- 8.3. IPsec. . . . . . . . . . . . . . . . . . . . . . . . . 104
+- 8.3.1. Data Integrity and Authentication. . . . . . 104
+- 8.3.2. Confidentiality. . . . . . . . . . . . . . . 105
+- 8.3.3. Policy, Security Associations, and
+- Cryptographic Key Management . . . . . . . . 105
+- 9. Notes to Implementers . . . . . . . . . . . . . . . . . . . . 106
+-
+-
+-
+-Satran, et al. Standards Track [Page 4]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 9.1. Multiple Network Adapters. . . . . . . . . . . . . . . 106
+- 9.1.1. Conservative Reuse of ISIDs. . . . . . . . . 107
+- 9.1.2. iSCSI Name, ISID, and TPGT Use . . . . . . . 107
+- 9.2. Autosense and Auto Contingent Allegiance (ACA) . . . . 109
+- 9.3. iSCSI Timeouts . . . . . . . . . . . . . . . . . . . . 109
+- 9.4. Command Retry and Cleaning Old Command Instances . . . 110
+- 9.5. Synch and Steering Layer and Performance . . . . . . . 110
+- 9.6. Considerations for State-dependent Devices and
+- Long-lasting SCSI Operations . . . . . . . . . . . . . 111
+- 9.6.1. Determining the Proper ErrorRecoveryLevel. . 112
+- 10. iSCSI PDU Formats . . . . . . . . . . . . . . . . . . . . . . 112
+- 10.1. iSCSI PDU Length and Padding . . . . . . . . . . . . . 113
+- 10.2. PDU Template, Header, and Opcodes. . . . . . . . . . . 113
+- 10.2.1. Basic Header Segment (BHS) . . . . . . . . . 114
+- 10.2.1.1. I . . . . . . . . . . . . . . . . 115
+- 10.2.1.2. Opcode. . . . . . . . . . . . . . 115
+- 10.2.1.3. Final (F) bit . . . . . . . . . . 116
+- 10.2.1.4. Opcode-specific Fields. . . . . . 116
+- 10.2.1.5. TotalAHSLength. . . . . . . . . . 116
+- 10.2.1.6. DataSegmentLength . . . . . . . . 116
+- 10.2.1.7. LUN . . . . . . . . . . . . . . . 116
+- 10.2.1.8. Initiator Task Tag. . . . . . . . 117
+- 10.2.2. Additional Header Segment (AHS) . . . . . . . 117
+- 10.2.2.1. AHSType . . . . . . . . . . . . . 117
+- 10.2.2.2. AHSLength . . . . . . . . . . . . 117
+- 10.2.2.3. Extended CDB AHS. . . . . . . . . 118
+- 10.2.2.4. Bidirectional Expected Read-Data
+- Length AHS. . . . . . . . . . . . 118
+- 10.2.3. Header Digest and Data Digest. . . . . . . . 118
+- 10.2.4. Data Segment . . . . . . . . . . . . . . . . 119
+- 10.3. SCSI Command . . . . . . . . . . . . . . . . . . . . . 119
+- 10.3.1. Flags and Task Attributes (byte 1) . . . . . 120
+- 10.3.2. CmdSN - Command Sequence Number. . . . . . . 120
+- 10.3.3. ExpStatSN. . . . . . . . . . . . . . . . . . 120
+- 10.3.4. Expected Data Transfer Length. . . . . . . . 121
+- 10.3.5. CDB - SCSI Command Descriptor Block. . . . . 121
+- 10.3.6. Data Segment - Command Data. . . . . . . . . 121
+- 10.4. SCSI Response. . . . . . . . . . . . . . . . . . . . . 122
+- 10.4.1. Flags (byte 1) . . . . . . . . . . . . . . . 123
+- 10.4.2. Status . . . . . . . . . . . . . . . . . . . 123
+- 10.4.3. Response . . . . . . . . . . . . . . . . . . 124
+- 10.4.4. SNACK Tag. . . . . . . . . . . . . . . . . . 125
+- 10.4.5. Residual Count . . . . . . . . . . . . . . . 125
+- 10.4.6. Bidirectional Read Residual Count. . . . . . 125
+- 10.4.7. Data Segment - Sense and Response Data
+- Segment. . . . . . . . . . . . . . . . . . . 125
+- 10.4.7.1. SenseLength . . . . . . . . . . . 126
+- 10.4.7.2. Sense Data. . . . . . . . . . . . 126
+-
+-
+-
+-Satran, et al. Standards Track [Page 5]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 10.4.8. ExpDataSN. . . . . . . . . . . . . . . . . . 127
+- 10.4.9. StatSN - Status Sequence Number. . . . . . . 127
+- 10.4.10. ExpCmdSN - Next Expected CmdSN from this
+- Initiator. . . . . . . . . . . . . . . . . . 128
+- 10.4.11. MaxCmdSN - Maximum CmdSN from this Initiator 128
+- 10.5. Task Management Function Request . . . . . . . . . . . 129
+- 10.5.1. Function . . . . . . . . . . . . . . . . . . 129
+- 10.5.2. TotalAHSLength and DataSegmentLength . . . . 132
+- 10.5.3. LUN. . . . . . . . . . . . . . . . . . . . . 132
+- 10.5.4. Referenced Task Tag. . . . . . . . . . . . . 132
+- 10.5.5. RefCmdSN . . . . . . . . . . . . . . . . . . 132
+- 10.5.6. ExpDataSN. . . . . . . . . . . . . . . . . . 133
+- 10.6. Task Management Function Response. . . . . . . . . . . 134
+- 10.6.1. Response . . . . . . . . . . . . . . . . . . 134
+- 10.6.2. Task Management Actions on Task Sets . . . . 136
+- 10.6.3. TotalAHSLength and DataSegmentLength . . . . 137
+- 10.7. SCSI Data-Out & SCSI Data-In . . . . . . . . . . . . . 137
+- 10.7.1. F (Final) Bit. . . . . . . . . . . . . . . . 139
+- 10.7.2. A (Acknowledge) Bit. . . . . . . . . . . . . 139
+- 10.7.3. Flags (byte 1) . . . . . . . . . . . . . . . 140
+- 10.7.4. Target Transfer Tag and LUN. . . . . . . . . 140
+- 10.7.5. DataSN . . . . . . . . . . . . . . . . . . . 141
+- 10.7.6. Buffer Offset. . . . . . . . . . . . . . . . 141
+- 10.7.7. DataSegmentLength. . . . . . . . . . . . . . 141
+- 10.8. Ready To Transfer (R2T). . . . . . . . . . . . . . . . 142
+- 10.8.1. TotalAHSLength and DataSegmentLength . . . . 143
+- 10.8.2. R2TSN. . . . . . . . . . . . . . . . . . . . 143
+- 10.8.3. StatSN . . . . . . . . . . . . . . . . . . . 144
+- 10.8.4. Desired Data Transfer Length and Buffer
+- Offset . . . . . . . . . . . . . . . . . . . 144
+- 10.8.5. Target Transfer Tag. . . . . . . . . . . . . 144
+- 10.9. Asynchronous Message . . . . . . . . . . . . . . . . . 145
+- 10.9.1. AsyncEvent . . . . . . . . . . . . . . . . . 146
+- 10.9.2. AsyncVCode . . . . . . . . . . . . . . . . . 147
+- 10.9.3. LUN. . . . . . . . . . . . . . . . . . . . . 147
+- 10.9.4. Sense Data and iSCSI Event Data. . . . . . . 148
+- 10.9.4.1. SenseLength . . . . . . . . . . . 148
+- 10.10. Text Request . . . . . . . . . . . . . . . . . . . . . 149
+- 10.10.1. F (Final) Bit. . . . . . . . . . . . . . . . 150
+- 10.10.2. C (Continue) Bit . . . . . . . . . . . . . . 150
+- 10.10.3. Initiator Task Tag . . . . . . . . . . . . . 150
+- 10.10.4. Target Transfer Tag. . . . . . . . . . . . . 150
+- 10.10.5. Text . . . . . . . . . . . . . . . . . . . . 151
+- 10.11. Text Response. . . . . . . . . . . . . . . . . . . . . 152
+- 10.11.1. F (Final) Bit. . . . . . . . . . . . . . . . 152
+- 10.11.2. C (Continue) Bit . . . . . . . . . . . . . . 153
+- 10.11.3. Initiator Task Tag . . . . . . . . . . . . . 153
+- 10.11.4. Target Transfer Tag. . . . . . . . . . . . . 153
+-
+-
+-
+-Satran, et al. Standards Track [Page 6]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 10.11.5. StatSN . . . . . . . . . . . . . . . . . . . 154
+- 10.11.6. Text Response Data . . . . . . . . . . . . . 154
+- 10.12. Login Request. . . . . . . . . . . . . . . . . . . . . 154
+- 10.12.1. T (Transit) Bit. . . . . . . . . . . . . . . 155
+- 10.12.2. C (Continue) Bit . . . . . . . . . . . . . . 155
+- 10.12.3. CSG and NSG. . . . . . . . . . . . . . . . . 156
+- 10.12.4. Version. . . . . . . . . . . . . . . . . . . 156
+- 10.12.4.1. Version-max. . . . . . . . . . . 156
+- 10.12.4.2. Version-min. . . . . . . . . . . 156
+- 10.12.5. ISID . . . . . . . . . . . . . . . . . . . . 157
+- 10.12.6. TSIH . . . . . . . . . . . . . . . . . . . . 158
+- 10.12.7. Connection ID - CID. . . . . . . . . . . . . 158
+- 10.12.8. CmdSN. . . . . . . . . . . . . . . . . . . . 159
+- 10.12.9. ExpStatSN. . . . . . . . . . . . . . . . . . 159
+- 10.12.10. Login Parameters . . . . . . . . . . . . . . 159
+- 10.13. Login Response . . . . . . . . . . . . . . . . . . . . 160
+- 10.13.1. Version-max. . . . . . . . . . . . . . . . . 160
+- 10.13.2. Version-active . . . . . . . . . . . . . . . 161
+- 10.13.3. TSIH . . . . . . . . . . . . . . . . . . . . 161
+- 10.13.4. StatSN . . . . . . . . . . . . . . . . . . . 161
+- 10.13.5. Status-Class and Status-Detail . . . . . . . 161
+- 10.13.6. T (Transit) Bit. . . . . . . . . . . . . . . 164
+- 10.13.7. C (Continue) Bit . . . . . . . . . . . . . . 164
+- 10.13.8. Login Parameters . . . . . . . . . . . . . . 164
+- 10.14. Logout Request . . . . . . . . . . . . . . . . . . . . 165
+- 10.14.1. Reason Code. . . . . . . . . . . . . . . . . 167
+- 10.14.2. TotalAHSLength and DataSegmentLength . . . . 168
+- 10.14.3. CID. . . . . . . . . . . . . . . . . . . . . 168
+- 10.14.4. ExpStatSN. . . . . . . . . . . . . . . . . . 168
+- 10.14.5. Implicit termination of tasks. . . . . . . . 168
+- 10.15. Logout Response. . . . . . . . . . . . . . . . . . . . 169
+- 10.15.1. Response . . . . . . . . . . . . . . . . . . 170
+- 10.15.2. TotalAHSLength and DataSegmentLength . . . . 170
+- 10.15.3. Time2Wait. . . . . . . . . . . . . . . . . . 170
+- 10.15.4. Time2Retain. . . . . . . . . . . . . . . . . 170
+- 10.16. SNACK Request. . . . . . . . . . . . . . . . . . . . . 171
+- 10.16.1. Type . . . . . . . . . . . . . . . . . . . . 172
+- 10.16.2. Data Acknowledgement . . . . . . . . . . . . 173
+- 10.16.3. Resegmentation . . . . . . . . . . . . . . . 173
+- 10.16.4. Initiator Task Tag . . . . . . . . . . . . . 174
+- 10.16.5. Target Transfer Tag or SNACK Tag . . . . . . 174
+- 10.16.6. BegRun . . . . . . . . . . . . . . . . . . . 174
+- 10.16.7. RunLength. . . . . . . . . . . . . . . . . . 174
+- 10.17. Reject . . . . . . . . . . . . . . . . . . . . . . . . 175
+- 10.17.1. Reason . . . . . . . . . . . . . . . . . . . 176
+- 10.17.2. DataSN/R2TSN . . . . . . . . . . . . . . . . 177
+- 10.17.3. StatSN, ExpCmdSN and MaxCmdSN. . . . . . . . 177
+- 10.17.4. Complete Header of Bad PDU . . . . . . . . . 177
+-
+-
+-
+-Satran, et al. Standards Track [Page 7]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 10.18. NOP-Out. . . . . . . . . . . . . . . . . . . . . . . . 178
+- 10.18.1. Initiator Task Tag . . . . . . . . . . . . . 179
+- 10.18.2. Target Transfer Tag. . . . . . . . . . . . . 179
+- 10.18.3. Ping Data. . . . . . . . . . . . . . . . . . 179
+- 10.19. NOP-In . . . . . . . . . . . . . . . . . . . . . . . . 180
+- 10.19.1. Target Transfer Tag. . . . . . . . . . . . . 181
+- 10.19.2. StatSN . . . . . . . . . . . . . . . . . . . 181
+- 10.19.3. LUN. . . . . . . . . . . . . . . . . . . . . 181
+- 11. iSCSI Security Text Keys and Authentication Methods . . . . . 181
+- 11.1. AuthMethod . . . . . . . . . . . . . . . . . . . . . . 182
+- 11.1.1. Kerberos . . . . . . . . . . . . . . . . . . 184
+- 11.1.2. Simple Public-Key Mechanism (SPKM) . . . . . 184
+- 11.1.3. Secure Remote Password (SRP) . . . . . . . . 185
+- 11.1.4. Challenge Handshake Authentication Protocol
+- (CHAP) . . . . . . . . . . . . . . . . . . . 186
+- 12. Login/Text Operational Text Keys. . . . . . . . . . . . . . . 187
+- 12.1. HeaderDigest and DataDigest. . . . . . . . . . . . . . 188
+- 12.2. MaxConnections . . . . . . . . . . . . . . . . . . . . 190
+- 12.3. SendTargets. . . . . . . . . . . . . . . . . . . . . . 191
+- 12.4. TargetName . . . . . . . . . . . . . . . . . . . . . . 191
+- 12.5. InitiatorName. . . . . . . . . . . . . . . . . . . . . 192
+- 12.6. TargetAlias. . . . . . . . . . . . . . . . . . . . . . 192
+- 12.7. InitiatorAlias . . . . . . . . . . . . . . . . . . . . 193
+- 12.8. TargetAddress. . . . . . . . . . . . . . . . . . . . . 193
+- 12.9. TargetPortalGroupTag . . . . . . . . . . . . . . . . . 194
+- 12.10. InitialR2T . . . . . . . . . . . . . . . . . . . . . . 194
+- 12.11. ImmediateData. . . . . . . . . . . . . . . . . . . . . 195
+- 12.12. MaxRecvDataSegmentLength . . . . . . . . . . . . . . . 196
+- 12.13. MaxBurstLength . . . . . . . . . . . . . . . . . . . . 196
+- 12.14. FirstBurstLength . . . . . . . . . . . . . . . . . . . 197
+- 12.15. DefaultTime2Wait . . . . . . . . . . . . . . . . . . . 197
+- 12.16. DefaultTime2Retain . . . . . . . . . . . . . . . . . . 198
+- 12.17. MaxOutstandingR2T. . . . . . . . . . . . . . . . . . . 198
+- 12.18. DataPDUInOrder . . . . . . . . . . . . . . . . . . . . 198
+- 12.19. DataSequenceInOrder. . . . . . . . . . . . . . . . . . 199
+- 12.20. ErrorRecoveryLevel . . . . . . . . . . . . . . . . . . 199
+- 12.21. SessionType. . . . . . . . . . . . . . . . . . . . . . 200
+- 12.22. The Private or Public Extension Key Format . . . . . . 200
+- 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 201
+- 13.1. Naming Requirements. . . . . . . . . . . . . . . . . . 203
+- 13.2. Mechanism Specification Requirements . . . . . . . . . 203
+- 13.3. Publication Requirements . . . . . . . . . . . . . . . 203
+- 13.4. Security Requirements. . . . . . . . . . . . . . . . . 203
+- 13.5. Registration Procedure . . . . . . . . . . . . . . . . 204
+- 13.5.1. Present the iSCSI extension item to the
+- Community. . . . . . . . . . . . . . . . . . 204
+- 13.5.2. iSCSI extension item review and IESG
+- approval . . . . . . . . . . . . . . . . . . 204
+-
+-
+-
+-Satran, et al. Standards Track [Page 8]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 13.5.3. IANA Registration. . . . . . . . . . . . . . 204
+- 13.5.4. Standard iSCSI extension item-label format . 204
+- 13.6. IANA Procedures for Registering iSCSI extension items. 205
+- References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
+- Appendix A. Sync and Steering with Fixed Interval Markers . . . . 209
+- A.1. Markers At Fixed Intervals . . . . . . . . . . . . . . 209
+- A.2. Initial Marker-less Interval . . . . . . . . . . . . . 210
+- A.3. Negotiation. . . . . . . . . . . . . . . . . . . . . . 210
+- A.3.1. OFMarker, IFMarker . . . . . . . . . . . . . 210
+- A.3.2. OFMarkInt, IFMarkInt . . . . . . . . . . . . 211
+- Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 212
+- B.1. Read Operation Example . . . . . . . . . . . . . . . . 212
+- B.2. Write Operation Example. . . . . . . . . . . . . . . . 213
+- B.3. R2TSN/DataSN Use Examples. . . . . . . . . . . . . . . 214
+- B.4. CRC Examples . . . . . . . . . . . . . . . . . . . . . 217
+- Appendix C. Login Phase Examples . . . . . . . . . . . . . . . . 219
+- Appendix D. SendTargets Operation. . . . . . . . . . . . . . . . 229
+- Appendix E. Algorithmic Presentation of Error Recovery Classes . 233
+- E.1. General Data Structure and Procedure Description . . . 233
+- E.2. Within-command Error Recovery Algorithms . . . . . . . 234
+- E.2.1. Procedure Descriptions . . . . . . . . . . . 234
+- E.2.2. Initiator Algorithms . . . . . . . . . . . . 235
+- E.2.3. Target Algorithms. . . . . . . . . . . . . . 237
+- E.3. Within-connection Recovery Algorithms. . . . . . . . . 240
+- E.3.1. Procedure Descriptions . . . . . . . . . . . 240
+- E.3.2. Initiator Algorithms . . . . . . . . . . . . 241
+- E.3.3. Target Algorithms. . . . . . . . . . . . . . 243
+- E.4. Connection Recovery Algorithms . . . . . . . . . . . . 243
+- E.4.1. Procedure Descriptions . . . . . . . . . . . 243
+- E.4.2. Initiator Algorithms . . . . . . . . . . . . 244
+- E.4.3. Target Algorithms. . . . . . . . . . . . . . 246
+- Appendix F. Clearing Effects of Various Events on Targets. . . . 249
+- F.1. Clearing Effects on iSCSI Objects. . . . . . . . . . . 249
+- F.2. Clearing Effects on SCSI Objects . . . . . . . . . . . 253
+- Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 254
+- Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 256
+- Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 257
+-
+-1. Introduction
+-
+- The Small Computer Systems Interface (SCSI) is a popular family of
+- protocols for communicating with I/O devices, especially storage
+- devices. SCSI is a client-server architecture. Clients of a SCSI
+- interface are called "initiators". Initiators issue SCSI "commands"
+- to request services from components, logical units of a server known
+- as a "target". A "SCSI transport" maps the client-server SCSI
+- protocol to a specific interconnect. An Initiator is one endpoint of
+- a SCSI transport and a target is the other endpoint.
+-
+-
+-
+-Satran, et al. Standards Track [Page 9]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The SCSI protocol has been mapped over various transports, including
+- Parallel SCSI, IPI, IEEE-1394 (firewire) and Fibre Channel. These
+- transports are I/O specific and have limited distance capabilities.
+-
+- The iSCSI protocol defined in this document describes a means of
+- transporting SCSI packets over TCP/IP (see [RFC791], [RFC793],
+- [RFC1035], [RFC1122]), providing for an interoperable solution which
+- can take advantage of existing Internet infrastructure, Internet
+- management facilities, and address distance limitations.
+-
+-2. Definitions and Acronyms
+-
+-2.1. Definitions
+-
+- - Alias: An alias string can also be associated with an iSCSI Node.
+- The alias allows an organization to associate a user-friendly
+- string with the iSCSI Name. However, the alias string is not a
+- substitute for the iSCSI Name.
+-
+- - CID (Connection ID): Connections within a session are identified by
+- a connection ID. It is a unique ID for this connection within the
+- session for the initiator. It is generated by the initiator and
+- presented to the target during login requests and during logouts
+- that close connections.
+-
+- - Connection: A connection is a TCP connection. Communication
+- between the initiator and target occurs over one or more TCP
+- connections. The TCP connections carry control messages, SCSI
+- commands, parameters, and data within iSCSI Protocol Data Units
+- (iSCSI PDUs).
+-
+- - iSCSI Device: A SCSI Device using an iSCSI service delivery
+- subsystem. Service Delivery Subsystem is defined by [SAM2] as a
+- transport mechanism for SCSI commands and responses.
+-
+- - iSCSI Initiator Name: The iSCSI Initiator Name specifies the
+- worldwide unique name of the initiator.
+-
+- - iSCSI Initiator Node: The "initiator". The word "initiator" has
+- been appropriately qualified as either a port or a device in the
+- rest of the document when the context is ambiguous. All
+- unqualified usages of "initiator" refer to an initiator port (or
+- device) depending on the context.
+-
+- - iSCSI Layer: This layer builds/receives iSCSI PDUs and
+- relays/receives them to/from one or more TCP connections that form
+- an initiator-target "session".
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 10]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - iSCSI Name: The name of an iSCSI initiator or iSCSI target.
+-
+- - iSCSI Node: The iSCSI Node represents a single iSCSI initiator or
+- iSCSI target. There are one or more iSCSI Nodes within a Network
+- Entity. The iSCSI Node is accessible via one or more Network
+- Portals. An iSCSI Node is identified by its iSCSI Name. The
+- separation of the iSCSI Name from the addresses used by and for the
+- iSCSI Node allows multiple iSCSI Nodes to use the same address, and
+- the same iSCSI Node to use multiple addresses.
+-
+- - iSCSI Target Name: The iSCSI Target Name specifies the worldwide
+- unique name of the target.
+-
+- - iSCSI Target Node: The "target".
+-
+- - iSCSI Task: An iSCSI task is an iSCSI request for which a response
+- is expected.
+-
+- - iSCSI Transfer Direction: The iSCSI transfer direction is defined
+- with regard to the initiator. Outbound or outgoing transfers are
+- transfers from the initiator to the target, while inbound or
+- incoming transfers are from the target to the initiator.
+-
+- - ISID: The initiator part of the Session Identifier. It is
+- explicitly specified by the initiator during Login.
+-
+- - I_T nexus: According to [SAM2], the I_T nexus is a relationship
+- between a SCSI Initiator Port and a SCSI Target Port. For iSCSI,
+- this relationship is a session, defined as a relationship between
+- an iSCSI Initiator's end of the session (SCSI Initiator Port) and
+- the iSCSI Target's Portal Group. The I_T nexus can be identified
+- by the conjunction of the SCSI port names; that is, the I_T nexus
+- identifier is the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI
+- Target Name + ',t,'+ Portal Group Tag).
+-
+- - Network Entity: The Network Entity represents a device or gateway
+- that is accessible from the IP network. A Network Entity must have
+- one or more Network Portals, each of which can be used to gain
+- access to the IP network by some iSCSI Nodes contained in that
+- Network Entity.
+-
+- - Network Portal: The Network Portal is a component of a Network
+- Entity that has a TCP/IP network address and that may be used by an
+- iSCSI Node within that Network Entity for the connection(s) within
+- one of its iSCSI sessions. A Network Portal in an initiator is
+- identified by its IP address. A Network Portal in a target is
+- identified by its IP address and its listening TCP port.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 11]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - Originator: In a negotiation or exchange, the party that initiates
+- the negotiation or exchange.
+-
+- - PDU (Protocol Data Unit): The initiator and target divide their
+- communications into messages. The term "iSCSI protocol data unit"
+- (iSCSI PDU) is used for these messages.
+-
+- - Portal Groups: iSCSI supports multiple connections within the same
+- session; some implementations will have the ability to combine
+- connections in a session across multiple Network Portals. A Portal
+- Group defines a set of Network Portals within an iSCSI Network
+- Entity that collectively supports the capability of coordinating a
+- session with connections spanning these portals. Not all Network
+- Portals within a Portal Group need participate in every session
+- connected through that Portal Group. One or more Portal Groups may
+- provide access to an iSCSI Node. Each Network Portal, as utilized
+- by a given iSCSI Node, belongs to exactly one portal group within
+- that node.
+-
+- - Portal Group Tag: This 16-bit quantity identifies a Portal Group
+- within an iSCSI Node. All Network Portals with the same portal
+- group tag in the context of a given iSCSI Node are in the same
+- Portal Group.
+-
+- - Recovery R2T: An R2T generated by a target upon detecting the loss
+- of one or more Data-Out PDUs through one of the following means: a
+- digest error, a sequence error, or a sequence reception timeout. A
+- recovery R2T carries the next unused R2TSN, but requests all or
+- part of the data burst that an earlier R2T (with a lower R2TSN) had
+- already requested.
+-
+- - Responder: In a negotiation or exchange, the party that responds to
+- the originator of the negotiation or exchange.
+-
+- - SCSI Device: This is the SAM2 term for an entity that contains one
+- or more SCSI ports that are connected to a service delivery
+- subsystem and supports a SCSI application protocol. For example, a
+- SCSI Initiator Device contains one or more SCSI Initiator Ports and
+- zero or more application clients. A Target Device contains one or
+- more SCSI Target Ports and one or more device servers and
+- associated logical units. For iSCSI, the SCSI Device is the
+- component within an iSCSI Node that provides the SCSI
+- functionality. As such, there can be at most, one SCSI Device
+- within a given iSCSI Node. Access to the SCSI Device can only be
+- achieved in an iSCSI normal operational session. The SCSI Device
+- Name is defined to be the iSCSI Name of the node.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 12]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - SCSI Layer: This builds/receives SCSI CDBs (Command Descriptor
+- Blocks) and relays/receives them with the remaining command execute
+- [SAM2] parameters to/from the iSCSI Layer.
+-
+- - Session: The group of TCP connections that link an initiator with a
+- target form a session (loosely equivalent to a SCSI I-T nexus).
+- TCP connections can be added and removed from a session. Across
+- all connections within a session, an initiator sees one and the
+- same target.
+-
+- - SCSI Initiator Port: This maps to the endpoint of an iSCSI normal
+- operational session. An iSCSI normal operational session is
+- negotiated through the login process between an iSCSI initiator
+- node and an iSCSI target node. At successful completion of this
+- process, a SCSI Initiator Port is created within the SCSI Initiator
+- Device. The SCSI Initiator Port Name and SCSI Initiator Port
+- Identifier are both defined to be the iSCSI Initiator Name together
+- with (a) a label that identifies it as an initiator port
+- name/identifier and (b) the ISID portion of the session identifier.
+-
+- - SCSI Port: This is the SAM2 term for an entity in a SCSI Device
+- that provides the SCSI functionality to interface with a service
+- delivery subsystem. For iSCSI, the definition of the SCSI
+- Initiator Port and the SCSI Target Port are different.
+-
+- - SCSI Port Name: A name made up as UTF-8 [RFC2279] characters and
+- includes the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag.
+-
+-
+- - SCSI Target Port: This maps to an iSCSI Target Portal Group.
+-
+- - SCSI Target Port Name and SCSI Target Port Identifier: These are
+- both defined to be the iSCSI Target Name together with (a) a label
+- that identifies it as a target port name/identifier and (b) the
+- portal group tag.
+-
+- - SSID (Session ID): A session between an iSCSI initiator and an
+- iSCSI target is defined by a session ID that is a tuple composed of
+- an initiator part (ISID) and a target part (Target Portal Group
+- Tag). The ISID is explicitly specified by the initiator at session
+- establishment. The Target Portal Group Tag is implied by the
+- initiator through the selection of the TCP endpoint at connection
+- establishment. The TargetPortalGroupTag key must also be returned
+- by the target as a confirmation during connection establishment
+- when TargetName is given.
+-
+- - Target Portal Group Tag: A numerical identifier (16-bit) for an
+- iSCSI Target Portal Group.
+-
+-
+-
+-Satran, et al. Standards Track [Page 13]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - TSIH (Target Session Identifying Handle): A target assigned tag for
+- a session with a specific named initiator. The target generates it
+- during session establishment. Its internal format and content are
+- not defined by this protocol, except for the value 0 that is
+- reserved and used by the initiator to indicate a new session. It
+- is given to the target during additional connection establishment
+- for the same session.
+-
+-2.2. Acronyms
+-
+- Acronym Definition
+- ------------------------------------------------------------
+- 3DES Triple Data Encryption Standard
+- ACA Auto Contingent Allegiance
+- AEN Asynchronous Event Notification
+- AES Advanced Encryption Standard
+- AH Additional Header (not the IPsec AH!)
+- AHS Additional Header Segment
+- API Application Programming Interface
+- ASC Additional Sense Code
+- ASCII American Standard Code for Information Interchange
+- ASCQ Additional Sense Code Qualifier
+- BHS Basic Header Segment
+- CBC Cipher Block Chaining
+- CD Compact Disk
+- CDB Command Descriptor Block
+- CHAP Challenge Handshake Authentication Protocol
+- CID Connection ID
+- CO Connection Only
+- CRC Cyclic Redundancy Check
+- CRL Certificate Revocation List
+- CSG Current Stage
+- CSM Connection State Machine
+- DES Data Encryption Standard
+- DNS Domain Name Server
+- DOI Domain of Interpretation
+- DVD Digital Versatile Disk
+- ESP Encapsulating Security Payload
+- EUI Extended Unique Identifier
+- FFP Full Feature Phase
+- FFPO Full Feature Phase Only
+- FIM Fixed Interval Marker
+- Gbps Gigabits per Second
+- HBA Host Bus Adapter
+- HMAC Hashed Message Authentication Code
+- I_T Initiator_Target
+- I_T_L Initiator_Target_LUN
+- IANA Internet Assigned Numbers Authority
+-
+-
+-
+-Satran, et al. Standards Track [Page 14]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- ID Identifier
+- IDN Internationalized Domain Name
+- IEEE Institute of Electrical & Electronics Engineers
+- IETF Internet Engineering Task Force
+- IKE Internet Key Exchange
+- I/O Input - Output
+- IO Initialize Only
+- IP Internet Protocol
+- IPsec Internet Protocol Security
+- IPv4 Internet Protocol Version 4
+- IPv6 Internet Protocol Version 6
+- IQN iSCSI Qualified Name
+- ISID Initiator Session ID
+- ITN iSCSI Target Name
+- ITT Initiator Task Tag
+- KRB5 Kerberos V5
+- LFL Lower Functional Layer
+- LTDS Logical-Text-Data-Segment
+- LO Leading Only
+- LU Logical Unit
+- LUN Logical Unit Number
+- MAC Message Authentication Codes
+- NA Not Applicable
+- NIC Network Interface Card
+- NOP No Operation
+- NSG Next Stage
+- OS Operating System
+- PDU Protocol Data Unit
+- PKI Public Key Infrastructure
+- R2T Ready To Transfer
+- R2TSN Ready To Transfer Sequence Number
+- RDMA Remote Direct Memory Access
+- RFC Request For Comments
+- SAM SCSI Architecture Model
+- SAM2 SCSI Architecture Model - 2
+- SAN Storage Area Network
+- SCSI Small Computer Systems Interface
+- SN Sequence Number
+- SNACK Selective Negative Acknowledgment - also
+- Sequence Number Acknowledgement for data
+- SPKM Simple Public-Key Mechanism
+- SRP Secure Remote Password
+- SSID Session ID
+- SW Session Wide
+- TCB Task Control Block
+- TCP Transmission Control Protocol
+- TPGT Target Portal Group Tag
+- TSIH Target Session Identifying Handle
+-
+-
+-
+-Satran, et al. Standards Track [Page 15]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- TTT Target Transfer Tag
+- UFL Upper Functional Layer
+- ULP Upper Level Protocol
+- URN Uniform Resource Names [RFC2396]
+- UTF Universal Transformation Format
+- WG Working Group
+-
+-2.3. Conventions
+-
+- In examples, "I->" and "T->" show iSCSI PDUs sent by the initiator
+- and target respectively.
+-
+- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+- document are to be interpreted as described in BCP 14 [RFC2119].
+-
+- iSCSI messages - PDUs - are represented by diagrams as in the
+- following example:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0| Basic Header Segment (BHS) |
+- +---------------+---------------+---------------+---------------+
+- ----------
+- +| |
+- +---------------+---------------+---------------+---------------+
+-
+- The diagrams include byte and bit numbering.
+-
+- The following representation and ordering rules are observed in this
+- document:
+-
+- - Word Rule
+- - Half-word Rule
+- - Byte Rule
+-
+-2.3.1. Word Rule
+-
+- A word holds four consecutive bytes. Whenever a word has numeric
+- content, it is considered an unsigned number in base 2 positional
+- representation with the lowest numbered byte (e.g., byte 0) bit 0
+- representing 2**31 and bit 1 representing 2**30 through lowest
+- numbered byte + 3 (e.g., byte 3) bit 7 representing 2**0.
+-
+- Decimal and hexadecimal representation of word values map this
+- representation to decimal or hexadecimal positional notation.
+-
+-
+-
+-Satran, et al. Standards Track [Page 16]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-2.3.2. Half-Word Rule
+-
+- A half-word holds two consecutive bytes. Whenever a half-word has
+- numeric content it is considered an unsigned number in base 2
+- positional representation with the lowest numbered byte (e.g., byte
+- 0), bit 0 representing 2**15 and bit 1 representing 2**14 through
+- lowest numbered byte + 1 (e.g., byte 1), bit 7 representing 2**0.
+-
+- Decimal and hexadecimal representation of half-word values map this
+- representation to decimal or hexadecimal positional notation.
+-
+-2.3.3. Byte Rule
+-
+- For every PDU, bytes are sent and received in increasing numbered
+- order (network order).
+-
+- Whenever a byte has numerical content, it is considered an unsigned
+- number in base 2 positional representation with bit 0 representing
+- 2**7 and bit 1 representing 2**6 through bit 7 representing 2**0.
+-
+-3. Overview
+-
+-3.1. SCSI Concepts
+-
+- The SCSI Architecture Model-2 [SAM2] describes in detail the
+- architecture of the SCSI family of I/O protocols. This section
+- provides a brief background of the SCSI architecture and is intended
+- to familiarize readers with its terminology.
+-
+- At the highest level, SCSI is a family of interfaces for requesting
+- services from I/O devices, including hard drives, tape drives, CD and
+- DVD drives, printers, and scanners. In SCSI terminology, an
+- individual I/O device is called a "logical unit" (LU).
+-
+- SCSI is a client-server architecture. Clients of a SCSI interface
+- are called "initiators". Initiators issue SCSI "commands" to request
+- services from components, logical units, of a server known as a
+- "target". The "device server" on the logical unit accepts SCSI
+- commands and processes them.
+-
+- A "SCSI transport" maps the client-server SCSI protocol to a specific
+- interconnect. Initiators are one endpoint of a SCSI transport. The
+- "target" is the other endpoint. A target can contain multiple
+- Logical Units (LUs). Each Logical Unit has an address within a
+- target called a Logical Unit Number (LUN).
+-
+- A SCSI task is a SCSI command or possibly a linked set of SCSI
+- commands. Some LUs support multiple pending (queued) tasks, but the
+-
+-
+-
+-Satran, et al. Standards Track [Page 17]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- queue of tasks is managed by the logical unit. The target uses an
+- initiator provided "task tag" to distinguish between tasks. Only one
+- command in a task can be outstanding at any given time.
+-
+- Each SCSI command results in an optional data phase and a required
+- response phase. In the data phase, information can travel from the
+- initiator to target (e.g., WRITE), target to initiator (e.g., READ),
+- or in both directions. In the response phase, the target returns the
+- final status of the operation, including any errors.
+-
+- Command Descriptor Blocks (CDB) are the data structures used to
+- contain the command parameters that an initiator sends to a target.
+- The CDB content and structure is defined by [SAM2] and device-type
+- specific SCSI standards.
+-
+-3.2. iSCSI Concepts and Functional Overview
+-
+- The iSCSI protocol is a mapping of the SCSI remote procedure
+- invocation model (see [SAM2]) over the TCP protocol. SCSI commands
+- are carried by iSCSI requests and SCSI responses and status are
+- carried by iSCSI responses. iSCSI also uses the request response
+- mechanism for iSCSI protocol mechanisms.
+-
+- For the remainder of this document, the terms "initiator" and
+- "target" refer to "iSCSI initiator node" and "iSCSI target node",
+- respectively (see Section 3.4.1 iSCSI Architecture Model) unless
+- otherwise qualified.
+-
+- In keeping with similar protocols, the initiator and target divide
+- their communications into messages. This document uses the term
+- "iSCSI protocol data unit" (iSCSI PDU) for these messages.
+-
+- For performance reasons, iSCSI allows a "phase-collapse". A command
+- and its associated data may be shipped together from initiator to
+- target, and data and responses may be shipped together from targets.
+-
+- The iSCSI transfer direction is defined with respect to the
+- initiator. Outbound or outgoing transfers are transfers from an
+- initiator to a target, while inbound or incoming transfers are from a
+- target to an initiator.
+-
+- An iSCSI task is an iSCSI request for which a response is expected.
+-
+- In this document "iSCSI request", "iSCSI command", request, or
+- (unqualified) command have the same meaning. Also, unless otherwise
+- specified, status, response, or numbered response have the same
+- meaning.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 18]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-3.2.1. Layers and Sessions
+-
+- The following conceptual layering model is used to specify initiator
+- and target actions and the way in which they relate to transmitted
+- and received Protocol Data Units:
+-
+- a) the SCSI layer builds/receives SCSI CDBs (Command Descriptor
+- Blocks) and passes/receives them with the remaining command
+- execute parameters ([SAM2]) to/from
+-
+- b) the iSCSI layer that builds/receives iSCSI PDUs and
+- relays/receives them to/from one or more TCP connections; the
+- group of connections form an initiator-target "session".
+-
+- Communication between the initiator and target occurs over one or
+- more TCP connections. The TCP connections carry control messages,
+- SCSI commands, parameters, and data within iSCSI Protocol Data Units
+- (iSCSI PDUs). The group of TCP connections that link an initiator
+- with a target form a session (loosely equivalent to a SCSI I_T nexus,
+- see Section 3.4.2 SCSI Architecture Model). A session is defined by
+- a session ID that is composed of an initiator part and a target part.
+- TCP connections can be added and removed from a session. Each
+- connection within a session is identified by a connection ID (CID).
+-
+- Across all connections within a session, an initiator sees one
+- "target image". All target identifying elements, such as LUN, are
+- the same. A target also sees one "initiator image" across all
+- connections within a session. Initiator identifying elements, such
+- as the Initiator Task Tag, are global across the session regardless
+- of the connection on which they are sent or received.
+-
+- iSCSI targets and initiators MUST support at least one TCP connection
+- and MAY support several connections in a session. For error recovery
+- purposes, targets and initiators that support a single active
+- connection in a session SHOULD support two connections during
+- recovery.
+-
+-3.2.2. Ordering and iSCSI Numbering
+-
+- iSCSI uses Command and Status numbering schemes and a Data sequencing
+- scheme.
+-
+- Command numbering is session-wide and is used for ordered command
+- delivery over multiple connections. It can also be used as a
+- mechanism for command flow control over a session.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 19]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Status numbering is per connection and is used to enable missing
+- status detection and recovery in the presence of transient or
+- permanent communication errors.
+-
+- Data sequencing is per command or part of a command (R2T triggered
+- sequence) and is used to detect missing data and/or R2T PDUs due to
+- header digest errors.
+-
+- Typically, fields in the iSCSI PDUs communicate the Sequence Numbers
+- between the initiator and target. During periods when traffic on a
+- connection is unidirectional, iSCSI NOP-Out/In PDUs may be utilized
+- to synchronize the command and status ordering counters of the target
+- and initiator.
+-
+- The iSCSI session abstraction is equivalent to the SCSI I_T nexus,
+- and the iSCSI session provides an ordered command delivery from the
+- SCSI initiator to the SCSI target. For detailed design
+- considerations that led to the iSCSI session model as it is defined
+- here and how it relates the SCSI command ordering features defined in
+- SCSI specifications to the iSCSI concepts see [CORD].
+-
+-3.2.2.1. Command Numbering and Acknowledging
+-
+- iSCSI performs ordered command delivery within a session. All
+- commands (initiator-to-target PDUs) in transit from the initiator to
+- the target are numbered.
+-
+- iSCSI considers a task to be instantiated on the target in response
+- to every request issued by the initiator. A set of task management
+- operations including abort and reassign (see Section 10.5 Task
+- Management Function Request) may be performed on any iSCSI task.
+-
+- Some iSCSI tasks are SCSI tasks, and many SCSI activities are related
+- to a SCSI task ([SAM2]). In all cases, the task is identified by the
+- Initiator Task Tag for the life of the task.
+-
+- The command number is carried by the iSCSI PDU as CmdSN
+- (Command Sequence Number). The numbering is session-wide. Outgoing
+- iSCSI PDUs carry this number. The iSCSI initiator allocates CmdSNs
+- with a 32-bit unsigned counter (modulo 2**32). Comparisons and
+- arithmetic on CmdSN use Serial Number Arithmetic as defined in
+- [RFC1982] where SERIAL_BITS = 32.
+-
+- Commands meant for immediate delivery are marked with an immediate
+- delivery flag; they MUST also carry the current CmdSN. CmdSN does
+- not advance after a command marked for immediate delivery is sent.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 20]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Command numbering starts with the first login request on the first
+- connection of a session (the leading login on the leading connection)
+- and command numbers are incremented by 1 for every non-immediate
+- command issued afterwards.
+-
+- If immediate delivery is used with task management commands, these
+- commands may reach the target before the tasks on which they are
+- supposed to act. However their CmdSN serves as a marker of their
+- position in the stream of commands. The initiator and target must
+- ensure that the task management commands act as specified by [SAM2].
+- For example, both commands and responses appear as if delivered in
+- order. Whenever CmdSN for an outgoing PDU is not specified by an
+- explicit rule, CmdSN will carry the current value of the local CmdSN
+- variable (see later in this section).
+-
+- The means by which an implementation decides to mark a PDU for
+- immediate delivery or by which iSCSI decides by itself to mark a PDU
+- for immediate delivery are beyond the scope of this document.
+-
+- The number of commands used for immediate delivery is not limited and
+- their delivery for execution is not acknowledged through the
+- numbering scheme. Immediate commands MAY be rejected by the iSCSI
+- target layer due to a lack of resources. An iSCSI target MUST be
+- able to handle at least one immediate task management command and one
+- immediate non-task-management iSCSI command per connection at any
+- time.
+-
+- In this document, delivery for execution means delivery to the SCSI
+- execution engine or an iSCSI protocol specific execution engine
+- (e.g., for text requests with public or private extension keys
+- involving an execution component). With the exception of the
+- commands marked for immediate delivery, the iSCSI target layer MUST
+- deliver the commands for execution in the order specified by CmdSN.
+- Commands marked for immediate delivery may be delivered by the iSCSI
+- target layer for execution as soon as detected. iSCSI may avoid
+- delivering some commands to the SCSI target layer if required by a
+- prior SCSI or iSCSI action (e.g., CLEAR TASK SET Task Management
+- request received before all the commands on which it was supposed to
+- act).
+-
+- On any connection, the iSCSI initiator MUST send the commands in
+- increasing order of CmdSN, except for commands that are retransmitted
+- due to digest error recovery and connection recovery.
+-
+- For the numbering mechanism, the initiator and target maintain the
+- following three variables for each session:
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 21]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - CmdSN - the current command Sequence Number, advanced by 1 on
+- each command shipped except for commands marked for immediate
+- delivery. CmdSN always contains the number to be assigned to
+- the next Command PDU.
+- - ExpCmdSN - the next expected command by the target. The target
+- acknowledges all commands up to, but not including, this
+- number. The initiator treats all commands with CmdSN less than
+- ExpCmdSN as acknowledged. The target iSCSI layer sets the
+- ExpCmdSN to the largest non-immediate CmdSN that it can deliver
+- for execution plus 1 (no holes in the CmdSN sequence).
+- - MaxCmdSN - the maximum number to be shipped. The queuing
+- capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN +
+- 1.
+-
+- The initiator's ExpCmdSN and MaxCmdSN are derived from
+- target-to-initiator PDU fields. Comparisons and arithmetic on
+- ExpCmdSN and MaxCmdSN MUST use Serial Number Arithmetic as defined in
+- [RFC1982] where SERIAL_BITS = 32.
+-
+- The target MUST NOT transmit a MaxCmdSN that is less than
+- ExpCmdSN-1. For non-immediate commands, the CmdSN field can take any
+- value from ExpCmdSN to MaxCmdSN inclusive. The target MUST silently
+- ignore any non-immediate command outside of this range or non-
+- immediate duplicates within the range. The CmdSN carried by
+- immediate commands may lie outside the ExpCmdSN to MaxCmdSN range.
+- For example, if the initiator has previously sent a non-immediate
+- command carrying the CmdSN equal to MaxCmdSN, the target window is
+- closed. For group task management commands issued as immediate
+- commands, CmdSN indicates the scope of the group action (e.g., on
+- ABORT TASK SET indicates which commands are aborted).
+-
+- MaxCmdSN and ExpCmdSN fields are processed by the initiator as
+- follows:
+-
+- - If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial
+- Arithmetic Sense), they are both ignored.
+- - If the PDU MaxCmdSN is greater than the local MaxCmdSN (in
+- Serial Arithmetic Sense), it updates the local MaxCmdSN;
+- otherwise, it is ignored.
+- - If the PDU ExpCmdSN is greater than the local ExpCmdSN (in
+- Serial Arithmetic Sense), it updates the local ExpCmdSN;
+- otherwise, it is ignored.
+-
+- This sequence is required because updates may arrive out of order
+- (e.g., the updates are sent on different TCP connections).
+-
+- iSCSI initiators and targets MUST support the command numbering
+- scheme.
+-
+-
+-
+-Satran, et al. Standards Track [Page 22]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A numbered iSCSI request will not change its allocated CmdSN,
+- regardless of the number of times and circumstances in which it is
+- reissued (see Section 6.2.1 Usage of Retry). At the target, CmdSN is
+- only relevant when the command has not created any state related to
+- its execution (execution state); afterwards, CmdSN becomes
+- irrelevant. Testing for the execution state (represented by
+- identifying the Initiator Task Tag) MUST precede any other action at
+- the target. If no execution state is found, it is followed by
+- ordering and delivery. If an execution state is found, it is
+- followed by delivery.
+-
+- If an initiator issues a command retry for a command with CmdSN R on
+- a connection when the session CmdSN value is Q, it MUST NOT advance
+- the CmdSN past R + 2**31 -1 unless the connection is no longer
+- operational (i.e., it has returned to the FREE state, see Section
+- 7.1.3 Standard Connection State Diagram for an Initiator), the
+- connection has been reinstated (see Section 5.3.4 Connection
+- Reinstatement), or a non-immediate command with CmdSN equal or
+- greater than Q was issued subsequent to the command retry on the same
+- connection and the reception of that command is acknowledged by the
+- target (see Section 9.4 Command Retry and Cleaning Old Command
+- Instances).
+-
+- A target MUST NOT issue a command response or Data-In PDU with status
+- before acknowledging the command. However, the acknowledgement can
+- be included in the response or Data-In PDU.
+-
+-3.2.2.2. Response/Status Numbering and Acknowledging
+-
+- Responses in transit from the target to the initiator are numbered.
+- The StatSN (Status Sequence Number) is used for this purpose. StatSN
+- is a counter maintained per connection. ExpStatSN is used by the
+- initiator to acknowledge status. The status sequence number space is
+- 32-bit unsigned-integers and the arithmetic operations are the
+- regular mod(2**32) arithmetic.
+-
+- Status numbering starts with the Login response to the first Login
+- request of the connection. The Login response includes an initial
+- value for status numbering (any initial value is valid).
+-
+- To enable command recovery, the target MAY maintain enough state
+- information for data and status recovery after a connection failure.
+- A target doing so can safely discard all of the state information
+- maintained for recovery of a command after the delivery of the status
+- for the command (numbered StatSN) is acknowledged through ExpStatSN.
+-
+- A large absolute difference between StatSN and ExpStatSN may indicate
+- a failed connection. Initiators MUST undertake recovery actions if
+-
+-
+-
+-Satran, et al. Standards Track [Page 23]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- the difference is greater than an implementation defined constant
+- that MUST NOT exceed 2**31-1.
+-
+- Initiators and Targets MUST support the response-numbering scheme.
+-
+-3.2.2.3. Data Sequencing
+-
+- Data and R2T PDUs transferred as part of some command execution MUST
+- be sequenced. The DataSN field is used for data sequencing. For
+- input (read) data PDUs, DataSN starts with 0 for the first data PDU
+- of an input command and advances by 1 for each subsequent data PDU.
+- For output data PDUs, DataSN starts with 0 for the first data PDU of
+- a sequence (the initial unsolicited sequence or any data PDU sequence
+- issued to satisfy an R2T) and advances by 1 for each subsequent data
+- PDU. R2Ts are also sequenced per command. For example, the first
+- R2T has an R2TSN of 0 and advances by 1 for each subsequent R2T. For
+- bidirectional commands, the target uses the DataSN/R2TSN to sequence
+- Data-In and R2T PDUs in one continuous sequence (undifferentiated).
+- Unlike command and status, data PDUs and R2Ts are not acknowledged by
+- a field in regular outgoing PDUs. Data-In PDUs can be acknowledged
+- on demand by a special form of the SNACK PDU. Data and R2T PDUs are
+- implicitly acknowledged by status for the command. The DataSN/R2TSN
+- field enables the initiator to detect missing data or R2T PDUs.
+-
+- For any read or bidirectional command, a target MUST issue less than
+- 2**32 combined R2T and Data-In PDUs. Any output data sequence MUST
+- contain less than 2**32 Data-Out PDUs.
+-
+-3.2.3. iSCSI Login
+-
+- The purpose of the iSCSI login is to enable a TCP connection for
+- iSCSI use, authentication of the parties, negotiation of the
+- session's parameters and marking of the connection as belonging to an
+- iSCSI session.
+-
+- A session is used to identify to a target all the connections with a
+- given initiator that belong to the same I_T nexus. (For more details
+- on how a session relates to an I_T nexus, see Section 3.4.2 SCSI
+- Architecture Model).
+-
+- The targets listen on a well-known TCP port or other TCP port for
+- incoming connections. The initiator begins the login process by
+- connecting to one of these TCP ports.
+-
+- As part of the login process, the initiator and target SHOULD
+- authenticate each other and MAY set a security association protocol
+- for the session. This can occur in many different ways and is
+- subject to negotiation.
+-
+-
+-
+-Satran, et al. Standards Track [Page 24]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- To protect the TCP connection, an IPsec security association MAY be
+- established before the Login request. For information on using IPsec
+- security for iSCSI see Chapter 8 and [RFC3723].
+-
+- The iSCSI Login Phase is carried through Login requests and
+- responses. Once suitable authentication has occurred and operational
+- parameters have been set, the session transitions to the Full Feature
+- Phase and the initiator may start to send SCSI commands. The
+- security policy for whether, and by what means, a target chooses to
+- authorize an initiator is beyond the scope of this document. For a
+- more detailed description of the Login Phase, see Chapter 5.
+-
+- The login PDU includes the ISID part of the session ID (SSID). The
+- target portal group that services the login is implied by the
+- selection of the connection endpoint. For a new session, the TSIH is
+- zero. As part of the response, the target generates a TSIH.
+-
+- During session establishment, the target identifies the SCSI
+- initiator port (the "I" in the "I_T nexus") through the value pair
+- (InitiatorName, ISID). We describe InitiatorName later in this
+- section. Any persistent state (e.g., persistent reservations) on the
+- target that is associated with a SCSI initiator port is identified
+- based on this value pair. Any state associated with the SCSI target
+- port (the "T" in the "I_T nexus") is identified externally by the
+- TargetName and portal group tag (see Section 3.4.1 iSCSI Architecture
+- Model). ISID is subject to reuse restrictions because it is used to
+- identify a persistent state (see Section 3.4.3 Consequences of the
+- Model).
+-
+- Before the Full Feature Phase is established, only Login Request and
+- Login Response PDUs are allowed. Login requests and responses MUST
+- be used exclusively during Login. On any connection, the login phase
+- MUST immediately follow TCP connection establishment and a subsequent
+- Login Phase MUST NOT occur before tearing down a connection.
+-
+- A target receiving any PDU except a Login request before the Login
+- phase is started MUST immediately terminate the connection on which
+- the PDU was received. Once the Login phase has started, if the
+- target receives any PDU except a Login request, it MUST send a Login
+- reject (with Status "invalid during login") and then disconnect. If
+- the initiator receives any PDU except a Login response, it MUST
+- immediately terminate the connection.
+-
+-3.2.4. iSCSI Full Feature Phase
+-
+- Once the initiator is authorized to do so, the iSCSI session is in
+- the iSCSI Full Feature Phase. A session is in Full Feature Phase
+- after successfully finishing the Login Phase on the first (leading)
+-
+-
+-
+-Satran, et al. Standards Track [Page 25]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- connection of a session. A connection is in Full Feature Phase if
+- the session is in Full Feature Phase and the connection login has
+- completed successfully. An iSCSI connection is not in Full Feature
+- Phase
+-
+- a) when it does not have an established transport connection,
+-
+- OR
+-
+- b) when it has a valid transport connection, but a successful
+- login was not performed or the connection is currently logged
+- out.
+-
+- In a normal Full Feature Phase, the initiator may send SCSI commands
+- and data to the various LUs on the target by encapsulating them in
+- iSCSI PDUs that go over the established iSCSI session.
+-
+-3.2.4.1. Command Connection Allegiance
+-
+- For any iSCSI request issued over a TCP connection, the corresponding
+- response and/or other related PDU(s) MUST be sent over the same
+- connection. We call this "connection allegiance". If the original
+- connection fails before the command is completed, the connection
+- allegiance of the command may be explicitly reassigned to a different
+- transport connection as described in detail in Section 6.2 Retry and
+- Reassign in Recovery.
+-
+- Thus, if an initiator issues a READ command, the target MUST send the
+- requested data, if any, followed by the status to the initiator over
+- the same TCP connection that was used to deliver the SCSI command.
+- If an initiator issues a WRITE command, the initiator MUST send the
+- data, if any, for that command over the same TCP connection that was
+- used to deliver the SCSI command. The target MUST return Ready To
+- Transfer (R2T), if any, and the status over the same TCP connection
+- that was used to deliver the SCSI command. Retransmission requests
+- (SNACK PDUs) and the data and status that they generate MUST also use
+- the same connection.
+-
+- However, consecutive commands that are part of a SCSI linked
+- command-chain task (see [SAM2]) MAY use different connections.
+- Connection allegiance is strictly per-command and not per-task.
+- During the iSCSI Full Feature Phase, the initiator and target MAY
+- interleave unrelated SCSI commands, their SCSI Data, and responses
+- over the session.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 26]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-3.2.4.2. Data Transfer Overview
+-
+- Outgoing SCSI data (initiator to target user data or command
+- parameters) is sent as either solicited data or unsolicited data.
+- Solicited data are sent in response to R2T PDUs. Unsolicited data
+- can be sent as part of an iSCSI command PDU ("immediate data") or in
+- separate iSCSI data PDUs.
+-
+- Immediate data are assumed to originate at offset 0 in the initiator
+- SCSI write-buffer (outgoing data buffer). All other Data PDUs have
+- the buffer offset set explicitly in the PDU header.
+-
+- An initiator may send unsolicited data up to FirstBurstLength as
+- immediate (up to the negotiated maximum PDU length), in a separate
+- PDU sequence or both. All subsequent data MUST be solicited. The
+- maximum length of an individual data PDU or the immediate-part of the
+- first unsolicited burst MAY be negotiated at login.
+-
+- The maximum amount of unsolicited data that can be sent with a
+- command is negotiated at login through the FirstBurstLength key. A
+- target MAY separately enable immediate data (through the
+- ImmediateData key) without enabling the more general (separate data
+- PDUs) form of unsolicited data (through the InitialR2T key).
+-
+- Unsolicited data on write are meant to reduce the effect of latency
+- on throughput (no R2T is needed to start sending data). In addition,
+- immediate data is meant to reduce the protocol overhead (both
+- bandwidth and execution time).
+-
+- An iSCSI initiator MAY choose not to send unsolicited data, only
+- immediate data or FirstBurstLength bytes of unsolicited data with a
+- command. If any non-immediate unsolicited data is sent, the total
+- unsolicited data MUST be either FirstBurstLength, or all of the data
+- if the total amount is less than the FirstBurstLength.
+-
+- It is considered an error for an initiator to send unsolicited data
+- PDUs to a target that operates in R2T mode (only solicited data are
+- allowed). It is also an error for an initiator to send more
+- unsolicited data, whether immediate or as separate PDUs, than
+- FirstBurstLength.
+-
+- An initiator MUST honor an R2T data request for a valid outstanding
+- command (i.e., carrying a valid Initiator Task Tag) and deliver all
+- the requested data provided the command is supposed to deliver
+- outgoing data and the R2T specifies data within the command bounds.
+- The initiator action is unspecified for receiving an R2T request that
+- specifies data, all or part, outside of the bounds of the command.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 27]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A target SHOULD NOT silently discard data and then request
+- retransmission through R2T. Initiators SHOULD NOT keep track of the
+- data transferred to or from the target (scoreboarding). SCSI targets
+- perform residual count calculation to check how much data was
+- actually transferred to or from the device by a command. This may
+- differ from the amount the initiator sent and/or received for reasons
+- such as retransmissions and errors. Read or bidirectional commands
+- implicitly solicit the transmission of the entire amount of data
+- covered by the command. SCSI data packets are matched to their
+- corresponding SCSI commands by using tags specified in the protocol.
+-
+- In addition, iSCSI initiators and targets MUST enforce some ordering
+- rules. When unsolicited data is used, the order of the unsolicited
+- data on each connection MUST match the order in which the commands on
+- that connection are sent. Command and unsolicited data PDUs may be
+- interleaved on a single connection as long as the ordering
+- requirements of each are maintained (e.g., command N+1 MAY be sent
+- before the unsolicited Data-Out PDUs for command N, but the
+- unsolicited Data-Out PDUs for command N MUST precede the unsolicited
+- Data-Out PDUs of command N+1). A target that receives data out of
+- order MAY terminate the session.
+-
+-3.2.4.3. Tags and Integrity Checks
+-
+- Initiator tags for pending commands are unique initiator-wide for a
+- session. Target tags are not strictly specified by the protocol. It
+- is assumed that target tags are used by the target to tag (alone or
+- in combination with the LUN) the solicited data. Target tags are
+- generated by the target and "echoed" by the initiator. These
+- mechanisms are designed to accomplish efficient data delivery along
+- with a large degree of control over the data flow.
+-
+- As the Initiator Task Tag is used to identify a task during its
+- execution, the iSCSI initiator and target MUST verify that all other
+- fields used in task-related PDUs have values that are consistent with
+- the values used at the task instantiation based on the Initiator Task
+- Tag (e.g., the LUN used in an R2T PDU MUST be the same as the one
+- used in the SCSI command PDU used to instantiate the task). Using
+- inconsistent field values is considered a protocol error.
+-
+-3.2.4.4. Task Management
+-
+- SCSI task management assumes that individual tasks and task groups
+- can be aborted solely based on the task tags (for individual tasks)
+- or the timing of the task management command (for task groups), and
+- that the task management action is executed synchronously - i.e., no
+- message involving an aborted task will be seen by the SCSI initiator
+- after receiving the task management response. In iSCSI initiators
+-
+-
+-
+-Satran, et al. Standards Track [Page 28]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- and targets interact asynchronously over several connections. iSCSI
+- specifies the protocol mechanism and implementation requirements
+- needed to present a synchronous view while using an asynchronous
+- infrastructure.
+-
+-3.2.5. iSCSI Connection Termination
+-
+- An iSCSI connection may be terminated by use of a transport
+- connection shutdown or a transport reset. Transport reset is assumed
+- to be an exceptional event.
+-
+- Graceful TCP connection shutdowns are done by sending TCP FINs. A
+- graceful transport connection shutdown SHOULD only be initiated by
+- either party when the connection is not in iSCSI Full Feature Phase.
+- A target MAY terminate a Full Feature Phase connection on internal
+- exception events, but it SHOULD announce the fact through an
+- Asynchronous Message PDU. Connection termination with outstanding
+- commands may require recovery actions.
+-
+- If a connection is terminated while in Full Feature Phase, connection
+- cleanup (see section 7) is required prior to recovery. By doing
+- connection cleanup before starting recovery, the initiator and target
+- will avoid receiving stale PDUs after recovery.
+-
+-3.2.6. iSCSI Names
+-
+- Both targets and initiators require names for the purpose of
+- identification. In addition, names enable iSCSI storage resources to
+- be managed regardless of location (address). An iSCSI node name is
+- also the SCSI device name of an iSCSI device. The iSCSI name of a
+- SCSI device is the principal object used in authentication of targets
+- to initiators and initiators to targets. This name is also used to
+- identify and manage iSCSI storage resources.
+-
+- iSCSI names must be unique within the operational domain of the end
+- user. However, because the operational domain of an IP network is
+- potentially worldwide, the iSCSI name formats are architected to be
+- worldwide unique. To assist naming authorities in the construction
+- of worldwide unique names, iSCSI provides two name formats for
+- different types of naming authorities.
+-
+- iSCSI names are associated with iSCSI nodes, and not iSCSI network
+- adapter cards, to ensure that the replacement of network adapter
+- cards does not require reconfiguration of all SCSI and iSCSI resource
+- allocation information.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 29]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Some SCSI commands require that protocol-specific identifiers be
+- communicated within SCSI CDBs. See Section 3.4.2 SCSI Architecture
+- Model for the definition of the SCSI port name/identifier for iSCSI
+- ports.
+-
+- An initiator may discover the iSCSI Target Names to which it has
+- access, along with their addresses, using the SendTargets text
+- request, or other techniques discussed in [RFC3721].
+-
+-3.2.6.1. iSCSI Name Properties
+-
+- Each iSCSI node, whether an initiator or target, MUST have an iSCSI
+- name.
+-
+- Initiators and targets MUST support the receipt of iSCSI names of up
+- to the maximum length of 223 bytes.
+-
+- The initiator MUST present both its iSCSI Initiator Name and the
+- iSCSI Target Name to which it wishes to connect in the first login
+- request of a new session or connection. The only exception is if a
+- discovery session (see Section 2.3 iSCSI Session Types) is to be
+- established. In this case, the iSCSI Initiator Name is still
+- required, but the iSCSI Target Name MAY be omitted.
+-
+- iSCSI names have the following properties:
+-
+- a) iSCSI names are globally unique. No two initiators or targets
+- can have the same name.
+- b) iSCSI names are permanent. An iSCSI initiator node or target
+- node has the same name for its lifetime.
+- c) iSCSI names do not imply a location or address. An iSCSI
+- initiator or target can move, or have multiple addresses. A
+- change of address does not imply a change of name.
+- d) iSCSI names do not rely on a central name broker; the naming
+- authority is distributed.
+- e) iSCSI names support integration with existing unique naming
+- schemes.
+- f) iSCSI names rely on existing naming authorities. iSCSI does
+- not create any new naming authority.
+-
+- The encoding of an iSCSI name has the following properties:
+-
+- a) iSCSI names have the same encoding method regardless of the
+- underlying protocols.
+- b) iSCSI names are relatively simple to compare. The algorithm
+- for comparing two iSCSI names for equivalence does not rely on
+- an external server.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 30]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- c) iSCSI names are composed only of displayable characters. iSCSI
+- names allow the use of international character sets but are not
+- case sensitive. No whitespace characters are used in iSCSI
+- names.
+- d) iSCSI names may be transported using both binary and
+- ASCII-based protocols.
+-
+- An iSCSI name really names a logical software entity, and is not tied
+- to a port or other hardware that can be changed. For instance, an
+- initiator name should name the iSCSI initiator node, not a particular
+- NIC or HBA. When multiple NICs are used, they should generally all
+- present the same iSCSI initiator name to the targets, because they
+- are simply paths to the same SCSI layer. In most operating systems,
+- the named entity is the operating system image.
+-
+- Similarly, a target name should not be tied to hardware interfaces
+- that can be changed. A target name should identify the logical
+- target and must be the same for the target regardless of the physical
+- portion being addressed. This assists iSCSI initiators in
+- determining that the two targets it has discovered are really two
+- paths to the same target.
+-
+- The iSCSI name is designed to fulfill the functional requirements for
+- Uniform Resource Names (URN) [RFC1737]. For example, it is required
+- that the name have a global scope, be independent of address or
+- location, and be persistent and globally unique. Names must be
+- extensible and scalable with the use of naming authorities. The name
+- encoding should be both human and machine readable. See [RFC1737]
+- for further requirements.
+-
+-3.2.6.2. iSCSI Name Encoding
+-
+- An iSCSI name MUST be a UTF-8 encoding of a string of Unicode
+- characters with the following properties:
+-
+- - It is in Normalization Form C (see "Unicode Normalization
+- Forms" [UNICODE]).
+- - It only contains characters allowed by the output of the iSCSI
+- stringprep template (described in [RFC3722]).
+- - The following characters are used for formatting iSCSI names:
+-
+- - dash ('-'=U+002d)
+- - dot ('.'=U+002e)
+- - colon (':'=U+003a)
+-
+- - The UTF-8 encoding of the name is not larger than 223 bytes.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 31]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The stringprep process is described in [RFC3454]; iSCSI's use of the
+- stringprep process is described in [RFC3722]. Stringprep is a method
+- designed by the Internationalized Domain Name (IDN) working group to
+- translate human-typed strings into a format that can be compared as
+- opaque strings. Strings MUST NOT include punctuation, spacing,
+- diacritical marks, or other characters that could get in the way of
+- readability. The stringprep process also converts strings into
+- equivalent strings of lower-case characters.
+-
+- The stringprep process does not need to be implemented if the names
+- are only generated using numeric and lower-case (any character set)
+- alphabetic characters.
+-
+- Once iSCSI names encoded in UTF-8 are "normalized" they may be safely
+- compared byte-for-byte.
+-
+-3.2.6.3. iSCSI Name Structure
+-
+- An iSCSI name consists of two parts--a type designator followed by a
+- unique name string.
+-
+- The iSCSI name does not define any new naming authorities. Instead,
+- it supports two existing ways of designating naming authorities: an
+- iSCSI-Qualified Name, using domain names to identify a naming
+- authority, and the EUI format, where the IEEE Registration Authority
+- assists in the formation of worldwide unique names (EUI-64 format).
+-
+- The type designator strings currently defined are:
+-
+- iqn. - iSCSI Qualified name
+- eui. - Remainder of the string is an IEEE EUI-64
+- identifier, in ASCII-encoded hexadecimal.
+-
+- These two naming authority designators were considered sufficient at
+- the time of writing this document. The creation of additional naming
+- type designators for iSCSI may be considered by the IETF and detailed
+- in separate RFCs.
+-
+-3.2.6.3.1. Type "iqn." (iSCSI Qualified Name)
+-
+- This iSCSI name type can be used by any organization that owns a
+- domain name. This naming format is useful when an end user or
+- service provider wishes to assign iSCSI names for targets and/or
+- initiators.
+-
+- To generate names of this type, the person or organization generating
+- the name must own a registered domain name. This domain name does
+- not have to be active, and does not have to resolve to an address; it
+-
+-
+-
+-Satran, et al. Standards Track [Page 32]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- just needs to be reserved to prevent others from generating iSCSI
+- names using the same domain name.
+-
+- Since a domain name can expire, be acquired by another entity, or may
+- be used to generate iSCSI names by both owners, the domain name must
+- be additionally qualified by a date during which the naming authority
+- owned the domain name. For this reason, a date code is provided as
+- part of the "iqn." format.
+-
+- The iSCSI qualified name string consists of:
+-
+- - The string "iqn.", used to distinguish these names from "eui."
+- formatted names.
+- - A date code, in yyyy-mm format. This date MUST be a date
+- during which the naming authority owned the domain name used in
+- this format, and SHOULD be the first month in which the domain
+- name was owned by this naming authority at 00:01 GMT of the
+- first day of the month. This date code uses the Gregorian
+- calendar. All four digits in the year must be present. Both
+- digits of the month must be present, with January == "01" and
+- December == "12". The dash must be included.
+- - A dot "."
+- - The reversed domain name of the naming authority (person or
+- organization) creating this iSCSI name.
+- - An optional, colon (:) prefixed, string within the character
+- set and length boundaries that the owner of the domain name
+- deems appropriate. This may contain product types, serial
+- numbers, host identifiers, or software keys (e.g., it may
+- include colons to separate organization boundaries). With the
+- exception of the colon prefix, the owner of the domain name can
+- assign everything after the reversed domain name as desired.
+- It is the responsibility of the entity that is the naming
+- authority to ensure that the iSCSI names it assigns are
+- worldwide unique. For example, "Example Storage Arrays, Inc.",
+- might own the domain name "example.com".
+-
+- The following are examples of iSCSI qualified names that might be
+- generated by "EXAMPLE Storage Arrays, Inc."
+-
+- Naming String defined by
+- Type Date Auth "example.com" naming authority
+- +--++-----+ +---------+ +--------------------------------+
+- | || | | | | |
+-
+- iqn.2001-04.com.example:storage:diskarrays-sn-a8675309
+- iqn.2001-04.com.example
+- iqn.2001-04.com.example:storage.tape1.sys1.xyz
+- iqn.2001-04.com.example:storage.disk2.sys1.xyz
+-
+-
+-
+-Satran, et al. Standards Track [Page 33]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-
+-3.2.6.3.2. Type "eui." (IEEE EUI-64 format)
+-
+- The IEEE Registration Authority provides a service for assigning
+- globally unique identifiers [EUI]. The EUI-64 format is used to
+- build a global identifier in other network protocols. For example,
+- Fibre Channel defines a method of encoding it into a WorldWideName.
+- For more information on registering for EUI identifiers, see [OUI].
+-
+- The format is "eui." followed by an EUI-64 identifier (16
+- ASCII-encoded hexadecimal digits).
+-
+- Example iSCSI name:
+-
+- Type EUI-64 identifier (ASCII-encoded hexadecimal)
+- +--++--------------+
+- | || |
+- eui.02004567A425678D
+-
+- The IEEE EUI-64 iSCSI name format might be used when a manufacturer
+- is already registered with the IEEE Registration Authority and uses
+- EUI-64 formatted worldwide unique names for its products.
+-
+- More examples of name construction are discussed in [RFC3721].
+-
+-3.2.7. Persistent State
+-
+- iSCSI does not require any persistent state maintenance across
+- sessions. However, in some cases, SCSI requires persistent
+- identification of the SCSI initiator port name (See Section 3.4.2
+- SCSI Architecture Model and Section 3.4.3 Consequences of the Model).
+-
+- iSCSI sessions do not persist through power cycles and boot
+- operations.
+-
+- All iSCSI session and connection parameters are re-initialized upon
+- session and connection creation.
+-
+- Commands persist beyond connection termination if the session
+- persists and command recovery within the session is supported.
+- However, when a connection is dropped, command execution, as
+- perceived by iSCSI (i.e., involving iSCSI protocol exchanges for the
+- affected task), is suspended until a new allegiance is established by
+- the 'task reassign' task management function. (See Section 10.5 Task
+- Management Function Request.)
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 34]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-3.2.8. Message Synchronization and Steering
+-
+- iSCSI presents a mapping of the SCSI protocol onto TCP. This
+- encapsulation is accomplished by sending iSCSI PDUs of varying
+- lengths. Unfortunately, TCP does not have a built-in mechanism for
+- signaling message boundaries at the TCP layer. iSCSI overcomes this
+- obstacle by placing the message length in the iSCSI message header.
+- This serves to delineate the end of the current message as well as
+- the beginning of the next message.
+-
+- In situations where IP packets are delivered in order from the
+- network, iSCSI message framing is not an issue and messages are
+- processed one after the other. In the presence of IP packet
+- reordering (i.e., frames being dropped), legacy TCP implementations
+- store the "out of order" TCP segments in temporary buffers until the
+- missing TCP segments arrive, upon which the data must be copied to
+- the application buffers. In iSCSI, it is desirable to steer the SCSI
+- data within these out of order TCP segments into the pre-allocated
+- SCSI buffers rather than store them in temporary buffers. This
+- decreases the need for dedicated reassembly buffers as well as the
+- latency and bandwidth related to extra copies.
+-
+- Relying solely on the "message length" information from the iSCSI
+- message header may make it impossible to find iSCSI message
+- boundaries in subsequent TCP segments due to the loss of a TCP
+- segment that contains the iSCSI message length. The missing TCP
+- segment(s) must be received before any of the following segments can
+- be steered to the correct SCSI buffers (due to the inability to
+- determine the iSCSI message boundaries). Since these segments cannot
+- be steered to the correct location, they must be saved in temporary
+- buffers that must then be copied to the SCSI buffers.
+-
+- Different schemes can be used to recover synchronization. To make
+- these schemes work, iSCSI implementations have to make sure that the
+- appropriate protocol layers are provided with enough information to
+- implement a synchronization and/or data steering mechanism. One of
+- these schemes is detailed in Appendix A. - Sync and Steering with
+- Fixed Interval Markers -.
+-
+- The Fixed Interval Markers (FIM) scheme works by inserting markers in
+- the payload stream at fixed intervals that contain the offset for the
+- start of the next iSCSI PDU.
+-
+- Under normal circumstances (no PDU loss or data reception out of
+- order), iSCSI data steering can be accomplished by using the
+- identifying tag and the data offset fields in the iSCSI header in
+- addition to the TCP sequence number from the TCP header. The
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 35]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- identifying tag helps associate the PDU with a SCSI buffer address
+- while the data offset and TCP sequence number are used to determine
+- the offset within the buffer.
+-
+- When the part of the TCP data stream containing an iSCSI PDU header
+- is delayed or lost, markers may be used to minimize the damage as
+- follows:
+-
+- - Markers indicate where the next iSCSI PDU starts and enable
+- continued processing when iSCSI headers have to be dropped due to
+- data errors discovered at the iSCSI level (e.g., iSCSI header CRC
+- errors).
+-
+- - Markers help minimize the amount of data that has to be kept by
+- the TCP/iSCSI layer while waiting for a late TCP packet arrival
+- or recovery, because later they might help find iSCSI PDU headers
+- and use the information contained in those to steer data to SCSI
+- buffers.
+-
+-3.2.8.1. Sync/Steering and iSCSI PDU Length
+-
+- When a large iSCSI message is sent, the TCP segment(s) that contain
+- the iSCSI header may be lost. The remaining TCP segment(s), up to
+- the next iSCSI message, must be buffered (in temporary buffers)
+- because the iSCSI header that indicates to which SCSI buffers the
+- data are to be steered was lost. To minimize the amount of
+- buffering, it is recommended that the iSCSI PDU length be restricted
+- to a small value (perhaps a few TCP segments in length). During
+- login, each end of the iSCSI session specifies the maximum iSCSI PDU
+- length it will accept.
+-
+-3.3. iSCSI Session Types
+-
+- iSCSI defines two types of sessions:
+-
+- a) Normal operational session - an unrestricted session.
+- b) Discovery-session - a session only opened for target
+- discovery. The target MUST ONLY accept text requests with the
+- SendTargets key and a logout request with the reason "close
+- the session". All other requests MUST be rejected.
+-
+- The session type is defined during login with the key=value parameter
+- in the login command.
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 36]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-3.4. SCSI to iSCSI Concepts Mapping Model
+-
+- The following diagram shows an example of how multiple iSCSI Nodes
+- (targets in this case) can coexist within the same Network Entity and
+- can share Network Portals (IP addresses and TCP ports). Other more
+- complex configurations are also possible. For detailed descriptions
+- of the components of these diagrams, see Section 3.4.1 iSCSI
+- Architecture Model.
+-
+- +-----------------------------------+
+- | Network Entity (iSCSI Client) |
+- | |
+- | +-------------+ |
+- | | iSCSI Node | |
+- | | (Initiator) | |
+- | +-------------+ |
+- | | | |
+- | +--------------+ +--------------+ |
+- | |Network Portal| |Network Portal| |
+- | | 10.1.30.4 | | 10.1.40.6 | |
+- +-+--------------+-+--------------+-+
+- | |
+- | IP Networks |
+- | |
+- +-+--------------+-+--------------+-+
+- | |Network Portal| |Network Portal| |
+- | | 10.1.30.21 | | 10.1.40.3 | |
+- | | TCP Port 3260| | TCP Port 3260| |
+- | +--------------+ +--------------+ |
+- | | | |
+- | ----------------- |
+- | | | |
+- | +-------------+ +--------------+ |
+- | | iSCSI Node | | iSCSI Node | |
+- | | (Target) | | (Target) | |
+- | +-------------+ +--------------+ |
+- | |
+- | Network Entity (iSCSI Server) |
+- +-----------------------------------+
+-
+-3.4.1. iSCSI Architecture Model
+-
+- This section describes the part of the iSCSI architecture model that
+- has the most bearing on the relationship between iSCSI and the SCSI
+- Architecture Model.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 37]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- a) Network Entity - represents a device or gateway that is
+- accessible from the IP network. A Network Entity must have
+- one or more Network Portals (see item d), each of which can be
+- used by some iSCSI Nodes (see item (b)) contained in that
+- Network Entity to gain access to the IP network.
+-
+- b) iSCSI Node - represents a single iSCSI initiator or iSCSI
+- target. There are one or more iSCSI Nodes within a Network
+- Entity. The iSCSI Node is accessible via one or more Network
+- Portals (see item d). An iSCSI Node is identified by its
+- iSCSI Name (see Section 3.2.6 iSCSI Names and Chapter 12).
+- The separation of the iSCSI Name from the addresses used by
+- and for the iSCSI node allows multiple iSCSI nodes to use the
+- same addresses, and the same iSCSI node to use multiple
+- addresses.
+-
+- c) An alias string may also be associated with an iSCSI Node.
+- The alias allows an organization to associate a user friendly
+- string with the iSCSI Name. However, the alias string is not
+- a substitute for the iSCSI Name.
+-
+- d) Network Portal - a component of a Network Entity that has a
+- TCP/IP network address and that may be used by an iSCSI Node
+- within that Network Entity for the connection(s) within one of
+- its iSCSI sessions. In an initiator, it is identified by its
+- IP address. In a target, it is identified by its IP address
+- and its listening TCP port.
+-
+- e) Portal Groups - iSCSI supports multiple connections within the
+- same session; some implementations will have the ability to
+- combine connections in a session across multiple Network
+- Portals. A Portal Group defines a set of Network Portals
+- within an iSCSI Node that collectively supports the capability
+- of coordinating a session with connections that span these
+- portals. Not all Network Portals within a Portal Group need
+- to participate in every session connected through that Portal
+- Group. One or more Portal Groups may provide access to an
+- iSCSI Node. Each Network Portal, as utilized by a given iSCSI
+- Node, belongs to exactly one portal group within that node.
+- Portal Groups are identified within an iSCSI Node by a portal
+- group tag, a simple unsigned-integer between 0 and 65535 (see
+- Section 12.3 SendTargets). All Network Portals with the same
+- portal group tag in the context of a given iSCSI Node are in
+- the same Portal Group.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 38]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Both iSCSI Initiators and iSCSI Targets have portal groups,
+- though only the iSCSI Target Portal Groups are used directly
+- in the iSCSI protocol (e.g., in SendTargets). For references
+- to the initiator Portal Groups, see Section 9.1.1 Conservative
+- Reuse of ISIDs.
+-
+- f) Portals within a Portal Group should support similar session
+- parameters, because they may participate in a common session.
+-
+- The following diagram shows an example of one such configuration on a
+- target and how a session that shares Network Portals within a Portal
+- Group may be established.
+-
+- ----------------------------IP Network---------------------
+- | | |
+- +----|---------------|-----+ +----|---------+
+- | +---------+ +---------+ | | +---------+ |
+- | | Network | | Network | | | | Network | |
+- | | Portal | | Portal | | | | Portal | |
+- | +--|------+ +---------+ | | +---------+ |
+- | | | | | | |
+- | | Portal | | | | Portal |
+- | | Group 1 | | | | Group 2 |
+- +--------------------------+ +--------------+
+- | | |
+- +--------|---------------|--------------------|--------------------+
+- | | | | |
+- | +----------------------------+ +-----------------------------+ |
+- | | iSCSI Session (Target side)| | iSCSI Session (Target side) | |
+- | | | | | |
+- | | (TSIH = 56) | | (TSIH = 48) | |
+- | +----------------------------+ +-----------------------------+ |
+- | |
+- | iSCSI Target Node |
+- | (within Network Entity, not shown) |
+- +------------------------------------------------------------------+
+-
+-3.4.2. SCSI Architecture Model
+-
+- This section describes the relationship between the SCSI Architecture
+- Model [SAM2] and the constructs of the SCSI device, SCSI port and I_T
+- nexus, and the iSCSI constructs described in Section 3.4.1 iSCSI
+- Architecture Model.
+-
+- This relationship implies implementation requirements in order to
+- conform to the SAM2 model and other SCSI operational functions.
+- These requirements are detailed in Section 3.4.3 Consequences of the
+- Model.
+-
+-
+-
+-Satran, et al. Standards Track [Page 39]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The following list outlines mappings of SCSI architectural elements
+- to iSCSI.
+-
+- a) SCSI Device - the SAM2 term for an entity that contains one or
+- more SCSI ports that are connected to a service delivery
+- subsystem and supports a SCSI application protocol. For
+- example, a SCSI Initiator Device contains one or more SCSI
+- Initiator Ports and zero or more application clients. A SCSI
+- Target Device contains one or more SCSI Target Ports and one
+- or more logical units. For iSCSI, the SCSI Device is the
+- component within an iSCSI Node that provides the SCSI
+- functionality. As such, there can be one SCSI Device, at
+- most, within an iSCSI Node. Access to the SCSI Device can
+- only be achieved in an iSCSI normal operational session (see
+- Section 3.3 iSCSI Session Types). The SCSI Device Name is
+- defined to be the iSCSI Name of the node and MUST be used in
+- the iSCSI protocol.
+-
+- b) SCSI Port - the SAM2 term for an entity in a SCSI Device that
+- provides the SCSI functionality to interface with a service
+- delivery subsystem or transport. For iSCSI, the definition of
+- SCSI Initiator Port and SCSI Target Port are different.
+-
+- SCSI Initiator Port: This maps to one endpoint of an iSCSI
+- normal operational session (see Section 3.3 iSCSI Session
+- Types). An iSCSI normal operational session is negotiated
+- through the login process between an iSCSI initiator node and
+- an iSCSI target node. At successful completion of this
+- process, a SCSI Initiator Port is created within the SCSI
+- Initiator Device. The SCSI Initiator Port Name and SCSI
+- Initiator Port Identifier are both defined to be the iSCSI
+- Initiator Name together with (a) a label that identifies it as
+- an initiator port name/identifier and (b) the ISID portion of
+- the session identifier.
+-
+- SCSI Target Port: This maps to an iSCSI Target Portal Group.
+- The SCSI Target Port Name and the SCSI Target Port Identifier
+- are both defined to be the iSCSI Target Name together with (a)
+- a label that identifies it as a target port name/identifier
+- and (b) the portal group tag.
+-
+- The SCSI Port Name MUST be used in iSCSI. When used in SCSI
+- parameter data, the SCSI port name MUST be encoded as:
+- - The iSCSI Name in UTF-8 format, followed by
+- - a comma separator (1 byte), followed by
+- - the ASCII character 'i' (for SCSI Initiator Port) or the
+- ASCII character 't' (for SCSI Target Port) (1 byte),
+- followed by
+-
+-
+-
+-Satran, et al. Standards Track [Page 40]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - a comma separator (1 byte), followed by
+- - a text encoding as a hex-constant (see Section 5.1 Text
+- Format) of the ISID (for SCSI initiator port) or the portal
+- group tag (for SCSI target port) including the initial 0X
+- or 0x and the terminating null (15 bytes).
+-
+- The ASCII character 'i' or 't' is the label that identifies
+- this port as either a SCSI Initiator Port or a SCSI Target
+- Port.
+-
+- c) I_T nexus - a relationship between a SCSI Initiator Port and a
+- SCSI Target Port, according to [SAM2]. For iSCSI, this
+- relationship is a session, defined as a relationship between
+- an iSCSI Initiator's end of the session (SCSI Initiator Port)
+- and the iSCSI Target's Portal Group. The I_T nexus can be
+- identified by the conjunction of the SCSI port names or by the
+- iSCSI session identifier SSID. iSCSI defines the I_T nexus
+- identifier to be the tuple (iSCSI Initiator Name + 'i' + ISID,
+- iSCSI Target Name + 't' + Portal Group Tag).
+-
+- NOTE: The I_T nexus identifier is not equal to the session
+- identifier (SSID).
+-
+-3.4.3. Consequences of the Model
+-
+- This section describes implementation and behavioral requirements
+- that result from the mapping of SCSI constructs to the iSCSI
+- constructs defined above. Between a given SCSI initiator port and a
+- given SCSI target port, only one I_T nexus (session) can exist. No
+- more than one nexus relationship (parallel nexus) is allowed by
+- [SAM2]. Therefore, at any given time, only one session can exist
+- between a given iSCSI initiator node and an iSCSI target node, with
+- the same session identifier (SSID).
+-
+- These assumptions lead to the following conclusions and requirements:
+-
+- ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal
+- Group (SCSI target port), there can only be one session with a given
+- value for ISID that identifies the SCSI initiator port. See Section
+- 10.12.5 ISID.
+-
+- The structure of the ISID that contains a naming authority component
+- (see Section 10.12.5 ISID and [RFC3721]) provides a mechanism to
+- facilitate compliance with the ISID rule. (See Section 9.1.1
+- Conservative Reuse of ISIDs.)
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 41]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The iSCSI Initiator Node should manage the assignment of ISIDs prior
+- to session initiation. The "ISID RULE" does not preclude the use of
+- the same ISID from the same iSCSI Initiator with different Target
+- Portal Groups on the same iSCSI target or on other iSCSI targets (see
+- Section 9.1.1 Conservative Reuse of ISIDs). Allowing this would be
+- analogous to a single SCSI Initiator Port having relationships
+- (nexus) with multiple SCSI target ports on the same SCSI target
+- device or SCSI target ports on other SCSI target devices. It is also
+- possible to have multiple sessions with different ISIDs to the same
+- Target Portal Group. Each such session would be considered to be
+- with a different initiator even when the sessions originate from the
+- same initiator device. The same ISID may be used by a different
+- iSCSI initiator because it is the iSCSI Name together with the ISID
+- that identifies the SCSI Initiator Port.
+-
+- NOTE: A consequence of the ISID RULE and the specification for the
+- I_T nexus identifier is that two nexus with the same identifier
+- should never exist at the same time.
+-
+- TSIH RULE: The iSCSI Target selects a non-zero value for the TSIH at
+- session creation (when an initiator presents a 0 value at Login).
+- After being selected, the same TSIH value MUST be used whenever the
+- initiator or target refers to the session and a TSIH is required.
+-
+-3.4.3.1. I_T Nexus State
+-
+- Certain nexus relationships contain an explicit state (e.g.,
+- initiator-specific mode pages) that may need to be preserved by the
+- device server [SAM2] in a logical unit through changes or failures in
+- the iSCSI layer (e.g., session failures). In order for that state to
+- be restored, the iSCSI initiator should reestablish its session
+- (re-login) to the same Target Portal Group using the previous ISID.
+- That is, it should perform session recovery as described in Chapter
+- 6. This is because the SCSI initiator port identifier and the SCSI
+- target port identifier (or relative target port) form the datum that
+- the SCSI logical unit device server uses to identify the I_T nexus.
+-
+-3.5. Request/Response Summary
+-
+- This section lists and briefly describes all the iSCSI PDU types
+- (request and responses).
+-
+- All iSCSI PDUs are built as a set of one or more header segments
+- (basic and auxiliary) and zero or one data segments. The header
+- group and the data segment may each be followed by a CRC (digest).
+-
+- The basic header segment has a fixed length of 48 bytes.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 42]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-3.5.1. Request/Response Types Carrying SCSI Payload
+-
+-3.5.1.1. SCSI-Command
+-
+- This request carries the SCSI CDB and all the other SCSI execute
+- command procedure call (see [SAM2]) IN arguments such as task
+- attributes, Expected Data Transfer Length for one or both transfer
+- directions (the latter for bidirectional commands), and Task Tag (as
+- part of the I_T_L_x nexus). The I_T_L nexus is derived by the
+- initiator and target from the LUN field in the request and the I_T
+- nexus is implicit in the session identification.
+-
+- In addition, the SCSI-command PDU carries information required for
+- the proper operation of the iSCSI protocol - the command sequence
+- number (CmdSN) for the session and the expected status number
+- (ExpStatSN) for the connection.
+-
+- All or part of the SCSI output (write) data associated with the SCSI
+- command may be sent as part of the SCSI-Command PDU as a data
+- segment.
+-
+-3.5.1.2. SCSI-Response
+-
+- The SCSI-Response carries all the SCSI execute-command procedure call
+- (see [SAM2]) OUT arguments and the SCSI execute-command procedure
+- call return value.
+-
+- The SCSI-Response contains the residual counts from the operation, if
+- any, an indication of whether the counts represent an overflow or an
+- underflow, and the SCSI status if the status is valid or a response
+- code (a non-zero return value for the execute-command procedure call)
+- if the status is not valid.
+-
+- For a valid status that indicates that the command has been
+- processed, but resulted in an exception (e.g., a SCSI CHECK
+- CONDITION), the PDU data segment contains the associated sense data.
+- The use of Autosense ([SAM2]) is REQUIRED by iSCSI.
+-
+- Some data segment content may also be associated (in the data
+- segment) with a non-zero response code.
+-
+- In addition, the SCSI-Response PDU carries information required for
+- the proper operation of the iSCSI protocol:
+-
+- - The number of Data-In PDUs that a target has sent (to enable
+- the initiator to check that all have arrived).
+- - StatSN - the Status Sequence Number on this connection.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 43]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - ExpCmdSN - the next Expected Command Sequence Number at the
+- target.
+- - MaxCmdSN - the maximum CmdSN acceptable at the target from
+- this initiator.
+-
+-3.5.1.3 Task Management Function Request
+-
+- The Task Management function request provides an initiator with a way
+- to explicitly control the execution of one or more SCSI Tasks or
+- iSCSI functions. The PDU carries a function identifier (which task
+- management function to perform) and enough information to
+- unequivocally identify the task or task-set on which to perform the
+- action, even if the task(s) to act upon has not yet arrived or has
+- been discarded due to an error.
+-
+- The referenced tag identifies an individual task if the function
+- refers to an individual task.
+-
+- The I_T_L nexus identifies task sets. In iSCSI the I_T_L nexus is
+- identified by the LUN and the session identification (the session
+- identifies an I_T nexus).
+-
+- For task sets, the CmdSN of the Task Management function request
+- helps identify the tasks upon which to act, namely all tasks
+- associated with a LUN and having a CmdSN preceding the Task
+- Management function request CmdSN.
+-
+- For a Task Management function, the coordination between responses to
+- the tasks affected and the Task Management function response is done
+- by the target.
+-
+-3.5.1.4. Task Management Function Response
+-
+- The Task Management function response carries an indication of
+- function completion for a Task Management function request including
+- how it was completed (response and qualifier) and additional
+- information for failure responses.
+-
+- After the Task Management response indicates Task Management function
+- completion, the initiator will not receive any additional responses
+- from the affected tasks.
+-
+-3.5.1.5. SCSI Data-Out and SCSI Data-In
+-
+- SCSI Data-Out and SCSI Data-In are the main vehicles by which SCSI
+- data payload is carried between initiator and target. Data payload
+- is associated with a specific SCSI command through the Initiator Task
+- Tag. For target convenience, outgoing solicited data also carries a
+-
+-
+-
+-Satran, et al. Standards Track [Page 44]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Target Transfer Tag (copied from R2T) and the LUN. Each PDU contains
+- the payload length and the data offset relative to the buffer address
+- contained in the SCSI execute command procedure call.
+-
+- In each direction, the data transfer is split into "sequences". An
+- end-of-sequence is indicated by the F bit.
+-
+- An outgoing sequence is either unsolicited (only the first sequence
+- can be unsolicited) or consists of all the Data-Out PDUs sent in
+- response to an R2T.
+-
+- Input sequences are built to enable the direction switching for
+- bidirectional commands.
+-
+- For input, the target may request positive acknowledgement of input
+- data. This is limited to sessions that support error recovery and is
+- implemented through the A bit in the SCSI Data-In PDU header.
+-
+- Data-In and Data-Out PDUs also carry the DataSN to enable the
+- initiator and target to detect missing PDUs (discarded due to an
+- error).
+-
+- In addition, StatSN is carried by the Data-In PDUs.
+-
+- To enable a SCSI command to be processed while involving a minimum
+- number of messages, the last SCSI Data-In PDU passed for a command
+- may also contain the status if the status indicates termination with
+- no exceptions (no sense or response involved).
+-
+-3.5.1.6. Ready To Transfer (R2T)
+-
+- R2T is the mechanism by which the SCSI target "requests" the
+- initiator for output data. R2T specifies to the initiator the offset
+- of the requested data relative to the buffer address from the execute
+- command procedure call and the length of the solicited data.
+-
+- To help the SCSI target associate the resulting Data-Out with an R2T,
+- the R2T carries a Target Transfer Tag that will be copied by the
+- initiator in the solicited SCSI Data-Out PDUs. There are no protocol
+- specific requirements with regard to the value of these tags, but it
+- is assumed that together with the LUN, they will enable the target to
+- associate data with an R2T.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 45]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- R2T also carries information required for proper operation of the
+- iSCSI protocol, such as:
+-
+- - R2TSN (to enable an initiator to detect a missing R2T)
+- - StatSN
+- - ExpCmdSN
+- - MaxCmdSN
+-
+-3.5.2. Requests/Responses carrying SCSI and iSCSI Payload
+-
+-3.5.2.1. Asynchronous Message
+-
+- Asynchronous Messages are used to carry SCSI asynchronous events
+- (AEN) and iSCSI asynchronous messages.
+-
+- When carrying an AEN, the event details are reported as sense data in
+- the data segment.
+-
+-3.5.3. Requests/Responses Carrying iSCSI Only Payload
+-
+-3.5.3.1. Text Request and Text Response
+-
+- Text requests and responses are designed as a parameter negotiation
+- vehicle and as a vehicle for future extension.
+-
+- In the data segment, Text Requests/Responses carry text information
+- using a simple "key=value" syntax.
+-
+- Text Request/Responses may form extended sequences using the same
+- Initiator Task Tag. The initiator uses the F (Final) flag bit in the
+- text request header to indicate its readiness to terminate a
+- sequence. The target uses the F (Final) flag bit in the text
+- response header to indicate its consent to sequence termination.
+-
+- Text Request and Responses also use the Target Transfer Tag to
+- indicate continuation of an operation or a new beginning. A target
+- that wishes to continue an operation will set the Target Transfer Tag
+- in a Text Response to a value different from the default 0xffffffff.
+- An initiator willing to continue will copy this value into the Target
+- Transfer Tag of the next Text Request. If the initiator wants to
+- restart the current target negotiation (start fresh) will set the
+- Target Transfer Tag to 0xffffffff.
+-
+- Although a complete exchange is always started by the initiator,
+- specific parameter negotiations may be initiated by the initiator or
+- target.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 46]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-3.5.3.2. Login Request and Login Response
+-
+- Login Requests and Responses are used exclusively during the Login
+- Phase of each connection to set up the session and connection
+- parameters. (The Login Phase consists of a sequence of login
+- requests and responses carrying the same Initiator Task Tag.)
+-
+- A connection is identified by an arbitrarily selected connection-ID
+- (CID) that is unique within a session.
+-
+- Similar to the Text Requests and Responses, Login Requests/Responses
+- carry key=value text information with a simple syntax in the data
+- segment.
+-
+- The Login Phase proceeds through several stages (security
+- negotiation, operational parameter negotiation) that are selected
+- with two binary coded fields in the header -- the "current stage"
+- (CSG) and the "next stage" (NSG) with the appearance of the latter
+- being signaled by the "transit" flag (T).
+-
+- The first Login Phase of a session plays a special role, called the
+- leading login, which determines some header fields (e.g., the version
+- number, the maximum number of connections, and the session
+- identification).
+-
+- The CmdSN initial value is also set by the leading login.
+-
+- StatSN for each connection is initiated by the connection login.
+-
+- A login request may indicate an implied logout (cleanup) of the
+- connection to be logged in (a connection restart) by using the same
+- Connection ID (CID) as an existing connection, as well as the same
+- session identifying elements of the session to which the old
+- connection was associated.
+-
+-3.5.3.3. Logout Request and Response
+-
+- Logout Requests and Responses are used for the orderly closing of
+- connections for recovery or maintenance. The logout request may be
+- issued following a target prompt (through an asynchronous message) or
+- at an initiators initiative. When issued on the connection to be
+- logged out, no other request may follow it.
+-
+- The Logout Response indicates that the connection or session cleanup
+- is completed and no other responses will arrive on the connection (if
+- received on the logging out connection). In addition, the Logout
+- Response indicates how long the target will continue to hold
+- resources for recovery (e.g., command execution that continues on a
+-
+-
+-
+-Satran, et al. Standards Track [Page 47]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- new connection) in the text key Time2Retain and how long the
+- initiator must wait before proceeding with recovery in the text key
+- Time2Wait.
+-
+-3.5.3.4. SNACK Request
+-
+- With the SNACK Request, the initiator requests retransmission of
+- numbered-responses or data from the target. A single SNACK request
+- covers a contiguous set of missing items, called a run, of a given
+- type of items. The type is indicated in a type field in the PDU
+- header. The run is composed of an initial item (StatSN, DataSN,
+- R2TSN) and the number of missed Status, Data, or R2T PDUs. For long
+- Data-In sequences, the target may request (at predefined minimum
+- intervals) a positive acknowledgement for the data sent. A SNACK
+- request with a type field that indicates ACK and the number of
+- Data-In PDUs acknowledged conveys this positive acknowledgement.
+-
+-3.5.3.5. Reject
+-
+- Reject enables the target to report an iSCSI error condition (e.g.,
+- protocol, unsupported option) that uses a Reason field in the PDU
+- header and includes the complete header of the bad PDU in the Reject
+- PDU data segment.
+-
+-3.5.3.6. NOP-Out Request and NOP-In Response
+-
+- This request/response pair may be used by an initiator and target as
+- a "ping" mechanism to verify that a connection/session is still
+- active and all of its components are operational. Such a ping may be
+- triggered by the initiator or target. The triggering party indicates
+- that it wants a reply by setting a value different from the default
+- 0xffffffff in the corresponding Initiator/Target Transfer Tag.
+-
+- NOP-In/NOP-Out may also be used "unidirectional" to convey to the
+- initiator/target command, status or data counter values when there is
+- no other "carrier" and there is a need to update the initiator/
+- target.
+-
+-4. SCSI Mode Parameters for iSCSI
+-
+- There are no iSCSI specific mode pages.
+-
+-5. Login and Full Feature Phase Negotiation
+-
+- iSCSI parameters are negotiated at session or connection
+- establishment by using Login Requests and Responses (see Section
+- 3.2.3 iSCSI Login) and during the Full Feature Phase (Section 3.2.4
+- iSCSI Full Feature Phase) by using Text Requests and Responses. In
+-
+-
+-
+-Satran, et al. Standards Track [Page 48]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- both cases the mechanism used is an exchange of iSCSI-text-key=value
+- pairs. For brevity iSCSI-text-keys are called just keys in the rest
+- of this document.
+-
+- Keys are either declarative or require negotiation and the key
+- description indicates if the key is declarative or requires
+- negotiation.
+-
+- For the declarative keys, the declaring party sets a value for the
+- key. The key specification indicates if the key can be declared by
+- the initiator, target or both.
+-
+- For the keys that require negotiation one of the parties (the
+- proposing party) proposes a value or set of values by including the
+- key=value in the data part of a Login or Text Request or Response
+- PDUs. The other party (the accepting party) makes a selection based
+- on the value or list of values proposed and includes the selected
+- value in a key=value in the data part of one of the following Login
+- or Text Response or Request PDUs. For most of the keys both the
+- initiator and target can be proposing parties.
+-
+- The login process proceeds in two stages - the security negotiation
+- stage and the operational parameter negotiation stage. Both stages
+- are optional but at least one of them has to be present to enable the
+- setting of some mandatory parameters.
+-
+- If present, the security negotiation stage precedes the operational
+- parameter negotiation stage.
+-
+- Progression from stage to stage is controlled by the T (Transition)
+- bit in the Login Request/Response PDU header. Through the T bit set
+- to 1, the initiator indicates that it would like to transition. The
+- target agrees to the transition (and selects the next stage) when
+- ready. A field in the Login PDU header indicates the current stage
+- (CSG) and during transition, another field indicates the next stage
+- (NSG) proposed (initiator) and selected (target).
+-
+- The text negotiation process is used to negotiate or declare
+- operational parameters. The negotiation process is controlled by the
+- F (final) bit in the PDU header. During text negotiations, the F bit
+- is used by the initiator to indicate that it is ready to finish the
+- negotiation and by the Target to acquiesce the end of negotiation.
+-
+- Since some key=value pairs may not fit entirely in a single PDU, the
+- C (continuation) bit is used (both in Login and Text) to indicate
+- that "more follows".
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 49]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The text negotiation uses an additional mechanism by which a target
+- may deliver larger amounts of data to an enquiring initiator. The
+- target sets a Target Task Tag to be used as a bookmark that when
+- returned by the initiator, means "go on". If reset to a "neutral
+- value", it means "forget about the rest".
+-
+- This chapter details types of keys and values used, the syntax rules
+- for parameter formation, and the negotiation schemes to be used with
+- different types of parameters.
+-
+-5.1. Text Format
+-
+- The initiator and target send a set of key=value pairs encoded in
+- UTF-8 Unicode. All the text keys and text values specified in this
+- document are to be presented and interpreted in the case in which
+- they appear in this document. They are case sensitive.
+-
+- The following character symbols are used in this document for text
+- items (the hexadecimal values represent Unicode code points):
+-
+- (a-z, A-Z) - letters
+- (0-9) - digits
+- " " (0x20) - space
+- "." (0x2e) - dot
+- "-" (0x2d) - minus
+- "+" (0x2b) - plus
+- "@" (0x40) - commercial at
+- "_" (0x5f) - underscore
+- "=" (0x3d) - equal
+- ":" (0x3a) - colon
+- "/" (0x2f) - solidus or slash
+- "[" (0x5b) - left bracket
+- "]" (0x5d) - right bracket
+- null (0x00) - null separator
+- "," (0x2c) - comma
+- "~" (0x7e) - tilde
+-
+- Key=value pairs may span PDU boundaries. An initiator or target that
+- sends partial key=value text within a PDU indicates that more text
+- follows by setting the C bit in the Text or Login Request or Text or
+- Login Response to 1. Data segments in a series of PDUs that have the
+- C bit set to 1 and end with a PDU that have the C bit set to 0, or
+- include a single PDU that has the C bit set to 0, have to be
+- considered as forming a single logical-text-data-segment (LTDS).
+-
+- Every key=value pair, including the last or only pair in a LTDS, MUST
+- be followed by one null (0x00) delimiter.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 50]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A key-name is whatever precedes the first "=" in the key=value pair.
+- The term key is used frequently in this document in place of
+- key-name.
+-
+- A value is whatever follows the first "=" in the key=value pair up to
+- the end of the key=value pair, but not including the null delimiter.
+-
+- The following definitions will be used in the rest of this document:
+-
+- standard-label: A string of one or more characters that consist of
+- letters, digits, dot, minus, plus, commercial at, or underscore.
+- A standard-label MUST begin with a capital letter and must not
+- exceed 63 characters.
+-
+- key-name: A standard-label.
+-
+- text-value: A string of zero or more characters that consist of
+- letters, digits, dot, minus, plus, commercial at, underscore,
+- slash, left bracket, right bracket, or colon.
+-
+- iSCSI-name-value: A string of one or more characters that consist
+- of minus, dot, colon, or any character allowed by the output of
+- the iSCSI string-prep template as specified in [RFC3722] (see
+- also Section 3.2.6.2 iSCSI Name Encoding).
+-
+- iSCSI-local-name-value: A UTF-8 string; no null characters are
+- allowed in the string. This encoding is to be used for localized
+- (internationalized) aliases.
+-
+- boolean-value: The string "Yes" or "No".
+-
+- hex-constant: A hexadecimal constant encoded as a string that
+- starts with "0x" or "0X" followed by one or more digits or the
+- letters a, b, c, d, e, f, A, B, C, D, E, or F. Hex-constants are
+- used to encode numerical values or binary strings. When used to
+- encode numerical values, the excessive use of leading 0 digits is
+- discouraged. The string following 0X (or 0x) represents a base16
+- number that starts with the most significant base16 digit,
+- followed by all other digits in decreasing order of significance
+- and ending with the least-significant base16 digit. When used to
+- encode binary strings, hexadecimal constants have an implicit
+- byte-length that includes four bits for every hexadecimal digit
+- of the constant, including leading zeroes. For example, a
+- hex-constant of n hexadecimal digits has a byte-length of (the
+- integer part of) (n+1)/2.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 51]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- decimal-constant: An unsigned decimal number with the digit 0 or a
+- string of one or more digits that start with a non-zero digit.
+- Decimal-constants are used to encode numerical values or binary
+- strings. Decimal constants can only be used to encode binary
+- strings if the string length is explicitly specified. There is
+- no implicit length for decimal strings. Decimal-constant MUST
+- NOT be used for parameter values if the values can be equal or
+- greater than 2**64 (numerical) or for binary strings that can be
+- longer than 64 bits.
+-
+- base64-constant: base64 constant encoded as a string that starts
+- with "0b" or "0B" followed by 1 or more digits or letters or plus
+- or slash or equal. The encoding is done according to [RFC2045]
+- and each character, except equal, represents a base64 digit or a
+- 6-bit binary string. Base64-constants are used to encode
+- numerical-values or binary strings. When used to encode
+- numerical values, the excessive use of leading 0 digits (encoded
+- as A) is discouraged. The string following 0B (or 0b) represents
+- a base64 number that starts with the most significant base64
+- digit, followed by all other digits in decreasing order of
+- significance and ending with the least-significant base64 digit;
+- the least significant base64 digit may be optionally followed by
+- pad digits (encoded as equal) that are not considered as part of
+- the number. When used to encode binary strings, base64-constants
+- have an implicit
+- byte-length that includes six bits for every character of the
+- constant, excluding trailing equals (i.e., a base64-constant of n
+- base64 characters excluding the trailing equals has a byte-length
+- of ((the integer part of) (n*3/4)). Correctly encoded base64
+- strings cannot have n values of 1, 5 ... k*4+1.
+-
+- numerical-value: An unsigned integer always less than 2**64 encoded
+- as a decimal-constant or a hex-constant. Unsigned integer
+- arithmetic applies to numerical-values.
+-
+- large-numerical-value: An unsigned integer that can be larger than
+- or equal to 2**64 encoded as a hex constant, or
+- base64-constant. Unsigned integer arithmetic applies to
+- large-numeric-values.
+-
+- numeric-range: Two numerical-values separated by a tilde where the
+- value to the right of tilde must not be lower than the value to
+- the left.
+-
+- regular-binary-value: A binary string not longer than 64 bits
+- encoded as a decimal constant, hex constant, or base64-constant.
+- The length of the string is either specified by the key
+- definition or is the implicit byte-length of the encoded string.
+-
+-
+-
+-Satran, et al. Standards Track [Page 52]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- large-binary-value: A binary string longer than 64 bits encoded as
+- a hex-constant or base64-constant. The length of the string is
+- either specified by the key definition or is the implicit
+- byte-length of the encoded string.
+-
+- binary-value: A regular-binary-value or a large-binary-value.
+- Operations on binary values are key specific.
+-
+- simple-value: Text-value, iSCSI-name-value, boolean-value,
+- numeric-value, a numeric-range, or a binary-value.
+-
+- list-of-values: A sequence of text-values separated by a comma.
+-
+- If not otherwise specified, the maximum length of a simple-value (not
+- its encoded representation) is 255 bytes, not including the delimiter
+- (comma or zero byte).
+-
+- Any iSCSI target or initiator MUST support receiving at least 8192
+- bytes of key=value data in a negotiation sequence. When proposing or
+- accepting authentication methods that explicitly require support for
+- very long authentication items, the initiator and target MUST support
+- receiving of at least 64 kilobytes of key=value data (see Appendix
+- 11.1.2 - Simple Public-Key Mechanism (SPKM) - that require support
+- for public key certificates).
+-
+-5.2. Text Mode Negotiation
+-
+- During login, and thereafter, some session or connection parameters
+- are either declared or negotiated through an exchange of textual
+- information.
+-
+- The initiator starts the negotiation and/or declaration through a
+- Text or Login Request and indicates when it is ready for completion
+- (by setting the F bit to 1 and keeping it to 1 in a Text Request or
+- the T bit in the Login Request). As negotiation text may span PDU
+- boundaries, a Text or Login Request or Text or Login Response PDU
+- that has the C bit set to 1 MUST NOT have the F/T bit set to 1.
+-
+- A target receiving a Text or Login Request with the C bit set to 1
+- MUST answer with a Text or Login Response with no data segment
+- (DataSegmentLength 0). An initiator receiving a Text or Login
+- Response with the C bit set to 1 MUST answer with a Text or Login
+- Request with no data segment (DataSegmentLength 0).
+-
+- A target or initiator SHOULD NOT use a Text or Login Response or Text
+- or Login Request with no data segment (DataSegmentLength 0) unless
+- explicitly required by a general or a key-specific negotiation rule.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 53]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The format of a declaration is:
+-
+- Declarer-> <key>=<valuex>
+-
+- The general format of text negotiation is:
+-
+- Proposer-> <key>=<valuex>
+- Acceptor-> <key>={<valuey>|NotUnderstood|Irrelevant|Reject}
+-
+- Thus a declaration is a one-way textual exchange while a negotiation
+- is a two-way exchange.
+-
+- The proposer or declarer can either be the initiator or the target,
+- and the acceptor can either be the target or initiator, respectively.
+- Targets are not limited to respond to key=value pairs as proposed by
+- the initiator. The target may propose key=value pairs of its own.
+-
+- All negotiations are explicit (i.e., the result MUST only be based on
+- newly exchanged or declared values). There are no implicit
+- proposals. If a proposal is not made, then a reply cannot be
+- expected. Conservative design also requires that default values
+- should not be relied upon when use of some other value has serious
+- consequences.
+-
+- The value proposed or declared can be a numerical-value, a
+- numerical-range defined by lower and upper values with both integers
+- separated by a tilde, a binary value, a text-value, an
+- iSCSI-name-value, an iSCSI-local-name-value, a boolean-value (Yes or
+- No), or a list of comma separated text-values. A range, a
+- large-numerical-value, an iSCSI-name-value and an
+- iSCSI-local-name-value MAY ONLY be used if it is explicitly allowed.
+- An accepted value can be a numerical-value, a large-numerical-value,
+- a text-value, or a boolean-value.
+-
+- If a specific key is not relevant for the current negotiation, the
+- acceptor may answer with the constant "Irrelevant" for all types of
+- negotiation. However the negotiation is not considered as failed if
+- the answer is "Irrelevant". The "Irrelevant" answer is meant for
+- those cases in which several keys are presented by a proposing party
+- but the selection made by the acceptor for one of the keys makes
+- other keys irrelevant. The following example illustrates the use of
+- "Irrelevant":
+-
+- I->T OFMarker=Yes,OFMarkInt=2048~8192
+- T->I OFMarker=No,OFMarkInt=Irrelevant
+-
+- I->T X#vkey1=(bla,alb,None),X#vkey2=(bla,alb)
+- T->I X#vkey1=None,X#vkey2=Irrelevant
+-
+-
+-
+-Satran, et al. Standards Track [Page 54]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-
+- Any key not understood by the acceptor may be ignored by the acceptor
+- without affecting the basic function. However, the answer for a key
+- not understood MUST be key=NotUnderstood.
+-
+- The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are
+- reserved and MUST ONLY be used as described here. Violation of this
+- rule is a protocol error (in particular the use of "Reject",
+- "Irrelevant", and "NotUnderstood" as proposed values).
+-
+- Reject or Irrelevant are legitimate negotiation options where allowed
+- but their excessive use is discouraged. A negotiation is considered
+- complete when the acceptor has sent the key value pair even if the
+- value is "Reject", "Irrelevant", or "NotUnderstood. Sending the key
+- again would be a re-negotiation and is forbidden for many keys.
+-
+- If the acceptor sends "Reject" as an answer the negotiated key is
+- left at its current value (or default if no value was set). If the
+- current value is not acceptable to the proposer on the connection or
+- to the session it is sent, the proposer MAY choose to terminate the
+- connection or session.
+-
+- All keys in this document, except for the X extension formats, MUST
+- be supported by iSCSI initiators and targets when used as specified
+- here. If used as specified, these keys MUST NOT be answered with
+- NotUnderstood.
+-
+- Implementers may introduce new keys by prefixing them with
+- "X-", followed by their (reversed) domain name, or with new keys
+- registered with IANA prefixing them with X#. For example, the entity
+- owning the domain example.com can issue:
+-
+- X-com.example.bar.foo.do_something=3
+-
+- or a new registered key may be used as in:
+-
+- X#SuperCalyPhraGilistic=Yes
+-
+- Implementers MAY also introduce new values, but ONLY for new keys or
+- authentication methods (see Section 11 iSCSI Security Text Keys and
+- Authentication Methods), or digests (see Section 12.1 HeaderDigest
+- and DataDigest).
+-
+- Whenever parameter action or acceptance is dependent on other
+- parameters, the dependency rules and parameter sequence must be
+- specified with the parameters.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 55]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- In the Login Phase (see Section 5.3 Login Phase), every stage is a
+- separate negotiation. In the FullFeaturePhase, a Text Request
+- Response sequence is a negotiation. Negotiations MUST be handled as
+- atomic operations. For example, all negotiated values go into effect
+- after the negotiation concludes in agreement or are ignored if the
+- negotiation fails.
+-
+- Some parameters may be subject to integrity rules (e.g., parameter-x
+- must not exceed parameter-y or parameter-u not 1 implies parameter-v
+- be Yes). Whenever required, integrity rules are specified with the
+- keys. Checking for compliance with the integrity rule must only be
+- performed after all the parameters are available (the existent and
+- the newly negotiated). An iSCSI target MUST perform integrity
+- checking before the new parameters take effect. An initiator MAY
+- perform integrity checking.
+-
+- An iSCSI initiator or target MAY terminate a negotiation that does
+- not end within a reasonable time or number of exchanges.
+-
+-5.2.1. List negotiations
+-
+- In list negotiation, the originator sends a list of values (which may
+- include "None") in its order of preference.
+-
+- The responding party MUST respond with the same key and the first
+- value that it supports (and is allowed to use for the specific
+- originator) selected from the originator list.
+-
+- The constant "None" MUST always be used to indicate a missing
+- function. However, "None" is only a valid selection if it is
+- explicitly proposed.
+-
+- If an acceptor does not understand any particular value in a list, it
+- MUST ignore it. If an acceptor does not support, does not
+- understand, or is not allowed to use any of the proposed options with
+- a specific originator, it may use the constant "Reject" or terminate
+- the negotiation. The selection of a value not proposed MUST be
+- handled as a protocol error.
+-
+-5.2.2. Simple-value Negotiations
+-
+- For simple-value negotiations, the accepting party MUST answer with
+- the same key. The value it selects becomes the negotiation result.
+-
+- Proposing a value not admissible (e.g., not within the specified
+- bounds) MAY be answered with the constant "Reject" or the acceptor
+- MAY select an admissible value.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 56]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The selection by the acceptor, of a value not admissible under the
+- selection rules is considered a protocol error. The selection rules
+- are key-specific.
+-
+- For a numerical range, the value selected must be an integer within
+- the proposed range or "Reject" (if the range is unacceptable).
+-
+- In Boolean negotiations (i.e., those that result in keys taking the
+- values Yes or No), the accepting party MUST answer with the same key
+- and the result of the negotiation when the received value does not
+- determine that result by itself. The last value transmitted becomes
+- the negotiation result. The rules for selecting the value to answer
+- with are expressed as Boolean functions of the value received, and
+- the value that the accepting party would have selected if given a
+- choice.
+-
+- Specifically, the two cases in which answers are OPTIONAL are:
+-
+- - The Boolean function is "AND" and the value "No" is received.
+- The outcome of the negotiation is "No".
+- - The Boolean function is "OR" and the value "Yes" is received.
+- The outcome of the negotiation is "Yes".
+-
+- Responses are REQUIRED in all other cases, and the value chosen and
+- sent by the acceptor becomes the outcome of the negotiation.
+-
+-5.3. Login Phase
+-
+- The Login Phase establishes an iSCSI connection between an initiator
+- and a target; it also creates a new session or associates the
+- connection to an existing session. The Login Phase sets the iSCSI
+- protocol parameters, security parameters, and authenticates the
+- initiator and target to each other.
+-
+- The Login Phase is only implemented via Login Request and Responses.
+- The whole Login Phase is considered as a single task and has a single
+- Initiator Task Tag (similar to the linked SCSI commands).
+-
+- The default MaxRecvDataSegmentLength is used during Login.
+-
+- The Login Phase sequence of requests and responses proceeds as
+- follows:
+-
+- - Login initial request
+- - Login partial response (optional)
+- - More Login Requests and Responses (optional)
+- - Login Final-Response (mandatory)
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 57]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The initial Login Request of any connection MUST include the
+- InitiatorName key=value pair. The initial Login Request of the first
+- connection of a session MAY also include the SessionType key=value
+- pair. For any connection within a session whose type is not
+- "Discovery", the first Login Request MUST also include the TargetName
+- key=value pair.
+-
+- The Login Final-response accepts or rejects the Login Request.
+-
+- The Login Phase MAY include a SecurityNegotiation stage and a
+- LoginOperationalNegotiation stage or both, but MUST include at least
+- one of them. The included stage MAY be empty except for the
+- mandatory names.
+-
+- The Login Requests and Responses contain a field (CSG) that indicates
+- the current negotiation stage (SecurityNegotiation or
+- LoginOperationalNegotiation). If both stages are used, the
+- SecurityNegotiation MUST precede the LoginOperationalNegotiation.
+-
+- Some operational parameters can be negotiated outside the login
+- through Text Requests and Responses.
+-
+- Security MUST be completely negotiated within the Login Phase. The
+- use of underlying IPsec security is specified in Chapter 8 and in
+- [RFC3723]. iSCSI support for security within the protocol only
+- consists of authentication in the Login Phase.
+-
+- In some environments, a target or an initiator is not interested in
+- authenticating its counterpart. It is possible to bypass
+- authentication through the Login Request and Response.
+-
+- The initiator and target MAY want to negotiate iSCSI authentication
+- parameters. Once this negotiation is completed, the channel is
+- considered secure.
+-
+- Most of the negotiation keys are only allowed in a specific stage.
+- The SecurityNegotiation keys appear in Chapter 11 and the
+- LoginOperationalNegotiation keys appear in Chapter 12. Only a
+- limited set of keys (marked as Any-Stage in Chapter 12) may be used
+- in any of the two stages.
+-
+- Any given Login Request or Response belongs to a specific stage; this
+- determines the negotiation keys allowed with the request or response.
+- It is considered to be a protocol error to send a key that is not
+- allowed in the current stage.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 58]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Stage transition is performed through a command exchange (request/
+- response) that carries the T bit and the same CSG code. During this
+- exchange, the next stage is selected by the target through the "next
+- stage" code (NSG). The selected NSG MUST NOT exceed the value stated
+- by the initiator. The initiator can request a transition whenever it
+- is ready, but a target can only respond with a transition after one
+- is proposed by the initiator.
+-
+- In a negotiation sequence, the T bit settings in one pair of Login
+- Request-Responses have no bearing on the T bit settings of the next
+- pair. An initiator that has a T bit set to 1 in one pair and is
+- answered with a T bit setting of 0, may issue the next request with
+- the T bit set to 0.
+-
+- When a transition is requested by the initiator and acknowledged by
+- the target, both the initiator and target switch to the selected
+- stage.
+-
+- Targets MUST NOT submit parameters that require an additional
+- initiator Login Request in a Login Response with the T bit set to 1.
+-
+- Stage transitions during login (including entering and exit) are only
+- possible as outlined in the following table:
+-
+- +-----------------------------------------------------------+
+- |From To -> | Security | Operational | FullFeature |
+- | | | | | |
+- | V | | | |
+- +-----------------------------------------------------------+
+- | (start) | yes | yes | no |
+- +-----------------------------------------------------------+
+- | Security | no | yes | yes |
+- +-----------------------------------------------------------+
+- | Operational | no | no | yes |
+- +-----------------------------------------------------------+
+-
+- The Login Final-Response that accepts a Login Request can only come
+- as a response to a Login Request with the T bit set to 1, and both
+- the request and response MUST indicate FullFeaturePhase as the next
+- phase via the NSG field.
+-
+- Neither the initiator nor the target should attempt to declare or
+- negotiate a parameter more than once during login except for
+- responses to specific keys that explicitly allow repeated key
+- declarations (e.g., TargetAddress). An attempt to
+- renegotiate/redeclare parameters not specifically allowed MUST be
+- detected by the initiator and target. If such an attempt is detected
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 59]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- by the target, the target MUST respond with Login reject (initiator
+- error); if detected by the initiator, the initiator MUST drop the
+- connection.
+-
+-5.3.1. Login Phase Start
+-
+- The Login Phase starts with a Login Request from the initiator to the
+- target. The initial Login Request includes:
+-
+- - Protocol version supported by the initiator.
+- - iSCSI Initiator Name and iSCSI Target Name
+- - ISID, TSIH, and connection Ids
+- - Negotiation stage that the initiator is ready to enter.
+-
+- A login may create a new session or it may add a connection to an
+- existing session. Between a given iSCSI Initiator Node (selected
+- only by an InitiatorName) and a given iSCSI target defined by an
+- iSCSI TargetName and a Target Portal Group Tag, the login results are
+- defined by the following table:
+-
+-
+- +------------------------------------------------------------------+
+- |ISID | TSIH | CID | Target action |
+- +------------------------------------------------------------------+
+- |new | non-zero | any | fail the login |
+- | | | | ("session does not exist") |
+- +------------------------------------------------------------------+
+- |new | zero | any | instantiate a new session |
+- +------------------------------------------------------------------+
+- |existing | zero | any | do session reinstatement |
+- | | | | (see section 5.3.5) |
+- +------------------------------------------------------------------+
+- |existing | non-zero | new | add a new connection to |
+- | | existing | | the session |
+- +------------------------------------------------------------------+
+- |existing | non-zero |existing| do connection reinstatement|
+- | | existing | | (see section 5.3.4) |
+- +------------------------------------------------------------------+
+- |existing | non-zero | any | fail the login |
+- | | new | | ("session does not exist") |
+- +------------------------------------------------------------------+
+-
+- Determination of "existing" or "new" are made by the target.
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 60]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Optionally, the Login Request may include:
+-
+- - Security parameters
+- OR
+- - iSCSI operational parameters
+- AND/OR
+- - The next negotiation stage that the initiator is ready to
+- enter.
+-
+- The target can answer the login in the following ways:
+-
+- - Login Response with Login reject. This is an immediate rejection
+- from the target that causes the connection to terminate and the
+- session to terminate if this is the first (or only) connection of
+- a new session. The T bit and the CSG and NSG fields are
+- reserved.
+- - Login Response with Login Accept as a final response (T bit set
+- to 1 and the NSG in both request and response are set to
+- FullFeaturePhase). The response includes the protocol version
+- supported by the target and the session ID, and may include iSCSI
+- operational or security parameters (that depend on the current
+- stage).
+- - Login Response with Login Accept as a partial response (NSG not
+- set to FullFeaturePhase in both request and response) that
+- indicates the start of a negotiation sequence. The response
+- includes the protocol version supported by the target and either
+- security or iSCSI parameters (when no security mechanism is
+- chosen) supported by the target.
+-
+- If the initiator decides to forego the SecurityNegotiation stage, it
+- issues the Login with the CSG set to LoginOperationalNegotiation and
+- the target may reply with a Login Response that indicates that it is
+- unwilling to accept the connection (see Section 10.13 Login Response)
+- without SecurityNegotiation and will terminate the connection with a
+- response of Authentication failure (see Section 10.13.5 Status-Class
+- and Status-Detail).
+-
+- If the initiator is willing to negotiate iSCSI security, but is
+- unwilling to make the initial parameter proposal and may accept a
+- connection without iSCSI security, it issues the Login with the T bit
+- set to 1, the CSG set to SecurityNegotiation, and the NSG set to
+- LoginOperationalNegotiation. If the target is also ready to skip
+- security, the Login Response only contains the TargetPortalGroupTag
+- key (see Section 12.9 TargetPortalGroupTag), the T bit set to 1, the
+- CSG set to SecurityNegotiation, and the NSG set to
+- LoginOperationalNegotiation.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 61]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- An initiator that chooses to operate without iSCSI security, with all
+- the operational parameters taking the default values, issues the
+- Login with the T bit set to 1, the CSG set to
+- LoginOperationalNegotiation, and the NSG set to FullFeaturePhase. If
+- the target is also ready to forego security and can finish its
+- LoginOperationalNegotiation, the Login Response has T bit set to 1,
+- the CSG set to LoginOperationalNegotiation, and the NSG set to
+- FullFeaturePhase in the next stage.
+-
+- During the Login Phase the iSCSI target MUST return the
+- TargetPortalGroupTag key with the first Login Response PDU with which
+- it is allowed to do so (i.e., the first Login Response issued after
+- the first Login Request with the C bit set to 0) for all session
+- types when TargetName is given and the response is not a redirection.
+- The TargetPortalGroupTag key value indicates the iSCSI portal group
+- servicing the Login Request PDU. If the reconfiguration of iSCSI
+- portal groups is a concern in a given environment, the iSCSI
+- initiator should use this key to ascertain that it had indeed
+- initiated the Login Phase with the intended target portal group.
+-
+-5.3.2. iSCSI Security Negotiation
+-
+- The security exchange sets the security mechanism and authenticates
+- the initiator user and the target to each other. The exchange
+- proceeds according to the authentication method chosen in the
+- negotiation phase and is conducted using the Login Requests' and
+- responses' key=value parameters.
+-
+- An initiator directed negotiation proceeds as follows:
+-
+- - The initiator sends a Login Request with an ordered list of the
+- options it supports (authentication algorithm). The options are
+- listed in the initiator's order of preference. The initiator MAY
+- also send private or public extension options.
+-
+- - The target MUST reply with the first option in the list it
+- supports and is allowed to use for the specific initiator unless
+- it does not support any, in which case it MUST answer with
+- "Reject" (see Section 5.2 Text Mode Negotiation). The parameters
+- are encoded in UTF8 as key=value. For security parameters, see
+- Chapter 11.
+-
+- - When the initiator considers that it is ready to conclude the
+- SecurityNegotiation stage, it sets the T bit to 1 and the NSG to
+- what it would like the next stage to be. The target will then
+- set the T bit to 1 and set the NSG to the next stage in the Login
+- Response when it finishes sending its security keys. The next
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 62]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- stage selected will be the one the target selected. If the next
+- stage is FullFeaturePhase, the target MUST respond with a Login
+- Response with the TSIH value.
+-
+- If the security negotiation fails at the target, then the target MUST
+- send the appropriate Login Response PDU. If the security negotiation
+- fails at the initiator, the initiator SHOULD close the connection.
+-
+- It should be noted that the negotiation might also be directed by the
+- target if the initiator does support security, but is not ready to
+- direct the negotiation (propose options).
+-
+-5.3.3. Operational Parameter Negotiation During the Login Phase
+-
+- Operational parameter negotiation during the login MAY be done:
+-
+- - Starting with the first Login Request if the initiator does not
+- propose any security/integrity option.
+-
+- - Starting immediately after the security negotiation if the
+- initiator and target perform such a negotiation.
+-
+- Operational parameter negotiation MAY involve several Login
+- Request-Response exchanges started and terminated by the initiator.
+- The initiator MUST indicate its intent to terminate the negotiation
+- by setting the T bit to 1; the target sets the T bit to 1 on the last
+- response.
+-
+- If the target responds to a Login Request that has the T bit set to 1
+- with a Login Response that has the T bit set to 0, the initiator
+- should keep sending the Login Request (even empty) with the T bit set
+- to 1, while it still wants to switch stage, until it receives the
+- Login Response that has the T bit set to 1 or it receives a key that
+- requires it to set the T bit to 0.
+-
+- Some session specific parameters can only be specified during the
+- Login Phase of the first connection of a session (i.e., begun by a
+- Login Request that contains a zero-valued TSIH) - the leading Login
+- Phase (e.g., the maximum number of connections that can be used for
+- this session).
+-
+- A session is operational once it has at least one connection in
+- FullFeaturePhase. New or replacement connections can only be added
+- to a session after the session is operational.
+-
+- For operational parameters, see Chapter 12.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 63]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-5.3.4. Connection Reinstatement
+-
+- Connection reinstatement is the process of an initiator logging in
+- with an ISID-TSIH-CID combination that is possibly active from the
+- target's perspective, which causes the implicit logging out of the
+- connection corresponding to the CID, and reinstating a new Full
+- Feature Phase iSCSI connection in its place (with the same CID).
+- Thus, the TSIH in the Login PDU MUST be non-zero and the CID does not
+- change during a connection reinstatement. The Login Request performs
+- the logout function of the old connection if an explicit logout was
+- not performed earlier. In sessions with a single connection, this
+- may imply the opening of a second connection with the sole purpose of
+- cleaning up the first. Targets MUST support opening a second
+- connection even when they do not support multiple connections in Full
+- Feature Phase if ErrorRecoveryLevel is 2 and SHOULD support opening a
+- second connection if ErrorRecoveryLevel is less than 2.
+-
+- If the operational ErrorRecoveryLevel is 2, connection reinstatement
+- enables future task reassignment. If the operational
+- ErrorRecoveryLevel is less than 2, connection reinstatement is the
+- replacement of the old CID without enabling task reassignment. In
+- this case, all the tasks that were active on the old CID must be
+- immediately terminated without further notice to the initiator.
+-
+- The initiator connection state MUST be CLEANUP_WAIT (section 7.1.3)
+- when the initiator attempts a connection reinstatement.
+-
+- In practical terms, in addition to the implicit logout of the old
+- connection, reinstatement is equivalent to a new connection login.
+-
+-5.3.5. Session Reinstatement, Closure, and Timeout
+-
+- Session reinstatement is the process of the initiator logging in with
+- an ISID that is possibly active from the target's perspective. Thus
+- implicitly logging out the session that corresponds to the ISID and
+- reinstating a new iSCSI session in its place (with the same ISID).
+- Therefore, the TSIH in the Login PDU MUST be zero to signal session
+- reinstatement. Session reinstatement causes all the tasks that were
+- active on the old session to be immediately terminated by the target
+- without further notice to the initiator.
+-
+- The initiator session state MUST be FAILED (Section 7.3 Session State
+- Diagrams) when the initiator attempts a session reinstatement.
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 64]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Session closure is an event defined to be one of the following:
+-
+- - A successful "session close" logout.
+- - A successful "connection close" logout for the last Full Feature
+- Phase connection when no other connection in the session is
+- waiting for cleanup (Section 7.2 Connection Cleanup State Diagram
+- for Initiators and Targets) and no tasks in the session are
+- waiting for reassignment.
+-
+- Session timeout is an event defined to occur when the last connection
+- state timeout expires and no tasks are waiting for reassignment.
+- This takes the session to the FREE state (N6 transition in the
+- session state diagram).
+-
+-5.3.5.1. Loss of Nexus Notification
+-
+- The iSCSI layer provides the SCSI layer with the "I_T nexus loss"
+- notification when any one of the following events happens:
+-
+- a) Successful completion of session reinstatement.
+- b) Session closure event.
+- c) Session timeout event.
+-
+- Certain SCSI object clearing actions may result due to the
+- notification in the SCSI end nodes, as documented in Appendix F.
+- - Clearing Effects of Various Events on Targets -.
+-
+-5.3.6. Session Continuation and Failure
+-
+- Session continuation is the process by which the state of a
+- preexisting session continues to be used by connection reinstatement
+- (Section 5.3.4 Connection Reinstatement), or by adding a connection
+- with a new CID. Either of these actions associates the new transport
+- connection with the session state.
+-
+- Session failure is an event where the last Full Feature Phase
+- connection reaches the CLEANUP_WAIT state (Section 7.2 Connection
+- Cleanup State Diagram for Initiators and Targets), or completes a
+- successful recovery logout, thus causing all active tasks (that are
+- formerly allegiant to the connection) to start waiting for task
+- reassignment.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 65]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-5.4. Operational Parameter Negotiation Outside the Login Phase
+-
+- Some operational parameters MAY be negotiated outside (after) the
+- Login Phase.
+-
+- Parameter negotiation in Full Feature Phase is done through Text
+- requests and responses. Operational parameter negotiation MAY
+- involve several Text request-response exchanges, which the initiator
+- always starts and terminates using the same Initiator Task Tag. The
+- initiator MUST indicate its intent to terminate the negotiation by
+- setting the F bit to 1; the target sets the F bit to 1 on the last
+- response.
+-
+- If the target responds to a Text request with the F bit set to 1 and
+- with a Text response with the F bit set to 0, the initiator should
+- keep sending the Text request (even empty) with the F bit set to 1,
+- while it still wants to finish the negotiation, until it receives the
+- Text response with the F bit set to 1. Responding to a Text request
+- with the F bit set to 1 with an empty (no key=value pairs) response
+- with the F bit set to 0 is discouraged.
+-
+- Targets MUST NOT submit parameters that require an additional
+- initiator Text request in a Text response with the F bit set to 1.
+-
+- In a negotiation sequence, the F bit settings in one pair of Text
+- request-responses have no bearing on the F bit settings of the next
+- pair. An initiator that has the F bit set to 1 in a request and is
+- being answered with an F bit setting of 0 may issue the next request
+- with the F bit set to 0.
+-
+- Whenever the target responds with the F bit set to 0, it MUST set the
+- Target Transfer Tag to a value other than the default 0xffffffff.
+-
+- An initiator MAY reset an operational parameter negotiation by
+- issuing a Text request with the Target Transfer Tag set to the value
+- 0xffffffff after receiving a response with the Target Transfer Tag
+- set to a value other than 0xffffffff. A target may reset an
+- operational parameter negotiation by answering a Text request with a
+- Reject PDU.
+-
+- Neither the initiator nor the target should attempt to declare or
+- negotiate a parameter more than once during any negotiation sequence
+- without an intervening operational parameter negotiation reset,
+- except for responses to specific keys that explicitly allow repeated
+- key declarations (e.g., TargetAddress). If detected by the target,
+- this MUST result in a Reject PDU with a reason of "protocol error".
+- The initiator MUST reset the negotiation as outlined above.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 66]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Parameters negotiated by a text exchange negotiation sequence only
+- become effective after the negotiation sequence is completed.
+-
+-6. iSCSI Error Handling and Recovery
+-
+-6.1. Overview
+-
+-6.1.1. Background
+-
+- The following two considerations prompted the design of much of the
+- error recovery functionality in iSCSI:
+-
+- i) An iSCSI PDU may fail the digest check and be dropped, despite
+- being received by the TCP layer. The iSCSI layer must
+- optionally be allowed to recover such dropped PDUs.
+- ii) A TCP connection may fail at any time during the data
+- transfer. All the active tasks must optionally be allowed to
+- continue on a different TCP connection within the same
+- session.
+-
+- Implementations have considerable flexibility in deciding what degree
+- of error recovery to support, when to use it and by which mechanisms
+- to achieve the required behavior. Only the externally visible
+- actions of the error recovery mechanisms must be standardized to
+- ensure interoperability.
+-
+- This chapter describes a general model for recovery in support of
+- interoperability. See Appendix E. - Algorithmic Presentation of
+- Error Recovery Classes - for further detail on how the described
+- model may be implemented. Compliant implementations do not have to
+- match the implementation details of this model as presented, but the
+- external behavior of such implementations must correspond to the
+- externally observable characteristics of the presented model.
+-
+-6.1.2. Goals
+-
+- The major design goals of the iSCSI error recovery scheme are as
+- follows:
+-
+- a) Allow iSCSI implementations to meet different requirements by
+- defining a collection of error recovery mechanisms that
+- implementations may choose from.
+- b) Ensure interoperability between any two implementations
+- supporting different sets of error recovery capabilities.
+- c) Define the error recovery mechanisms to ensure command
+- ordering even in the face of errors, for initiators that
+- demand ordering.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 67]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- d) Do not make additions in the fast path, but allow moderate
+- complexity in the error recovery path.
+- e) Prevent both the initiator and target from attempting to
+- recover the same set of PDUs at the same time. For example,
+- there must be a clear "error recovery functionality
+- distribution" between the initiator and target.
+-
+-6.1.3. Protocol Features and State Expectations
+-
+- The initiator mechanisms defined in connection with error recovery
+- are:
+-
+- a) NOP-OUT to probe sequence numbers of the target (section
+- 10.18)
+- b) Command retry (section 6.2.1)
+- c) Recovery R2T support (section 6.7)
+- d) Requesting retransmission of status/data/R2T using the SNACK
+- facility (section 10.16)
+- e) Acknowledging the receipt of the data (section 10.16)
+- f) Reassigning the connection allegiance of a task to a different
+- TCP connection (section 6.2.2)
+- g) Terminating the entire iSCSI session to start afresh (section
+- 6.1.4.4)
+-
+- The target mechanisms defined in connection with error recovery are:
+-
+- a) NOP-IN to probe sequence numbers of the initiator (section
+- 10.19)
+- b) Requesting retransmission of data using the recovery R2T
+- feature (section 6.7)
+- c) SNACK support (section 10.16) d) Requesting that parts of
+- read data be acknowledged (section 10.7.2)
+- e) Allegiance reassignment support (section 6.2.2)
+- f) Terminating the entire iSCSI session to force the initiator to
+- start over (section 6.1.4.4)
+-
+- For any outstanding SCSI command, it is assumed that iSCSI, in
+- conjunction with SCSI at the initiator, is able to keep enough
+- information to be able to rebuild the command PDU, and that outgoing
+- data is available (in host memory) for retransmission while the
+- command is outstanding. It is also assumed that at the target,
+- incoming data (read data) MAY be kept for recovery or it can be
+- reread from a device server.
+-
+- It is further assumed that a target will keep the "status & sense"
+- for a command it has executed if it supports status retransmission.
+- A target that agrees to support data retransmission is expected to be
+- prepared to retransmit the outgoing data (i.e., Data-In) on request
+-
+-
+-
+-Satran, et al. Standards Track [Page 68]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- until either the status for the completed command is acknowledged, or
+- the data in question has been separately acknowledged.
+-
+-6.1.4. Recovery Classes
+-
+- iSCSI enables the following classes of recovery (in the order of
+- increasing scope of affected iSCSI tasks):
+-
+- - Within a command (i.e., without requiring command restart).
+- - Within a connection (i.e., without requiring the connection to
+- be rebuilt, but perhaps requiring command restart).
+- - Connection recovery (i.e., perhaps requiring connections to be
+- rebuilt and commands to be reissued).
+- - Session recovery.
+-
+- The recovery scenarios detailed in the rest of this section are
+- representative rather than exclusive. In every case, they detail the
+- lowest class recovery that MAY be attempted. The implementer is left
+- to decide under which circumstances to escalate to the next recovery
+- class and/or what recovery classes to implement. Both the iSCSI
+- target and initiator MAY escalate the error handling to an error
+- recovery class, which impacts a larger number of iSCSI tasks in any
+- of the cases identified in the following discussion.
+-
+- In all classes, the implementer has the choice of deferring errors to
+- the SCSI initiator (with an appropriate response code), in which case
+- the task, if any, has to be removed from the target and all the side
+- effects, such as ACA, must be considered.
+-
+- Use of within-connection and within-command recovery classes MUST NOT
+- be attempted before the connection is in Full Feature Phase.
+-
+- In the detailed description of the recovery classes, the mandating
+- terms (MUST, SHOULD, MAY, etc.) indicate normative actions to be
+- executed if the recovery class is supported and used.
+-
+-6.1.4.1. Recovery Within-command
+-
+- At the target, the following cases lend themselves to
+- within-command recovery:
+-
+- - Lost data PDU - realized through one of the following:
+-
+- a) Data digest error - dealt with as specified in Section 6.7
+- Digest Errors, using the option of a recovery R2T.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 69]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- b) Sequence reception timeout (no data or
+- partial-data-and-no-F-bit) - considered an implicit sequence
+- error and dealt with as specified in Section 6.8 Sequence
+- Errors, using the option of a recovery R2T.
+- c) Header digest error, which manifests as a sequence reception
+- timeout or a sequence error - dealt with as specified in
+- Section 6.8 Sequence Errors, using the option of a recovery
+- R2T.
+-
+- At the initiator, the following cases lend themselves to
+- within-command recovery:
+-
+- Lost data PDU or lost R2T - realized through one of the
+- following:
+-
+- a) Data digest error - dealt with as specified in Section 6.7
+- Digest Errors, using the option of a SNACK.
+- b) Sequence reception timeout (no status) or response reception
+- timeout - dealt with as specified in Section 6.8 Sequence
+- Errors, using the option of a SNACK.
+- c) Header digest error, which manifests as a sequence reception
+- timeout or a sequence error - dealt with as specified in
+- Section 6.8 Sequence Errors, using the option of a SNACK.
+-
+- To avoid a race with the target, which may already have a recovery
+- R2T or a termination response on its way, an initiator SHOULD NOT
+- originate a SNACK for an R2T based on its internal timeouts (if any).
+- Recovery in this case is better left to the target.
+-
+- The timeout values used by the initiator and target are outside the
+- scope of this document. Sequence reception timeout is generally a
+- large enough value to allow the data sequence transfer to be
+- complete.
+-
+-6.1.4.2. Recovery Within-connection
+-
+- At the initiator, the following cases lend themselves to
+- within-connection recovery:
+-
+- - Requests not acknowledged for a long time. Requests are
+- acknowledged explicitly through ExpCmdSN or implicitly by
+- receiving data and/or status. The initiator MAY retry
+- non-acknowledged commands as specified in Section 6.2 Retry and
+- Reassign in Recovery.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 70]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - Lost iSCSI numbered Response. It is recognized by either
+- identifying a data digest error on a Response PDU or a Data-In
+- PDU carrying the status, or by receiving a Response PDU with a
+- higher StatSN than expected. In the first case, digest error
+- handling is done as specified in Section 6.7 Digest Errors using
+- the option of a SNACK. In the second case, sequence error
+- handling is done as specified in Section 6.8 Sequence Errors,
+- using the option of a SNACK.
+-
+- At the target, the following cases lend themselves to
+- within-connection recovery:
+-
+- - Status/Response not acknowledged for a long time. The target MAY
+- issue a NOP-IN (with a valid Target Transfer Tag or otherwise)
+- that carries the next status sequence number it is going to use
+- in the StatSN field. This helps the initiator detect any missing
+- StatSN(s) and issue a SNACK for the status.
+-
+- The timeout values used by the initiator and the target are outside
+- the scope of this document.
+-
+-6.1.4.3. Connection Recovery
+-
+- At an iSCSI initiator, the following cases lend themselves to
+- connection recovery:
+-
+- - TCP connection failure: The initiator MUST close the connection.
+- It then MUST either implicitly or explicitly logout the failed
+- connection with the reason code "remove the connection for
+- recovery" and reassign connection allegiance for all commands
+- still in progress associated with the failed connection on one or
+- more connections (some or all of which MAY be newly established
+- connections) using the "Task reassign" task management function
+- (see Section 10.5.1 Function). For an initiator, a command is in
+- progress as long as it has not received a response or a Data-In
+- PDU including status.
+-
+- Note: The logout function is mandatory. However, a new connection
+- establishment is only mandatory if the failed connection was the
+- last or only connection in the session.
+-
+- - Receiving an Asynchronous Message that indicates one or all
+- connections in a session has been dropped. The initiator MUST
+- handle it as a TCP connection failure for the connection(s)
+- referred to in the Message.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 71]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- At an iSCSI target, the following cases lend themselves to connection
+- recovery:
+-
+- - TCP connection failure. The target MUST close the connection and,
+- if more than one connection is available, the target SHOULD send
+- an Asynchronous Message that indicates it has dropped the
+- connection. Then, the target will wait for the initiator to
+- continue recovery.
+-
+-6.1.4.4. Session Recovery
+-
+- Session recovery should be performed when all other recovery attempts
+- have failed. Very simple initiators and targets MAY perform session
+- recovery on all iSCSI errors and rely on recovery on the SCSI layer
+- and above.
+-
+- Session recovery implies the closing of all TCP connections,
+- internally aborting all executing and queued tasks for the given
+- initiator at the target, terminating all outstanding SCSI commands
+- with an appropriate SCSI service response at the initiator, and
+- restarting a session on a new set of connection(s) (TCP connection
+- establishment and login on all new connections).
+-
+- For possible clearing effects of session recovery on SCSI and iSCSI
+- objects, refer to Appendix F. - Clearing Effects of Various Events on
+- Targets -.
+-
+-6.1.5. Error Recovery Hierarchy
+-
+- The error recovery classes described so far are organized into a
+- hierarchy for ease in understanding and to limit the implementation
+- complexity. With few and well defined recovery levels
+- interoperability is easier to achieve. The attributes of this
+- hierarchy are as follows:
+-
+- a) Each level is a superset of the capabilities of the previous
+- level. For example, Level 1 support implies supporting all
+- capabilities of Level 0 and more.
+- b) As a corollary, supporting a higher error recovery level means
+- increased sophistication and possibly an increase in resource
+- requirements.
+- c) Supporting error recovery level "n" is advertised and
+- negotiated by each iSCSI entity by exchanging the text key
+- "ErrorRecoveryLevel=n". The lower of the two exchanged values
+- is the operational ErrorRecoveryLevel for the session.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 72]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The following diagram represents the error recovery hierarchy.
+-
+- +
+- /
+- / 2 \ <-- Connection recovery
+- +-----+
+- / 1 \ <-- Digest failure recovery
+- +---------+
+- / 0 \ <-- Session failure recovery
+- +-------------+
+-
+- The following table lists the error recovery capabilities expected
+- from the implementations that support each error recovery level.
+-
+- +-------------------+--------------------------------------------+
+- |ErrorRecoveryLevel | Associated Error recovery capabilities |
+- +-------------------+--------------------------------------------+
+- | 0 | Session recovery class |
+- | | (Section 6.1.4.4 Session Recovery) |
+- +-------------------+--------------------------------------------+
+- | 1 | Digest failure recovery (See Note below.) |
+- | | plus the capabilities of ER Level 0 |
+- +-------------------+--------------------------------------------+
+- | 2 | Connection recovery class |
+- | | (Section 6.1.4.3 Connection Recovery) |
+- | | plus the capabilities of ER Level 1 |
+- +-------------------+--------------------------------------------+
+-
+- Note: Digest failure recovery is comprised of two recovery classes:
+- Within-Connection recovery class (Section 6.1.4.2 Recovery Within-
+- connection) and Within-Command recovery class (Section 6.1.4.1
+- Recovery Within-command).
+-
+- When a defined value of ErrorRecoveryLevel is proposed by an
+- originator in a text negotiation, the originator MUST support the
+- functionality defined for the proposed value and additionally, the
+- functionality corresponding to any defined value numerically less
+- than the proposed. When a defined value of ErrorRecoveryLevel is
+- returned by a responder in a text negotiation, the responder MUST
+- support the functionality corresponding to the ErrorRecoveryLevel it
+- is accepting.
+-
+- When either party attempts to use error recovery functionality beyond
+- what is negotiated, the recovery attempts MAY fail unless an a priori
+- agreement outside the scope of this document exists between the two
+- parties to provide such support.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 73]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Implementations MUST support error recovery level "0", while the rest
+- are OPTIONAL to implement. In implementation terms, the above
+- striation means that the following incremental sophistication with
+- each level is required.
+-
+- +-------------------+---------------------------------------------+
+- |Level transition | Incremental requirement |
+- +-------------------+---------------------------------------------+
+- | 0->1 | PDU retransmissions on the same connection |
+- +-------------------+---------------------------------------------+
+- | 1->2 | Retransmission across connections and |
+- | | allegiance reassignment |
+- +-------------------+---------------------------------------------+
+-
+-6.2. Retry and Reassign in Recovery
+-
+- This section summarizes two important and somewhat related iSCSI
+- protocol features used in error recovery.
+-
+-6.2.1. Usage of Retry
+-
+- By resending the same iSCSI command PDU ("retry") in the absence of a
+- command acknowledgement (by way of an ExpCmdSN update) or a response,
+- an initiator attempts to "plug" (what it thinks are) the
+- discontinuities in CmdSN ordering on the target end. Discarded
+- command PDUs, due to digest errors, may have created these
+- discontinuities.
+-
+- Retry MUST NOT be used for reasons other than plugging command
+- sequence gaps, and in particular, cannot be used for requesting PDU
+- retransmissions from a target. Any such PDU retransmission requests
+- for a currently allegiant command in progress may be made using the
+- SNACK mechanism described in section 10.16, although the usage of
+- SNACK is OPTIONAL.
+-
+- If initiators, as part of plugging command sequence gaps as described
+- above, inadvertently issue retries for allegiant commands already in
+- progress (i.e., targets did not see the discontinuities in CmdSN
+- ordering), the duplicate commands are silently ignored by targets as
+- specified in section 3.2.2.1.
+-
+- When an iSCSI command is retried, the command PDU MUST carry the
+- original Initiator Task Tag and the original operational attributes
+- (e.g., flags, function names, LUN, CDB etc.) as well as the original
+- CmdSN. The command being retried MUST be sent on the same connection
+- as the original command unless the original connection was already
+- successfully logged out.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 74]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-6.2.2. Allegiance Reassignment
+-
+- By issuing a "task reassign" task management request (Section 10.5.1
+- Function), the initiator signals its intent to continue an already
+- active command (but with no current connection allegiance) as part of
+- connection recovery. This means that a new connection allegiance is
+- requested for the command, which seeks to associate it to the
+- connection on which the task management request is being issued.
+- Before the allegiance reassignment is attempted for a task, an
+- implicit or explicit Logout with the reason code "remove the
+- connection for recovery" ( see section 10.14) MUST be successfully
+- completed for the previous connection to which the task was
+- allegiant.
+-
+- In reassigning connection allegiance for a command, the targets
+- SHOULD continue the command from its current state. For example,
+- when reassigning read commands, the target SHOULD take advantage of
+- the ExpDataSN field provided by the Task Management function request
+- (which must be set to zero if there was no data transfer) and bring
+- the read command to completion by sending the remaining data and
+- sending (or resending) the status. ExpDataSN acknowledges all data
+- sent up to, but not including, the Data-In PDU and or R2T with DataSN
+- (or R2TSN) equal to ExpDataSN. However, targets may choose to
+- send/receive all unacknowledged data or all of the data on a
+- reassignment of connection allegiance if unable to recover or
+- maintain an accurate state. Initiators MUST not subsequently request
+- data retransmission through Data SNACK for PDUs numbered less than
+- ExpDataSN (i.e., prior to the acknowledged sequence number). For all
+- types of commands, a reassignment request implies that the task is
+- still considered in progress by the initiator and the target must
+- conclude the task appropriately if the target returns the "Function
+- Complete" response to the reassignment request. This might possibly
+- involve retransmission of data/R2T/status PDUs as necessary, but MUST
+- involve the (re)transmission of the status PDU.
+-
+- It is OPTIONAL for targets to support the allegiance reassignment.
+- This capability is negotiated via the ErrorRecoveryLevel text key
+- during the login time. When a target does not support allegiance
+- reassignment, it MUST respond with a Task Management response code of
+- "Allegiance reassignment not supported". If allegiance reassignment
+- is supported by the target, but the task is still allegiant to a
+- different connection, or a successful recovery Logout of the
+- previously allegiant connection was not performed, the target MUST
+- respond with a Task Management response code of "Task still
+- allegiant".
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 75]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- If allegiance reassignment is supported by the target, the Task
+- Management response to the reassignment request MUST be issued before
+- the reassignment becomes effective.
+-
+- If a SCSI Command that involves data input is reassigned, any SNACK
+- Tag it holds for a final response from the original connection is
+- deleted and the default value of 0 MUST be used instead.
+-
+-6.3. Usage Of Reject PDU in Recovery
+-
+- Targets MUST NOT implicitly terminate an active task by sending a
+- Reject PDU for any PDU exchanged during the life of the task. If the
+- target decides to terminate the task, a Response PDU (SCSI, Text,
+- Task, etc.) must be returned by the target to conclude the task. If
+- the task had never been active before the Reject (i.e., the Reject is
+- on the command PDU), targets should not send any further responses
+- because the command itself is being discarded.
+-
+- The above rule means that the initiator can eventually expect a
+- response on receiving Rejects, if the received Reject is for a PDU
+- other than the command PDU itself. The non-command Rejects only have
+- diagnostic value in logging the errors, and they can be used for
+- retransmission decisions by the initiators.
+-
+- The CmdSN of the rejected command PDU (if it is a non-immediate
+- command) MUST NOT be considered received by the target (i.e., a
+- command sequence gap must be assumed for the CmdSN), even though the
+- CmdSN of the rejected command PDU may be reliably ascertained. Upon
+- receiving the Reject, the initiator MUST plug the CmdSN gap in order
+- to continue to use the session. The gap may be plugged either by
+- transmitting a command PDU with the same CmdSN, or by aborting the
+- task (see section 6.9 on how an abort may plug a CmdSN gap).
+-
+- When a data PDU is rejected and its DataSN can be ascertained, a
+- target MUST advance ExpDataSN for the current data burst if a
+- recovery R2T is being generated. The target MAY advance its
+- ExpDataSN if it does not attempt to recover the lost data PDU.
+-
+-6.4. Connection Timeout Management
+-
+- iSCSI defines two session-global timeout values (in seconds)
+- - Time2Wait and Time2Retain - that are applicable when an iSCSI Full
+- Feature Phase connection is taken out of service either intentionally
+- or by an exception. Time2Wait is the initial "respite time" before
+- attempting an explicit/implicit Logout for the CID in question or
+- task reassignment for the affected tasks (if any). Time2Retain is
+- the maximum time after the initial respite interval that the task
+- and/or connection state(s) is/are guaranteed to be maintained on the
+-
+-
+-
+-Satran, et al. Standards Track [Page 76]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- target to cater to a possible recovery attempt. Recovery attempts
+- for the connection and/or task(s) SHOULD NOT be made before Time2Wait
+- seconds, but MUST be completed within Time2Retain seconds after that
+- initial Time2Wait waiting period.
+-
+-6.4.1. Timeouts on Transport Exception Events
+-
+- A transport connection shutdown or a transport reset without any
+- preceding iSCSI protocol interactions informing the end-points of the
+- fact causes a Full Feature Phase iSCSI connection to be abruptly
+- terminated. The timeout values to be used in this case are the
+- negotiated values of defaultTime2Wait (Section 12.15
+- DefaultTime2Wait) and DefaultTime2Retain (Section 12.16
+- DefaultTime2Retain) text keys for the session.
+-
+-6.4.2. Timeouts on Planned Decommissioning
+-
+- Any planned decommissioning of a Full Feature Phase iSCSI connection
+- is preceded by either a Logout Response PDU, or an Async Message PDU.
+- The Time2Wait and Time2Retain field values (section 10.15) in a
+- Logout Response PDU, and the Parameter2 and Parameter3 fields of an
+- Async Message (AsyncEvent types "drop the connection" or "drop all
+- the connections"; section 10.9.1) specify the timeout values to be
+- used in each of these cases.
+-
+- These timeout values are only applicable for the affected connection,
+- and the tasks active on that connection. These timeout values have
+- no bearing on initiator timers (if any) that are already running on
+- connections or tasks associated with that session.
+-
+-6.5. Implicit Termination of Tasks
+-
+- A target implicitly terminates the active tasks due to iSCSI protocol
+- dynamics in the following cases:
+-
+- a) When a connection is implicitly or explicitly logged out with
+- the reason code of "Close the connection" and there are active
+- tasks allegiant to that connection.
+-
+- b) When a connection fails and the connection state eventually
+- times out (state transition M1 in Section 7.2.2 State
+- Transition Descriptions for Initiators and Targets) and there
+- are active tasks allegiant to that connection.
+-
+- c) When a successful Logout with the reason code of "remove the
+- connection for recovery" is performed while there are active
+- tasks allegiant to that connection, and those tasks eventually
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 77]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- time out after the Time2Wait and Time2Retain periods without
+- allegiance reassignment.
+-
+- d) When a connection is implicitly or explicitly logged out with
+- the reason code of "Close the session" and there are active
+- tasks in that session.
+-
+- If the tasks terminated in the above cases a), b, c) and d)are SCSI
+- tasks, they must be internally terminated as if with CHECK CONDITION
+- status. This status is only meaningful for appropriately handling
+- the internal SCSI state and SCSI side effects with respect to
+- ordering because this status is never communicated back as a
+- terminating status to the initiator. However additional actions may
+- have to be taken at SCSI level depending on the SCSI context as
+- defined by the SCSI standards (e.g., queued commands and ACA, in
+- cases a), b), and c), after the tasks are terminated, the target MUST
+- report a Unit Attention condition on the next command processed on
+- any connection for each affected I_T_L nexus with the status of CHECK
+- CONDITION, and the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED
+- BY ISCSI PROTOCOL EVENT" , etc. - see [SAM2] and [SPC3]).
+-
+-6.6. Format Errors
+-
+- The following two explicit violations of PDU layout rules are format
+- errors:
+-
+- a) Illegal contents of any PDU header field except the Opcode
+- (legal values are specified in Section 10 iSCSI PDU Formats).
+- b) Inconsistent field contents (consistent field contents are
+- specified in Section 10 iSCSI PDU Formats).
+-
+- Format errors indicate a major implementation flaw in one of the
+- parties.
+-
+- When a target or an initiator receives an iSCSI PDU with a format
+- error, it MUST immediately terminate all transport connections in the
+- session either with a connection close or with a connection reset and
+- escalate the format error to session recovery (see Section 6.1.4.4
+- Session Recovery).
+-
+-6.7. Digest Errors
+-
+- The discussion of the legal choices in handling digest errors below
+- excludes session recovery as an explicit option, but either party
+- detecting a digest error may choose to escalate the error to session
+- recovery.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 78]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- When a target or an initiator receives any iSCSI PDU, with a header
+- digest error, it MUST either discard the header and all data up to
+- the beginning of a later PDU or close the connection. Because the
+- digest error indicates that the length field of the header may have
+- been corrupted, the location of the beginning of a later PDU needs to
+- be reliably ascertained by other means such as the operation of a
+- sync and steering layer.
+-
+- When a target receives any iSCSI PDU with a payload digest error, it
+- MUST answer with a Reject PDU with a reason code of
+- Data-Digest-Error and discard the PDU.
+-
+- - If the discarded PDU is a solicited or unsolicited iSCSI data
+- PDU (for immediate data in a command PDU, non-data PDU rule
+- below applies), the target MUST do one of the following:
+- a) Request retransmission with a recovery R2T.
+- b) Terminate the task with a response PDU with a CHECK
+- CONDITION Status and an iSCSI Condition of "protocol service
+- CRC error" (Section 10.4.7.2 Sense Data). If the target
+- chooses to implement this option, it MUST wait to receive
+- all the data (signaled by a Data PDU with the final bit set
+- for all outstanding R2Ts) before sending the response PDU.
+- A task management command (such as an abort task) from the
+- initiator during this wait may also conclude the task.
+- - No further action is necessary for targets if the discarded PDU
+- is a non-data PDU. In case of immediate data being present on
+- a discarded command, the immediate data is implicitly recovered
+- when the task is retried (see section 6.2.1), followed by the
+- entire data transfer for the task.
+-
+- When an initiator receives any iSCSI PDU with a payload digest error,
+- it MUST discard the PDU.
+-
+- - If the discarded PDU is an iSCSI data PDU, the initiator MUST do
+- one of the following:
+-
+- a) Request the desired data PDU through SNACK. In response to the
+- SNACK, the target MUST either resend the data PDU or reject the
+- SNACK with a Reject PDU with a reason code of "SNACK reject" in
+- which case:
+- i) If the status has not already been sent for the command,
+- the target MUST terminate the command with a CHECK
+- CONDITION Status and an iSCSI Condition of "SNACK rejected"
+- (Section 10.4.7.2 Sense Data).
+- ii) If the status was already sent, no further action is
+- necessary for the target. The initiator in this case MUST
+- wait for the status to be received and then discard it, so
+- as to internally signal the completion with CHECK CONDITION
+-
+-
+-
+-Satran, et al. Standards Track [Page 79]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Status and an iSCSI Condition of "protocol service CRC
+- error" (Section 10.4.7.2 Sense Data).
+- b) Abort the task and terminate the command with an error.
+-
+- - If the discarded PDU is a response PDU, the initiator MUST do one
+- of the following:
+-
+- a) Request PDU retransmission with a status SNACK.
+- b) Logout the connection for recovery and continue the tasks on a
+- different connection instance as described in Section 6.2 Retry
+- and Reassign in Recovery.
+- c) Logout to close the connection (abort all the commands
+- associated with the connection).
+-
+- - No further action is necessary for initiators if the discarded PDU
+- is an unsolicited PDU (e.g., Async, Reject). Task timeouts as in
+- the initiator waiting for a command completion, or process
+- timeouts, as in the target waiting for a Logout, will ensure that
+- the correct operational behavior will result in these cases
+- despite the discarded PDU.
+-
+-6.8. Sequence Errors
+-
+- When an initiator receives an iSCSI R2T/data PDU with an out of order
+- R2TSN/DataSN or a SCSI response PDU with an ExpDataSN that implies
+- missing data PDU(s), it means that the initiator must have detected a
+- header or payload digest error on one or more earlier R2T/data PDUs.
+- The initiator MUST address these implied digest errors as described
+- in Section 6.7 Digest Errors. When a target receives a data PDU with
+- an out of order DataSN, it means that the target must have hit a
+- header or payload digest error on at least one of the earlier data
+- PDUs. The target MUST address these implied digest errors as
+- described in Section 6.7 Digest Errors.
+-
+- When an initiator receives an iSCSI status PDU with an out of order
+- StatSN that implies missing responses, it MUST address the one or
+- more missing status PDUs as described in Section 6.7 Digest Errors.
+- As a side effect of receiving the missing responses, the initiator
+- may discover missing data PDUs. If the initiator wants to recover
+- the missing data for a command, it MUST NOT acknowledge the received
+- responses that start from the StatSN of the relevant command, until
+- it has completed receiving all the data PDUs of the command.
+-
+- When an initiator receives duplicate R2TSNs (due to proactive
+- retransmission of R2Ts by the target) or duplicate DataSNs (due to
+- proactive SNACKs by the initiator), it MUST discard the duplicates.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 80]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-6.9. SCSI Timeouts
+-
+- An iSCSI initiator MAY attempt to plug a command sequence gap on the
+- target end (in the absence of an acknowledgement of the command by
+- way of ExpCmdSN) before the ULP timeout by retrying the
+- unacknowledged command, as described in Section 6.2 Retry and
+- Reassign in Recovery.
+-
+- On a ULP timeout for a command (that carried a CmdSN of n), if the
+- iSCSI initiator intends to continue the session, it MUST abort the
+- command by either using an appropriate Task Management function
+- request for the specific command, or a "close the connection" Logout.
+- When using an ABORT TASK, if the ExpCmdSN is still less than (n+1),
+- the target may see the abort request while missing the original
+- command itself due to one of the following reasons:
+-
+- - Original command was dropped due to digest error.
+- - Connection on which the original command was sent was
+- successfully logged out. Upon logout, the unacknowledged
+- commands issued on the connection being logged out are
+- discarded.
+-
+- If the abort request is received and the original command is missing,
+- targets MUST consider the original command with that RefCmdSN to be
+- received and issue a Task Management response with the response code:
+- "Function Complete". This response concludes the task on both ends.
+- If the abort request is received and the target can determine (based
+- on the Referenced Task Tag) that the command was received and
+- executed and also that the response was sent prior to the abort, then
+- the target MUST respond with the response code of "Task Does Not
+- Exist".
+-
+-6.10. Negotiation Failures
+-
+- Text request and response sequences, when used to set/negotiate
+- operational parameters, constitute the negotiation/parameter setting.
+- A negotiation failure is considered to be one or more of the
+- following:
+-
+- - None of the choices, or the stated value, is acceptable to one
+- of the sides in the negotiation.
+- - The text request timed out and possibly terminated.
+- - The text request was answered with a Reject PDU.
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 81]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The following two rules should be used to address negotiation
+- failures:
+-
+- - During Login, any failure in negotiation MUST be considered a
+- login process failure and the Login Phase must be terminated,
+- and with it, the connection. If the target detects the
+- failure, it must terminate the login with the appropriate Login
+- Response code.
+-
+- - A failure in negotiation, while in the Full Feature Phase, will
+- terminate the entire negotiation sequence that may consist of a
+- series of text requests that use the same Initiator Task Tag.
+- The operational parameters of the session or the connection
+- MUST continue to be the values agreed upon during an earlier
+- successful negotiation (i.e., any partial results of this
+- unsuccessful negotiation MUST NOT take effect and MUST be
+- discarded).
+-
+-6.11. Protocol Errors
+-
+- Mapping framed messages over a "stream" connection, such as TCP,
+- makes the proposed mechanisms vulnerable to simple software framing
+- errors. On the other hand, the introduction of framing mechanisms to
+- limit the effects of these errors may be onerous on performance for
+- simple implementations. Command Sequence Numbers and the above
+- mechanisms for connection drop and reestablishment help handle this
+- type of mapping errors.
+-
+- All violations of iSCSI PDU exchange sequences specified in this
+- document are also protocol errors. This category of errors can only
+- be addressed by fixing the implementations; iSCSI defines Reject and
+- response codes to enable this.
+-
+-6.12. Connection Failures
+-
+- iSCSI can keep a session in operation if it is able to
+- keep/establish at least one TCP connection between the initiator and
+- the target in a timely fashion. Targets and/or initiators may
+- recognize a failing connection by either transport level means (TCP),
+- a gap in the command sequence number, a response stream that is not
+- filled for a long time, or by a failing iSCSI NOP (acting as a ping).
+- The latter MAY be used periodically to increase the speed and
+- likelihood of detecting connection failures. Initiators and targets
+- MAY also use the keep-alive option on the TCP connection to enable
+- early link failure detection on otherwise idle links.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 82]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- On connection failure, the initiator and target MUST do one of the
+- following:
+-
+- - Attempt connection recovery within the session (Section 6.1.4.3
+- Connection Recovery).
+-
+- - Logout the connection with the reason code "closes the
+- connection" (Section 10.14.5 Implicit termination of tasks),
+- re-issue missing commands, and implicitly terminate all active
+- commands. This option requires support for the
+- within-connection recovery class (Section 6.1.4.2 Recovery
+- Within-connection).
+-
+- - Perform session recovery (Section 6.1.4.4 Session Recovery).
+-
+- Either side may choose to escalate to session recovery (via the
+- initiator dropping all the connections, or via an Async Message that
+- announces the similar intent from a target), and the other side MUST
+- give it precedence. On a connection failure, a target MUST terminate
+- and/or discard all of the active immediate commands regardless of
+- which of the above options is used (i.e., immediate commands are not
+- recoverable across connection failures).
+-
+-6.13. Session Errors
+-
+- If all of the connections of a session fail and cannot be
+- reestablished in a short time, or if initiators detect protocol
+- errors repeatedly, an initiator may choose to terminate a session and
+- establish a new session.
+-
+- In this case, the initiator takes the following actions:
+-
+- - Resets or closes all the transport connections.
+- - Terminates all outstanding requests with an appropriate
+- response before initiating a new session. If the same I_T
+- nexus is intended to be reestablished, the initiator MUST
+- employ session reinstatement (see section 5.3.5).
+-
+- When the session timeout (the connection state timeout for the last
+- failed connection) happens on the target, it takes the following
+- actions:
+-
+- - Resets or closes the TCP connections (closes the session).
+- - Terminates all active tasks that were allegiant to the
+- connection(s) that constituted the session.
+-
+- A target MUST also be prepared to handle a session reinstatement
+- request from the initiator, that may be addressing session errors.
+-
+-
+-
+-Satran, et al. Standards Track [Page 83]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-7. State Transitions
+-
+- iSCSI connections and iSCSI sessions go through several well-defined
+- states from the time they are created to the time they are cleared.
+-
+- The connection state transitions are described in two separate but
+- dependent state diagrams for ease in understanding. The first
+- diagram, "standard connection state diagram", describes the
+- connection state transitions when the iSCSI connection is not waiting
+- for, or undergoing, a cleanup by way of an explicit or implicit
+- Logout. The second diagram, "connection cleanup state diagram",
+- describes the connection state transitions while performing the iSCSI
+- connection cleanup.
+-
+- The "session state diagram" describes the state transitions an iSCSI
+- session would go through during its lifetime, and it depends on the
+- states of possibly multiple iSCSI connections that participate in the
+- session.
+-
+- States and state transitions are described in the text, tables and
+- diagrams. The diagrams are used for illustration. The text and the
+- tables are the governing specification.
+-
+-7.1. Standard Connection State Diagrams
+-
+-7.1.1. State Descriptions for Initiators and Targets
+-
+- State descriptions for the standard connection state diagram are as
+- follows:
+-
+- -S1: FREE
+- -initiator: State on instantiation, or after successful
+- connection closure.
+- -target: State on instantiation, or after successful connection
+- closure.
+- -S2: XPT_WAIT
+- -initiator: Waiting for a response to its transport connection
+- establishment request.
+- -target: Illegal
+- -S3: XPT_UP
+- -initiator: Illegal
+- -target: Waiting for the Login process to commence.
+- -S4: IN_LOGIN
+- -initiator: Waiting for the Login process to conclude, possibly
+- involving several PDU exchanges.
+- -target: Waiting for the Login process to conclude, possibly
+- involving several PDU exchanges.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 84]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- -S5: LOGGED_IN
+- -initiator: In Full Feature Phase, waiting for all internal,
+- iSCSI, and transport events.
+- -target: In Full Feature Phase, waiting for all internal, iSCSI,
+- and transport events.
+- -S6: IN_LOGOUT
+- -initiator: Waiting for a Logout response.
+- -target: Waiting for an internal event signaling completion of
+- logout processing.
+- -S7: LOGOUT_REQUESTED
+- -initiator: Waiting for an internal event signaling readiness to
+- proceed with Logout.
+- -target: Waiting for the Logout process to start after having
+- requested a Logout via an Async Message.
+- -S8: CLEANUP_WAIT
+- -initiator: Waiting for the context and/or resources to initiate
+- the cleanup processing for this CSM.
+- -target: Waiting for the cleanup process to start for this CSM.
+-
+-7.1.2. State Transition Descriptions for Initiators and Targets
+-
+- -T1:
+- -initiator: Transport connect request was made (e.g., TCP SYN
+- sent).
+- -target: Illegal
+- -T2:
+- -initiator: Transport connection request timed out, a transport
+- reset was received, or an internal event of receiving a
+- Logout response (success) on another connection for a
+- "close the session" Logout request was received.
+- -target:Illegal
+- -T3:
+- -initiator: Illegal
+- -target: Received a valid transport connection request that
+- establishes the transport connection.
+- -T4:
+- -initiator: Transport connection established, thus prompting the
+- initiator to start the iSCSI Login.
+- -target: Initial iSCSI Login Request was received.
+- -T5:
+- -initiator: The final iSCSI Login Response with a Status-Class
+- of zero was received.
+- -target: The final iSCSI Login Request to conclude the Login
+- Phase was received, thus prompting the target to send the
+- final iSCSI Login Response with a Status-Class of zero.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 85]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- -T6:
+- -initiator: Illegal
+- -target: Timed out waiting for an iSCSI Login, transport
+- disconnect indication was received, transport reset was
+- received, or an internal event indicating a transport
+- timeout was received. In all these cases, the connection is
+- to be closed.
+- -T7:
+- -initiator - one of the following events caused the transition:
+- - The final iSCSI Login Response was received with a
+- non-zero Status-Class.
+- - Login timed out.
+- - A transport disconnect indication was received.
+- - A transport reset was received.
+- - An internal event was received indicating a transport
+- timeout.
+- - An internal event of receiving a Logout response (success)
+- on another connection for a "close the session" Logout
+- request was received.
+-
+- In all these cases, the transport connection is closed.
+-
+- -target - one of the following events caused the transition:
+- - The final iSCSI Login Request to conclude the Login Phase
+- was received, prompting the target to send the final iSCSI
+- Login Response with a non-zero Status-Class.
+- - Login timed out.
+- - Transport disconnect indication was received.
+- - Transport reset was received.
+- - An internal event indicating a transport timeout was
+- received.
+- - On another connection a "close the session" Logout request
+- was received.
+- In all these cases, the connection is to be closed.
+- -T8:
+- -initiator: An internal event of receiving a Logout response
+- (success) on another connection for a "close the session"
+- Logout request was received, thus closing this connection
+- requiring no further cleanup.
+- -target: An internal event of sending a Logout response
+- (success) on another connection for a "close the session"
+- Logout request was received, or an internal event of a
+- successful connection/session reinstatement is received,
+- thus prompting the target to close this connection cleanly.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 86]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- -T9, T10:
+- -initiator: An internal event that indicates the readiness to
+- start the Logout process was received, thus prompting an
+- iSCSI Logout to be sent by the initiator.
+- -target: An iSCSI Logout request was received.
+- -T11, T12:
+- -initiator: Async PDU with AsyncEvent "Request Logout" was
+- received.
+- -target: An internal event that requires the decommissioning of
+- the connection is received, thus causing an Async PDU with
+- an AsyncEvent "Request Logout" to be sent.
+- -T13:
+- -initiator: An iSCSI Logout response (success) was received, or
+- an internal event of receiving a Logout response (success)
+- on another connection for a "close the session" Logout
+- request was received.
+- -target: An internal event was received that indicates
+- successful processing of the Logout, which prompts an iSCSI
+- Logout response (success) to be sent; an internal event of
+- sending a Logout response (success) on another connection
+- for a "close the session" Logout request was received; or an
+- internal event of a successful connection/session
+- reinstatement is received. In all these cases, the
+- transport connection is closed.
+-
+- -T14:
+- -initiator: Async PDU with AsyncEvent "Request Logout" was
+- received again.
+- -target: Illegal
+- -T15, T16:
+- -initiator: One or more of the following events caused this
+- transition:
+- -Internal event that indicates a transport connection
+- timeout was received thus prompting transport RESET or
+- transport connection closure.
+- -A transport RESET.
+- -A transport disconnect indication.
+- -Async PDU with AsyncEvent "Drop connection" (for this CID).
+- -Async PDU with AsyncEvent "Drop all connections".
+- -target: One or more of the following events caused this
+- transition:
+- -Internal event that indicates a transport connection
+- timeout was received, thus prompting transport RESET or
+- transport connection closure.
+- -An internal event of a failed connection/session
+- reinstatement is received.
+- -A transport RESET.
+- -A transport disconnect indication.
+-
+-
+-
+-Satran, et al. Standards Track [Page 87]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- -Internal emergency cleanup event was received which prompts
+- an Async PDU with AsyncEvent "Drop connection" (for this
+- CID), or event "Drop all connections".
+- -T17:
+- -initiator: One or more of the following events caused this
+- transition:
+- -Logout response, (failure i.e., a non-zero status) was
+- received, or Logout timed out.
+- -Any of the events specified for T15 and T16.
+- -target: One or more of the following events caused this
+- transition:
+- -Internal event that indicates a failure of the Logout
+- processing was received, which prompts a Logout response
+- (failure, i.e., a non-zero status) to be sent.
+- -Any of the events specified for T15 and T16.
+- -T18:
+- -initiator: An internal event of receiving a Logout response
+- (success) on another connection for a "close the session"
+- Logout request was received.
+- -target: An internal event of sending a Logout response
+- (success) on another connection for a "close the session"
+- Logout request was received, or an internal event of a
+- successful connection/session reinstatement is received. In
+- both these cases, the connection is closed.
+-
+- The CLEANUP_WAIT state (S8) implies that there are possible iSCSI
+- tasks that have not reached conclusion and are still considered busy.
+-
+-7.1.3. Standard Connection State Diagram for an Initiator
+-
+- Symbolic names for States:
+-
+- S1: FREE
+- S2: XPT_WAIT
+- S4: IN_LOGIN
+- S5: LOGGED_IN
+- S6: IN_LOGOUT
+- S7: LOGOUT_REQUESTED
+- S8: CLEANUP_WAIT
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 88]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- States S5, S6, and S7 constitute the Full Feature Phase operation of
+- the connection.
+-
+- The state diagram is as follows:
+-
+- -------<-------------+
+- +--------->/ S1 \<----+ |
+- T13| +->\ /<-+ \ |
+- | / ---+--- \ \ |
+- | / | T2 \ | |
+- | T8 | |T1 | | |
+- | | | / |T7 |
+- | | | / | |
+- | | | / | |
+- | | V / / |
+- | | ------- / / |
+- | | / S2 \ / |
+- | | \ / / |
+- | | ---+--- / |
+- | | |T4 / |
+- | | V / | T18
+- | | ------- / |
+- | | / S4 \ |
+- | | \ / |
+- | | ---+--- | T15
+- | | |T5 +--------+---------+
+- | | | /T16+-----+------+ |
+- | | | / -+-----+--+ | |
+- | | | / / S7 \ |T12| |
+- | | | / +->\ /<-+ V V
+- | | | / / -+----- -------
+- | | | / /T11 |T10 / S8 \
+- | | V / / V +----+ \ /
+- | | ---+-+- ----+-- | -------
+- | | / S5 \T9 / S6 \<+ ^
+- | +-----\ /--->\ / T14 |
+- | ------- --+----+------+T17
+- +---------------------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 89]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The following state transition table represents the above diagram.
+- Each row represents the starting state for a given transition, which
+- after taking a transition marked in a table cell would end in the
+- state represented by the column of the cell. For example, from state
+- S1, the connection takes the T1 transition to arrive at state S2.
+- The fields marked "-" correspond to undefined transitions.
+-
+- +----+---+---+---+---+----+---+
+- |S1 |S2 |S4 |S5 |S6 |S7 |S8 |
+- ---+----+---+---+---+---+----+---+
+- S1| - |T1 | - | - | - | - | - |
+- ---+----+---+---+---+---+----+---+
+- S2|T2 |- |T4 | - | - | - | - |
+- ---+----+---+---+---+---+----+---+
+- S4|T7 |- |- |T5 | - | - | - |
+- ---+----+---+---+---+---+----+---+
+- S5|T8 |- |- | - |T9 |T11 |T15|
+- ---+----+---+---+---+---+----+---+
+- S6|T13 |- |- | - |T14|- |T17|
+- ---+----+---+---+---+---+----+---+
+- S7|T18 |- |- | - |T10|T12 |T16|
+- ---+----+---+---+---+---+----+---+
+- S8| - |- |- | - | - | - | - |
+- ---+----+---+---+---+---+----+---+
+-
+-7.1.4. Standard Connection State Diagram for a Target
+-
+- Symbolic names for States:
+-
+- S1: FREE
+- S3: XPT_UP
+- S4: IN_LOGIN
+- S5: LOGGED_IN
+- S6: IN_LOGOUT
+- S7: LOGOUT_REQUESTED
+- S8: CLEANUP_WAIT
+-
+- States S5, S6, and S7 constitute the Full Feature Phase operation of
+- the connection.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 90]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The state diagram is as follows:
+-
+- -------<-------------+
+- +--------->/ S1 \<----+ |
+- T13| +->\ /<-+ \ |
+- | / ---+--- \ \ |
+- | / | T6 \ | |
+- | T8 | |T3 | | |
+- | | | / |T7 |
+- | | | / | |
+- | | | / | |
+- | | V / / |
+- | | ------- / / |
+- | | / S3 \ / |
+- | | \ / / | T18
+- | | ---+--- / |
+- | | |T4 / |
+- | | V / |
+- | | ------- / |
+- | | / S4 \ |
+- | | \ / |
+- | | ---+--- T15 |
+- | | |T5 +--------+---------+
+- | | | /T16+-----+------+ |
+- | | | / -+-----+---+ | |
+- | | | / / S7 \ |T12| |
+- | | | / +->\ /<-+ V V
+- | | | / / -+----- -------
+- | | | / /T11 |T10 / S8 \
+- | | V / / V \ /
+- | | ---+-+- ------- -------
+- | | / S5 \T9 / S6 \ ^
+- | +-----\ /--->\ / |
+- | ------- --+----+--------+T17
+- +---------------------------+
+-
+- The following state transition table represents the above diagram,
+- and follows the conventions described for the initiator diagram.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 91]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- +----+---+---+---+---+----+---+
+- |S1 |S3 |S4 |S5 |S6 |S7 |S8 |
+- ---+----+---+---+---+---+----+---+
+- S1| - |T3 | - | - | - | - | - |
+- ---+----+---+---+---+---+----+---+
+- S3|T6 |- |T4 | - | - | - | - |
+- ---+----+---+---+---+---+----+---+
+- S4|T7 |- |- |T5 | - | - | - |
+- ---+----+---+---+---+---+----+---+
+- S5|T8 |- |- | - |T9 |T11 |T15|
+- ---+----+---+---+---+---+----+---+
+- S6|T13 |- |- | - |- |- |T17|
+- ---+----+---+---+---+---+----+---+
+- S7|T18 |- |- | - |T10|T12 |T16|
+- ---+----+---+---+---+---+----+---+
+- S8| - |- |- | - | - | - | - |
+- ---+----+---+---+---+---+----+---+
+-
+-7.2. Connection Cleanup State Diagram for Initiators and Targets
+-
+- Symbolic names for states:
+-
+- R1: CLEANUP_WAIT (same as S8)
+- R2: IN_CLEANUP
+- R3: FREE (same as S1)
+-
+- Whenever a connection state machine (e.g., CSM-C) enters the
+- CLEANUP_WAIT state (S8), it must go through the state transitions
+- described in the connection cleanup state diagram either a) using a
+- separate full-feature phase connection (let's call it CSM-E) in the
+- LOGGED_IN state in the same session, or b) using a new transport
+- connection (let's call it CSM-I) in the FREE state that is to be
+- added to the same session. In the CSM-E case, an explicit logout for
+- the CID that corresponds to CSM-C (either as a connection or session
+- logout) needs to be performed to complete the cleanup. In the CSM-I
+- case, an implicit logout for the CID that corresponds to CSM-C needs
+- to be performed by way of connection reinstatement (section 5.3.4)
+- for that CID. In either case, the protocol exchanges on CSM-E or
+- CSM-I determine the state transitions for CSM-C. Therefore, this
+- cleanup state diagram is only applicable to the instance of the
+- connection in cleanup (i.e., CSM-C). In the case of an implicit
+- logout for example, CSM-C reaches FREE (R3) at the time CSM-I reaches
+- LOGGED_IN. In the case of an explicit logout, CSM-C reaches FREE
+- (R3) when CSM-E receives a successful logout response while
+- continuing to be in the LOGGED_IN state.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 92]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- An initiator must initiate an explicit or implicit connection logout
+- for a connection in the CLEANUP_WAIT state, if the initiator intends
+- to continue using the associated iSCSI session.
+-
+- The following state diagram applies to both initiators and targets.
+-
+- -------
+- / R1 \
+- +--\ /<-+
+- / ---+---
+- / | \ M3
+- M1 | |M2 |
+- | | /
+- | | /
+- | | /
+- | V /
+- | ------- /
+- | / R2 \
+- | \ /
+- | -------
+- | |
+- | |M4
+- | |
+- | |
+- | |
+- | V
+- | -------
+- | / R3 \
+- +---->\ /
+- -------
+-
+- The following state transition table represents the above diagram,
+- and follows the same conventions as in earlier sections.
+-
+- +----+----+----+
+- |R1 |R2 |R3 |
+- -----+----+----+----+
+- R1 | - |M2 |M1 |
+- -----+----+----+----+
+- R2 |M3 | - |M4 |
+- -----+----+----+----+
+- R3 | - | - | - |
+- -----+----+----+----+
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 93]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-7.2.1. State Descriptions for Initiators and Targets
+-
+- -R1: CLEANUP_WAIT (Same as S8)
+- -initiator: Waiting for the internal event to initiate the
+- cleanup processing for CSM-C.
+- -target: Waiting for the cleanup process to start for CSM-C.
+- -R2: IN_CLEANUP
+- -initiator: Waiting for the connection cleanup process to
+- conclude for CSM-C.
+- -target: Waiting for the connection cleanup process to conclude
+- for CSM-C.
+- -R3: FREE (Same as S1)
+- -initiator: End state for CSM-C.
+- -target: End state for CSM-C.
+-
+-7.2.2. State Transition Descriptions for Initiators and Targets
+-
+- -M1: One or more of the following events was received:
+- -initiator:
+- -An internal event that indicates connection state timeout.
+- -An internal event of receiving a successful Logout response
+- on a different connection for a "close the session"
+- Logout.
+- -target:
+- -An internal event that indicates connection state timeout.
+- -An internal event of sending a Logout response (success) on
+- a different connection for a "close the session" Logout
+- request.
+-
+- -M2: An implicit/explicit logout process was initiated by the
+- initiator.
+- -In CSM-I usage:
+- -initiator: An internal event requesting the connection (or
+- session) reinstatement was received, thus prompting a
+- connection (or session) reinstatement Login to be sent
+- transitioning CSM-I to state IN_LOGIN.
+- -target: A connection/session reinstatement Login was
+- received while in state XPT_UP.
+- -In CSM-E usage:
+- -initiator: An internal event that indicates that an
+- explicit logout was sent for this CID in state LOGGED_IN.
+- -target: An explicit logout was received for this CID in
+- state LOGGED_IN.
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 94]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- -M3: Logout failure detected
+- -In CSM-I usage:
+- -initiator: CSM-I failed to reach LOGGED_IN and arrived into
+- FREE instead.
+- -target: CSM-I failed to reach LOGGED_IN and arrived into
+- FREE instead.
+- -In CSM-E usage:
+- -initiator: CSM-E either moved out of LOGGED_IN, or Logout
+- timed out and/or aborted, or Logout response (failure)
+- was received.
+- -target: CSM-E either moved out of LOGGED_IN, Logout timed
+- out and/or aborted, or an internal event that indicates a
+- failed Logout processing was received. A Logout response
+- (failure) was sent in the last case.
+-
+- -M4: Successful implicit/explicit logout was performed.
+-
+- - In CSM-I usage:
+- -initiator: CSM-I reached state LOGGED_IN, or an internal
+- event of receiving a Logout response (success) on another
+- connection for a "close the session" Logout request was
+- received.
+- -target: CSM-I reached state LOGGED_IN, or an internal event
+- of sending a Logout response (success) on a different
+- connection for a "close the session" Logout request was
+- received.
+- - In CSM-E usage:
+- -initiator: CSM-E stayed in LOGGED_IN and received a Logout
+- response (success), or an internal event of receiving a
+- Logout response (success) on another connection for a
+- "close the session" Logout request was received.
+- -target: CSM-E stayed in LOGGED_IN and an internal event
+- indicating a successful Logout processing was received,
+- or an internal event of sending a Logout response
+- (success) on a different connection for a "close the
+- session" Logout request was received.
+-
+-7.3. Session State Diagrams
+-
+-7.3.1. Session State Diagram for an Initiator
+-
+- Symbolic Names for States:
+-
+- Q1: FREE
+- Q3: LOGGED_IN
+- Q4: FAILED
+-
+- State Q3 represents the Full Feature Phase operation of the session.
+-
+-
+-
+-Satran, et al. Standards Track [Page 95]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The state diagram is as follows:
+-
+- -------
+- / Q1 \
+- +------>\ /<-+
+- / ---+--- |
+- / | |N3
+- N6 | |N1 |
+- | | |
+- | N4 | |
+- | +--------+ | /
+- | | | | /
+- | | | | /
+- | | V V /
+- -+--+-- -----+-
+- / Q4 \ N5 / Q3 \
+- \ /<---\ /
+- ------- -------
+-
+- The state transition table is as follows:
+-
+- +----+----+----+
+- |Q1 |Q3 |Q4 |
+- -----+----+----+----+
+- Q1 | - |N1 | - |
+- -----+----+----+----+
+- Q3 |N3 | - |N5 |
+- -----+----+----+----+
+- Q4 |N6 |N4 | - |
+- -----+----+----+----+
+-
+-7.3.2. Session State Diagram for a Target
+-
+- Symbolic Names for States:
+-
+- Q1: FREE
+- Q2: ACTIVE
+- Q3: LOGGED_IN
+- Q4: FAILED
+- Q5: IN_CONTINUE
+-
+- State Q3 represents the Full Feature Phase operation of the session.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 96]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The state diagram is as follows:
+-
+- -------
+- +------------------>/ Q1 \
+- / +-------------->\ /<-+
+- | | ---+--- |
+- | | ^ | |N3
+- N6 | |N11 N9| V N1 |
+- | | +------ |
+- | | / Q2 \ |
+- | | \ / |
+- | --+---- +--+--- |
+- | / Q5 \ | |
+- | \ / N10 | |
+- | +-+---+------------+ |N2 /
+- | ^ | | | /
+- |N7| |N8 | | /
+- | | | | V /
+- -+--+-V V----+-
+- / Q4 \ N5 / Q3 \
+- \ /<-------------\ /
+- ------- -------
+-
+- The state transition table is as follows:
+-
+- +----+----+----+----+----+
+- |Q1 |Q2 |Q3 |Q4 |Q5 |
+- -----+----+----+----+----+----+
+- Q1 | - |N1 | - | - | - |
+- -----+----+----+----+----+----+
+- Q2 |N9 | - |N2 | - | - |
+- -----+----+----+----+----+----+
+- Q3 |N3 | - | - |N5 | - |
+- -----+----+----+----+----+----+
+- Q4 |N6 | - | - | - |N7 |
+- -----+----+----+----+----+----+
+- Q5 |N11 | - |N10 |N8 | - |
+- -----+----+----+----+----+----+
+-
+-7.3.3. State Descriptions for Initiators and Targets
+-
+- -Q1: FREE
+- -initiator: State on instantiation or after cleanup.
+- -target: State on instantiation or after cleanup.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 97]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- -Q2: ACTIVE
+- -initiator: Illegal.
+- -target: The first iSCSI connection in the session transitioned
+- to IN_LOGIN, waiting for it to complete the login process.
+-
+- -Q3: LOGGED_IN
+- -initiator: Waiting for all session events.
+- -target: Waiting for all session events.
+-
+- -Q4: FAILED
+- -initiator: Waiting for session recovery or session
+- continuation.
+- -target: Waiting for session recovery or session continuation.
+-
+- -Q5: IN_CONTINUE
+- -initiator: Illegal.
+- -target: Waiting for session continuation attempt to reach a
+- conclusion.
+-
+-7.3.4. State Transition Descriptions for Initiators and Targets
+-
+- -N1:
+- -initiator: At least one transport connection reached the
+- LOGGED_IN state.
+- -target: The first iSCSI connection in the session had reached
+- the IN_LOGIN state.
+-
+- -N2:
+- -initiator: Illegal.
+- -target: At least one iSCSI connection reached the LOGGED_IN
+- state.
+-
+- -N3:
+- -initiator: Graceful closing of the session via session closure
+- (Section 5.3.6 Session Continuation and Failure).
+- -target: Graceful closing of the session via session closure
+- (Section 5.3.6 Session Continuation and Failure) or a
+- successful session reinstatement cleanly closed the session.
+-
+- -N4:
+- -initiator: A session continuation attempt succeeded.
+- -target: Illegal.
+-
+- -N5:
+- -initiator: Session failure (Section 5.3.6 Session Continuation
+- and Failure) occurred.
+- -target: Session failure (Section 5.3.6 Session Continuation and
+- Failure) occurred.
+-
+-
+-
+-Satran, et al. Standards Track [Page 98]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- -N6:
+- -initiator: Session state timeout occurred, or a session
+- reinstatement cleared this session instance. This results
+- in the freeing of all associated resources and the session
+- state is discarded.
+- -target: Session state timeout occurred, or a session
+- reinstatement cleared this session instance. This results
+- in the freeing of all associated resources and the session
+- state is discarded.
+-
+- -N7:
+- -initiator: Illegal.
+- -target: A session continuation attempt is initiated.
+-
+- -N8:
+- -initiator: Illegal.
+- -target: The last session continuation attempt failed.
+-
+- -N9:
+- -initiator: Illegal.
+- -target: Login attempt on the leading connection failed.
+-
+- -N10:
+- -initiator: Illegal.
+- -target: A session continuation attempt succeeded.
+-
+- -N11:
+- -initiator: Illegal.
+- -target: A successful session reinstatement cleanly closed the
+- session.
+-
+-8. Security Considerations
+-
+- Historically, native storage systems have not had to consider
+- security because their environments offered minimal security risks.
+- That is, these environments consisted of storage devices either
+- directly attached to hosts or connected via a Storage Area Network
+- (SAN) distinctly separate from the communications network. The use
+- of storage protocols, such as SCSI, over IP-networks requires that
+- security concerns be addressed. iSCSI implementations MUST provide
+- means of protection against active attacks (e.g., pretending to be
+- another identity, message insertion, deletion, modification, and
+- replaying) and passive attacks (e.g., eavesdropping, gaining
+- advantage by analyzing the data sent over the line).
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 99]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Although technically possible, iSCSI SHOULD NOT be configured without
+- security. iSCSI configured without security should be confined, in
+- extreme cases, to closed environments without any security risk.
+- [RFC3723] specifies the mechanisms that must be used in order to
+- mitigate risks fully described in that document.
+-
+- The following section describes the security mechanisms provided by
+- an iSCSI implementation.
+-
+-8.1. iSCSI Security Mechanisms
+-
+- The entities involved in iSCSI security are the initiator, target,
+- and the IP communication end points. iSCSI scenarios in which
+- multiple initiators or targets share a single communication end point
+- are expected. To accommodate such scenarios, iSCSI uses two separate
+- security mechanisms: In-band authentication between the initiator and
+- the target at the iSCSI connection level (carried out by exchange of
+- iSCSI Login PDUs), and packet protection (integrity, authentication,
+- and confidentiality) by IPsec at the IP level. The two security
+- mechanisms complement each other. The in-band authentication
+- provides end-to-end trust (at login time) between the iSCSI initiator
+- and the target while IPsec provides a secure channel between the IP
+- communication end points.
+-
+- Further details on typical iSCSI scenarios and the relation between
+- the initiators, targets, and the communication end points can be
+- found in [RFC3723].
+-
+-8.2. In-band Initiator-Target Authentication
+-
+- During login, the target MAY authenticate the initiator and the
+- initiator MAY authenticate the target. The authentication is
+- performed on every new iSCSI connection by an exchange of iSCSI Login
+- PDUs using a negotiated authentication method.
+-
+- The authentication method cannot assume an underlying IPsec
+- protection, because IPsec is optional to use. An attacker should
+- gain as little advantage as possible by inspecting the authentication
+- phase PDUs. Therefore, a method using clear text (or equivalent)
+- passwords is not acceptable; on the other hand, identity protection
+- is not strictly required.
+-
+- The authentication mechanism protects against an unauthorized login
+- to storage resources by using a false identity (spoofing). Once the
+- authentication phase is completed, if the underlying IPsec is not
+- used, all PDUs are sent and received in clear. The authentication
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 100]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- mechanism alone (without underlying IPsec) should only be used when
+- there is no risk of eavesdropping, message insertion, deletion,
+- modification, and replaying.
+-
+- Section 11 iSCSI Security Text Keys and Authentication Methods
+- defines several authentication methods and the exact steps that must
+- be followed in each of them, including the iSCSI-text-keys and their
+- allowed values in each step. Whenever an iSCSI initiator gets a
+- response whose keys, or their values, are not according to the step
+- definition, it MUST abort the connection. Whenever an iSCSI target
+- gets a response whose keys, or their values, are not according to the
+- step definition, it MUST answer with a Login reject with the
+- "Initiator Error" or "Missing Parameter" status. These statuses are
+- not intended for cryptographically incorrect values such as the CHAP
+- response, for which "Authentication Failure" status MUST be
+- specified. The importance of this rule can be illustrated in CHAP
+- with target authentication (see Section 11.1.4 Challenge Handshake
+- Authentication Protocol (CHAP)) where the initiator would have been
+- able to conduct a reflection attack by omitting his response key
+- (CHAP_R) using the same CHAP challenge as the target and reflecting
+- the target's response back to the target. In CHAP, this is prevented
+- because the target must answer the missing CHAP_R key with a Login
+- reject with the "Missing Parameter" status.
+-
+- For some of the authentication methods, a key specifies the identity
+- of the iSCSI initiator or target for authentication purposes. The
+- value associated with that key MAY be different from the iSCSI name
+- and SHOULD be configurable. (CHAP_N, see Section 11.1.4 Challenge
+- Handshake Authentication Protocol (CHAP) and SRP_U, see Section
+- 11.1.3 Secure Remote Password (SRP)).
+-
+-8.2.1. CHAP Considerations
+-
+- Compliant iSCSI initiators and targets MUST implement the CHAP
+- authentication method [RFC1994] (according to Section 11.1.4
+- Challenge Handshake Authentication Protocol (CHAP) including the
+- target authentication option).
+-
+- When CHAP is performed over a non-encrypted channel, it is vulnerable
+- to an off-line dictionary attack. Implementations MUST support use
+- of up to 128 bit random CHAP secrets, including the means to generate
+- such secrets and to accept them from an external generation source.
+- Implementations MUST NOT provide secret generation (or expansion)
+- means other than random generation.
+-
+- An administrative entity of an environment in which CHAP is used with
+- a secret that has less than 96 random bits MUST enforce IPsec
+- encryption (according to the implementation requirements in Section
+-
+-
+-
+-Satran, et al. Standards Track [Page 101]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 8.3.2 Confidentiality) to protect the connection. Moreover, in this
+- case IKE authentication with group pre-shared cryptographic keys
+- SHOULD NOT be used unless it is not essential to protect group
+- members against off-line dictionary attacks by other members.
+-
+- CHAP secrets MUST be an integral number of bytes (octets). A
+- compliant implementation SHOULD NOT continue with the login step in
+- which it should send a CHAP response (CHAP_R, Section 11.1.4
+- Challenge Handshake Authentication Protocol (CHAP)) unless it can
+- verify that the CHAP secret is at least 96 bits, or that IPsec
+- encryption is being used to protect the connection.
+-
+- Any CHAP secret used for initiator authentication MUST NOT be
+- configured for authentication of any target, and any CHAP secret used
+- for target authentication MUST NOT be configured for authentication
+- of any initiator. If the CHAP response received by one end of an
+- iSCSI connection is the same as the CHAP response that the receiving
+- endpoint would have generated for the same CHAP challenge, the
+- response MUST be treated as an authentication failure and cause the
+- connection to close (this ensures that the same CHAP secret is not
+- used for authentication in both directions). Also, if an iSCSI
+- implementation can function as both initiator and target, different
+- CHAP secrets and identities MUST be configured for these two roles.
+- The following is an example of the attacks prevented by the above
+- requirements:
+-
+- Rogue wants to impersonate Storage to Alice, and knows that a
+- single secret is used for both directions of Storage-Alice
+- authentication.
+-
+- Rogue convinces Alice to open two connections to Rogue, and Rogue
+- identifies itself as Storage on both connections.
+-
+- Rogue issues a CHAP challenge on connection 1, waits for Alice to
+- respond, and then reflects Alice's challenge as the initial
+- challenge to Alice on connection 2.
+-
+- If Alice doesn't check for the reflection across connections,
+- Alice's response on connection 2 enables Rogue to impersonate
+- Storage on connection 1, even though Rogue does not know the
+- Alice-Storage CHAP secret.
+-
+- Originators MUST NOT reuse the CHAP challenge sent by the Responder
+- for the other direction of a bidirectional authentication.
+- Responders MUST check for this condition and close the iSCSI TCP
+- connection if it occurs.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 102]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The same CHAP secret SHOULD NOT be configured for authentication of
+- multiple initiators or multiple targets, as this enables any of them
+- to impersonate any other one of them, and compromising one of them
+- enables the attacker to impersonate any of them. It is recommended
+- that iSCSI implementations check for use of identical CHAP secrets by
+- different peers when this check is feasible, and take appropriate
+- measures to warn users and/or administrators when this is detected.
+-
+- When an iSCSI initiator or target authenticates itself to
+- counterparts in multiple administrative domains, it SHOULD use a
+- different CHAP secret for each administrative domain to avoid
+- propagating security compromises across domains.
+-
+- Within a single administrative domain:
+- - A single CHAP secret MAY be used for authentication of an initiator
+- to multiple targets.
+- - A single CHAP secret MAY be used for an authentication of a target
+- to multiple initiators when the initiators use an external server
+- (e.g., RADIUS) to verify the target's CHAP responses and do not know
+- the target's CHAP secret.
+-
+- If an external response verification server (e.g., RADIUS) is not
+- used, employing a single CHAP secret for authentication of a target
+- to multiple initiators requires that all such initiators know that
+- target secret. Any of these initiators can impersonate the target to
+- any other such initiator, and compromise of such an initiator enables
+- an attacker to impersonate the target to all such initiators.
+- Targets SHOULD use separate CHAP secrets for authentication to each
+- initiator when such risks are of concern; in this situation it may be
+- useful to configure a separate logical iSCSI target with its own
+- iSCSI Node Name for each initiator or group of initiators among which
+- such separation is desired.
+-
+-8.2.2. SRP Considerations
+-
+- The strength of the SRP authentication method (specified in
+- [RFC2945]) is dependent on the characteristics of the group being
+- used (i.e., the prime modulus N and generator g). As described in
+- [RFC2945], N is required to be a Sophie-German prime (of the form
+- N = 2q + 1, where q is also prime) and the generator g is a primitive
+- root of GF(n). In iSCSI authentication, the prime modulus N MUST be
+- at least 768 bits.
+-
+- The list of allowed SRP groups is provided in [RFC3723].
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 103]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-8.3. IPsec
+-
+- iSCSI uses the IPsec mechanism for packet protection (cryptographic
+- integrity, authentication, and confidentiality) at the IP level
+- between the iSCSI communicating end points. The following sections
+- describe the IPsec protocols that must be implemented for data
+- integrity and authentication, confidentiality, and cryptographic key
+- management.
+-
+- An iSCSI initiator or target may provide the required IPsec support
+- fully integrated or in conjunction with an IPsec front-end device.
+- In the latter case, the compliance requirements with regard to IPsec
+- support apply to the "combined device". Only the "combined device"
+- is to be considered an iSCSI device.
+-
+- Detailed considerations and recommendations for using IPsec for iSCSI
+- are provided in [RFC3723].
+-
+-8.3.1. Data Integrity and Authentication
+-
+- Data authentication and integrity is provided by a cryptographic
+- keyed Message Authentication Code in every sent packet. This code
+- protects against message insertion, deletion, and modification.
+- Protection against message replay is realized by using a sequence
+- counter.
+-
+- An iSCSI compliant initiator or target MUST provide data integrity
+- and authentication by implementing IPsec [RFC2401] with ESP [RFC2406]
+- in tunnel mode and MAY provide data integrity and authentication by
+- implementing IPsec with ESP in transport mode. The IPsec
+- implementation MUST fulfill the following iSCSI specific
+- requirements:
+-
+- - HMAC-SHA1 MUST be implemented [RFC2404].
+- - AES CBC MAC with XCBC extensions SHOULD be implemented
+- [RFC3566].
+-
+- The ESP anti-replay service MUST also be implemented.
+-
+- At the high speeds iSCSI is expected to operate, a single IPsec SA
+- could rapidly cycle through the 32-bit IPsec sequence number space.
+- In view of this, it may be desirable in the future for an iSCSI
+- implementation that operates at speeds of 1 Gbps or greater to
+- implement the IPsec sequence number extension [SEQ-EXT].
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 104]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-8.3.2. Confidentiality
+-
+- Confidentiality is provided by encrypting the data in every packet.
+- When confidentiality is used it MUST be accompanied by data integrity
+- and authentication to provide comprehensive protection against
+- eavesdropping, message insertion, deletion, modification, and
+- replaying.
+-
+- An iSCSI compliant initiator or target MUST provide confidentiality
+- by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and
+- MAY provide confidentiality by implementing IPsec with ESP in
+- transport mode, with the following iSCSI specific requirements:
+-
+- - 3DES in CBC mode MUST be implemented [RFC2451].
+- - AES in Counter mode SHOULD be implemented [RFC3686].
+-
+- DES in CBC mode SHOULD NOT be used due to its inherent weakness. The
+- NULL encryption algorithm MUST also be implemented.
+-
+-8.3.3. Policy, Security Associations, and Cryptographic Key Management
+-
+- A compliant iSCSI implementation MUST meet the cryptographic key
+- management requirements of the IPsec protocol suite. Authentication,
+- security association negotiation, and cryptographic key management
+- MUST be provided by implementing IKE [RFC2409] using the IPsec DOI
+- [RFC2407] with the following iSCSI specific requirements:
+-
+- - Peer authentication using a pre-shared cryptographic key MUST be
+- supported. Certificate-based peer authentication using digital
+- signatures MAY be supported. Peer authentication using the
+- public key encryption methods outlined in IKE sections 5.2 and
+- 5.3[7] SHOULD NOT be used.
+-
+- - When digital signatures are used to achieve authentication, an
+- IKE negotiator SHOULD use IKE Certificate Request Payload(s) to
+- specify the certificate authority. IKE negotiators SHOULD check
+- the pertinent Certificate Revocation List (CRL) before accepting
+- a PKI certificate for use in IKE authentication procedures.
+-
+- - Conformant iSCSI implementations MUST support IKE Main Mode and
+- SHOULD support Aggressive Mode. IKE main mode with pre-shared
+- key authentication method SHOULD NOT be used when either the
+- initiator or the target uses dynamically assigned IP addresses.
+- While in many cases pre-shared keys offer good security,
+- situations in which dynamically assigned addresses are used force
+- the use of a group pre-shared key, which creates vulnerability to
+- a man-in-the-middle attack.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 105]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - In the IKE Phase 2 Quick Mode, exchanges for creating the Phase 2
+- SA, the Identity Payload, fields MUST be present. ID_IPV4_ADDR,
+- ID_IPV6_ADDR (if the protocol stack supports IPv6) and ID_FQDN
+- Identity payloads MUST be supported; ID_USER_FQDN SHOULD be
+- supported. The IP Subnet, IP Address Range, ID_DER_ASN1_DN, and
+- ID_DER_ASN1_GN formats SHOULD NOT be used. The ID_KEY_ID
+- Identity Payload MUST NOT be used.
+-
+- Manual cryptographic keying MUST NOT be used because it does not
+- provide the necessary re-keying support.
+-
+- When IPsec is used, the receipt of an IKE Phase 2 delete message
+- SHOULD NOT be interpreted as a reason for tearing down the iSCSI TCP
+- connection. If additional traffic is sent on it, a new IKE Phase 2
+- SA will be created to protect it.
+-
+- The method used by the initiator to determine whether the target
+- should be connected using IPsec is regarded as an issue of IPsec
+- policy administration, and thus not defined in the iSCSI standard.
+-
+- If an iSCSI target is discovered via a SendTargets request in a
+- discovery session not using IPsec, the initiator should assume that
+- it does not need IPsec to establish a session to that target. If an
+- iSCSI target is discovered using a discovery session that does use
+- IPsec, the initiator SHOULD use IPsec when establishing a session to
+- that target.
+-
+-9. Notes to Implementers
+-
+- This section notes some of the performance and reliability
+- considerations of the iSCSI protocol. This protocol was designed to
+- allow efficient silicon and software implementations. The iSCSI task
+- tag mechanism was designed to enable Direct Data Placement (DDP - a
+- DMA form) at the iSCSI level or lower.
+-
+- The guiding assumption made throughout the design of this protocol is
+- that targets are resource constrained relative to initiators.
+-
+- Implementers are also advised to consider the implementation
+- consequences of the iSCSI to SCSI mapping model as outlined in
+- Section 3.4.3 Consequences of the Model.
+-
+-9.1. Multiple Network Adapters
+-
+- The iSCSI protocol allows multiple connections, not all of which need
+- to go over the same network adapter. If multiple network connections
+- are to be utilized with hardware support, the iSCSI protocol
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 106]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- command-data-status allegiance to one TCP connection ensures that
+- there is no need to replicate information across network adapters or
+- otherwise require them to cooperate.
+-
+- However, some task management commands may require some loose form of
+- cooperation or replication at least on the target.
+-
+-9.1.1. Conservative Reuse of ISIDs
+-
+- Historically, the SCSI model (and implementations and applications
+- based on that model) has assumed that SCSI ports are static, physical
+- entities. Recent extensions to the SCSI model have taken advantage
+- of persistent worldwide unique names for these ports. In iSCSI
+- however, the SCSI initiator ports are the endpoints of dynamically
+- created sessions, so the presumptions of "static and physical" do not
+- apply. In any case, the model clauses (particularly, Section 3.4.2
+- SCSI Architecture Model) provide for persistent, reusable names for
+- the iSCSI-type SCSI initiator ports even though there does not need
+- to be any physical entity bound to these names.
+-
+- To both minimize the disruption of legacy applications and to better
+- facilitate the SCSI features that rely on persistent names for SCSI
+- ports, iSCSI implementations SHOULD attempt to provide a stable
+- presentation of SCSI Initiator Ports (both to the upper OS-layers and
+- to the targets to which they connect). This can be achieved in an
+- initiator implementation by conservatively reusing ISIDs. In other
+- words, the same ISID should be used in the Login process to multiple
+- target portal groups (of the same iSCSI Target or different iSCSI
+- Targets). The ISID RULE (Section 3.4.3 Consequences of the Model)
+- only prohibits reuse to the same target portal group. It does not
+- "preclude" reuse to other target portal groups. The principle of
+- conservative reuse "encourages" reuse to other target portal groups.
+- When a SCSI target device sees the same (InitiatorName, ISID) pair in
+- different sessions to different target portal groups, it can identify
+- the underlying SCSI Initiator Port on each session as the same SCSI
+- port. In effect, it can recognize multiple paths from the same
+- source.
+-
+-9.1.2. iSCSI Name, ISID, and TPGT Use
+-
+- The designers of the iSCSI protocol envisioned there being one iSCSI
+- Initiator Node Name per operating system image on a machine. This
+- enables SAN resource configuration and authentication schemes based
+- on a system's identity. It supports the notion that it should be
+- possible to assign access to storage resources based on "initiator
+- device" identity.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 107]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- When there are multiple hardware or software components coordinated
+- as a single iSCSI Node, there must be some (logical) entity that
+- represents the iSCSI Node that makes the iSCSI Node Name available to
+- all components involved in session creation and login. Similarly,
+- this entity that represents the iSCSI Node must be able to coordinate
+- session identifier resources (ISID for initiators) to enforce both
+- the ISID and TSIH RULES (see Section 3.4.3 Consequences of the
+- Model).
+-
+- For targets, because of the closed environment, implementation of
+- this entity should be straightforward. However, vendors of iSCSI
+- hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide
+- mechanisms for configuration of the iSCSI Node Name across the portal
+- groups instantiated by multiple instances of these components within
+- a target.
+-
+- However, complex targets making use of multiple Target Portal Group
+- Tags may reconfigure them to achieve various quality goals. The
+- initiators have two mechanisms at their disposal to discover and/or
+- check reconfiguring targets - the discovery session type and a key
+- returned by the target during login to confirm the TPGT. An
+- initiator should attempt to "rediscover" the target configuration
+- anytime a session is terminated unexpectedly.
+-
+- For initiators, in the long term, it is expected that operating
+- system vendors will take on the role of this entity and provide
+- standard APIs that can inform components of their iSCSI Node Name and
+- can configure and/or coordinate ISID allocation, use, and reuse.
+-
+- Recognizing that such initiator APIs are not available today, other
+- implementations of the role of this entity are possible. For
+- example, a human may instantiate the (common) Node name as part of
+- the installation process of each iSCSI component involved in session
+- creation and login. This may be done either by pointing the
+- component to a vendor-specific location for this datum or to a
+- system-wide location. The structure of the ISID namespace (see
+- Section 10.12.5 ISID and [RFC3721]) facilitates implementation of the
+- ISID coordination by allowing each component vendor to independently
+- (of other vendor's components) coordinate allocation, use, and reuse
+- of its own partition of the ISID namespace in a vendor-specific
+- manner. Partitioning of the ISID namespace within initiator portal
+- groups managed by that vendor allows each such initiator portal group
+- to act independently of all other portal groups when selecting an
+- ISID for a login; this facilitates enforcement of the ISID RULE (see
+- Section 3.4.3 Consequences of the Model) at the initiator.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 108]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in
+- initiators MUST implement a mechanism for configuring the iSCSI Node
+- Name. Vendors, and administrators must ensure that iSCSI Node Names
+- are unique worldwide. It is therefore important that when one
+- chooses to reuse the iSCSI Node Name of a disabled unit, not to
+- re-assign that name to the original unit unless its worldwide
+- uniqueness can be ascertained again.
+-
+- In addition, a vendor of iSCSI hardware must implement a mechanism to
+- configure and/or coordinate ISIDs for all sessions managed by
+- multiple instances of that hardware within a given iSCSI Node. Such
+- configuration might be either permanently pre-assigned at the factory
+- (in a necessarily globally unique way), statically assigned (e.g.,
+- partitioned across all the NICs at initialization in a locally unique
+- way), or dynamically assigned (e.g., on-line allocator, also in a
+- locally unique way). In the latter two cases, the configuration may
+- be via public APIs (perhaps driven by an independent vendor's
+- software, such as the OS vendor) or via private APIs driven by the
+- vendor's own software.
+-
+-9.2. Autosense and Auto Contingent Allegiance (ACA)
+-
+- Autosense refers to the automatic return of sense data to the
+- initiator in case a command did not complete successfully. iSCSI
+- initiators and targets MUST support and use autosense.
+-
+- ACA helps preserve ordered command execution in the presence of
+- errors. As iSCSI can have many commands in-flight between initiator
+- and target, iSCSI initiators and targets SHOULD support ACA.
+-
+-9.3. iSCSI Timeouts
+-
+- iSCSI recovery actions are often dependent on iSCSI time-outs being
+- recognized and acted upon before SCSI time-outs. Determining the
+- right time-outs to use for various iSCSI actions (command
+- acknowledgements expected, status acknowledgements, etc.) is very
+- much dependent on infrastructure (hardware, links, TCP/IP stack,
+- iSCSI driver). As a guide, the implementer may use an average
+- Nop-Out/Nop-In turnaround delay multiplied by a "safety factor"
+- (e.g., 4) as a good estimate for the basic delay of the iSCSI stack
+- for a given connection. The safety factor should account for the
+- network load variability. For connection teardown the implementer
+- may want to consider also the TCP common practice for the given
+- infrastructure.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 109]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Text negotiations MAY also be subject to either time-limits or limits
+- in the number of exchanges. Those SHOULD be generous enough to avoid
+- affecting interoperability (e.g., allowing each key to be negotiated
+- on a separate exchange).
+-
+- The relation between iSCSI timeouts and SCSI timeouts should also be
+- considered. SCSI timeouts should be longer than iSCSI timeouts plus
+- the time required for iSCSI recovery whenever iSCSI recovery is
+- planned. Alternatively, an implementer may choose to interlock iSCSI
+- timeouts and recovery with SCSI timeouts so that SCSI recovery will
+- become active only where iSCSI is not planned to, or failed to,
+- recover.
+-
+- The implementer may also want to consider the interaction between
+- various iSCSI exception events - such as a digest failure - and
+- subsequent timeouts. When iSCSI error recovery is active, a digest
+- failure is likely to result in discovering a missing command or data
+- PDU. In these cases, an implementer may want to lower the timeout
+- values to enable faster initiation for recovery procedures.
+-
+-9.4. Command Retry and Cleaning Old Command Instances
+-
+- To avoid having old, retried command instances appear in a valid
+- command window after a command sequence number wrap around, the
+- protocol requires (see Section 3.2.2.1 Command Numbering and
+- Acknowledging) that on every connection on which a retry has been
+- issued, a non-immediate command be issued and acknowledged within a
+- 2**31-1 commands interval from the CmdSN of the retried command.
+- This requirement can be fulfilled by an implementation in several
+- ways.
+-
+- The simplest technique to use is to send a (non-retry) non-immediate
+- SCSI command (or a NOP if no SCSI command is available for a while)
+- after every command retry on the connection on which the retry was
+- attempted. As errors are deemed rare events, this technique is
+- probably the most effective, as it does not involve additional checks
+- at the initiator when issuing commands.
+-
+-9.5. Synch and Steering Layer and Performance
+-
+- While a synch and steering layer is optional, an initiator/target
+- that does not have it working against a target/initiator that demands
+- synch and steering may experience performance degradation caused by
+- packet reordering and loss. Providing a synch and steering mechanism
+- is recommended for all high-speed implementations.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 110]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-9.6. Considerations for State-dependent Devices and Long-lasting SCSI
+- Operations
+-
+- Sequential access devices operate on the principle that the position
+- of the device is based on the last command processed. As such,
+- command processing order and knowledge of whether or not the previous
+- command was processed is of the utmost importance to maintain data
+- integrity. For example, inadvertent retries of SCSI commands when it
+- is not known if the previous SCSI command was processed is a
+- potential data integrity risk.
+-
+- For a sequential access device, consider the scenario in which a SCSI
+- SPACE command to backspace one filemark is issued and then re-issued
+- due to no status received for the command. If the first SPACE
+- command was actually processed, the re-issued SPACE command, if
+- processed, will cause the position to change. Thus, a subsequent
+- write operation will write data to the wrong position and any
+- previous data at that position will be overwritten.
+-
+- For a medium changer device, consider the scenario in which an
+- EXCHANGE MEDIUM command (the SOURCE ADDRESS and DESTINATION ADDRESS
+- are the same thus performing a swap) is issued and then re-issued due
+- to no status received for the command. If the first EXCHANGE MEDIUM
+- command was actually processed, the re-issued EXCHANGE MEDIUM
+- command, if processed, will perform the swap again. The net effect
+- is that a swap was not performed thus leaving a data integrity
+- exposure.
+-
+- All commands that change the state of the device (as in SPACE
+- commands for sequential access devices, and EXCHANGE MEDIUM for
+- medium changer device), MUST be issued as non-immediate commands for
+- deterministic and in order delivery to iSCSI targets.
+-
+- For many of those state changing commands, the execution model also
+- assumes that the command is executed exactly once. Devices
+- implementing READ POSITION and LOCATE provide a means for SCSI level
+- command recovery and new tape-class devices should support those
+- commands. In their absence a retry at SCSI level is difficult and
+- error recovery at iSCSI level is advisable.
+-
+- Devices operating on long latency delivery subsystems and performing
+- long lasting SCSI operations may need mechanisms that enable
+- connection replacement while commands are running (e.g., during an
+- extended copy operation).
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 111]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-9.6.1. Determining the Proper ErrorRecoveryLevel
+-
+- The implementation and use of a specific ErrorRecoveryLevel should be
+- determined based on the deployment scenarios of a given iSCSI
+- implementation. Generally, the following factors must be considered
+- before deciding on the proper level of recovery:
+-
+- a) Application resilience to I/O failures.
+- b) Required level of availability in the face of transport
+- connection failures.
+- c) Probability of transport layer "checksum escape". This in
+- turn decides the iSCSI digest failure frequency, and thus the
+- criticality of iSCSI-level error recovery. The details of
+- estimating this probability are outside the scope of this
+- document.
+-
+-
+- A consideration of the above factors for SCSI tape devices as an
+- example suggests that implementations SHOULD use ErrorRecoveryLevel=1
+- when transport connection failure is not a concern and SCSI level
+- recovery is unavailable, and ErrorRecoveryLevel=2 when the connection
+- failure is also of high likelihood during a backup/retrieval.
+-
+- For extended copy operations, implementations SHOULD use
+- ErrorRecoveryLevel=2 whenever there is a relatively high likelihood
+- of connection failure.
+-
+-10. iSCSI PDU Formats
+-
+- All multi-byte integers that are specified in formats defined in this
+- document are to be represented in network byte order (i.e., big
+- endian). Any field that appears in this document assumes that the
+- most significant byte is the lowest numbered byte and the most
+- significant bit (within byte or field) is the lowest numbered bit
+- unless specified otherwise.
+-
+- Any compliant sender MUST set all bits not defined and all reserved
+- fields to zero unless specified otherwise. Any compliant receiver
+- MUST ignore any bit not defined and all reserved fields unless
+- specified otherwise. Receipt of reserved code values in defined
+- fields MUST be reported as a protocol error.
+-
+- Reserved fields are marked by the word "reserved", some abbreviation
+- of "reserved", or by "." for individual bits when no other form of
+- marking is technically feasible.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 112]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.1. iSCSI PDU Length and Padding
+-
+- iSCSI PDUs are padded to the closest integer number of four byte
+- words. The padding bytes SHOULD be sent as 0.
+-
+-10.2. PDU Template, Header, and Opcodes
+-
+- All iSCSI PDUs have one or more header segments and, optionally, a
+- data segment. After the entire header segment group a header-digest
+- MAY follow. The data segment MAY also be followed by a data-digest.
+-
+- The Basic Header Segment (BHS) is the first segment in all of the
+- iSCSI PDUs. The BHS is a fixed-length 48-byte header segment. It
+- MAY be followed by Additional Header Segments (AHS), a Header-Digest,
+- a Data Segment, and/or a Data-Digest.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 113]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The overall structure of an iSCSI PDU is as follows:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0/ Basic Header Segment (BHS) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48/ Additional Header Segment 1 (AHS) (optional) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- / Additional Header Segment 2 (AHS) (optional) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- ----
+- +---------------+---------------+---------------+---------------+
+- / Additional Header Segment n (AHS) (optional) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- ----
+- +---------------+---------------+---------------+---------------+
+- k/ Header-Digest (optional) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- l/ Data Segment(optional) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- m/ Data-Digest (optional) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+-
+- All PDU segments and digests are padded to the closest integer number
+- of four byte words. For example, all PDU segments and digests start
+- at a four byte word boundary and the padding ranges from 0 to 3
+- bytes. The padding bytes SHOULD be sent as 0.
+-
+- iSCSI response PDUs do not have AH Segments.
+-
+-10.2.1. Basic Header Segment (BHS)
+-
+- The BHS is 48 bytes long. The Opcode and DataSegmentLength fields
+- appear in all iSCSI PDUs. In addition, when used, the Initiator Task
+- Tag and Logical Unit Number always appear in the same location in the
+- header.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 114]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The format of the BHS is:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|I| Opcode |F| Opcode-specific fields |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN or Opcode-specific fields |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20/ Opcode-specific fields /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48
+-
+-10.2.1.1 I
+-
+- For request PDUs, the I bit set to 1 is an immediate delivery marker.
+-
+-10.2.1.2. Opcode
+-
+- The Opcode indicates the type of iSCSI PDU the header encapsulates.
+-
+- The Opcodes are divided into two categories: initiator opcodes and
+- target opcodes. Initiator opcodes are in PDUs sent by the initiator
+- (request PDUs). Target opcodes are in PDUs sent by the target
+- (response PDUs).
+-
+- Initiators MUST NOT use target opcodes and targets MUST NOT use
+- initiator opcodes.
+-
+- Initiator opcodes defined in this specification are:
+-
+- 0x00 NOP-Out
+- 0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block)
+- 0x02 SCSI Task Management function request
+- 0x03 Login Request
+- 0x04 Text Request
+- 0x05 SCSI Data-Out (for WRITE operations)
+- 0x06 Logout Request
+- 0x10 SNACK Request
+- 0x1c-0x1e Vendor specific codes
+-
+-
+-
+-Satran, et al. Standards Track [Page 115]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-
+- Target opcodes are:
+-
+- 0x20 NOP-In
+- 0x21 SCSI Response - contains SCSI status and possibly sense
+- information or other response information.
+- 0x22 SCSI Task Management function response
+- 0x23 Login Response
+- 0x24 Text Response
+- 0x25 SCSI Data-In - for READ operations.
+- 0x26 Logout Response
+- 0x31 Ready To Transfer (R2T) - sent by target when it is ready
+- to receive data.
+- 0x32 Asynchronous Message - sent by target to indicate certain
+- special conditions.
+- 0x3c-0x3e Vendor specific codes
+- 0x3f Reject
+-
+- All other opcodes are reserved.
+-
+-10.2.1.3. Final (F) bit
+-
+- When set to 1 it indicates the final (or only) PDU of a sequence.
+-
+-10.2.1.4. Opcode-specific Fields
+-
+- These fields have different meanings for different opcode types.
+-
+-10.2.1.5. TotalAHSLength
+-
+- Total length of all AHS header segments in units of four byte words
+- including padding, if any.
+-
+- The TotalAHSLength is only used in PDUs that have an AHS and MUST be
+- 0 in all other PDUs.
+-
+-10.2.1.6. DataSegmentLength
+-
+- This is the data segment payload length in bytes (excluding padding).
+- The DataSegmentLength MUST be 0 whenever the PDU has no data segment.
+-
+-10.2.1.7. LUN
+-
+- Some opcodes operate on a specific Logical Unit. The Logical Unit
+- Number (LUN) field identifies which Logical Unit. If the opcode does
+- not relate to a Logical Unit, this field is either ignored or may be
+- used in an opcode specific way. The LUN field is 64-bits and should
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 116]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- be formatted in accordance with [SAM2]. For example, LUN[0] from
+- [SAM2] is BHS byte 8 and so on up to LUN[7] from [SAM2], which is BHS
+- byte 15.
+-
+-10.2.1.8. Initiator Task Tag
+-
+- The initiator assigns a Task Tag to each iSCSI task it issues. While
+- a task exists, this tag MUST uniquely identify the task session-wide.
+- SCSI may also use the initiator task tag as part of the SCSI task
+- identifier when the timespan during which an iSCSI initiator task tag
+- must be unique extends over the timespan during which a SCSI task tag
+- must be unique. However, the iSCSI Initiator Task Tag must exist and
+- be unique even for untagged SCSI commands.
+-
+-10.2.2. Additional Header Segment (AHS)
+-
+- The general format of an AHS is:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0| AHSLength | AHSType | AHS-Specific |
+- +---------------+---------------+---------------+---------------+
+- 4/ AHS-Specific /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- x
+-
+-10.2.2.1. AHSType
+-
+- The AHSType field is coded as follows:
+-
+- bit 0-1 - Reserved
+-
+- bit 2-7 - AHS code
+-
+- 0 - Reserved
+- 1 - Extended CDB
+- 2 - Expected Bidirectional Read Data Length
+- 3 - 63 Reserved
+-
+-10.2.2.2. AHSLength
+-
+- This field contains the effective length in bytes of the AHS
+- excluding AHSType and AHSLength and padding, if any. The AHS is
+- padded to the smallest integer number of 4 byte words (i.e., from 0
+- up to 3 padding bytes).
+-
+-
+-
+-Satran, et al. Standards Track [Page 117]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.2.2.3. Extended CDB AHS
+-
+- The format of the Extended CDB AHS is:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0| AHSLength (CDBLength-15) | 0x01 | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4/ ExtendedCDB...+padding /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- x
+-
+- This type of AHS MUST NOT be used if the CDBLength is less than 17.
+- The length includes the reserved byte 3.
+-
+-10.2.2.4. Bidirectional Expected Read-Data Length AHS
+-
+- The format of the Bidirectional Read Expected Data Transfer Length
+- AHS is:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0| AHSLength (0x0005) | 0x02 | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4| Expected Read-Data Length |
+- +---------------+---------------+---------------+---------------+
+- 8
+-
+-10.2.3. Header Digest and Data Digest
+-
+- Optional header and data digests protect the integrity of the header
+- and data, respectively. The digests, if present, are located,
+- respectively, after the header and PDU-specific data, and cover
+- respectively the header and the PDU data, each including the padding
+- bytes, if any.
+-
+- The existence and type of digests are negotiated during the Login
+- Phase.
+-
+- The separation of the header and data digests is useful in iSCSI
+- routing applications, in which only the header changes when a message
+- is forwarded. In this case, only the header digest should be
+- recalculated.
+-
+-
+-
+-Satran, et al. Standards Track [Page 118]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Digests are not included in data or header length fields.
+-
+- A zero-length Data Segment also implies a zero-length data-digest.
+-
+-10.2.4. Data Segment
+-
+- The (optional) Data Segment contains PDU associated data. Its
+- payload effective length is provided in the BHS field -
+- DataSegmentLength. The Data Segment is also padded to an integer
+- number of 4 byte words.
+-
+-10.3. SCSI Command
+-
+- The format of the SCSI Command PDU is:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|I| 0x01 |F|R|W|. .|ATTR | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| Logical Unit Number (LUN) |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Expected Data Transfer Length |
+- +---------------+---------------+---------------+---------------+
+- 24| CmdSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpStatSN |
+- +---------------+---------------+---------------+---------------+
+- 32/ SCSI Command Descriptor Block (CDB) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48/ AHS (Optional) /
+- +---------------+---------------+---------------+---------------+
+- x/ Header Digest (Optional) /
+- +---------------+---------------+---------------+---------------+
+- y/ (DataSegment, Command Data) (Optional) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- z/ Data Digest (Optional) /
+- +---------------+---------------+---------------+---------------+
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 119]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.3.1. Flags and Task Attributes (byte 1)
+-
+- The flags for a SCSI Command are:
+-
+- bit 0 (F) is set to 1 when no unsolicited SCSI Data-Out PDUs follow
+- this PDU. When F=1 for a write and if Expected Data
+- Transfer Length is larger than the DataSegmentLength, the
+- target may solicit additional data through R2T.
+-
+- bit 1 (R) is set to 1 when the command is expected to input data.
+-
+- bit 2 (W) is set to 1 when the command is expected to output data.
+-
+- bit 3-4 Reserved.
+-
+- bit 5-7 contains Task Attributes.
+-
+- Task Attributes (ATTR) have one of the following integer values (see
+- [SAM2] for details):
+-
+- 0 - Untagged
+- 1 - Simple
+- 2 - Ordered
+- 3 - Head of Queue
+- 4 - ACA
+- 5-7 - Reserved
+-
+- Setting both the W and the F bit to 0 is an error. Either or both of
+- R and W MAY be 1 when either the Expected Data Transfer Length and/or
+- Bidirectional Read Expected Data Transfer Length are 0, but they MUST
+- NOT both be 0 when the Expected Data Transfer Length and/or
+- Bidirectional Read Expected Data Transfer Length are not 0 (i.e.,
+- when some data transfer is expected the transfer direction is
+- indicated by the R and/or W bit).
+-
+-10.3.2. CmdSN - Command Sequence Number
+-
+- Enables ordered delivery across multiple connections in a single
+- session.
+-
+-10.3.3. ExpStatSN
+-
+- Command responses up to ExpStatSN-1 (mod 2**32) have been received
+- (acknowledges status) on the connection.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 120]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.3.4. Expected Data Transfer Length
+-
+- For unidirectional operations, the Expected Data Transfer Length
+- field contains the number of bytes of data involved in this SCSI
+- operation. For a unidirectional write operation (W flag set to 1 and
+- R flag set to 0), the initiator uses this field to specify the number
+- of bytes of data it expects to transfer for this operation. For a
+- unidirectional read operation (W flag set to 0 and R flag set to 1),
+- the initiator uses this field to specify the number of bytes of data
+- it expects the target to transfer to the initiator. It corresponds
+- to the SAM2 byte count.
+-
+- For bidirectional operations (both R and W flags are set to 1), this
+- field contains the number of data bytes involved in the write
+- transfer. For bidirectional operations, an additional header segment
+- MUST be present in the header sequence that indicates the
+- Bidirectional Read Expected Data Transfer Length. The Expected Data
+- Transfer Length field and the Bidirectional Read Expected Data
+- Transfer Length field correspond to the SAM2 byte count
+-
+- If the Expected Data Transfer Length for a write and the length of
+- the immediate data part that follows the command (if any) are the
+- same, then no more data PDUs are expected to follow. In this case,
+- the F bit MUST be set to 1.
+-
+- If the Expected Data Transfer Length is higher than the
+- FirstBurstLength (the negotiated maximum amount of unsolicited data
+- the target will accept), the initiator MUST send the maximum amount
+- of unsolicited data OR ONLY the immediate data, if any.
+-
+- Upon completion of a data transfer, the target informs the initiator
+- (through residual counts) of how many bytes were actually processed
+- (sent and/or received) by the target.
+-
+-10.3.5. CDB - SCSI Command Descriptor Block
+-
+- There are 16 bytes in the CDB field to accommodate the commonly used
+- CDBs. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS
+- MUST be used to contain the CDB spillover.
+-
+-10.3.6. Data Segment - Command Data
+-
+- Some SCSI commands require additional parameter data to accompany the
+- SCSI command. This data may be placed beyond the boundary of the
+- iSCSI header in a data segment. Alternatively, user data (e.g., from
+- a WRITE operation) can be placed in the data segment (both cases are
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 121]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- referred to as immediate data). These data are governed by the rules
+- for solicited vs. unsolicited data outlined in Section 3.2.4.2 Data
+- Transfer Overview.
+-
+-10.4. SCSI Response
+-
+- The format of the SCSI Response PDU is:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x21 |1|. .|o|u|O|U|.| Response | Status |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| SNACK Tag or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36| ExpDataSN or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 40| Bidirectional Read Residual Count or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 44| Residual Count or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+- / Data Segment (Optional) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- | Data-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 122]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.4.1. Flags (byte 1)
+-
+- bit 1-2 Reserved.
+-
+- bit 3 - (o) set for Bidirectional Read Residual Overflow. In this
+- case, the Bidirectional Read Residual Count indicates the number
+- of bytes that were not transferred to the initiator because the
+- initiator's Expected Bidirectional Read Data Transfer Length was
+- not sufficient.
+-
+- bit 4 - (u) set for Bidirectional Read Residual Underflow. In this
+- case, the Bidirectional Read Residual Count indicates the number
+- of bytes that were not transferred to the initiator out of the
+- number of bytes expected to be transferred.
+-
+- bit 5 - (O) set for Residual Overflow. In this case, the Residual
+- Count indicates the number of bytes that were not transferred
+- because the initiator's Expected Data Transfer Length was not
+- sufficient. For a bidirectional operation, the Residual Count
+- contains the residual for the write operation.
+-
+- bit 6 - (U) set for Residual Underflow. In this case, the Residual
+- Count indicates the number of bytes that were not transferred out
+- of the number of bytes that were expected to be transferred. For
+- a bidirectional operation, the Residual Count contains the
+- residual for the write operation.
+-
+- bit 7 - (0) Reserved.
+-
+- Bits O and U and bits o and u are mutually exclusive (i.e., having
+- both o and u or O and U set to 1 is a protocol error). For a
+- response other than "Command Completed at Target", bits 3-6 MUST be
+- 0.
+-
+-10.4.2. Status
+-
+- The Status field is used to report the SCSI status of the command (as
+- specified in [SAM2]) and is only valid if the Response Code is
+- Command Completed at target.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 123]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Some of the status codes defined in [SAM2] are:
+-
+- 0x00 GOOD
+- 0x02 CHECK CONDITION
+- 0x08 BUSY
+- 0x18 RESERVATION CONFLICT
+- 0x28 TASK SET FULL
+- 0x30 ACA ACTIVE
+- 0x40 TASK ABORTED
+-
+- See [SAM2] for the complete list and definitions.
+-
+- If a SCSI device error is detected while data from the initiator is
+- still expected (the command PDU did not contain all the data and the
+- target has not received a Data PDU with the final bit Set), the
+- target MUST wait until it receives a Data PDU with the F bit set in
+- the last expected sequence before sending the Response PDU.
+-
+-10.4.3. Response
+-
+- This field contains the iSCSI service response.
+-
+- iSCSI service response codes defined in this specification are:
+-
+- 0x00 - Command Completed at Target
+- 0x01 - Target Failure
+- 0x80-0xff - Vendor specific
+-
+- All other response codes are reserved.
+-
+- The Response is used to report a Service Response. The mapping of
+- the response code into a SCSI service response code value, if needed,
+- is outside the scope of this document. However, in symbolic terms
+- response value 0x00 maps to the SCSI service response (see [SAM2] and
+- [SPC3]) of TASK COMPLETE or LINKED COMMAND COMPLETE. All other
+- Response values map to the SCSI service response of SERVICE DELIVERY
+- OR TARGET FAILURE.
+-
+- If a PDU that includes SCSI status (Response PDU or Data-In PDU
+- including status) does not arrive before the session is terminated,
+- the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE.
+-
+- A non-zero Response field indicates a failure to execute the command
+- in which case the Status and Flag fields are undefined.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 124]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.4.4. SNACK Tag
+-
+- This field contains a copy of the SNACK Tag of the last SNACK Tag
+- accepted by the target on the same connection and for the command for
+- which the response is issued. Otherwise it is reserved and should be
+- set to 0.
+-
+- After issuing a R-Data SNACK the initiator must discard any SCSI
+- status unless contained in an SCSI Response PDU carrying the same
+- SNACK Tag as the last issued R-Data SNACK for the SCSI command on the
+- current connection.
+-
+- For a detailed discussion on R-Data SNACK see Section 10.16 SNACK
+- Request.
+-
+-10.4.5. Residual Count
+-
+- The Residual Count field MUST be valid in the case where either the U
+- bit or the O bit is set. If neither bit is set, the Residual Count
+- field is reserved. Targets may set the residual count and initiators
+- may use it when the response code is "completed at target" (even if
+- the status returned is not GOOD). If the O bit is set, the Residual
+- Count indicates the number of bytes that were not transferred because
+- the initiator's Expected Data Transfer Length was not sufficient. If
+- the U bit is set, the Residual Count indicates the number of bytes
+- that were not transferred out of the number of bytes expected to be
+- transferred.
+-
+-10.4.6. Bidirectional Read Residual Count
+-
+- The Bidirectional Read Residual Count field MUST be valid in the case
+- where either the u bit or the o bit is set. If neither bit is set,
+- the Bidirectional Read Residual Count field is reserved. Targets may
+- set the Bidirectional Read Residual Count and initiators may use it
+- when the response code is "completed at target". If the o bit is
+- set, the Bidirectional Read Residual Count indicates the number of
+- bytes that were not transferred to the initiator because the
+- initiator's Expected Bidirectional Read Transfer Length was not
+- sufficient. If the u bit is set, the Bidirectional Read Residual
+- Count indicates the number of bytes that were not transferred to the
+- initiator out of the number of bytes expected to be transferred.
+-
+-10.4.7. Data Segment - Sense and Response Data Segment
+-
+- iSCSI targets MUST support and enable autosense. If Status is CHECK
+- CONDITION (0x02), then the Data Segment MUST contain sense data for
+- the failed command.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 125]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- For some iSCSI responses, the response data segment MAY contain some
+- response related information, (e.g., for a target failure, it may
+- contain a vendor specific detailed description of the failure).
+-
+- If the DataSegmentLength is not 0, the format of the Data Segment is
+- as follows:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|SenseLength | Sense Data |
+- +---------------+---------------+---------------+---------------+
+- x/ Sense Data /
+- +---------------+---------------+---------------+---------------+
+- y/ Response Data /
+- / /
+- +---------------+---------------+---------------+---------------+
+- z|
+-
+-10.4.7.1. SenseLength
+-
+- Length of Sense Data.
+-
+-10.4.7.2. Sense Data
+-
+- The Sense Data contains detailed information about a check condition
+- and [SPC3] specifies the format and content of the Sense Data.
+-
+- Certain iSCSI conditions result in the command being terminated at
+- the target (response Command Completed at Target) with a SCSI Check
+- Condition Status as outlined in the next table:
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 126]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- +--------------------------+----------+---------------------------+
+- | iSCSI Condition |Sense | Additional Sense Code & |
+- | |Key | Qualifier |
+- +--------------------------+----------+---------------------------+
+- | Unexpected unsolicited |Aborted | ASC = 0x0c ASCQ = 0x0c |
+- | data |Command-0B| Write Error |
+- +--------------------------+----------+---------------------------+
+- | Incorrect amount of data |Aborted | ASC = 0x0c ASCQ = 0x0d |
+- | |Command-0B| Write Error |
+- +--------------------------+----------+---------------------------+
+- | Protocol Service CRC |Aborted | ASC = 0x47 ASCQ = 0x05 |
+- | error |Command-0B| CRC Error Detected |
+- +--------------------------+----------+---------------------------+
+- | SNACK rejected |Aborted | ASC = 0x11 ASCQ = 0x13 |
+- | |Command-0B| Read Error |
+- +--------------------------+----------+---------------------------+
+-
+- The target reports the "Incorrect amount of data" condition if during
+- data output the total data length to output is greater than
+- FirstBurstLength and the initiator sent unsolicited non-immediate
+- data but the total amount of unsolicited data is different than
+- FirstBurstLength. The target reports the same error when the amount
+- of data sent as a reply to an R2T does not match the amount
+- requested.
+-
+-10.4.8. ExpDataSN
+-
+- The number of R2T and Data-In (read) PDUs the target has sent for the
+- command.
+-
+- This field MUST be 0 if the response code is not Command Completed at
+- Target or the target sent no Data-In PDUs for the command.
+-
+-10.4.9. StatSN - Status Sequence Number
+-
+- StatSN is a Sequence Number that the target iSCSI layer generates per
+- connection and that in turn, enables the initiator to acknowledge
+- status reception. StatSN is incremented by 1 for every
+- response/status sent on a connection except for responses sent as a
+- result of a retry or SNACK. In the case of responses sent due to a
+- retransmission request, the StatSN MUST be the same as the first time
+- the PDU was sent unless the connection has since been restarted.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 127]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.4.10. ExpCmdSN - Next Expected CmdSN from this Initiator
+-
+- ExpCmdSN is a Sequence Number that the target iSCSI returns to the
+- initiator to acknowledge command reception. It is used to update a
+- local variable with the same name. An ExpCmdSN equal to MaxCmdSN+1
+- indicates that the target cannot accept new commands.
+-
+-10.4.11. MaxCmdSN - Maximum CmdSN from this Initiator
+-
+- MaxCmdSN is a Sequence Number that the target iSCSI returns to the
+- initiator to indicate the maximum CmdSN the initiator can send. It
+- is used to update a local variable with the same name. If MaxCmdSN
+- is equal to ExpCmdSN-1, this indicates to the initiator that the
+- target cannot receive any additional commands. When MaxCmdSN changes
+- at the target while the target has no pending PDUs to convey this
+- information to the initiator, it MUST generate a NOP-IN to carry the
+- new MaxCmdSN.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 128]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.5. Task Management Function Request
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|I| 0x02 |1| Function | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| Logical Unit Number (LUN) or Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Referenced Task Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 24| CmdSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpStatSN |
+- +---------------+---------------+---------------+---------------+
+- 32| RefCmdSN or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 36| ExpDataSN or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 40/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+-10.5.1. Function
+-
+- The Task Management functions provide an initiator with a way to
+- explicitly control the execution of one or more Tasks (SCSI and iSCSI
+- tasks). The Task Management function codes are listed below. For a
+- more detailed description of SCSI task management, see [SAM2].
+-
+- 1 - ABORT TASK - aborts the task identified by the Referenced Task
+- Tag field.
+-
+- 2 - ABORT TASK SET - aborts all Tasks issued via this session on the
+- logical unit.
+-
+- 3 - CLEAR ACA - clears the Auto Contingent Allegiance condition.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 129]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 4 - CLEAR TASK SET - aborts all Tasks in the appropriate task set as
+- defined by the TST field in the Control mode page (see [SPC3]).
+-
+- 5 - LOGICAL UNIT RESET
+-
+- 6 - TARGET WARM RESET
+-
+- 7 - TARGET COLD RESET
+-
+- 8 - TASK REASSIGN - reassigns connection allegiance for the task
+- identified by the Referenced Task Tag field to this connection,
+- thus resuming the iSCSI exchanges for the task.
+-
+- For all these functions, the Task Management function response MUST
+- be returned as detailed in Section 10.6 Task Management Function
+- Response. All these functions apply to the referenced tasks
+- regardless of whether they are proper SCSI tasks or tagged iSCSI
+- operations. Task management requests must act on all the commands
+- from the same session having a CmdSN lower than the task management
+- CmdSN. LOGICAL UNIT RESET, TARGET WARM RESET and TARGET COLD RESET
+- may affect commands from other sessions or commands from the same
+- session with CmdSN equal or exceeding CmdSN.
+-
+- If the task management request is marked for immediate delivery, it
+- must be considered immediately for execution, but the operations
+- involved (all or part of them) may be postponed to allow the target
+- to receive all relevant tasks. According to [SAM2], for all the
+- tasks covered by the Task Management response (i.e., with CmdSN lower
+- than the task management command CmdSN) but except the Task
+- Management response to a TASK REASSIGN, additional responses MUST NOT
+- be delivered to the SCSI layer after the Task Management response.
+- The iSCSI initiator MAY deliver to the SCSI layer all responses
+- received before the Task Management response (i.e., it is a matter of
+- implementation if the SCSI responses, received before the Task
+- Management response but after the task management request was issued,
+- are delivered to the SCSI layer by the iSCSI layer in the initiator).
+- The iSCSI target MUST ensure that no responses for the tasks covered
+- by a task management function are delivered to the iSCSI initiator
+- after the Task Management response except for a task covered by a
+- TASK REASSIGN.
+-
+- For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST
+- continue to respond to all valid target transfer tags (received via
+- R2T, Text Response, NOP-In, or SCSI Data-In PDUs) related to the
+- affected task set, even after issuing the task management request.
+- The issuing initiator SHOULD however terminate (i.e., by setting the
+- F-bit to 1) these response sequences as quickly as possible. The
+- target on its part MUST wait for responses on all affected target
+-
+-
+-
+-Satran, et al. Standards Track [Page 130]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- transfer tags before acting on either of these two task management
+- requests. In case all or part of the response sequence is not
+- received (due to digest errors) for a valid TTT, the target MAY treat
+- it as a case of within-command error recovery class (see Section
+- 6.1.4.1 Recovery Within-command) if it is supporting
+- ErrorRecoveryLevel >= 1, or alternatively may drop the connection to
+- complete the requested task set function.
+-
+- If an ABORT TASK is issued for a task created by an immediate command
+- then RefCmdSN MUST be that of the Task Management request itself
+- (i.e., CmdSN and RefCmdSN are equal); otherwise RefCmdSN MUST be set
+- to the CmdSN of the task to be aborted (lower than CmdSN).
+-
+- If the connection is still active (it is not undergoing an implicit
+- or explicit logout), ABORT TASK MUST be issued on the same connection
+- to which the task to be aborted is allegiant at the time the Task
+- Management Request is issued. If the connection is implicitly or
+- explicitly logged out (i.e., no other request will be issued on the
+- failing connection and no other response will be received on the
+- failing connection), then an ABORT TASK function request may be
+- issued on another connection. This Task Management request will then
+- establish a new allegiance for the command to be aborted as well as
+- abort it (i.e., the task to be aborted will not have to be retried or
+- reassigned, and its status, if issued but not acknowledged, will be
+- reissued followed by the Task Management response).
+-
+- At the target an ABORT TASK function MUST NOT be executed on a Task
+- Management request; such a request MUST result in Task Management
+- response of "Function rejected".
+-
+- For the LOGICAL UNIT RESET function, the target MUST behave as
+- dictated by the Logical Unit Reset function in [SAM2].
+-
+- The implementation of the TARGET WARM RESET function and the TARGET
+- COLD RESET function is OPTIONAL and when implemented, should act as
+- described below. The TARGET WARM RESET is also subject to SCSI
+- access controls on the requesting initiator as defined in [SPC3].
+- When authorization fails at the target, the appropriate response as
+- described in Section 10.6 Task Management Function Response MUST be
+- returned by the target. The TARGET COLD RESET function is not
+- subject to SCSI access controls, but its execution privileges may be
+- managed by iSCSI mechanisms such as login authentication.
+-
+- When executing the TARGET WARM RESET and TARGET COLD RESET functions,
+- the target cancels all pending operations on all Logical Units known
+- by the issuing initiator. Both functions are equivalent to the
+- Target Reset function specified by [SAM2]. They can affect many
+- other initiators logged in with the servicing SCSI target port.
+-
+-
+-
+-Satran, et al. Standards Track [Page 131]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The target MUST treat the TARGET COLD RESET function additionally as
+- a power on event, thus terminating all of its TCP connections to all
+- initiators (all sessions are terminated). For this reason, the
+- Service Response (defined by [SAM2]) for this SCSI task management
+- function may not be reliably delivered to the issuing initiator port.
+-
+- For the TASK REASSIGN function, the target should reassign the
+- connection allegiance to this new connection (and thus resume iSCSI
+- exchanges for the task). TASK REASSIGN MUST ONLY be received by the
+- target after the connection on which the command was previously
+- executing has been successfully logged-out. The Task Management
+- response MUST be issued before the reassignment becomes effective.
+- For additional usage semantics see Section 6.2 Retry and Reassign in
+- Recovery.
+-
+- At the target a TASK REASSIGN function request MUST NOT be executed
+- to reassign the connection allegiance of a Task Management function
+- request, an active text negotiation task, or a Logout task; such a
+- request MUST result in Task Management response of "Function
+- rejected".
+-
+- TASK REASSIGN MUST be issued as an immediate command.
+-
+-10.5.2. TotalAHSLength and DataSegmentLength
+-
+- For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+-
+-10.5.3. LUN
+-
+- This field is required for functions that address a specific LU
+- (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT
+- RESET) and is reserved in all others.
+-
+-10.5.4. Referenced Task Tag
+-
+- The Initiator Task Tag of the task to be aborted for the ABORT TASK
+- function or reassigned for the TASK REASSIGN function. For all the
+- other functions this field MUST be set to the reserved value
+- 0xffffffff.
+-
+-10.5.5. RefCmdSN
+-
+- If an ABORT TASK is issued for a task created by an immediate command
+- then RefCmdSN MUST be that of the Task Management request itself
+- (i.e., CmdSN and RefCmdSN are equal).
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 132]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- For an ABORT TASK of a task created by non-immediate command RefCmdSN
+- MUST be set to the CmdSN of the task identified by the Referenced
+- Task Tag field. Targets must use this field as described in section
+- 10.6.1 when the task identified by the Referenced Task Tag field is
+- not with the target.
+-
+- Otherwise, this field is reserved.
+-
+-10.5.6. ExpDataSN
+-
+- For recovery purposes, the iSCSI target and initiator maintain a data
+- acknowledgement reference number - the first input DataSN number
+- unacknowledged by the initiator. When issuing a new command, this
+- number is set to 0. If the function is TASK REASSIGN, which
+- establishes a new connection allegiance for a previously issued Read
+- or Bidirectional command, ExpDataSN will contain an updated data
+- acknowledgement reference number or the value 0; the latter
+- indicating that the data acknowledgement reference number is
+- unchanged. The initiator MUST discard any data PDUs from the
+- previous execution that it did not acknowledge and the target MUST
+- transmit all Data-In PDUs (if any) starting with the data
+- acknowledgement reference number. The number of retransmitted PDUs
+- may or may not be the same as the original transmission depending on
+- if there was a change in MaxRecvDataSegmentLength in the
+- reassignment. The target MAY also send no more Data-In PDUs if all
+- data has been acknowledged.
+-
+- The value of ExpDataSN MUST be 0 or higher than the DataSN of the
+- last acknowledged Data-In PDU, but not larger than DataSN+1 of the
+- last Data-In PDU sent by the target. Any other value MUST be ignored
+- by the target.
+-
+- For other functions this field is reserved.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 133]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.6. Task Management Function Response
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x22 |1| Reserved | Response | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------------------------------------------------------+
+- 8/ Reserved /
+- / /
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+- For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK
+- SET, LOGICAL UNIT RESET, TARGET COLD RESET, TARGET WARM RESET and
+- TASK REASSIGN, the target performs the requested Task Management
+- function and sends a Task Management response back to the initiator.
+- For TASK REASSIGN, the new connection allegiance MUST ONLY become
+- effective at the target after the target issues the Task Management
+- Response.
+-
+-10.6.1. Response
+-
+- The target provides a Response, which may take on the following
+- values:
+-
+- a) 0 - Function complete.
+- b) 1 - Task does not exist.
+- c) 2 - LUN does not exist.
+- d) 3 - Task still allegiant.
+- e) 4 - Task allegiance reassignment not supported.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 134]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- f) 5 - Task management function not supported.
+- g) 6 - Function authorization failed.
+- h) 255 - Function rejected.
+-
+- All other values are reserved.
+-
+- For a discussion on usage of response codes 3 and 4, see Section
+- 6.2.2 Allegiance Reassignment.
+-
+- For the TARGET COLD RESET and TARGET WARM RESET functions, the target
+- cancels all pending operations across all Logical Units known to the
+- issuing initiator. For the TARGET COLD RESET function, the target
+- MUST then close all of its TCP connections to all initiators
+- (terminates all sessions).
+-
+- The mapping of the response code into a SCSI service response code
+- value, if needed, is outside the scope of this document. However, in
+- symbolic terms Response values 0 and 1 map to the SCSI service
+- response of FUNCTION COMPLETE. All other Response values map to the
+- SCSI service response of FUNCTION REJECTED. If a Task Management
+- function response PDU does not arrive before the session is
+- terminated, the SCSI service response is SERVICE DELIVERY OR TARGET
+- FAILURE.
+-
+- The response to ABORT TASK SET and CLEAR TASK SET MUST only be issued
+- by the target after all of the commands affected have been received
+- by the target, the corresponding task management functions have been
+- executed by the SCSI target, and the delivery of all responses
+- delivered until the task management function completion have been
+- confirmed (acknowledged through ExpStatSN) by the initiator on all
+- connections of this session. For the exact timeline of events, refer
+- to Section 10.6.2 Task Management Actions on Task Sets.
+-
+- For the ABORT TASK function,
+-
+- a) If the Referenced Task Tag identifies a valid task leading to
+- a successful termination, then targets must return the
+- "Function complete" response.
+- b) If the Referenced Task Tag does not identify an existing task,
+- but if the CmdSN indicated by the RefCmdSN field in the Task
+- Management function request is within the valid CmdSN window
+- and less than the CmdSN of the Task Management function
+- request itself, then targets must consider the CmdSN received
+- and return the "Function complete" response.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 135]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- c) If the Referenced Task Tag does not identify an existing task
+- and if the CmdSN indicated by the RefCmdSN field in the Task
+- Management function request is outside the valid CmdSN window,
+- then targets must return the "Task does not exist" response.
+-
+-10.6.2. Task Management Actions on Task Sets
+-
+- The execution of ABORT TASK SET and CLEAR TASK SET Task Management
+- function requests consists of the following sequence of events in the
+- specified order on each of the entities.
+-
+- The initiator:
+-
+- a) Issues ABORT TASK SET/CLEAR TASK SET request.
+- b) Continues to respond to each target transfer tag received
+- for the affected task set.
+- c) Receives any responses for the tasks in the affected task
+- set (may process them as usual because they are guaranteed
+- to be valid).
+- d) Receives the task set management response, thus concluding
+- all the tasks in the affected task set.
+-
+- The target:
+-
+- a) Receives the ABORT TASK SET/CLEAR TASK SET request.
+- b) Waits for all target transfer tags to be responded to and
+- for all affected tasks in the task set to be received.
+- c) Propagates the command to and receives the response from the
+- target SCSI layer.
+- d) Takes note of last-sent StatSN on each of the connections in
+- the iSCSI sessions (one or more) sharing the affected task
+- set, and waits for acknowledgement of each StatSN (may
+- solicit for acknowledgement by way of a NOP-In). If some
+- tasks originate from non-iSCSI I_T_L nexi then the means by
+- which the target insures that all affected tasks have
+- returned their status to the initiator are defined by the
+- specific protocol.
+-
+- e) Sends the task set management response to the issuing
+- initiator.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 136]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.6.3. TotalAHSLength and DataSegmentLength
+-
+- For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+-
+-10.7. SCSI Data-Out & SCSI Data-In
+-
+- The SCSI Data-Out PDU for WRITE operations has the following format:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x05 |F| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN or Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Target Transfer Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 24| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpStatSN |
+- +---------------+---------------+---------------+---------------+
+- 32| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 36| DataSN |
+- +---------------+---------------+---------------+---------------+
+- 40| Buffer Offset |
+- +---------------+---------------+---------------+---------------+
+- 44| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+- / DataSegment /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- | Data-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 137]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The SCSI Data-In PDU for READ operations has the following format:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x25 |F|A|0 0 0|O|U|S| Reserved |Status or Rsvd |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN or Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Target Transfer Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36| DataSN |
+- +---------------+---------------+---------------+---------------+
+- 40| Buffer Offset |
+- +---------------+---------------+---------------+---------------+
+- 44| Residual Count |
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+- / DataSegment /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- | Data-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+- Status can accompany the last Data-In PDU if the command did not end
+- with an exception (i.e., the status is "good status" - GOOD,
+- CONDITION MET or INTERMEDIATE CONDITION MET). The presence of status
+- (and of a residual count) is signaled though the S flag bit.
+- Although targets MAY choose to send even non-exception status in
+- separate responses, initiators MUST support non-exception status in
+- Data-In PDUs.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 138]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.7.1. F (Final) Bit
+-
+- For outgoing data, this bit is 1 for the last PDU of unsolicited data
+- or the last PDU of a sequence that answers an R2T.
+-
+- For incoming data, this bit is 1 for the last input (read) data PDU
+- of a sequence. Input can be split into several sequences, each
+- having its own F bit. Splitting the data stream into sequences does
+- not affect DataSN counting on Data-In PDUs. It MAY be used as a
+- "change direction" indication for Bidirectional operations that need
+- such a change.
+-
+- DataSegmentLength MUST not exceed MaxRecvDataSegmentLength for the
+- direction it is sent and the total of all the DataSegmentLength of
+- all PDUs in a sequence MUST not exceed MaxBurstLength (or
+- FirstBurstLength for unsolicited data). However the number of
+- individual PDUs in a sequence (or in total) may be higher than the
+- MaxBurstLength (or FirstBurstLength) to MaxRecvDataSegmentLength
+- ratio (as PDUs may be limited in length by the sender capabilities).
+- Using DataSegmentLength of 0 may increase beyond what is reasonable
+- for the number of PDUs and should therefore be avoided.
+-
+- For Bidirectional operations, the F bit is 1 for both the end of the
+- input sequences and the end of the output sequences.
+-
+-10.7.2. A (Acknowledge) Bit
+-
+- For sessions with ErrorRecoveryLevel 1 or higher, the target sets
+- this bit to 1 to indicate that it requests a positive acknowledgement
+- from the initiator for the data received. The target should use the
+- A bit moderately; it MAY only set the A bit to 1 once every
+- MaxBurstLength bytes, or on the last Data-In PDU that concludes the
+- entire requested read data transfer for the task from the target's
+- perspective, and it MUST NOT do so more frequently. The target MUST
+- NOT set to 1 the A bit for sessions with ErrorRecoveryLevel=0. The
+- initiator MUST ignore the A bit set to 1 for sessions with
+- ErrorRecoveryLevel=0.
+-
+- On receiving a Data-In PDU with the A bit set to 1 on a session with
+- ErrorRecoveryLevel greater than 0, if there are no holes in the read
+- data until that Data-In PDU, the initiator MUST issue a SNACK of type
+- DataACK except when it is able to acknowledge the status for the task
+- immediately via ExpStatSN on other outbound PDUs if the status for
+- the task is also received. In the latter case (acknowledgement
+- through ExpStatSN), sending a SNACK of type DataACK in response to
+- the A bit is OPTIONAL, but if it is done, it must not be sent after
+- the status acknowledgement through ExpStatSN. If the initiator has
+- detected holes in the read data prior to that Data-In PDU, it MUST
+-
+-
+-
+-Satran, et al. Standards Track [Page 139]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- postpone issuing the SNACK of type DataACK until the holes are
+- filled. An initiator also MUST NOT acknowledge the status for the
+- task before those holes are filled. A status acknowledgement for a
+- task that generated the Data-In PDUs is considered by the target as
+- an implicit acknowledgement of the Data-In PDUs if such an
+- acknowledgement was requested by the target.
+-
+-10.7.3. Flags (byte 1)
+-
+- The last SCSI Data packet sent from a target to an initiator for a
+- SCSI command that completed successfully (with a status of GOOD,
+- CONDITION MET, INTERMEDIATE or INTERMEDIATE CONDITION MET) may also
+- optionally contain the Status for the data transfer. As Sense Data
+- cannot be sent together with the Command Status, if the command is
+- completed with an error, then the response and sense data MUST be
+- sent in a SCSI Response PDU (i.e., MUST NOT be sent in a SCSI Data
+- packet). If Status is sent with the data, then a SCSI Response PDU
+- MUST NOT be sent as this would violate SCSI rules (a single status).
+- For Bidirectional commands, the status MUST be sent in a SCSI
+- Response PDU.
+-
+- bit 2-4 - Reserved.
+-
+- bit 5-6 - used the same as in a SCSI Response. These bits are
+- only valid when S is set to 1. For details see Section
+- 10.4.1 Flags (byte 1).
+-
+- bit 7 S (status)- set to indicate that the Command Status field
+- contains status. If this bit is set to 1, the F bit
+- MUST also be set to 1.
+-
+- The fields StatSN, Status, and Residual Count only have meaningful
+- content if the S bit is set to 1 and their values are defined in
+- Section 10.4 SCSI Response.
+-
+-10.7.4. Target Transfer Tag and LUN
+-
+- On outgoing data, the Target Transfer Tag is provided to the target
+- if the transfer is honoring an R2T. In this case, the Target
+- Transfer Tag field is a replica of the Target Transfer Tag provided
+- with the R2T.
+-
+- On incoming data, the Target Transfer Tag and LUN MUST be provided by
+- the target if the A bit is set to 1; otherwise they are reserved.
+- The Target Transfer Tag and LUN are copied by the initiator into the
+- SNACK of type DataACK that it issues as a result of receiving a SCSI
+- Data-In PDU with the A bit set to 1.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 140]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The Target Transfer Tag values are not specified by this protocol
+- except that the value 0xffffffff is reserved and means that the
+- Target Transfer Tag is not supplied. If the Target Transfer Tag is
+- provided, then the LUN field MUST hold a valid value and be
+- consistent with whatever was specified with the command; otherwise,
+- the LUN field is reserved.
+-
+-10.7.5. DataSN
+-
+- For input (read) or bidirectional Data-In PDUs, the DataSN is the
+- input PDU number within the data transfer for the command identified
+- by the Initiator Task Tag.
+-
+- R2T and Data-In PDUs, in the context of bidirectional commands, share
+- the numbering sequence (see Section 3.2.2.3 Data Sequencing).
+-
+- For output (write) data PDUs, the DataSN is the Data-Out PDU number
+- within the current output sequence. The current output sequence is
+- either identified by the Initiator Task Tag (for unsolicited data) or
+- is a data sequence generated for one R2T (for data solicited through
+- R2T).
+-
+-10.7.6. Buffer Offset
+-
+- The Buffer Offset field contains the offset of this PDU payload data
+- within the complete data transfer. The sum of the buffer offset and
+- length should not exceed the expected transfer length for the
+- command.
+-
+- The order of data PDUs within a sequence is determined by
+- DataPDUInOrder. When set to Yes, it means that PDUs have to be in
+- increasing Buffer Offset order and overlays are forbidden.
+-
+- The ordering between sequences is determined by DataSequenceInOrder.
+- When set to Yes, it means that sequences have to be in increasing
+- Buffer Offset order and overlays are forbidden.
+-
+-10.7.7. DataSegmentLength
+-
+- This is the data payload length of a SCSI Data-In or SCSI Data-Out
+- PDU. The sending of 0 length data segments should be avoided, but
+- initiators and targets MUST be able to properly receive 0 length data
+- segments.
+-
+- The Data Segments of Data-In and Data-Out PDUs SHOULD be filled to
+- the integer number of 4 byte words (real payload) unless the F bit is
+- set to 1.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 141]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.8. Ready To Transfer (R2T)
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x31 |1| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Target Transfer Tag |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36| R2TSN |
+- +---------------+---------------+---------------+---------------+
+- 40| Buffer Offset |
+- +---------------+---------------+---------------+---------------+
+- 44| Desired Data Transfer Length |
+- +---------------------------------------------------------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+- When an initiator has submitted a SCSI Command with data that passes
+- from the initiator to the target (WRITE), the target may specify
+- which blocks of data it is ready to receive. The target may request
+- that the data blocks be delivered in whichever order is convenient
+- for the target at that particular instant. This information is
+- passed from the target to the initiator in the Ready To Transfer
+- (R2T) PDU.
+-
+- In order to allow write operations without an explicit initial R2T,
+- the initiator and target MUST have negotiated the key InitialR2T to
+- No during Login.
+-
+- An R2T MAY be answered with one or more SCSI Data-Out PDUs with a
+- matching Target Transfer Tag. If an R2T is answered with a single
+- Data-Out PDU, the Buffer Offset in the Data PDU MUST be the same as
+-
+-
+-
+-Satran, et al. Standards Track [Page 142]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- the one specified by the R2T, and the data length of the Data PDU
+- MUST be the same as the Desired Data Transfer Length specified in the
+- R2T. If the R2T is answered with a sequence of Data PDUs, the Buffer
+- Offset and Length MUST be within the range of those specified by R2T,
+- and the last PDU MUST have the F bit set to 1. If the last PDU
+- (marked with the F bit) is received before the Desired Data Transfer
+- Length is transferred, a target MAY choose to Reject that
+-
+- PDU with "Protocol error" reason code. DataPDUInOrder governs the
+- Data-Out PDU ordering. If DataPDUInOrder is set to Yes, the Buffer
+- Offsets and Lengths for consecutive PDUs MUST form a continuous
+- non-overlapping range and the PDUs MUST be sent in increasing offset
+- order.
+-
+- The target may send several R2T PDUs. It, therefore, can have a
+- number of pending data transfers. The number of outstanding R2T PDUs
+- are limited by the value of the negotiated key MaxOutstandingR2T.
+- Within a connection, outstanding R2Ts MUST be fulfilled by the
+- initiator in the order in which they were received.
+-
+- R2T PDUs MAY also be used to recover Data Out PDUs. Such an R2T
+- (Recovery-R2T) is generated by a target upon detecting the loss of
+- one or more Data-Out PDUs due to:
+-
+- - Digest error
+- - Sequence error
+- - Sequence reception timeout
+-
+- A Recovery-R2T carries the next unused R2TSN, but requests part of or
+- the entire data burst that an earlier R2T (with a lower R2TSN) had
+- already requested.
+-
+- DataSequenceInOrder governs the buffer offset ordering in consecutive
+- R2Ts. If DataSequenceInOrder is Yes, then consecutive R2Ts MUST
+- refer to continuous non-overlapping ranges except for Recovery-R2Ts.
+-
+-10.8.1. TotalAHSLength and DataSegmentLength
+-
+- For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+-
+-10.8.2. R2TSN
+-
+- R2TSN is the R2T PDU input PDU number within the command identified
+- by the Initiator Task Tag.
+-
+- For bidirectional commands R2T and Data-In PDUs share the input PDU
+- numbering sequence (see Section 3.2.2.3 Data Sequencing).
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 143]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.8.3. StatSN
+-
+- The StatSN field will contain the next StatSN. The StatSN for this
+- connection is not advanced after this PDU is sent.
+-
+-10.8.4. Desired Data Transfer Length and Buffer Offset
+-
+- The target specifies how many bytes it wants the initiator to send
+- because of this R2T PDU. The target may request the data from the
+- initiator in several chunks, not necessarily in the original order of
+- the data. The target, therefore, also specifies a Buffer Offset that
+- indicates the point at which the data transfer should begin, relative
+- to the beginning of the total data transfer. The Desired Data
+- Transfer Length MUST NOT be 0 and MUST not exceed MaxBurstLength.
+-
+-10.8.5. Target Transfer Tag
+-
+- The target assigns its own tag to each R2T request that it sends to
+- the initiator. This tag can be used by the target to easily identify
+- the data it receives. The Target Transfer Tag and LUN are copied in
+- the outgoing data PDUs and are only used by the target. There is no
+- protocol rule about the Target Transfer Tag except that the value
+- 0xffffffff is reserved and MUST NOT be sent by a target in an R2T.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 144]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.9. Asynchronous Message
+-
+- An Asynchronous Message may be sent from the target to the initiator
+- without correspondence to a particular command. The target specifies
+- the reason for the event and sense data.
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x32 |1| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN or Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 20| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36| AsyncEvent | AsyncVCode | Parameter1 or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 40| Parameter2 or Reserved | Parameter3 or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 44| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+- / DataSegment - Sense Data and iSCSI Event Data /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- | Data-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+- Some Asynchronous Messages are strictly related to iSCSI while others
+- are related to SCSI [SAM2].
+-
+- StatSN counts this PDU as an acknowledgeable event (StatSN is
+- advanced), which allows for initiator and target state
+- synchronization.
+-
+-
+-
+-Satran, et al. Standards Track [Page 145]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.9.1. AsyncEvent
+-
+- The codes used for iSCSI Asynchronous Messages (events) are:
+-
+- 0 - a SCSI Asynchronous Event is reported in the sense data.
+- Sense Data that accompanies the report, in the data segment,
+- identifies the condition. The sending of a SCSI Event
+- (Asynchronous Event Reporting in SCSI terminology) is
+- dependent on the target support for SCSI asynchronous event
+- reporting (see [SAM2]) as indicated in the standard INQUIRY
+- data (see [SPC3]). Its use may be enabled by parameters in
+- the SCSI Control mode page (see [SPC3]).
+-
+- 1 - target requests Logout. This Async Message MUST be sent on
+- the same connection as the one requesting to be logged out.
+- The initiator MUST honor this request by issuing a Logout as
+- early as possible, but no later than Parameter3 seconds.
+- Initiator MUST send a Logout with a reason code of "Close the
+- connection" OR "Close the session" to close all the
+- connections. Once this message is received, the initiator
+- SHOULD NOT issue new iSCSI commands on the connection to be
+- logged out. The target MAY reject any new I/O requests that
+- it receives after this Message with the reason code "Waiting
+- for Logout". If the initiator does not Logout in Parameter3
+- seconds, the target should send an Async PDU with iSCSI event
+- code "Dropped the connection" if possible, or simply terminate
+- the transport connection. Parameter1 and Parameter2 are
+- reserved.
+-
+- 2 - target indicates it will drop the connection. The Parameter1
+- field indicates the CID of the connection that is going to be
+- dropped.
+-
+- The Parameter2 field (Time2Wait) indicates, in seconds, the
+- minimum time to wait before attempting to reconnect or
+- reassign.
+-
+- The Parameter3 field (Time2Retain) indicates the maximum time
+- allowed to reassign commands after the initial wait (in
+- Parameter2).
+-
+- If the initiator does not attempt to reconnect and/or reassign
+- the outstanding commands within the time specified by
+- Parameter3, or if Parameter3 is 0, the target will terminate
+- all outstanding commands on this connection. In this case, no
+- other responses should be expected from the target for the
+- outstanding commands on this connection.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 146]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A value of 0 for Parameter2 indicates that reconnect can be
+- attempted immediately.
+-
+- 3 - target indicates it will drop all the connections of this
+- session.
+-
+- Parameter1 field is reserved.
+-
+- The Parameter2 field (Time2Wait) indicates, in seconds, the
+- minimum time to wait before attempting to reconnect. The
+- Parameter3 field (Time2Retain) indicates the maximum time
+- allowed to reassign commands after the initial wait (in
+- Parameter2).
+-
+- If the initiator does not attempt to reconnect and/or reassign
+- the outstanding commands within the time specified by
+- Parameter3, or if Parameter3 is 0, the session is terminated.
+-
+- In this case, the target will terminate all outstanding
+- commands in this session; no other responses should be
+- expected from the target for the outstanding commands in this
+- session. A value of 0 for Parameter2 indicates that reconnect
+- can be attempted immediately.
+-
+- 4 - target requests parameter negotiation on this connection. The
+- initiator MUST honor this request by issuing a Text Request
+- (that can be empty) on the same connection as early as
+- possible, but no later than Parameter3 seconds, unless a Text
+- Request is already pending on the connection, or by issuing a
+- Logout Request. If the initiator does not issue a Text
+- Request the target may reissue the Asynchronous Message
+- requesting parameter negotiation.
+-
+- 255 - vendor specific iSCSI Event. The AsyncVCode details the
+- vendor code, and data MAY accompany the report.
+-
+- All other event codes are reserved.
+-
+-10.9.2. AsyncVCode
+-
+- AsyncVCode is a vendor specific detail code that is only valid if the
+- AsyncEvent field indicates a vendor specific event. Otherwise, it is
+- reserved.
+-
+-10.9.3. LUN
+-
+- The LUN field MUST be valid if AsyncEvent is 0. Otherwise, this
+- field is reserved.
+-
+-
+-
+-Satran, et al. Standards Track [Page 147]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.9.4. Sense Data and iSCSI Event Data
+-
+- For a SCSI event, this data accompanies the report in the data
+- segment and identifies the condition.
+-
+- For an iSCSI event, additional vendor-unique data MAY accompany the
+- Async event. Initiators MAY ignore the data when not understood
+- while processing the rest of the PDU.
+-
+- If the DataSegmentLength is not 0, the format of the DataSegment is
+- as follows:
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|SenseLength | Sense Data |
+- +---------------+---------------+---------------+---------------+
+- x/ Sense Data /
+- +---------------+---------------+---------------+---------------+
+- y/ iSCSI Event Data /
+- / /
+- +---------------+---------------+---------------+---------------+
+- z|
+-
+-10.9.4.1. SenseLength
+-
+- This is the length of Sense Data. When the Sense Data field is empty
+- (e.g., the event is not a SCSI event) SenseLength is 0.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 148]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.10. Text Request
+-
+- The Text Request is provided to allow for the exchange of information
+- and for future extensions. It permits the initiator to inform a
+- target of its capabilities or to request some special operations.
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|I| 0x04 |F|C| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN or Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Target Transfer Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 24| CmdSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpStatSN |
+- +---------------+---------------+---------------+---------------+
+- 32/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+- / DataSegment (Text) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- | Data-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+- An initiator MUST have at most one outstanding Text Request on a
+- connection at any given time.
+-
+- On a connection failure, an initiator must either explicitly abort
+- any active allegiant text negotiation task or must cause such a task
+- to be implicitly terminated by the target.
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 149]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.10.1. F (Final) Bit
+-
+- When set to 1, indicates that this is the last or only text request
+- in a sequence of Text Requests; otherwise, it indicates that more
+- Text Requests will follow.
+-
+-10.10.2. C (Continue) Bit
+-
+- When set to 1, indicates that the text (set of key=value pairs) in
+- this Text Request is not complete (it will be continued on subsequent
+- Text Requests); otherwise, it indicates that this Text Request ends a
+- set of key=value pairs. A Text Request with the C bit set to 1 MUST
+- have the F bit set to 0.
+-
+-10.10.3. Initiator Task Tag
+-
+- The initiator assigned identifier for this Text Request. If the
+- command is sent as part of a sequence of text requests and responses,
+- the Initiator Task Tag MUST be the same for all the requests within
+- the sequence (similar to linked SCSI commands). The I bit for all
+- requests in a sequence also MUST be the same.
+-
+-10.10.4. Target Transfer Tag
+-
+- When the Target Transfer Tag is set to the reserved value 0xffffffff,
+- it tells the target that this is a new request and the target resets
+- any internal state associated with the Initiator Task Tag (resets the
+- current negotiation state).
+-
+- The target sets the Target Transfer Tag in a text response to a value
+- other than the reserved value 0xffffffff whenever it indicates that
+- it has more data to send or more operations to perform that are
+- associated with the specified Initiator Task Tag. It MUST do so
+- whenever it sets the F bit to 0 in the response. By copying the
+- Target Transfer Tag from the response to the next Text Request, the
+- initiator tells the target to continue the operation for the specific
+- Initiator Task Tag. The initiator MUST ignore the Target Transfer
+- Tag in the Text Response when the F bit is set to 1.
+-
+- This mechanism allows the initiator and target to transfer a large
+- amount of textual data over a sequence of text-command/text-response
+- exchanges, or to perform extended negotiation sequences.
+-
+- If the Target Transfer Tag is not 0xffffffff, the LUN field MUST be
+- sent by the target in the Text Response.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 150]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A target MAY reset its internal negotiation state if an exchange is
+- stalled by the initiator for a long time or if it is running out of
+- resources.
+-
+- Long text responses are handled as in the following example:
+-
+- I->T Text SendTargets=All (F=1,TTT=0xffffffff)
+- T->I Text <part 1> (F=0,TTT=0x12345678)
+- I->T Text <empty> (F=1, TTT=0x12345678)
+- T->I Text <part 2> (F=0, TTT=0x12345678)
+- I->T Text <empty> (F=1, TTT=0x12345678)
+- ...
+- T->I Text <part n> (F=1, TTT=0xffffffff)
+-
+-10.10.5. Text
+-
+- The data lengths of a text request MUST NOT exceed the iSCSI target
+- MaxRecvDataSegmentLength (a per connection and per direction
+- negotiated parameter). The text format is specified in Section 5.2
+- Text Mode Negotiation.
+-
+- Chapter 11 and Chapter 12 list some basic Text key=value pairs, some
+- of which can be used in Login Request/Response and some in Text
+- Request/Response.
+-
+- A key=value pair can span Text request or response boundaries. A
+- key=value pair can start in one PDU and continue on the next. In
+- other words the end of a PDU does not necessarily signal the end of a
+- key=value pair.
+-
+- The target responds by sending its response back to the initiator.
+- The response text format is similar to the request text format. The
+- text response MAY refer to key=value pairs presented in an earlier
+- text request and the text in the request may refer to earlier
+- responses.
+-
+- Chapter 5 details the rules for the Text Requests and Responses.
+-
+- Text operations are usually meant for parameter setting/
+- negotiations, but can also be used to perform some long lasting
+- operations.
+-
+- Text operations that take a long time should be placed in their own
+- Text request.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 151]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.11. Text Response
+-
+- The Text Response PDU contains the target's responses to the
+- initiator's Text request. The format of the Text field matches that
+- of the Text request.
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x24 |F|C| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN or Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Target Transfer Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+- / DataSegment (Text) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- | Data-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+-10.11.1. F (Final) Bit
+-
+- When set to 1, in response to a Text Request with the Final bit set
+- to 1, the F bit indicates that the target has finished the whole
+- operation. Otherwise, if set to 0 in response to a Text Request with
+- the Final Bit set to 1, it indicates that the target has more work to
+- do (invites a follow-on text request). A Text Response with the F
+- bit set to 1 in response to a Text Request with the F bit set to 0 is
+- a protocol error.
+-
+-
+-
+-Satran, et al. Standards Track [Page 152]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A Text Response with the F bit set to 1 MUST NOT contain key=value
+- pairs that may require additional answers from the initiator.
+-
+- A Text Response with the F bit set to 1 MUST have a Target Transfer
+- Tag field set to the reserved value of 0xffffffff.
+-
+- A Text Response with the F bit set to 0 MUST have a Target Transfer
+- Tag field set to a value other than the reserved 0xffffffff.
+-
+-10.11.2. C (Continue) Bit
+-
+- When set to 1, indicates that the text (set of key=value pairs) in
+- this Text Response is not complete (it will be continued on
+- subsequent Text Responses); otherwise, it indicates that this Text
+- Response ends a set of key=value pairs. A Text Response with the C
+- bit set to 1 MUST have the F bit set to 0.
+-
+-10.11.3. Initiator Task Tag
+-
+- The Initiator Task Tag matches the tag used in the initial Text
+- Request.
+-
+-10.11.4. Target Transfer Tag
+-
+- When a target has more work to do (e.g., cannot transfer all the
+- remaining text data in a single Text Response or has to continue the
+- negotiation) and has enough resources to proceed, it MUST set the
+- Target Transfer Tag to a value other than the reserved value of
+- 0xffffffff. Otherwise, the Target Transfer Tag MUST be set to
+- 0xffffffff.
+-
+- When the Target Transfer Tag is not 0xffffffff, the LUN field may be
+- significant.
+-
+- The initiator MUST copy the Target Transfer Tag and LUN in its next
+- request to indicate that it wants the rest of the data.
+-
+- When the target receives a Text Request with the Target Transfer Tag
+- set to the reserved value of 0xffffffff, it resets its internal
+- information (resets state) associated with the given Initiator Task
+- Tag (restarts the negotiation).
+-
+- When a target cannot finish the operation in a single Text Response,
+- and does not have enough resources to continue, it rejects the Text
+- Request with the appropriate Reject code.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 153]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A target may reset its internal state associated with an Initiator
+- Task Tag (the current negotiation state), state expressed through the
+- Target Transfer Tag if the initiator fails to continue the exchange
+- for some time. The target may reject subsequent Text Requests with
+- the Target Transfer Tag set to the "stale" value.
+-
+-10.11.5. StatSN
+-
+- The target StatSN variable is advanced by each Text Response sent.
+-
+-10.11.6. Text Response Data
+-
+- The data lengths of a text response MUST NOT exceed the iSCSI
+- initiator MaxRecvDataSegmentLength (a per connection and per
+- direction negotiated parameter).
+-
+- The text in the Text Response Data is governed by the same rules as
+- the text in the Text Request Data (see Section 10.10.5 Text).
+-
+- Although the initiator is the requesting party and controls the
+- request-response initiation and termination, the target can offer
+- key=value pairs of its own as part of a sequence and not only in
+- response to the initiator.
+-
+-10.12. Login Request
+-
+- After establishing a TCP connection between an initiator and a
+- target, the initiator MUST start a Login Phase to gain further access
+- to the target's resources.
+-
+- The Login Phase (see Chapter 5) consists of a sequence of Login
+- Requests and Responses that carry the same Initiator Task Tag.
+-
+- Login Requests are always considered as immediate.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 154]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|1| 0x03 |T|C|.|.|CSG|NSG| Version-max | Version-min |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| ISID |
+- + +---------------+---------------+
+- 12| | TSIH |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| CID | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 24| CmdSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpStatSN or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 32| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 36| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 40/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48/ DataSegment - Login Parameters in Text request Format /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+-
+-10.12.1. T (Transit) Bit
+-
+- If set to 1, indicates that the initiator is ready to transit to the
+- next stage.
+-
+- If the T bit is set to 1 and NSG is FullFeaturePhase, then this also
+- indicates that the initiator is ready for the Final Login Response
+- (see Chapter 5).
+-
+-10.12.2. C (Continue) Bit
+-
+- When set to 1, indicates that the text (set of key=value pairs) in
+- this Login Request is not complete (it will be continued on
+- subsequent Login Requests); otherwise, it indicates that this Login
+- Request ends a set of key=value pairs. A Login Request with the C
+- bit set to 1 MUST have the T bit set to 0.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 155]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.12.3. CSG and NSG
+-
+- Through these fields, Current Stage (CSG) and Next Stage (NSG), the
+- Login negotiation requests and responses are associated with a
+- specific stage in the session (SecurityNegotiation,
+- LoginOperationalNegotiation, FullFeaturePhase) and may indicate the
+- next stage to which they want to move (see Chapter 5). The next
+- stage value is only valid when the T bit is 1; otherwise, it is
+- reserved.
+-
+- The stage codes are:
+-
+- - 0 - SecurityNegotiation
+- - 1 - LoginOperationalNegotiation
+- - 3 - FullFeaturePhase
+-
+- All other codes are reserved.
+-
+-10.12.4. Version
+-
+- The version number of the current draft is 0x00. As such, all
+- devices MUST carry version 0x00 for both Version-min and Version-max.
+-
+-10.12.4.1. Version-max
+-
+- Maximum Version number supported.
+-
+- All Login Requests within the Login Phase MUST carry the same
+- Version-max.
+-
+- The target MUST use the value presented with the first Login Request.
+-
+-10.12.4.2. Version-min
+-
+- All Login Requests within the Login Phase MUST carry the same
+- Version-min. The target MUST use the value presented with the first
+- Login Request.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 156]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.12.5. ISID
+-
+- This is an initiator-defined component of the session identifier and
+- is structured as follows (see [RFC3721] and Section 9.1.1
+- Conservative Reuse of ISIDs for details):
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 8| T | A | B | C |
+- +---------------+---------------+---------------+---------------+
+- 12| D |
+- +---------------+---------------+
+-
+- The T field identifies the format and usage of A, B, C, and D as
+- indicated below:
+-
+- T
+-
+- 00b OUI-Format
+- A&B are a 22 bit OUI
+- (the I/G & U/L bits are omitted)
+- C&D 24 bit qualifier
+- 01b EN - Format (IANA Enterprise Number)
+- A - Reserved
+- B&C EN (IANA Enterprise Number)
+- D - Qualifier
+- 10b "Random"
+- A - Reserved
+- B&C Random
+- D - Qualifier
+- 11b A,B,C&D Reserved
+-
+- For the T field values 00b and 01b, a combination of A and B (for
+- 00b) or B and C (for 01b) identifies the vendor or organization whose
+- component (software or hardware) generates this ISID. A vendor or
+- organization with one or more OUIs, or one or more Enterprise
+- Numbers, MUST use at least one of these numbers and select the
+- appropriate value for the T field when its components generate ISIDs.
+- An OUI or EN MUST be set in the corresponding fields in network byte
+- order (byte big-endian).
+-
+- If the T field is 10b, B and C are set to a random 24-bit unsigned
+- integer value in network byte order (byte big-endian). See [RFC3721]
+- for how this affects the principle of "conservative reuse".
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 157]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The Qualifier field is a 16 or 24-bit unsigned integer value that
+- provides a range of possible values for the ISID within the selected
+- namespace. It may be set to any value within the constraints
+- specified in the iSCSI protocol (see Section 3.4.3 Consequences of
+- the Model and Section 9.1.1 Conservative Reuse of ISIDs).
+-
+- The T field value of 11b is reserved.
+-
+- If the ISID is derived from something assigned to a hardware adapter
+- or interface by a vendor, as a preset default value, it MUST be
+- configurable to a value assigned according to the SCSI port behavior
+- desired by the system in which it is installed (see Section 9.1.1
+- Conservative Reuse of ISIDs and Section 9.1.2 iSCSI Name, ISID, and
+- TPGT Use). The resultant ISID MUST also be persistent over power
+- cycles, reboot, card swap, etc.
+-
+-10.12.6. TSIH
+-
+- TSIH must be set in the first Login Request. The reserved value 0
+- MUST be used on the first connection for a new session. Otherwise,
+- the TSIH sent by the target at the conclusion of the successful login
+- of the first connection for this session MUST be used. The TSIH
+- identifies to the target the associated existing session for this new
+- connection.
+-
+- All Login Requests within a Login Phase MUST carry the same TSIH.
+-
+- The target MUST check the value presented with the first Login
+- Request and act as specified in Section 5.3.1 Login Phase Start.
+-
+-10.12.7. Connection ID - CID
+-
+- A unique ID for this connection within the session.
+-
+- All Login Requests within the Login Phase MUST carry the same CID.
+-
+- The target MUST use the value presented with the first Login Request.
+-
+- A Login Request with a non-zero TSIH and a CID equal to that of an
+- existing connection implies a logout of the connection followed by a
+- Login (see Section 5.3.4 Connection Reinstatement). For the details
+- of the implicit Logout Request, see Section 10.14 Logout Request.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 158]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.12.8. CmdSN
+-
+- CmdSN is either the initial command sequence number of a session (for
+- the first Login Request of a session - the "leading" login), or the
+- command sequence number in the command stream if the login is for a
+- new connection in an existing session.
+-
+- Examples:
+-
+- - Login on a leading connection - if the leading login carries
+- the CmdSN 123, all other Login Requests in the same Login Phase
+- carry the CmdSN 123 and the first non-immediate command in
+- FullFeaturePhase also carries the CmdSN 123.
+-
+- - Login on other than a leading connection - if the current CmdSN
+- at the time the first login on the connection is issued is 500,
+- then that PDU carries CmdSN=500. Subsequent Login Requests
+- that are needed to complete this Login Phase may carry a CmdSN
+- higher than 500 if non-immediate requests that were issued on
+- other connections in the same session advance CmdSN.
+-
+- If the Login Request is a leading Login Request, the target MUST use
+- the value presented in CmdSN as the target value for ExpCmdSN.
+-
+-10.12.9. ExpStatSN
+-
+- For the first Login Request on a connection this is ExpStatSN for the
+- old connection and this field is only valid if the Login Request
+- restarts a connection (see Section 5.3.4 Connection Reinstatement).
+-
+- For subsequent Login Requests it is used to acknowledge the Login
+- Responses with their increasing StatSN values.
+-
+-10.12.10. Login Parameters
+-
+- The initiator MUST provide some basic parameters in order to enable
+- the target to determine if the initiator may use the target's
+- resources and the initial text parameters for the security exchange.
+-
+- All the rules specified in Section 10.10.5 Text for text requests
+- also hold for Login Requests. Keys and their explanations are listed
+- in Chapter 11 (security negotiation keys) and Chapter 12 (operational
+- parameter negotiation keys). All keys in Chapter 12, except for the
+- X extension formats, MUST be supported by iSCSI initiators and
+- targets. Keys in Chapter 11 only need to be supported when the
+- function to which they refer is mandatory to implement.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 159]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.13. Login Response
+-
+- The Login Response indicates the progress and/or end of the Login
+- Phase.
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x23 |T|C|.|.|CSG|NSG| Version-max | Version-active|
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| ISID |
+- + +---------------+---------------+
+- 12| | TSIH |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36| Status-Class | Status-Detail | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 40/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48/ DataSegment - Login Parameters in Text request Format /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+-
+-10.13.1. Version-max
+-
+- This is the highest version number supported by the target.
+-
+- All Login Responses within the Login Phase MUST carry the same
+- Version-max.
+-
+- The initiator MUST use the value presented as a response to the first
+- Login Request.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 160]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.13.2. Version-active
+-
+- Indicates the highest version supported by the target and initiator.
+- If the target does not support a version within the range specified
+- by the initiator, the target rejects the login and this field
+- indicates the lowest version supported by the target.
+-
+- All Login Responses within the Login Phase MUST carry the same
+- Version-active.
+-
+- The initiator MUST use the value presented as a response to the first
+- Login Request.
+-
+-10.13.3. TSIH
+-
+- The TSIH is the target assigned session identifying handle. Its
+- internal format and content are not defined by this protocol except
+- for the value 0 that is reserved. With the exception of the Login
+- Final-Response in a new session, this field should be set to the TSIH
+- provided by the initiator in the Login Request. For a new session,
+- the target MUST generate a non-zero TSIH and ONLY return it in the
+- Login Final-Response (see Section 5.3 Login Phase).
+-
+-10.13.4. StatSN
+-
+- For the first Login Response (the response to the first Login
+- Request), this is the starting status Sequence Number for the
+- connection. The next response of any kind, including the next Login
+- Response, if any, in the same Login Phase, will carry this number +
+- 1. This field is only valid if the Status-Class is 0.
+-
+-10.13.5. Status-Class and Status-Detail
+-
+- The Status returned in a Login Response indicates the execution
+- status of the Login Phase. The status includes:
+-
+- Status-Class
+- Status-Detail
+-
+- 0 Status-Class indicates success.
+-
+- A non-zero Status-Class indicates an exception. In this case,
+- Status-Class is sufficient for a simple initiator to use when
+- handling exceptions, without having to look at the Status-Detail.
+- The Status-Detail allows finer-grained exception handling for more
+- sophisticated initiators and for better information for logging.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 161]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The status classes are as follows:
+-
+- 0 - Success - indicates that the iSCSI target successfully
+- received, understood, and accepted the request. The numbering
+- fields (StatSN, ExpCmdSN, MaxCmdSN) are only valid if
+- Status-Class is 0.
+-
+- 1 - Redirection - indicates that the initiator must take further
+- action to complete the request. This is usually due to the
+- target moving to a different address. All of the redirection
+- status class responses MUST return one or more text key
+- parameters of the type "TargetAddress", which indicates the
+- target's new address. A redirection response MAY be issued by
+- a target prior or after completing a security negotiation if a
+- security negotiation is required. A redirection SHOULD be
+- accepted by an initiator even without having the target
+- complete a security negotiation if any security negotiation is
+- required, and MUST be accepted by the initiator after the
+- completion of the security negotiation if any security
+- negotiation is required.
+-
+- 2 - Initiator Error (not a format error) - indicates that the
+- initiator most likely caused the error. This MAY be due to a
+- request for a resource for which the initiator does not have
+- permission. The request should not be tried again.
+-
+- 3 - Target Error - indicates that the target sees no errors in the
+- initiator's Login Request, but is currently incapable of
+- fulfilling the request. The initiator may re-try the same
+- Login Request later.
+-
+- The table below shows all of the currently allocated status codes.
+- The codes are in hexadecimal; the first byte is the status class and
+- the second byte is the status detail.
+-
+- -----------------------------------------------------------------
+- Status | Code | Description
+- |(hex) |
+- -----------------------------------------------------------------
+- Success | 0000 | Login is proceeding OK (*1).
+- -----------------------------------------------------------------
+- Target moved | 0101 | The requested iSCSI Target Name (ITN)
+- temporarily | | has temporarily moved
+- | | to the address provided.
+- -----------------------------------------------------------------
+- Target moved | 0102 | The requested ITN has permanently moved
+- permanently | | to the address provided.
+- -----------------------------------------------------------------
+-
+-
+-
+-Satran, et al. Standards Track [Page 162]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Initiator | 0200 | Miscellaneous iSCSI initiator
+- error | | errors.
+- ----------------------------------------------------------------
+- Authentication| 0201 | The initiator could not be
+- failure | | successfully authenticated or target
+- | | authentication is not supported.
+- -----------------------------------------------------------------
+- Authorization | 0202 | The initiator is not allowed access
+- failure | | to the given target.
+- -----------------------------------------------------------------
+- Not found | 0203 | The requested ITN does not
+- | | exist at this address.
+- -----------------------------------------------------------------
+- Target removed| 0204 | The requested ITN has been removed and
+- | |no forwarding address is provided.
+- -----------------------------------------------------------------
+- Unsupported | 0205 | The requested iSCSI version range is
+- version | | not supported by the target.
+- -----------------------------------------------------------------
+- Too many | 0206 | Too many connections on this SSID.
+- connections | |
+- -----------------------------------------------------------------
+- Missing | 0207 | Missing parameters (e.g., iSCSI
+- parameter | | Initiator and/or Target Name).
+- -----------------------------------------------------------------
+- Can't include | 0208 | Target does not support session
+- in session | | spanning to this connection (address).
+- -----------------------------------------------------------------
+- Session type | 0209 | Target does not support this type of
+- not supported | | of session or not from this Initiator.
+- -----------------------------------------------------------------
+- Session does | 020a | Attempt to add a connection
+- not exist | | to a non-existent session.
+- -----------------------------------------------------------------
+- Invalid during| 020b | Invalid Request type during Login.
+- login | |
+- -----------------------------------------------------------------
+- Target error | 0300 | Target hardware or software error.
+- -----------------------------------------------------------------
+- Service | 0301 | The iSCSI service or target is not
+- unavailable | | currently operational.
+- -----------------------------------------------------------------
+- Out of | 0302 | The target has insufficient session,
+- resources | | connection, or other resources.
+- -----------------------------------------------------------------
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 163]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- (*1) If the response T bit is 1 in both the request and the matching
+- response, and the NSG is FullFeaturePhase in both the request and the
+- matching response, the Login Phase is finished and the initiator may
+- proceed to issue SCSI commands.
+-
+- If the Status Class is not 0, the initiator and target MUST close the
+- TCP connection.
+-
+- If the target wishes to reject the Login Request for more than one
+- reason, it should return the primary reason for the rejection.
+-
+-10.13.6. T (Transit) bit
+-
+- The T bit is set to 1 as an indicator of the end of the stage. If
+- the T bit is set to 1 and NSG is FullFeaturePhase, then this is also
+- the Final Login Response (see Chapter 5). A T bit of 0 indicates a
+- "partial" response, which means "more negotiation needed".
+-
+- A Login Response with a T bit set to 1 MUST NOT contain key=value
+- pairs that may require additional answers from the initiator within
+- the same stage.
+-
+- If the status class is 0, the T bit MUST NOT be set to 1 if the T bit
+- in the request was set to 0.
+-
+-10.13.7. C (Continue) Bit
+-
+- When set to 1, indicates that the text (set of key=value pairs) in
+- this Login Response is not complete (it will be continued on
+- subsequent Login Responses); otherwise, it indicates that this Login
+- Response ends a set of key=value pairs. A Login Response with the C
+- bit set to 1 MUST have the T bit set to 0.
+-
+-10.13.8. Login Parameters
+-
+- The target MUST provide some basic parameters in order to enable the
+- initiator to determine if it is connected to the correct port and the
+- initial text parameters for the security exchange.
+-
+- All the rules specified in Section 10.11.6 Text Response Data for
+- text responses also hold for Login Responses. Keys and their
+- explanations are listed in Chapter 11 (security negotiation keys) and
+- Chapter 12 (operational parameter negotiation keys). All keys in
+- Chapter 12, except for the X extension formats, MUST be supported by
+- iSCSI initiators and targets. Keys in Chapter 11, only need to be
+- supported when the function to which they refer is mandatory to
+- implement.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 164]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.14. Logout Request
+-
+- The Logout Request is used to perform a controlled closing of a
+- connection.
+-
+- An initiator MAY use a Logout Request to remove a connection from a
+- session or to close an entire session.
+-
+- After sending the Logout Request PDU, an initiator MUST NOT send any
+- new iSCSI requests on the closing connection. If the Logout Request
+- is intended to close the session, new iSCSI requests MUST NOT be sent
+- on any of the connections participating in the session.
+-
+- When receiving a Logout Request with the reason code of "close the
+- connection" or "close the session", the target MUST terminate all
+- pending commands, whether acknowledged via ExpCmdSN or not, on that
+- connection or session respectively.
+-
+- When receiving a Logout Request with the reason code "remove
+- connection for recovery", the target MUST discard all requests not
+- yet acknowledged via ExpCmdSN that were issued on the specified
+- connection, and suspend all data/status/R2T transfers on behalf of
+- pending commands on the specified connection.
+-
+- The target then issues the Logout Response and half-closes the TCP
+- connection (sends FIN). After receiving the Logout Response and
+- attempting to receive the FIN (if still possible), the initiator MUST
+- completely close the logging-out connection. For the terminated
+- commands, no additional responses should be expected.
+-
+- A Logout for a CID may be performed on a different transport
+- connection when the TCP connection for the CID has already been
+- terminated. In such a case, only a logical "closing" of the iSCSI
+- connection for the CID is implied with a Logout.
+-
+- All commands that were not terminated or not completed (with status)
+- and acknowledged when the connection is closed completely can be
+- reassigned to a new connection if the target supports connection
+- recovery.
+-
+- If an initiator intends to start recovery for a failing connection,
+- it MUST use the Logout Request to "clean-up" the target end of a
+- failing connection and enable recovery to start, or the Login Request
+- with a non-zero TSIH and the same CID on a new connection for the
+- same effect (see Section 10.14.3 CID). In sessions with a single
+- connection, the connection can be closed and then a new connection
+- reopened. A connection reinstatement login can be used for recovery
+- (see Section 5.3.4 Connection Reinstatement).
+-
+-
+-
+-Satran, et al. Standards Track [Page 165]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A successful completion of a Logout Request with the reason code of
+- "close the connection" or "remove the connection for recovery"
+- results at the target in the discarding of unacknowledged commands
+- received on the connection being logged out. These are commands that
+- have arrived on the connection being logged out, but have not been
+- delivered to SCSI because one or more commands with a smaller CmdSN
+- has not been received by iSCSI. See Section 3.2.2.1 Command
+- Numbering and Acknowledging. The resulting holes the in command
+- sequence numbers will have to be handled by appropriate recovery (see
+- Chapter 6) unless the session is also closed.
+-
+- The entire logout discussion in this section is also applicable for
+- an implicit Logout realized via a connection reinstatement or session
+- reinstatement. When a Login Request performs an implicit Logout, the
+- implicit Logout is performed as if having the reason codes specified
+- below:
+-
+- Reason code Type of implicit Logout
+- -------------------------------------------
+- 0 session reinstatement
+- 1 connection reinstatement when
+- the operational ErrorRecoveryLevel < 2
+- 2 connection reinstatement when
+- the operational ErrorRecoveryLevel = 2
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 166]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|I| 0x06 |1| Reason Code | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------------------------------------------------------+
+- 8/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| CID or Reserved | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 24| CmdSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpStatSN |
+- +---------------+---------------+---------------+---------------+
+- 32/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+-10.14.1. Reason Code
+-
+- Reason Code indicates the reason for Logout as follows:
+-
+- 0 - close the session. All commands associated with the session
+- (if any) are terminated.
+-
+- 1 - close the connection. All commands associated with connection
+- (if any) are terminated.
+-
+- 2 - remove the connection for recovery. Connection is closed and
+- all commands associated with it, if any, are to be prepared
+- for a new allegiance.
+-
+- All other values are reserved.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 167]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.14.2. TotalAHSLength and DataSegmentLength
+-
+- For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+-
+-10.14.3. CID
+-
+- This is the connection ID of the connection to be closed (including
+- closing the TCP stream). This field is only valid if the reason code
+- is not "close the session".
+-
+-10.14.4. ExpStatSN
+-
+- This is the last ExpStatSN value for the connection to be closed.
+-
+-10.14.5. Implicit termination of tasks
+-
+- A target implicitly terminates the active tasks due to the iSCSI
+- protocol in the following cases:
+-
+- a) When a connection is implicitly or explicitly logged out with
+- the reason code of "Close the connection" and there are active
+- tasks allegiant to that connection.
+-
+- b) When a connection fails and eventually the connection state
+- times out (state transition M1 in Section 7.2.2 State
+- Transition Descriptions for Initiators and Targets) and there
+- are active tasks allegiant to that connection.
+-
+- c) When a successful recovery Logout is performed while there are
+- active tasks allegiant to that connection, and those tasks
+- eventually time out after the Time2Wait and Time2Retain
+- periods without allegiance reassignment.
+-
+- d) When a connection is implicitly or explicitly logged out with
+- the reason code of "Close the session" and there are active
+- tasks in that session.
+-
+- If the tasks terminated in any of the above cases are SCSI tasks,
+- they must be internally terminated as if with CHECK CONDITION status.
+- This status is only meaningful for appropriately handling the
+- internal SCSI state and SCSI side effects with respect to ordering
+- because this status is never communicated back as a terminating
+- status to the initiator. However additional actions may have to be
+- taken at SCSI level depending on the SCSI context as defined by the
+- SCSI standards (e.g., queued commands and ACA, in cases a), b), and
+- c), after the tasks are terminated, the target MUST report a Unit
+- Attention condition on the next command processed on any connection
+- for each affected I_T_L nexus with the status of CHECK CONDITION, and
+-
+-
+-
+-Satran, et al. Standards Track [Page 168]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- the ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI
+- PROTOCOL EVENT" - etc. - see [SAM2] and [SPC3]).
+-
+-10.15. Logout Response
+-
+- The Logout Response is used by the target to indicate if the cleanup
+- operation for the connection(s) has completed.
+-
+- After Logout, the TCP connection referred by the CID MUST be closed
+- at both ends (or all connections must be closed if the logout reason
+- was session close).
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x26 |1| Reserved | Response | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------------------------------------------------------+
+- 8/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag |
+- +---------------+---------------+---------------+---------------+
+- 20| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36| Reserved |
+- +---------------------------------------------------------------+
+- 40| Time2Wait | Time2Retain |
+- +---------------+---------------+---------------+---------------+
+- 44| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 169]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.15.1. Response
+-
+- Logout Response:
+-
+- 0 - connection or session closed successfully.
+-
+- 1 - CID not found.
+-
+- 2 - connection recovery is not supported. If Logout reason code
+- was recovery and target does not support it as indicated by the
+- ErrorRecoveryLevel.
+-
+- 3 - cleanup failed for various reasons.
+-
+-10.15.2. TotalAHSLength and DataSegmentLength
+-
+- For this PDU TotalAHSLength and DataSegmentLength MUST be 0.
+-
+-10.15.3. Time2Wait
+-
+- If the Logout Response code is 0 and if the operational
+- ErrorRecoveryLevel is 2, this is the minimum amount of time, in
+- seconds, to wait before attempting task reassignment. If the Logout
+- Response code is 0 and if the operational ErrorRecoveryLevel is less
+- than 2, this field is to be ignored.
+-
+- This field is invalid if the Logout Response code is 1.
+-
+- If the Logout response code is 2 or 3, this field specifies the
+- minimum time to wait before attempting a new implicit or explicit
+- logout.
+-
+- If Time2Wait is 0, the reassignment or a new Logout may be attempted
+- immediately.
+-
+-10.15.4. Time2Retain
+-
+- If the Logout response code is 0 and if the operational
+- ErrorRecoveryLevel is 2, this is the maximum amount of time, in
+- seconds, after the initial wait (Time2Wait), the target waits for the
+- allegiance reassignment for any active task after which the task
+- state is discarded. If the Logout response code is 0 and if the
+- operational ErrorRecoveryLevel is less than 2, this field is to be
+- ignored.
+-
+- This field is invalid if the Logout response code is 1.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 170]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- If the Logout response code is 2 or 3, this field specifies the
+- maximum amount of time, in seconds, after the initial wait
+- (Time2Wait), the target waits for a new implicit or explicit logout.
+-
+- If it is the last connection of a session, the whole session state is
+- discarded after Time2Retain.
+-
+- If Time2Retain is 0, the target has already discarded the connection
+- (and possibly the session) state along with the task states. No
+- reassignment or Logout is required in this case.
+-
+-10.16. SNACK Request
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x10 |1|.|.|.| Type | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN or Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 20| Target Transfer Tag or SNACK Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 24| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpStatSN |
+- +---------------+---------------+---------------+---------------+
+- 32/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 40| BegRun |
+- +---------------------------------------------------------------+
+- 44| RunLength |
+- +---------------------------------------------------------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+- If the implementation supports ErrorRecoveryLevel greater than zero,
+- it MUST support all SNACK types.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 171]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The SNACK is used by the initiator to request the retransmission of
+- numbered-responses, data, or R2T PDUs from the target. The SNACK
+- request indicates the numbered-responses or data "runs" whose
+- retransmission is requested by the target, where the run starts with
+- the first StatSN, DataSN, or R2TSN whose retransmission is requested
+- and indicates the number of Status, Data, or R2T PDUs requested
+- including the first. 0 has special meaning when used as a starting
+- number and length:
+-
+- - When used in RunLength, it means all PDUs starting with the
+- initial.
+- - When used in both BegRun and RunLength, it means all
+- unacknowledged PDUs.
+-
+- The numbered-response(s) or R2T(s), requested by a SNACK, MUST be
+- delivered as exact replicas of the ones that the target transmitted
+- originally except for the fields ExpCmdSN, MaxCmdSN, and ExpDataSN,
+- which MUST carry the current values. R2T(s)requested by SNACK MUST
+- also carry the current value of StatSN.
+-
+- The numbered Data-In PDUs, requested by a Data SNACK MUST be
+- delivered as exact replicas of the ones that the target transmitted
+- originally except for the fields ExpCmdSN and MaxCmdSN, which MUST
+- carry the current values and except for resegmentation (see Section
+- 10.16.3 Resegmentation).
+-
+- Any SNACK that requests a numbered-response, Data, or R2T that was
+- not sent by the target or was already acknowledged by the initiator,
+- MUST be rejected with a reason code of "Protocol error".
+-
+-10.16.1. Type
+-
+- This field encodes the SNACK function as follows:
+-
+- 0-Data/R2T SNACK - requesting retransmission of one or more Data-
+- In or R2T PDUs.
+-
+- 1-Status SNACK - requesting retransmission of one or more numbered
+- responses.
+-
+- 2-DataACK - positively acknowledges Data-In PDUs.
+-
+- 3-R-Data SNACK - requesting retransmission of Data-In PDUs with
+- possible resegmentation and status tagging.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 172]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- All other values are reserved.
+-
+- Data/R2T SNACK, Status SNACK, or R-Data SNACK for a command MUST
+- precede status acknowledgement for the given command.
+-
+-10.16.2. Data Acknowledgement
+-
+- If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST
+- issue a SNACK of type DataACK after receiving a Data-In PDU with the
+- A bit set to 1. However, if the initiator has detected holes in the
+- input sequence, it MUST postpone issuing the SNACK of type DataACK
+- until the holes are filled. An initiator MAY ignore the A bit if it
+- deems that the bit is being set aggressively by the target (i.e.,
+- before the MaxBurstLength limit is reached).
+-
+- The DataACK is used to free resources at the target and not to
+- request or imply data retransmission.
+-
+- An initiator MUST NOT request retransmission for any data it had
+- already acknowledged.
+-
+-10.16.3. Resegmentation
+-
+- If the initiator MaxRecvDataSegmentLength changed between the
+- original transmission and the time the initiator requests
+- retransmission, the initiator MUST issue a R-Data SNACK (see Section
+- 10.16.1 Type). With R-Data SNACK, the initiator indicates that it
+- discards all the unacknowledged data and expects the target to resend
+- it. It also expects resegmentation. In this case, the retransmitted
+- Data-In PDUs MAY be different from the ones originally sent in order
+- to reflect changes in MaxRecvDataSegmentLength. Their DataSN starts
+- with the BegRun of the last DataACK received by the target if any was
+- received; otherwise it starts with 0 and is increased by 1 for each
+- resent Data-In PDU.
+-
+- A target that has received a R-Data SNACK MUST return a SCSI Response
+- that contains a copy of the SNACK Tag field from the R-Data SNACK in
+- the SCSI Response SNACK Tag field as its last or only Response. For
+- example, if it has already sent a response containing another value
+- in the SNACK Tag field or had the status included in the last Data-In
+- PDU, it must send a new SCSI Response PDU. If a target sends more
+- than one SCSI Response PDU due to this rule, all SCSI responses must
+- carry the same StatSN (see Section 10.4.4 SNACK Tag). If an
+- initiator attempts to recover a lost SCSI Response (with a
+- Status SNACK, see Section 10.16.1 Type) when more than one response
+- has been sent, the target will send the SCSI Response with the latest
+- content known to the target, including the last SNACK Tag for the
+- command.
+-
+-
+-
+-Satran, et al. Standards Track [Page 173]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- For considerations in allegiance reassignment of a task to a
+- connection with a different MaxRecvDataSegmentLength, refer to
+- Section 6.2.2 Allegiance Reassignment.
+-
+-10.16.4. Initiator Task Tag
+-
+- For Status SNACK and DataACK, the Initiator Task Tag MUST be set to
+- the reserved value 0xffffffff. In all other cases, the Initiator
+- Task Tag field MUST be set to the Initiator Task Tag of the
+- referenced command.
+-
+-10.16.5. Target Transfer Tag or SNACK Tag
+-
+- For an R-Data SNACK, this field MUST contain a value that is
+- different from 0 or 0xffffffff and is unique for the task (identified
+- by the Initiator Task Tag). This value MUST be copied by the iSCSI
+- target in the last or only SCSI Response PDU it issues for the
+- command.
+-
+- For DataACK, the Target Transfer Tag MUST contain a copy of the
+- Target Transfer Tag and LUN provided with the SCSI Data-In PDU with
+- the A bit set to 1.
+-
+- In all other cases, the Target Transfer Tag field MUST be set to the
+- reserved value of 0xffffffff.
+-
+-10.16.6. BegRun
+-
+- The DataSN, R2TSN, or StatSN of the first PDU whose retransmission is
+- requested (Data/R2T and Status SNACK), or the next expected DataSN
+- (DataACK SNACK).
+-
+- BegRun 0 when used in conjunction with RunLength 0 means resend all
+- unacknowledged Data-In, R2T or Response PDUs.
+-
+- BegRun MUST be 0 for a R-Data SNACK.
+-
+-10.16.7. RunLength
+-
+- The number of PDUs whose retransmission is requested.
+-
+- RunLength 0 signals that all Data-In, R2T, or Response PDUs carrying
+- the numbers equal to or greater than BegRun have to be resent.
+-
+- The RunLength MUST also be 0 for a DataACK SNACK in addition to
+- R-Data SNACK.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 174]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.17. Reject
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x3f |1| Reserved | Reason | Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 16| 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 20| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36| DataSN/R2TSN or Reserved |
+- +---------------+---------------+---------------+---------------+
+- 40| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 44| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+- xx/ Complete Header of Bad PDU /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- yy/Vendor specific data (if any) /
+- / /
+- +---------------+---------------+---------------+---------------+
+- zz| Data-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+- Reject is used to indicate an iSCSI error condition (protocol,
+- unsupported option, etc.).
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 175]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.17.1. Reason
+-
+- The reject Reason is coded as follows:
+-
+- +------+----------------------------------------+------------------+
+- | Code | Explanation | Can the original |
+- | (hex)| | PDU be re-sent? |
+- +------+----------------------------------------+------------------+
+- | 0x01 | Reserved | no |
+- | | | |
+- | 0x02 | Data (payload) Digest Error | yes (Note 1) |
+- | | | |
+- | 0x03 | SNACK Reject | yes |
+- | | | |
+- | 0x04 | Protocol Error (e.g., SNACK request for| no |
+- | | a status that was already acknowledged)| |
+- | | | |
+- | 0x05 | Command not supported | no |
+- | | | |
+- | 0x06 | Immediate Command Reject - too many | yes |
+- | | immediate commands | |
+- | | | |
+- | 0x07 | Task in progress | no |
+- | | | |
+- | 0x08 | Invalid Data ACK | no |
+- | | | |
+- | 0x09 | Invalid PDU field | no (Note 2) |
+- | | | |
+- | 0x0a | Long Operation Reject - Can't generate | yes |
+- | | Target Transfer Tag - out of resources | |
+- | | | |
+- | 0x0b | Negotiation Reset | no |
+- | | | |
+- | 0x0c | Waiting for Logout | no |
+- +------+----------------------------------------+------------------+
+-
+- Note 1: For iSCSI, Data-Out PDU retransmission is only done if the
+- target requests retransmission with a recovery R2T. However, if this
+- is the data digest error on immediate data, the initiator may choose
+- to retransmit the whole PDU including the immediate data.
+-
+- Note 2: A target should use this reason code for all invalid values
+- of PDU fields that are meant to describe a task, a response, or a
+- data transfer. Some examples are invalid TTT/ITT, buffer offset, LUN
+- qualifying a TTT, and an invalid sequence number in a SNACK.
+-
+- All other values for Reason are reserved.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 176]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- In all the cases in which a pre-instantiated SCSI task is terminated
+- because of the reject, the target MUST issue a proper SCSI command
+- response with CHECK CONDITION as described in Section 10.4.3
+- Response. In these cases in which a status for the SCSI task was
+- already sent before the reject, no additional status is required. If
+- the error is detected while data from the initiator is still expected
+- (i.e., the command PDU did not contain all the data and the target
+- has not received a Data-Out PDU with the Final bit set to 1 for the
+- unsolicited data, if any, and all outstanding R2Ts, if any), the
+- target MUST wait until it receives the last expected Data-Out PDUs
+- with the F bit set to 1 before sending the Response PDU.
+-
+- For additional usage semantics of Reject PDU, see Section 6.3 Usage
+- Of Reject PDU in Recovery.
+-
+-10.17.2. DataSN/R2TSN
+-
+- This field is only valid if the rejected PDU is a Data/R2T SNACK and
+- the Reject reason code is "Protocol error" (see Section 10.16 SNACK
+- Request). The DataSN/R2TSN is the next Data/R2T sequence number that
+- the target would send for the task, if any.
+-
+-10.17.3. StatSN, ExpCmdSN and MaxCmdSN
+-
+- These fields carry their usual values and are not related to the
+- rejected command. StatSN is advanced after a Reject.
+-
+-10.17.4. Complete Header of Bad PDU
+-
+- The target returns the header (not including digest) of the PDU in
+- error as the data of the response.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 177]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.18. NOP-Out
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|I| 0x00 |1| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN or Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 20| Target Transfer Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 24| CmdSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpStatSN |
+- +---------------+---------------+---------------+---------------+
+- 32/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+- / DataSegment - Ping Data (optional) /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- | Data-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+- A NOP-Out may be used by an initiator as a "ping request" to verify
+- that a connection/session is still active and all its components are
+- operational. The NOP-In response is the "ping echo".
+-
+- A NOP-Out is also sent by an initiator in response to a NOP-In.
+-
+- A NOP-Out may also be used to confirm a changed ExpStatSN if another
+- PDU will not be available for a long time.
+-
+- 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.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 178]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.18.1. Initiator Task Tag
+-
+- The NOP-Out MUST have the Initiator Task Tag set to a valid value
+- only if a response in the form of NOP-In is requested (i.e., the
+- NOP-Out is used as a ping request). Otherwise, the Initiator Task
+- Tag MUST be set to 0xffffffff.
+-
+- When a target receives the NOP-Out with a valid Initiator Task Tag,
+- it MUST respond with a Nop-In Response (see Section 10.19 NOP-In).
+-
+- If the Initiator Task Tag contains 0xffffffff, the I bit MUST be set
+- to 1 and the CmdSN is not advanced after this PDU is sent.
+-
+-10.18.2. Target Transfer Tag
+-
+- A target assigned identifier for the operation.
+-
+- The NOP-Out MUST only have the Target Transfer Tag set if it is
+- issued in response to a NOP-In with a valid Target Transfer Tag. In
+- this case, it copies the Target Transfer Tag from the NOP-In PDU.
+- Otherwise, the Target Transfer Tag MUST be set to 0xffffffff.
+-
+- When the Target Transfer Tag is set to a value other than 0xffffffff,
+- the LUN field MUST also be copied from the NOP-In.
+-
+-10.18.3. Ping Data
+-
+- Ping data are reflected in the NOP-In Response. The length of the
+- reflected data are limited to MaxRecvDataSegmentLength. The length
+- of ping data are indicated by the DataSegmentLength. 0 is a valid
+- value for the DataSegmentLength and indicates the absence of ping
+- data.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 179]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-10.19. NOP-In
+-
+- Byte/ 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0|.|.| 0x20 |1| Reserved |
+- +---------------+---------------+---------------+---------------+
+- 4|TotalAHSLength | DataSegmentLength |
+- +---------------+---------------+---------------+---------------+
+- 8| LUN or Reserved |
+- + +
+- 12| |
+- +---------------+---------------+---------------+---------------+
+- 16| Initiator Task Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 20| Target Transfer Tag or 0xffffffff |
+- +---------------+---------------+---------------+---------------+
+- 24| StatSN |
+- +---------------+---------------+---------------+---------------+
+- 28| ExpCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 32| MaxCmdSN |
+- +---------------+---------------+---------------+---------------+
+- 36/ Reserved /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- 48| Header-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+- / DataSegment - Return Ping Data /
+- +/ /
+- +---------------+---------------+---------------+---------------+
+- | Data-Digest (Optional) |
+- +---------------+---------------+---------------+---------------+
+-
+- NOP-In is either sent by a target as a response to a NOP-Out, as a
+- "ping" to an initiator, or as a means to carry a changed ExpCmdSN
+- and/or MaxCmdSN if another PDU will not be available for a long time
+- (as determined by the target).
+-
+- When a target receives the NOP-Out with a valid Initiator Task Tag
+- (not the reserved value 0xffffffff), it MUST respond with a NOP-In
+- with the same Initiator Task Tag that was provided in the NOP-Out
+- request. It MUST also duplicate up to the first
+- MaxRecvDataSegmentLength bytes of the initiator provided Ping Data.
+- For such a response, the Target Transfer Tag MUST be 0xffffffff.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 180]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Otherwise, 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 the Data Segment MUST NOT contain any data
+- (DataSegmentLength MUST be 0).
+-
+-10.19.1. Target Transfer Tag
+-
+- If the target is responding to a NOP-Out, this is set to the reserved
+- value 0xffffffff.
+-
+- If the target is sending a NOP-In as a Ping (intending to receive a
+- corresponding NOP-Out), this field is set to a valid value (not the
+- reserved 0xffffffff).
+-
+- If the target is initiating a NOP-In without wanting to receive a
+- corresponding NOP-Out, this field MUST hold the reserved value of
+- 0xffffffff.
+-
+-10.19.2. StatSN
+-
+- The StatSN field will always contain the next StatSN. However, when
+- the Initiator Task Tag is set to 0xffffffff, StatSN for the
+- connection is not advanced after this PDU is sent.
+-
+-10.19.3. LUN
+-
+- A LUN MUST be set to a correct value when the Target Transfer Tag is
+- valid (not the reserved value 0xffffffff).
+-
+-11. iSCSI Security Text Keys and Authentication Methods
+-
+- Only the following keys are used during the SecurityNegotiation stage
+- of the Login Phase:
+-
+- SessionType
+- InitiatorName
+- TargetName
+- TargetAddress
+- InitiatorAlias
+- TargetAlias
+- TargetPortalGroupTag
+- AuthMethod and the keys used by the authentication methods
+- specified under Section 11.1 AuthMethod along with all of
+- their associated keys as well as Vendor Specific
+- Authentication Methods.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 181]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Other keys MUST NOT be used.
+-
+- SessionType, InitiatorName, TargetName, InitiatorAlias, TargetAlias,
+- and TargetPortalGroupTag are described in Chapter 12 as they can be
+- used also in the OperationalNegotiation stage.
+-
+- All security keys have connection-wide applicability.
+-
+-11.1. AuthMethod
+-
+- Use: During Login - Security Negotiation Senders: Initiator and
+- Target Scope: connection
+-
+- AuthMethod = <list-of-values>
+-
+- The main item of security negotiation is the authentication method
+- (AuthMethod).
+-
+- The authentication methods that can be used (appear in the
+- list-of-values) are either those listed in the following table or are
+- vendor-unique methods:
+-
+- +------------------------------------------------------------+
+- | Name | Description |
+- +------------------------------------------------------------+
+- | KRB5 | Kerberos V5 - defined in [RFC1510] |
+- +------------------------------------------------------------+
+- | SPKM1 | Simple Public-Key GSS-API Mechanism |
+- | | defined in [RFC2025] |
+- +------------------------------------------------------------+
+- | SPKM2 | Simple Public-Key GSS-API Mechanism |
+- | | defined in [RFC2025] |
+- +------------------------------------------------------------+
+- | SRP | Secure Remote Password |
+- | | defined in [RFC2945] |
+- +------------------------------------------------------------+
+- | CHAP | Challenge Handshake Authentication Protocol|
+- | | defined in [RFC1994] |
+- +------------------------------------------------------------+
+- | None | No authentication |
+- +------------------------------------------------------------+
+-
+- The AuthMethod selection is followed by an "authentication exchange"
+- specific to the authentication method selected.
+-
+- The authentication method proposal may be made by either the
+- initiator or the target. However the initiator MUST make the first
+- step specific to the selected authentication method as soon as it is
+-
+-
+-
+-Satran, et al. Standards Track [Page 182]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- selected. It follows that if the target makes the authentication
+- method proposal the initiator sends the first keys(s) of the exchange
+- together with its authentication method selection.
+-
+- The authentication exchange authenticates the initiator to the
+- target, and optionally, the target to the initiator. Authentication
+- is OPTIONAL to use but MUST be supported by the target and initiator.
+-
+- The initiator and target MUST implement CHAP. All other
+- authentication methods are OPTIONAL.
+-
+- Private or public extension algorithms MAY also be negotiated for
+- authentication methods. Whenever a private or public extension
+- algorithm is part of the default offer (the offer made in absence of
+- explicit administrative action) the implementer MUST ensure that CHAP
+- is listed as an alternative in the default offer and "None" is not
+- part of the default offer.
+-
+- Extension authentication methods MUST be named using one of the
+- following two formats:
+-
+- a) Z-reversed.vendor.dns_name.do_something=
+- b) Z<#><IANA-registered-string>=
+-
+- Authentication methods named using the Z- format are used as private
+- extensions. Authentication methods named using the Z# format are
+- used as public extensions that must be registered with IANA and MUST
+- be described by an informational RFC.
+-
+- For all of the public or private extension authentication methods,
+- the method specific keys MUST conform to the format specified in
+- Section 5.1 Text Format for standard-label.
+-
+- To identify the vendor for private extension authentication methods,
+- we suggest you use the reversed DNS-name as a prefix to the proper
+- digest names.
+-
+- The part of digest-name following Z- and Z# MUST conform to the
+- format for standard-label specified in Section 5.1 Text Format.
+-
+- Support for public or private extension authentication methods is
+- OPTIONAL.
+-
+- The following subsections define the specific exchanges for each of
+- the standardized authentication methods. As mentioned earlier the
+- first step is always done by the initiator.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 183]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-11.1.1. Kerberos
+-
+- For KRB5 (Kerberos V5) [RFC1510] and [RFC1964], the initiator MUST
+- use:
+-
+- KRB_AP_REQ=<KRB_AP_REQ>
+-
+- where KRB_AP_REQ is the client message as defined in [RFC1510].
+-
+- The default principal name assumed by an iSCSI initiator or target
+- (prior to any administrative configuration action) MUST be the iSCSI
+- Initiator Name or iSCSI Target Name respectively, prefixed by the
+- string "iscsi/".
+-
+- If the initiator authentication fails, the target MUST respond with a
+- Login reject with "Authentication Failure" status. Otherwise, if the
+- initiator has selected the mutual authentication option (by setting
+- MUTUAL-REQUIRED in the ap-options field of the KRB_AP_REQ), the
+- target MUST reply with:
+-
+- KRB_AP_REP=<KRB_AP_REP>
+-
+- where KRB_AP_REP is the server's response message as defined in
+- [RFC1510].
+-
+- If mutual authentication was selected and target authentication
+- fails, the initiator MUST close the connection.
+-
+- KRB_AP_REQ and KRB_AP_REP are binary-values and their binary length
+- (not the length of the character string that represents them in
+- encoded form) MUST not exceed 65536 bytes.
+-
+-11.1.2. Simple Public-Key Mechanism (SPKM)
+-
+- For SPKM1 and SPKM2 [RFC2025], the initiator MUST use:
+-
+- SPKM_REQ=<SPKM-REQ>
+-
+- where SPKM-REQ is the first initiator token as defined in [RFC2025].
+-
+- [RFC2025] defines situations where each side may send an error token
+- that may cause the peer to re-generate and resend its last token.
+- This scheme is followed in iSCSI, and the error token syntax is:
+-
+- SPKM_ERROR=<SPKM-ERROR>
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 184]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- However, SPKM-DEL tokens that are defined by [RFC2025] for fatal
+- errors will not be used by iSCSI. If the target needs to send a
+- SPKM-DEL token, it will, instead, send a Login "login reject" message
+- with the "Authentication Failure" status and terminate the
+- connection. If the initiator needs to send a SPKM-DEL token, it will
+- close the connection.
+-
+- In the following sections, we assume that no SPKM-ERROR tokens are
+- required.
+-
+- If the initiator authentication fails, the target MUST return an
+- error. Otherwise, if the AuthMethod is SPKM1 or if the initiator has
+- selected the mutual authentication option (by setting mutual-state
+- bit in the options field of the REQ-TOKEN in the SPKM-REQ), the
+- target MUST reply with:
+-
+- SPKM_REP_TI=<SPKM-REP-TI>
+-
+- where SPKM-REP-TI is the target token as defined in [RFC2025].
+-
+- If mutual authentication was selected and target authentication
+- fails, the initiator MUST close the connection. Otherwise, if the
+- AuthMethod is SPKM1, the initiator MUST continue with:
+-
+- SPKM_REP_IT=<SPKM-REP-IT>
+-
+- where SPKM-REP-IT is the second initiator token as defined in
+- [RFC2025]. If the initiator authentication fails, the target MUST
+- answer with a Login reject with "Authentication Failure" status.
+-
+- SPKM requires support for very long authentication items.
+-
+- All the SPKM-* tokens are binary-values and their binary length (not
+- the length of the character string that represents them in encoded
+- form) MUST not exceed 65536 bytes.
+-
+-11.1.3. Secure Remote Password (SRP)
+-
+- For SRP [RFC2945], the initiator MUST use:
+-
+- SRP_U=<U> TargetAuth=Yes /* or TargetAuth=No */
+-
+- The target MUST answer with a Login reject with the "Authorization
+- Failure" status or reply with:
+-
+- SRP_GROUP=<G1,G2...> SRP_s=<s>
+-
+- Where G1,G2... are proposed groups, in order of preference.
+-
+-
+-
+-Satran, et al. Standards Track [Page 185]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The initiator MUST either close the connection or continue with:
+-
+- SRP_A=<A> SRP_GROUP=<G>
+-
+- Where G is one of G1,G2... that were proposed by the target.
+-
+- The target MUST answer with a Login reject with the "Authentication
+- Failure" status or reply with:
+-
+- SRP_B=<B>
+-
+- The initiator MUST close the connection or continue with:
+-
+- SRP_M=<M>
+-
+- If the initiator authentication fails, the target MUST answer with a
+- Login reject with "Authentication Failure" status. Otherwise, if the
+- initiator sent TargetAuth=Yes in the first message (requiring target
+- authentication), the target MUST reply with:
+-
+- SRP_HM=<H(A | M | K)>
+-
+- If the target authentication fails, the initiator MUST close the
+- connection.
+-
+- Where U, s, A, B, M, and H(A | M | K) are defined in [RFC2945] (using
+- the SHA1 hash function, such as SRP-SHA1) and G,Gn (Gn stands for
+- G1,G2...) are identifiers of SRP groups specified in [RFC3723]. G,
+- Gn, and U are text strings, s,A,B,M, and H(A | M | K) are
+- binary-values. The length of s,A,B,M and H(A | M | K) in binary form
+- (not the length of the character string that represents them in
+- encoded form) MUST not exceed 1024 bytes.
+-
+- For the SRP_GROUP, all the groups specified in [RFC3723] up to 1536
+- bits (i.e., SRP-768, SRP-1024, SRP-1280, SRP-1536) must be supported
+- by initiators and targets. To guarantee interoperability, targets
+- MUST always offer "SRP-1536" as one of the proposed groups.
+-
+-11.1.4. Challenge Handshake Authentication Protocol (CHAP)
+-
+- For CHAP [RFC1994], in the first step, the initiator MUST send:
+-
+- CHAP_A=<A1,A2...>
+-
+- Where A1,A2... are proposed algorithms, in order of preference.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 186]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- In the second step, the target MUST answer with a Login reject with
+- the "Authentication Failure" status or reply with:
+-
+- CHAP_A=<A> CHAP_I=<I> CHAP_C=<C>
+-
+- Where A is one of A1,A2... that were proposed by the initiator.
+-
+- In the third step, the initiator MUST continue with:
+-
+- CHAP_N=<N> CHAP_R=<R>
+-
+- or, if it requires target authentication, with:
+-
+- CHAP_N=<N> CHAP_R=<R> CHAP_I=<I> CHAP_C=<C>
+-
+- If the initiator authentication fails, the target MUST answer with a
+- Login reject with "Authentication Failure" status. Otherwise, if the
+- initiator required target authentication, the target MUST either
+- answer with a Login reject with "Authentication Failure" or reply
+- with:
+-
+- CHAP_N=<N> CHAP_R=<R>
+-
+- If target authentication fails, the initiator MUST close the
+- connection.
+-
+- Where N, (A,A1,A2), I, C, and R are (correspondingly) the Name,
+- Algorithm, Identifier, Challenge, and Response as defined in
+- [RFC1994], N is a text string, A,A1,A2, and I are numbers, and C and
+- R are large-binary-values and their binary length (not the length of
+- the character string that represents them in encoded form) MUST not
+- exceed 1024 bytes.
+-
+- For the Algorithm, as stated in [RFC1994], one value is required to
+- be implemented:
+-
+- 5 (CHAP with MD5)
+-
+- To guarantee interoperability, initiators MUST always offer it as one
+- of the proposed algorithms.
+-
+-12. Login/Text Operational Text Keys
+-
+- Some session specific parameters MUST only be carried on the leading
+- connection and cannot be changed after the leading connection login
+- (e.g., MaxConnections, the maximum number of connections). This
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 187]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- holds for a single connection session with regard to connection
+- restart. The keys that fall into this category have the use: LO
+- (Leading Only).
+-
+- Keys that can only be used during login have the use: IO (initialize
+- only), while those that can be used in both the Login Phase and Full
+- Feature Phase have the use: ALL.
+-
+- Keys that can only be used during Full Feature Phase use FFPO (Full
+- Feature Phase only).
+-
+- Keys marked as Any-Stage may also appear in the SecurityNegotiation
+- stage while all other keys described in this chapter are operational
+- keys.
+-
+- Keys that do not require an answer are marked as Declarative.
+-
+- Key scope is indicated as session-wide (SW) or connection-only (CO).
+-
+- Result function, wherever mentioned, states the function that can be
+- applied to check the validity of the responder selection. Minimum
+- means that the selected value cannot exceed the offered value.
+- Maximum means that the selected value cannot be lower than the
+- offered value. AND means that the selected value must be a possible
+- result of a Boolean "and" function with an arbitrary Boolean value
+- (e.g., if the offered value is No the selected value must be No). OR
+- means that the selected value must be a possible result of a Boolean
+- "or" function with an arbitrary Boolean value (e.g., if the offered
+- value is Yes the selected value must be Yes).
+-
+-12.1. HeaderDigest and DataDigest
+-
+- Use: IO
+- Senders: Initiator and Target
+- Scope: CO
+-
+- HeaderDigest = <list-of-values>
+- DataDigest = <list-of-values>
+-
+- Default is None for both HeaderDigest and DataDigest.
+-
+- Digests enable the checking of end-to-end, non-cryptographic data
+- integrity beyond the integrity checks provided by the link layers and
+- the covering of the whole communication path including all elements
+- that may change the network level PDUs such as routers, switches, and
+- proxies.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 188]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The following table lists cyclic integrity checksums that can be
+- negotiated for the digests and that MUST be implemented by every
+- iSCSI initiator and target. These digest options only have error
+- detection significance.
+-
+- +---------------------------------------------+
+- | Name | Description | Generator |
+- +---------------------------------------------+
+- | CRC32C | 32 bit CRC |0x11edc6f41|
+- +---------------------------------------------+
+- | None | no digest |
+- +---------------------------------------------+
+-
+- The generator polynomial for this digest is given in
+- hex-notation (e.g., 0x3b stands for 0011 1011 and the polynomial is
+- x**5+X**4+x**3+x+1).
+-
+- When the Initiator and Target agree on a digest, this digest MUST be
+- used for every PDU in Full Feature Phase.
+-
+- Padding bytes, when present in a segment covered by a CRC, SHOULD be
+- set to 0 and are included in the CRC.
+-
+- The CRC MUST be calculated by a method that produces the same
+- results as the following process:
+-
+- - The PDU bits are considered as the coefficients of a
+- polynomial M(x) of degree n-1; bit 7 of the lowest numbered
+- byte is considered the most significant bit (x^n-1), followed
+- by bit 6 of the lowest numbered byte through bit 0 of the
+- highest numbered byte (x^0).
+-
+- - The most significant 32 bits are complemented.
+-
+- - The polynomial is multiplied by x^32 then divided by G(x). The
+- generator polynomial produces a remainder R(x) of degree <= 31.
+-
+- - The coefficients of R(x) are considered a 32 bit sequence.
+-
+- - The bit sequence is complemented and the result is the CRC.
+-
+- - The CRC bits are mapped into the digest word. The x^31
+- coefficient in bit 7 of the lowest numbered byte of the digest
+- continuing through to the byte up to the x^24 coefficient in
+- bit 0 of the lowest numbered byte, continuing with the x^23
+- coefficient in bit 7 of next byte through x^0 in bit 0 of the
+- highest numbered byte.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 189]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- - Computing the CRC over any segment (data or header) extended
+- to include the CRC built using the generator 0x11edc6f41 will
+- always get the value 0x1c2d19ed as its final remainder (R(x)).
+- This value is given here in its polynomial form (i.e., not
+- mapped as the digest word).
+-
+- For a discussion about selection criteria for the CRC, see
+- [RFC3385]. For a detailed analysis of the iSCSI polynomial, see
+- [Castagnoli93].
+-
+- Private or public extension algorithms MAY also be negotiated for
+- digests. Whenever a private or public digest extension algorithm is
+- part of the default offer (the offer made in absence of explicit
+- administrative action) the implementer MUST ensure that CRC32C is
+- listed as an alternative in the default offer and "None" is not
+- part of the default offer.
+-
+- Extension digest algorithms MUST be named using one of the following
+- two formats:
+-
+- a) Y-reversed.vendor.dns_name.do_something=
+- b) Y<#><IANA-registered-string>=
+-
+- Digests named using the Y- format are used for private purposes
+- (unregistered). Digests named using the Y# format (public extension)
+- must be registered with IANA and MUST be described by an
+- informational RFC.
+-
+- For private extension digests, to identify the vendor, we suggest
+- you use the reversed DNS-name as a prefix to the proper digest
+- names.
+-
+- The part of digest-name following Y- and Y# MUST conform to the
+- format for standard-label specified in Section 5.1 Text Format.
+-
+- Support for public or private extension digests is OPTIONAL.
+-
+-12.2. MaxConnections
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+- Irrelevant when: SessionType=Discovery
+-
+- MaxConnections=<numerical-value-from-1-to-65535>
+-
+- Default is 1.
+- Result function is Minimum.
+-
+-
+-
+-Satran, et al. Standards Track [Page 190]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-
+- Initiator and target negotiate the maximum number of connections
+- requested/acceptable.
+-
+-12.3. SendTargets
+-
+- Use: FFPO
+- Senders: Initiator
+- Scope: SW
+-
+- For a complete description, see Appendix D. - SendTargets
+- Operation -.
+-
+-12.4. TargetName
+-
+- Use: IO by initiator, FFPO by target - only as response to a
+- SendTargets, Declarative, Any-Stage
+-
+- Senders: Initiator and Target
+- Scope: SW
+-
+- TargetName=<iSCSI-name-value>
+-
+- Examples:
+-
+- TargetName=iqn.1993-11.com.disk-vendor:diskarrays.sn.45678
+- TargetName=eui.020000023B040506
+-
+- The initiator of the TCP connection MUST provide this key to the
+- remote endpoint in the first login request if the initiator is not
+- establishing a discovery session. The iSCSI Target Name specifies
+- the worldwide unique name of the target.
+-
+- The TargetName key may also be returned by the "SendTargets" text
+- request (which is its only use when issued by a target).
+-
+- TargetName MUST not be redeclared within the login phase.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 191]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-12.5. InitiatorName
+-
+- Use: IO, Declarative, Any-Stage
+- Senders: Initiator
+- Scope: SW
+-
+- InitiatorName=<iSCSI-name-value>
+-
+- Examples:
+-
+- InitiatorName=iqn.1992-04.com.os-vendor.plan9:cdrom.12345
+- InitiatorName=iqn.2001-02.com.ssp.users:customer235.host90
+-
+- The initiator of the TCP connection MUST provide this key to the
+- remote endpoint at the first Login of the Login Phase for every
+- connection. The InitiatorName key enables the initiator to identify
+- itself to the remote endpoint.
+-
+- InitiatorName MUST not be redeclared within the login phase.
+-
+-12.6. TargetAlias
+-
+- Use: ALL, Declarative, Any-Stage
+- Senders: Target
+- Scope: SW
+-
+- TargetAlias=<iSCSI-local-name-value>
+-
+- Examples:
+-
+- TargetAlias=Bob-s Disk
+- TargetAlias=Database Server 1 Log Disk
+- TargetAlias=Web Server 3 Disk 20
+-
+- If a target has been configured with a human-readable name or
+- description, this name SHOULD be communicated to the initiator during
+- a Login Response PDU if SessionType=Normal (see Section 12.21
+- SessionType). This string is not used as an identifier, nor is it
+- meant to be used for authentication or authorization decisions. It
+- can be displayed by the initiator's user interface in a list of
+- targets to which it is connected.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 192]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-12.7. InitiatorAlias
+-
+- Use: ALL, Declarative, Any-Stage
+- Senders: Initiator
+- Scope: SW
+-
+- InitiatorAlias=<iSCSI-local-name-value>
+-
+- Examples:
+-
+- InitiatorAlias=Web Server 4
+- InitiatorAlias=spyalley.nsa.gov
+- InitiatorAlias=Exchange Server
+-
+- If an initiator has been configured with a human-readable name or
+- description, it SHOULD be communicated to the target during a Login
+- Request PDU. If not, the host name can be used instead. This string
+- is not used as an identifier, nor is meant to be used for
+- authentication or authorization decisions. It can be displayed by
+- the target's user interface in a list of initiators to which it is
+- connected.
+-
+-12.8. TargetAddress
+-
+- Use: ALL, Declarative, Any-Stage
+- Senders: Target
+- Scope: SW
+-
+- TargetAddress=domainname[:port][,portal-group-tag]
+-
+- The domainname can be specified as either a DNS host name, a
+- dotted-decimal IPv4 address, or a bracketed IPv6 address as specified
+- in [RFC2732].
+-
+- If the TCP port is not specified, it is assumed to be the
+- IANA-assigned default port for iSCSI (see Section 13 IANA
+- Considerations).
+-
+- If the TargetAddress is returned as the result of a redirect status
+- in a login response, the comma and portal group tag MUST be omitted.
+-
+- If the TargetAddress is returned within a SendTargets response, the
+- portal group tag MUST be included.
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 193]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Examples:
+-
+- TargetAddress=10.0.0.1:5003,1
+- TargetAddress=[1080:0:0:0:8:800:200C:417A],65
+- TargetAddress=[1080::8:800:200C:417A]:5003,1
+- TargetAddress=computingcenter.example.com,23
+-
+- Use of the portal-group-tag is described in Appendix D.
+- - SendTargets Operation -. The formats for the port and
+- portal-group-tag are the same as the one specified in Section 12.9
+- TargetPortalGroupTag.
+-
+-12.9. TargetPortalGroupTag
+-
+- Use: IO by target, Declarative, Any-Stage
+- Senders: Target
+- Scope: SW
+-
+- TargetPortalGroupTag=<16-bit-binary-value>
+-
+- Examples:
+- TargetPortalGroupTag=1
+-
+- The target portal group tag is a 16-bit binary-value that uniquely
+- identifies a portal group within an iSCSI target node. This key
+- carries the value of the tag of the portal group that is servicing
+- the Login request. The iSCSI target returns this key to the
+- initiator in the Login Response PDU to the first Login Request PDU
+- that has the C bit set to 0 when TargetName is given by the
+- initiator.
+-
+- For the complete usage expectations of this key see Section 5.3 Login
+- Phase.
+-
+-12.10. InitialR2T
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+- Irrelevant when: SessionType=Discovery
+-
+- InitialR2T=<boolean-value>
+-
+- Examples:
+-
+- I->InitialR2T=No
+- T->InitialR2T=No
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 194]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Default is Yes.
+- Result function is OR.
+-
+- The InitialR2T key is used to turn off the default use of R2T for
+- unidirectional and the output part of bidirectional commands, thus
+- allowing an initiator to start sending data to a target as if it has
+- received an initial R2T with Buffer Offset=Immediate Data Length and
+- Desired Data Transfer Length=(min(FirstBurstLength, Expected Data
+- Transfer Length) - Received Immediate Data Length).
+-
+- The default action is that R2T is required, unless both the initiator
+- and the target send this key-pair attribute specifying InitialR2T=No.
+- Only the first outgoing data burst (immediate data and/or separate
+- PDUs) can be sent unsolicited (i.e., not requiring an explicit R2T).
+-
+-12.11. ImmediateData
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+- Irrelevant when: SessionType=Discovery
+-
+- ImmediateData=<boolean-value>
+-
+- Default is Yes.
+- Result function is AND.
+-
+- The initiator and target negotiate support for immediate data. To
+- turn immediate data off, the initiator or target must state its
+- desire to do so. ImmediateData can be turned on if both the
+- initiator and target have ImmediateData=Yes.
+-
+- If ImmediateData is set to Yes and InitialR2T is set to Yes
+- (default), then only immediate data are accepted in the first burst.
+-
+- If ImmediateData is set to No and InitialR2T is set to Yes, then the
+- initiator MUST NOT send unsolicited data and the target MUST reject
+- unsolicited data with the corresponding response code.
+-
+- If ImmediateData is set to No and InitialR2T is set to No, then the
+- initiator MUST NOT send unsolicited immediate data, but MAY send one
+- unsolicited burst of Data-Out PDUs.
+-
+- If ImmediateData is set to Yes and InitialR2T is set to No, then the
+- initiator MAY send unsolicited immediate data and/or one unsolicited
+- burst of Data-Out PDUs.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 195]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The following table is a summary of unsolicited data options:
+-
+- +----------+-------------+------------------+--------------+
+- |InitialR2T|ImmediateData| Unsolicited |Immediate Data|
+- | | | Data Out PDUs | |
+- +----------+-------------+------------------+--------------+
+- | No | No | Yes | No |
+- +----------+-------------+------------------+--------------+
+- | No | Yes | Yes | Yes |
+- +----------+-------------+------------------+--------------+
+- | Yes | No | No | No |
+- +----------+-------------+------------------+--------------+
+- | Yes | Yes | No | Yes |
+- +----------+-------------+------------------+--------------+
+-
+-12.12. MaxRecvDataSegmentLength
+-
+- Use: ALL, Declarative
+- Senders: Initiator and Target
+- Scope: CO
+-
+- MaxRecvDataSegmentLength=<numerical-value-512-to-(2**24-1)>
+-
+- Default is 8192 bytes.
+-
+- The initiator or target declares the maximum data segment length in
+- bytes it can receive in an iSCSI PDU.
+-
+- The transmitter (initiator or target) is required to send PDUs with a
+- data segment that does not exceed MaxRecvDataSegmentLength of the
+- receiver.
+-
+- A target receiver is additionally limited by MaxBurstLength for
+- solicited data and FirstBurstLength for unsolicited data. An
+- initiator MUST NOT send solicited PDUs exceeding MaxBurstLength nor
+- unsolicited PDUs exceeding FirstBurstLength (or
+- FirstBurstLength-Immediate Data Length if immediate data were sent).
+-
+-12.13. MaxBurstLength
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+- Irrelevant when: SessionType=Discovery
+-
+- MaxBurstLength=<numerical-value-512-to-(2**24-1)>
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 196]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Default is 262144 (256 Kbytes).
+- Result function is Minimum.
+-
+- The initiator and target negotiate maximum SCSI data payload in bytes
+- in a Data-In or a solicited Data-Out iSCSI sequence. A sequence
+- consists of one or more consecutive Data-In or Data-Out PDUs that end
+- with a Data-In or Data-Out PDU with the F bit set to one.
+-
+-12.14. FirstBurstLength
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+- Irrelevant when: SessionType=Discovery
+- Irrelevant when: ( InitialR2T=Yes and ImmediateData=No )
+-
+- FirstBurstLength=<numerical-value-512-to-(2**24-1)>
+-
+- Default is 65536 (64 Kbytes).
+- Result function is Minimum.
+-
+- The initiator and target negotiate the maximum amount in bytes of
+- unsolicited data an iSCSI initiator may send to the target during the
+- execution of a single SCSI command. This covers the immediate data
+- (if any) and the sequence of unsolicited Data-Out PDUs (if any) that
+- follow the command.
+-
+- FirstBurstLength MUST NOT exceed MaxBurstLength.
+-
+-12.15. DefaultTime2Wait
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+-
+- DefaultTime2Wait=<numerical-value-0-to-3600>
+-
+- Default is 2.
+- Result function is Maximum.
+-
+- The initiator and target negotiate the minimum time, in seconds, to
+- wait before attempting an explicit/implicit logout or an active task
+- reassignment after an unexpected connection termination or a
+- connection reset.
+-
+- A value of 0 indicates that logout or active task reassignment can be
+- attempted immediately.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 197]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-12.16. DefaultTime2Retain
+-
+- Use: LO Senders: Initiator and Target Scope: SW
+-
+- DefaultTime2Retain=<numerical-value-0-to-3600>
+-
+- Default is 20. Result function is Minimum.
+-
+- The initiator and target negotiate the maximum time, in seconds after
+- an initial wait (Time2Wait), before which an active task reassignment
+- is still possible after an unexpected connection termination or a
+- connection reset.
+-
+- This value is also the session state timeout if the connection in
+- question is the last LOGGED_IN connection in the session.
+-
+- A value of 0 indicates that connection/task state is immediately
+- discarded by the target.
+-
+-12.17. MaxOutstandingR2T
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+-
+- MaxOutstandingR2T=<numerical-value-from-1-to-65535>
+- Irrelevant when: SessionType=Discovery
+-
+- Default is 1.
+- Result function is Minimum.
+-
+- Initiator and target negotiate the maximum number of outstanding R2Ts
+- per task, excluding any implied initial R2T that might be part of
+- that task. An R2T is considered outstanding until the last data PDU
+- (with the F bit set to 1) is transferred, or a sequence reception
+- timeout (Section 6.1.4.1 Recovery Within-command) is encountered for
+- that data sequence.
+-
+-12.18. DataPDUInOrder
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+- Irrelevant when: SessionType=Discovery
+-
+- DataPDUInOrder=<boolean-value>
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 198]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Default is Yes.
+- Result function is OR.
+-
+- No is used by iSCSI to indicate that the data PDUs within sequences
+- can be in any order. Yes is used to indicate that data PDUs within
+- sequences have to be at continuously increasing addresses and
+- overlays are forbidden.
+-
+-12.19. DataSequenceInOrder
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+- Irrelevant when: SessionType=Discovery
+-
+- DataSequenceInOrder=<boolean-value>
+-
+- Default is Yes.
+- Result function is OR.
+-
+- A Data Sequence is a sequence of Data-In or Data-Out PDUs that end
+- with a Data-In or Data-Out PDU with the F bit set to one. A Data-Out
+- sequence is sent either unsolicited or in response to an R2T.
+- Sequences cover an offset-range.
+-
+- If DataSequenceInOrder is set to No, Data PDU sequences may be
+- transferred in any order.
+-
+- If DataSequenceInOrder is set to Yes, Data Sequences MUST be
+- transferred using continuously non-decreasing sequence offsets (R2T
+- buffer offset for writes, or the smallest SCSI Data-In buffer offset
+- within a read data sequence).
+-
+- If DataSequenceInOrder is set to Yes, a target may retry at most the
+- last R2T, and an initiator may at most request retransmission for the
+- last read data sequence. For this reason, if ErrorRecoveryLevel is
+- not 0 and DataSequenceInOrder is set to Yes then MaxOustandingR2T
+- MUST be set to 1.
+-
+-12.20. ErrorRecoveryLevel
+-
+- Use: LO
+- Senders: Initiator and Target
+- Scope: SW
+-
+- ErrorRecoveryLevel=<numerical-value-0-to-2>
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 199]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Default is 0.
+- Result function is Minimum.
+-
+- The initiator and target negotiate the recovery level supported.
+-
+- Recovery levels represent a combination of recovery capabilities.
+- Each recovery level includes all the capabilities of the lower
+- recovery levels and adds some new ones to them.
+-
+- In the description of recovery mechanisms, certain recovery classes
+- are specified. Section 6.1.5 Error Recovery Hierarchy describes the
+- mapping between the classes and the levels.
+-
+-12.21. SessionType
+-
+- Use: LO, Declarative, Any-Stage
+- Senders: Initiator
+- Scope: SW
+-
+- SessionType= <Discovery|Normal>
+-
+- Default is Normal.
+-
+- The initiator indicates the type of session it wants to create. The
+- target can either accept it or reject it.
+-
+- A discovery session indicates to the Target that the only purpose of
+- this Session is discovery. The only requests a target accepts in
+- this type of session are a text request with a SendTargets key and a
+- logout request with reason "close the session".
+-
+- The discovery session implies MaxConnections = 1 and overrides both
+- the default and an explicit setting.
+-
+-12.22. The Private or Public Extension Key Format
+-
+- Use: ALL
+- Senders: Initiator and Target
+- Scope: specific key dependent
+-
+- X-reversed.vendor.dns_name.do_something=
+-
+- or
+-
+- X<#><IANA-registered-string>=
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 200]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Keys with this format are used for public or private extension
+- purposes. These keys always start with X- if unregistered with IANA
+- (private) or X# if registered with IANA (public).
+-
+- For unregistered keys, to identify the vendor, we suggest you use the
+- reversed DNS-name as a prefix to the key-proper.
+-
+- The part of key-name following X- and X# MUST conform to the format
+- for key-name specified in Section 5.1 Text Format.
+-
+- For IANA registered keys the string following X# must be registered
+- with IANA and the use of the key MUST be described by an
+- informational RFC.
+-
+- Vendor specific keys MUST ONLY be used in normal sessions.
+-
+- Support for public or private extension keys is OPTIONAL.
+-
+-13. IANA Considerations
+-
+- This section conforms to [RFC2434].
+-
+- The well-known user TCP port number for iSCSI connections assigned by
+- IANA is 3260 and this is the default iSCSI port. Implementations
+- needing a system TCP port number may use port 860, the port assigned
+- by IANA as the iSCSI system port; however in order to use port 860,
+- it MUST be explicitly specified - implementations MUST NOT default to
+- use of port 860, as 3260 is the only allowed default.
+-
+- Extension keys, authentication methods, or digest types for which a
+- vendor or group of vendors intend to provide publicly available
+- descriptions MUST be described by an RFC and MUST be registered with
+- IANA.
+-
+- The IANA has set up the following three registries:
+-
+- a) iSCSI extended key registry
+- b) iSCSI authentication methods registry
+- c) iSCSI digests registry
+-
+- [RFC3723] also instructs IANA to maintain a registry for the values
+- of the SRP_GROUP key. The format of these values must conform to the
+- one specified for iSCSI extension item-label in Section 13.5.4
+- Standard iSCSI extension item-label format.
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 201]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- For the iSCSI authentication methods registry and the iSCSI digests
+- registry, IANA MUST also assign a 16-bit unsigned integer number (the
+- method number for the authentication method and the digest number for
+- the digest).
+-
+- The following initial values for the registry for authentication
+- methods are specified by the standards action of this document:
+-
+- Authentication Method | Number |
+- +----------------------------------------+--------+
+- | CHAP | 1 |
+- +----------------------------------------+--------+
+- | SRP | 2 |
+- +----------------------------------------+--------+
+- | KRB5 | 3 |
+- +----------------------------------------+--------+
+- | SPKM1 | 4 |
+- +----------------------------------------+--------+
+- | SPKM2 | 5 |
+- +----------------------------------------+--------+
+-
+- All other record numbers from 0 to 255 are reserved. IANA will
+- register numbers above 255.
+-
+- Authentication methods with numbers above 255 MUST be unique within
+- the registry and MUST be used with the prefix Z#.
+-
+-
+- The following initial values for the registry for digests are
+- specified by the standards action of this document:
+-
+- Digest | Number |
+- +----------------------------------------+--------+
+- | CRC32C | 1 |
+- +----------------------------------------+--------+
+-
+- All other record numbers from 0 to 255 are reserved. IANA will
+- register numbers above 255.
+-
+- Digests with numbers above 255 MUST be unique within the registry and
+- MUST be used with the prefix Y#.
+-
+- The RFC that describes the item to be registered MUST indicate in the
+- IANA Considerations section the string and iSCSI registry to which it
+- should be recorded.
+-
+- Extension Keys, Authentication Methods, and digests (iSCSI extension
+- items) must conform to a number of requirements as described below.
+-
+-
+-
+-Satran, et al. Standards Track [Page 202]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-13.1. Naming Requirements
+-
+- Each iSCSI extension item must have a unique name in its category.
+- This name will be used as a standard-label for the key, access
+- method, or digest and must conform to the syntax specified in Section
+- 13.5.4 Standard iSCSI extension item-label format for iSCSI extension
+- item-labels.
+-
+-13.2. Mechanism Specification Requirements
+-
+- For iSCSI extension items all of the protocols and procedures used by
+- a given iSCSI extension item must be described, either in the
+- specification of the iSCSI extension item itself or in some other
+- publicly available specification, in sufficient detail for the iSCSI
+- extension item to be implemented by any competent implementor. Use
+- of secret and/or proprietary methods in iSCSI extension items are
+- expressly prohibited. In addition, the restrictions imposed by
+- [RFC1602] on the standardization of patented algorithms must be
+- respected.
+-
+-13.3. Publication Requirements
+-
+- All iSCSI extension items must be described by an RFC. The RFC may
+- be informational rather than Standards-Track, although Standards
+- Track review and approval are encouraged for all iSCSI extension
+- items.
+-
+-13.4. Security Requirements
+-
+- Any known security issues that arise from the use of the iSCSI
+- extension item must be completely and fully described. It is not
+- required that the iSCSI extension item be secure or that it be free
+- from risks, but that the known risks be identified. Publication of a
+- new iSCSI extension item does not require an exhaustive security
+- review, and the security considerations section is subject to
+- continuing evaluation.
+-
+- Additional security considerations should be addressed by publishing
+- revised versions of the iSCSI extension item specification.
+-
+- For each of these registries, IANA must record the registered string,
+- which MUST conform to the format rules described in Section 13.5.4
+- Standard iSCSI extension item-label format for iSCSI extension
+- item-labels, and the RFC number that describes it. The key prefix
+- (X#, Y# or Z#) is not part of the recorded string.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 203]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-13.5. Registration Procedure
+-
+- Registration of a new iSCSI extension item starts with the
+- construction of an Internet Draft to become an RFC.
+-
+-13.5.1. Present the iSCSI extension item to the Community
+-
+- Send a proposed access type specification to the IPS WG mailing list,
+- or if the IPS WG is disbanded at the registration time, to a mailing
+- list designated by the IETF Transport Area Director for a review
+- period of a month. The intent of the public posting is to solicit
+- comments and feedback on the iSCSI extension item specification and a
+- review of any security considerations.
+-
+-13.5.2. iSCSI extension item review and IESG approval
+-
+- When the one month period has passed, the IPS WG chair or a person
+- nominated by the IETF Transport Area Director (the iSCSI extension
+- item reviewer) forwards the Internet Draft to the IESG for
+- publication as an informational RFC or rejects it. If the
+- specification is a standards track document, the usual IETF
+- procedures for such documents are followed.
+-
+- Decisions made by the iSCSI extension item reviewer must be published
+- within two weeks after the month-long review period. Decisions made
+- by the iSCSI extension item reviewer can be appealed through the IESG
+- appeal process.
+-
+-13.5.3. IANA Registration
+-
+- Provided that the iSCSI extension item has either passed review or
+- has been successfully appealed to the IESG, and the specification is
+- published as an RFC, then IANA will register the iSCSI extension item
+- and make the registration available to the community.
+-
+-13.5.4. Standard iSCSI extension item-label format
+-
+- The following character symbols are used iSCSI extension item-labels
+- (the hexadecimal values represent Unicode code points):
+-
+- (a-z, A-Z) - letters
+- (0-9) - digits
+- "." (0x2e) - dot
+- "-" (0x2d) - minus
+- "+" (0x2b) - plus
+- "@" (0x40) - commercial at
+- "_" (0x5f) - underscore
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 204]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- An iSCSI extension item-label is a string of one or more characters
+- that consist of letters, digits, dot, minus, plus, commercial at, or
+- underscore. An iSCSI extension item-label MUST begin with a capital
+- letter and must not exceed 63 characters.
+-
+-13.6. IANA Procedures for Registering iSCSI extension items
+-
+- The identity of the iSCSI extension item reviewer is communicated to
+- the IANA by the IESG. Then, the IANA only acts in response to iSCSI
+- extension item definitions that are approved by the iSCSI extension
+- item reviewer and forwarded by the reviewer to the IANA for
+- registration, or in response to a communication from the IESG that an
+- iSCSI extension item definition appeal has overturned the iSCSI
+- extension item reviewer's ruling.
+-
+-References
+-
+-Normative References
+-
+- [CAM] ANSI X3.232-199X, Common Access Method-3.
+-
+- [EUI] "Guidelines for 64-bit Global Identifier (EUI-64)",
+- http:
+- //standards.ieee.org/regauth/oui/tutorials/EUI64.html
+-
+- [OUI] "IEEE OUI and Company_Id Assignments",
+- http://standards.ieee.org/regauth/oui
+-
+- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+- September 1981.
+-
+- [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
+- RFC 793, September 1981.
+-
+- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+- Specification", STD 13, RFC 1035, November 1987.
+-
+- [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts-
+- Communication Layer", STD 3, RFC 1122, October 1989.
+-
+- [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
+- Authentication Service (V5)", RFC 1510, September
+- 1993.
+-
+- [RFC1737] Sollins, K. and L. Masinter "Functional Requirements
+- for Uniform Resource Names"RFC 1737, December 1994.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 205]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+- RFC 1964, June 1996.
+-
+- [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
+- 1982, August 1996.
+-
+- [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
+- Protocol (CHAP)", RFC 1994, August 1996.
+-
+- [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
+- (SPKM)", RFC 2025, October 1996.
+-
+- [RFC2045] Borenstein, N. and N. Freed, "MIME (Multipurpose
+- Internet Mail Extensions) Part One: Mechanisms for
+- Specifying and Describing the Format of Internet
+- Message Bodies", RFC 2045, November 1996.
+-
+- [RFC2119] Bradner, S. "Key Words for use in RFCs to Indicate
+- Requirement Levels", BCP 14, RFC 2119, March 1997.
+-
+- [RFC2279] Yergeau, F., "UTF-8, a Transformation Format of ISO
+- 10646", RFC 2279 October 1996.
+-
+- [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+- Architecture", RFC 2373, July 1998.
+-
+- [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter "Uniform
+- Resource Identifiers", RFC 2396, August 1998.
+-
+- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
+- the Internet Protocol", RFC 2401, November 1998.
+-
+- [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96
+- within ESP and AH", RFC 2404, November 1998.
+-
+- [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+- Payload (ESP)", RFC 2406, November 1998.
+-
+- [RFC2407] Piper, D., "The Internet IP Security Domain of
+- Interpretation of ISAKMP", RFC 2407, November 1998.
+-
+- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+- (IKE)", RFC2409, November 1998.
+-
+- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
+- an IANA Considerations Section in RFCs.", BCP 26, RFC
+- 2434, October 1998.
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 206]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- [RFC2451] Pereira, R. and R. Adams " The ESP CBC-Mode Cipher
+- Algorithms", RFC 2451, November 1998.
+-
+- [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
+- Literal IPv6 Addresses in URL's", RFC 2451, December
+- 1999.
+-
+- [RFC2945] Wu, T., "The SRP Authentication and Key Exchange
+- System", RFC 2945, September 2000.
+-
+- [RFC3066] Alvestrand, H., "Tags for the Identification of
+- Languages", STD 47, RFC 3066, January 2001.
+-
+- [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+- Internationalized Strings ("stringprep")", RFC 3454,
+- December 2002.
+-
+- [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
+- Algorithm and Its Use With IPsec", RFC 3566, September
+- 2003.
+-
+- [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
+- Counter Mode with IPsec Encapsulating Security Payload
+- (ESP)", RFC 3686, January 2004.
+-
+- [RFC3722] Bakke, M., "String Profile for Internet Small Computer
+- Systems Interface (iSCSI) Names", RFC 3722, March
+- 2004.
+-
+- [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F.
+- Travostino, "Securing Block Storage Protocols over
+- IP", RFC 3723, March 2004.
+-
+- [SAM2] T10/1157D, SCSI Architecture Model - 2 (SAM-2).
+-
+- [SBC] NCITS.306-1998, SCSI-3 Block Commands (SBC).
+-
+- [SPC3] T10/1416-D, SCSI Primary Commands-3.
+-
+- [UNICODE] Unicode Standard Annex #15, "Unicode Normalization
+- Forms", http://www.unicode.org/unicode/reports/tr15
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 207]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Informative References
+-
+- [BOOT] P. Sarkar, et al., "Bootstrapping Clients using the
+- iSCSI Protocol", Work in Progress, July 2003.
+-
+- [Castagnoli93] G. Castagnoli, S. Braeuer and M. Herrman "Optimization
+- of Cyclic Redundancy-Check Codes with 24 and 32 Parity
+- Bits", IEEE Transact. on Communications, Vol. 41, No.
+- 6, June 1993.
+-
+- [CORD] Chadalapaka, M. and R. Elliott, "SCSI Command
+- Ordering Considerations with iSCSI", Work in Progress.
+-
+- [RFC3347] Krueger, M., Haagens, R., Sapuntzakis, C. and M.
+- Bakke, "Small Computer Systems Interface protocol over
+- the Internet (iSCSI) Requirements and Design
+- Considerations", RFC 3347, July 2002.
+-
+- [RFC3385] Sheinwald, D., Staran, J., Thaler, P. and V. Cavanna,
+- "Internet Protocol Small Computer System Interface
+- (iSCSI) Cyclic Redundancy Check (CRC)/Checksum
+- Considerations", RFC 3385, September 2002.
+-
+- [RFC3721] Bakke M., Hafner, J., Hufferd, J., Voruganti, K. and
+- M. Krueger, "Internet Small Computer Systems Interface
+- (iSCSI) Naming and Discovery, RFC 3721, March 2004.
+-
+- [SEQ-EXT] Kent, S., "IP Encapsulating Security Payload (ESP)",
+- Work in Progress, July 2002.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 208]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Appendix A. Sync and Steering with Fixed Interval Markers
+-
+- This appendix presents a simple scheme for synchronization (PDU
+- boundary retrieval). It uses markers that include synchronization
+- information placed at fixed intervals in the TCP stream.
+-
+- A Marker consists of:
+-
+- Byte / 0 | 1 | 2 | 3 |
+- / | | | |
+- |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
+- +---------------+---------------+---------------+---------------+
+- 0| Next-iSCSI-PDU-start pointer - copy #1 |
+- +---------------+---------------+---------------+---------------+
+- 4| Next-iSCSI-PDU-start pointer - copy #2 |
+- +---------------+---------------+---------------+---------------+
+-
+- The Marker scheme uses payload byte stream counting that includes
+- every byte placed by iSCSI in the TCP stream except for the markers
+- themselves. It also excludes any bytes that TCP counts but are not
+- originated by iSCSI.
+-
+- Markers MUST NOT be included in digest calculation.
+-
+- The Marker indicates the offset to the next iSCSI PDU header. The
+- Marker is eight bytes in length and contains two 32-bit offset fields
+- that indicate how many bytes to skip in the TCP stream in order to
+- find the next iSCSI PDU header. The marker uses two copies of the
+- pointer so that a marker that spans a TCP packet boundary should
+- leave at least one valid copy in one of the packets.
+-
+- The structure and semantics of an inserted marker are independent of
+- the marker interval.
+-
+- The use of markers is negotiable. The initiator and target MAY
+- indicate their readiness to receive and/or send markers during login
+- separately for each connection. The default is No.
+-
+-A.1. Markers At Fixed Intervals
+-
+- A marker is inserted at fixed intervals in the TCP byte stream.
+- During login, each end of the iSCSI session specifies the interval at
+- which it is willing to receive the marker, or it disables the marker
+- altogether. If a receiver indicates that it desires a marker, the
+- sender MAY agree (during negotiation) and provide the marker at the
+- desired interval. However, in certain environments, a sender that
+- does not provide markers to a receiver that wants markers may suffer
+- an appreciable performance degradation.
+-
+-
+-
+-Satran, et al. Standards Track [Page 209]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The marker interval and the initial marker-less interval are counted
+- in terms of the bytes placed in the TCP stream data by iSCSI.
+-
+- When reduced to iSCSI terms, markers MUST indicate the offset to a
+- 4-byte word boundary in the stream. The least significant two bits
+- of each marker word are reserved and are considered 0 for offset
+- computation.
+-
+- Padding iSCSI PDU payloads to 4-byte word boundaries simplifies
+- marker manipulation.
+-
+-A.2. Initial Marker-less Interval
+-
+- To enable the connection setup including the Login Phase negotiation,
+- marking (if any) is only started at the first marker interval after
+- the end of the Login Phase. However, in order to enable the marker
+- inclusion and exclusion mechanism to work without knowledge of the
+- length of the Login Phase, the first marker will be placed in the TCP
+- stream as if the Marker-less interval had included markers.
+-
+- Thus, all markers appear in the stream at locations conforming to the
+- formula: [(MI + 8) * n - 8] where MI = Marker Interval, n = integer
+- number.
+-
+- For example, if the marker interval is 512 bytes and the login ended
+- at byte 1003 (first iSCSI placed byte is 0), the first marker will be
+- inserted after byte 1031 in the stream.
+-
+-A.3. Negotiation
+-
+- The following operational key=value pairs are used to negotiate the
+- fixed interval markers. The direction (output or input) is relative
+- to the initiator.
+-
+-A.3.1. OFMarker, IFMarker
+-
+- Use: IO
+- Senders: Initiator and Target
+- Scope: CO
+-
+- OFMarker=<boolean-value>
+- IFMarker=<boolean-value>
+-
+- Default is No.
+-
+- Result function is AND.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 210]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- OFMarker is used to turn on or off the initiator to target markers
+- on the connection. IFMarker is used to turn on or off the target to
+- initiator markers on the connection.
+-
+- Examples:
+-
+- I->OFMarker=Yes,IFMarker=Yes
+- T->OFMarker=Yes,IFMarker=Yes
+-
+- Results in the Marker being used in both directions while:
+-
+- I->OFMarker=Yes,IFMarker=Yes
+- T->OFMarker=Yes,IFMarker=No
+-
+- Results in Marker being used from the initiator to the target, but
+- not from the target to initiator.
+-
+-A.3.2. OFMarkInt, IFMarkInt
+-
+- Use: IO
+- Senders: Initiator and Target
+- Scope: CO
+- OFMarkInt is Irrelevant when: OFMarker=No
+- IFMarkInt is Irrelevant when: IFMarker=No
+-
+- Offering:
+-
+- OFMarkInt=<numeric-range-from-1-to-65535>
+- IFMarkInt=<numeric-range-from-1-to-65535>
+-
+- Responding:
+-
+- OFMarkInt=<numeric-value-from-1-to-65535>|Reject
+- IFMarkInt=<numeric-value-from-1-to-65535>|Reject
+-
+- OFMarkInt is used to set the interval for the initiator to target
+- markers on the connection. IFMarkInt is used to set the interval for
+- the target to initiator markers on the connection.
+-
+- For the offering, the initiator or target indicates the minimum to
+- maximum interval (in 4-byte words) it wants the markers for one or
+- both directions. In case it only wants a specific value, only a
+- single value has to be specified. The responder selects a value
+- within the minimum and maximum offered or the only value offered or
+- indicates through the xFMarker key=value its inability to set and/or
+- receive markers. When the interval is unacceptable the responder
+- answers with "Reject". Reject is resetting the marker function in
+- the specified direction (Output or Input) to No.
+-
+-
+-
+-Satran, et al. Standards Track [Page 211]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The interval is measured from the end of a marker to the beginning of
+- the next marker. For example, a value of 1024 means 1024 words (4096
+- bytes of iSCSI payload between markers).
+-
+- The default is 2048.
+-
+-Appendix B. Examples
+-
+-B.1. Read Operation Example
+-
+- +------------------+-----------------------+----------------------+
+- |Initiator Function| PDU Type | Target Function |
+- +------------------+-----------------------+----------------------+
+- | Command request |SCSI Command (READ)>>> | |
+- | (read) | | |
+- +------------------+-----------------------+----------------------+
+- | | |Prepare Data Transfer |
+- +------------------+-----------------------+----------------------+
+- | Receive Data | <<< SCSI Data-In | Send Data |
+- +------------------+-----------------------+----------------------+
+- | Receive Data | <<< SCSI Data-In | Send Data |
+- +------------------+-----------------------+----------------------+
+- | Receive Data | <<< SCSI Data-In | Send Data |
+- +------------------+-----------------------+----------------------+
+- | | <<< SCSI Response |Send Status and Sense |
+- +------------------+-----------------------+----------------------+
+- | Command Complete | | |
+- +------------------+-----------------------+----------------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 212]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-B.2. Write Operation Example
+-
+- +------------------+-----------------------+---------------------+
+- |Initiator Function| PDU Type | Target Function |
+- +------------------+-----------------------+---------------------+
+- | Command request |SCSI Command (WRITE)>>>| Receive command |
+- | (write) | | and queue it |
+- +------------------+-----------------------+---------------------+
+- | | | Process old commands|
+- +------------------+-----------------------+---------------------+
+- | | | Ready to process |
+- | | <<< R2T | WRITE command |
+- +------------------+-----------------------+---------------------+
+- | Send Data | SCSI Data-Out >>> | Receive Data |
+- +------------------+-----------------------+---------------------+
+- | | <<< R2T | Ready for data |
+- +------------------+-----------------------+---------------------+
+- | | <<< R2T | Ready for data |
+- +------------------+-----------------------+---------------------+
+- | Send Data | SCSI Data-Out >>> | Receive Data |
+- +------------------+-----------------------+---------------------+
+- | Send Data | SCSI Data-Out >>> | Receive Data |
+- +------------------+-----------------------+---------------------+
+- | | <<< SCSI Response |Send Status and Sense|
+- +------------------+-----------------------+---------------------+
+- | Command Complete | | |
+- +------------------+-----------------------+---------------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 213]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-B.3. R2TSN/DataSN Use Examples
+-
+- Output (write) data DataSN/R2TSN Example
+-
+- +------------------+-----------------------+----------------------+
+- |Initiator Function| PDU Type & Content | Target Function |
+- +------------------+-----------------------+----------------------+
+- | Command request |SCSI Command (WRITE)>>>| Receive command |
+- | (write) | | and queue it |
+- +------------------+-----------------------+----------------------+
+- | | | Process old commands |
+- +------------------+-----------------------+----------------------+
+- | | <<< R2T | Ready for data |
+- | | R2TSN = 0 | |
+- +------------------+-----------------------+----------------------+
+- | | <<< R2T | Ready for more data |
+- | | R2TSN = 1 | |
+- +------------------+-----------------------+----------------------+
+- | Send Data | SCSI Data-Out >>> | Receive Data |
+- | for R2TSN 0 | DataSN = 0, F=0 | |
+- +------------------+-----------------------+----------------------+
+- | Send Data | SCSI Data-Out >>> | Receive Data |
+- | for R2TSN 0 | DataSN = 1, F=1 | |
+- +------------------+-----------------------+----------------------+
+- | Send Data | SCSI Data >>> | Receive Data |
+- | for R2TSN 1 | DataSN = 0, F=1 | |
+- +------------------+-----------------------+----------------------+
+- | | <<< SCSI Response |Send Status and Sense |
+- | | ExpDataSN = 0 | |
+- +------------------+-----------------------+----------------------+
+- | Command Complete | | |
+- +------------------+-----------------------+----------------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 214]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Input (read) data DataSN Example
+-
+- +------------------+-----------------------+----------------------+
+- |Initiator Function| PDU Type | Target Function |
+- +------------------+-----------------------+----------------------+
+- | Command request |SCSI Command (READ)>>> | |
+- | (read) | | |
+- +------------------+-----------------------+----------------------+
+- | | | Prepare Data Transfer|
+- +------------------+-----------------------+----------------------+
+- | Receive Data | <<< SCSI Data-In | Send Data |
+- | | DataSN = 0, F=0 | |
+- +------------------+-----------------------+----------------------+
+- | Receive Data | <<< SCSI Data-In | Send Data |
+- | | DataSN = 1, F=0 | |
+- +------------------+-----------------------+----------------------+
+- | Receive Data | <<< SCSI Data-In | Send Data |
+- | | DataSN = 2, F=1 | |
+- +------------------+-----------------------+----------------------+
+- | | <<< SCSI Response |Send Status and Sense |
+- | | ExpDataSN = 3 | |
+- +------------------+-----------------------+----------------------+
+- | Command Complete | | |
+- +------------------+-----------------------+----------------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 215]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Bidirectional DataSN Example
+-
+- +------------------+-----------------------+----------------------+
+- |Initiator Function| PDU Type | Target Function |
+- +------------------+-----------------------+----------------------+
+- | Command request |SCSI Command >>> | |
+- | (Read-Write) | Read-Write | |
+- +------------------+-----------------------+----------------------+
+- | | | Process old commands |
+- +------------------+-----------------------+----------------------+
+- | | <<< R2T | Ready to process |
+- | | R2TSN = 0 | WRITE command |
+- +------------------+-----------------------+----------------------+
+- | * Receive Data | <<< SCSI Data-In | Send Data |
+- | | DataSN = 1, F=0 | |
+- +------------------+-----------------------+----------------------+
+- | * Receive Data | <<< SCSI Data-In | Send Data |
+- | | DataSN = 2, F=1 | |
+- +------------------+-----------------------+----------------------+
+- | * Send Data | SCSI Data-Out >>> | Receive Data |
+- | for R2TSN 0 | DataSN = 0, F=1 | |
+- +------------------+-----------------------+----------------------+
+- | | <<< SCSI Response |Send Status and Sense |
+- | | ExpDataSN = 3 | |
+- +------------------+-----------------------+----------------------+
+- | Command Complete | | |
+- +------------------+-----------------------+----------------------+
+-
+- *) Send data and Receive Data may be transferred simultaneously as in
+- an atomic Read-Old-Write-New or sequentially as in an atomic
+- Read-Update-Write (in the latter case the R2T may follow the received
+- data).
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 216]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Unsolicited and immediate output (write) data with DataSN Example
+-
+- +------------------+-----------------------+----------------------+
+- |Initiator Function| PDU Type & Content | Target Function |
+- +------------------+-----------------------+----------------------+
+- | Command request |SCSI Command (WRITE)>>>| Receive command |
+- | (write) |F=0 | and data |
+- |+ Immediate data | | and queue it |
+- +------------------+-----------------------+----------------------+
+- | Send Unsolicited | SCSI Write Data >>> | Receive more Data |
+- | Data | DataSN = 0, F=1 | |
+- +------------------+-----------------------+----------------------+
+- | | | Process old commands |
+- +------------------+-----------------------+----------------------+
+- | | <<< R2T | Ready for more data |
+- | | R2TSN = 0 | |
+- +------------------+-----------------------+----------------------+
+- | Send Data | SCSI Write Data >>> | Receive Data |
+- | for R2TSN 0 | DataSN = 0, F=1 | |
+- +------------------+-----------------------+----------------------+
+- | | <<< SCSI Response |Send Status and Sense |
+- | | | |
+- +------------------+-----------------------+----------------------+
+- | Command Complete | | |
+- +------------------+-----------------------+----------------------+
+-
+-B.4. CRC Examples
+-
+- N.B. all Values are Hexadecimal
+-
+- 32 bytes of zeroes:
+-
+- Byte: 0 1 2 3
+-
+- 0: 00 00 00 00
+- ...
+- 28: 00 00 00 00
+-
+- CRC: aa 36 91 8a
+-
+- 32 bytes of ones:
+-
+- Byte: 0 1 2 3
+-
+- 0: ff ff ff ff
+- ...
+- 28: ff ff ff ff
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 217]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- CRC: 43 ab a8 62
+-
+- 32 bytes of incrementing 00..1f:
+-
+- Byte: 0 1 2 3
+-
+- 0: 00 01 02 03
+- ...
+- 28: 1c 1d 1e 1f
+-
+- CRC: 4e 79 dd 46
+-
+- 32 bytes of decrementing 1f..00:
+-
+- Byte: 0 1 2 3
+-
+- 0: 1f 1e 1d 1c
+- ...
+- 28: 03 02 01 00
+-
+- CRC: 5c db 3f 11
+-
+- An iSCSI - SCSI Read (10) Command PDU
+-
+- Byte: 0 1 2 3
+-
+- 0: 01 c0 00 00
+- 4: 00 00 00 00
+- 8: 00 00 00 00
+- 12: 00 00 00 00
+- 16: 14 00 00 00
+- 20: 00 00 04 00
+- 24: 00 00 00 14
+- 28: 00 00 00 18
+- 32: 28 00 00 00
+- 36: 00 00 00 00
+- 40: 02 00 00 00
+- 44: 00 00 00 00
+-
+- CRC: 56 3a 96 d9
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 218]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Appendix C. Login Phase Examples
+-
+- In the first example, the initiator and target authenticate each
+- other via Kerberos:
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- AuthMethod=KRB5,SRP,None
+-
+- T-> Login (CSG,NSG=0,0 T=0)
+- AuthMethod=KRB5
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- KRB_AP_REQ=<krb_ap_req>
+-
+- (krb_ap_req contains the Kerberos V5 ticket and authenticator
+- with MUTUAL-REQUIRED set in the ap-options field)
+-
+- If the authentication is successful, the target proceeds with:
+-
+- T-> Login (CSG,NSG=0,1 T=1)
+- KRB_AP_REP=<krb_ap_rep>
+-
+- (krb_ap_rep is the Kerberos V5 mutual authentication reply)
+-
+- If the authentication is successful, the initiator may proceed
+- with:
+-
+- I-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=8192
+- T-> Login (CSG,NSG=1,0 T=0) FirstBurstLength=4096
+- MaxBurstLength=8192
+- I-> Login (CSG,NSG=1,0 T=0) MaxBurstLength=8192
+- ... more iSCSI Operational Parameters
+-
+- T-> Login (CSG,NSG=1,0 T=0)
+- ... more iSCSI Operational Parameters
+-
+- And at the end:
+-
+- I-> Login (CSG,NSG=1,3 T=1)
+- optional iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,3 T=1) "login accept"
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 219]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- If the initiator's authentication by the target is not
+- successful, the target responds with:
+-
+- T-> Login "login reject"
+-
+- instead of the Login KRB_AP_REP message, and terminates the
+- connection.
+-
+- If the target's authentication by the initiator is not
+- successful, the initiator terminates the connection (without
+- responding to the Login KRB_AP_REP message).
+-
+- In the next example only the initiator is authenticated by the
+- target via Kerberos:
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- AuthMethod=SRP,KRB5,None
+-
+- T-> Login-PR (CSG,NSG=0,0 T=0)
+- AuthMethod=KRB5
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- KRB_AP_REQ=krb_ap_req
+-
+- (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req)
+-
+- If the authentication is successful, the target proceeds with:
+-
+- T-> Login (CSG,NSG=0,1 T=1)
+-
+- I-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- . . .
+-
+- T-> Login (CSG,NSG=1,3 T=1)"login accept"
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 220]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- In the next example, the initiator and target authenticate each
+- other via SPKM1:
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- AuthMethod=SPKM1,KRB5,None
+-
+- T-> Login (CSG,NSG=0,0 T=0)
+- AuthMethod=SPKM1
+-
+- I-> Login (CSG,NSG=0,0 T=0)
+- SPKM_REQ=<spkm-req>
+-
+- (spkm-req is the SPKM-REQ token with the mutual-state bit in the
+- options field of the REQ-TOKEN set)
+-
+- T-> Login (CSG,NSG=0,0 T=0)
+- SPKM_REP_TI=<spkm-rep-ti>
+-
+- If the authentication is successful, the initiator proceeds:
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- SPKM_REP_IT=<spkm-rep-it>
+-
+- If the authentication is successful, the target proceeds with:
+-
+- T-> Login (CSG,NSG=0,1 T=1)
+-
+- The initiator may proceed:
+-
+- I-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
+- T-> Login (CSG,NSG=1,0 T=0) ... iSCSI parameters
+-
+- And at the end:
+-
+- I-> Login (CSG,NSG=1,3 T=1)
+- optional iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,3 T=1) "login accept"
+-
+-
+- If the target's authentication by the initiator is not
+- successful, the initiator terminates the connection (without
+- responding to the Login SPKM_REP_TI message).
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 221]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- If the initiator's authentication by the target is not
+- successful, the target responds with:
+-
+- T-> Login "login reject"
+-
+- instead of the Login "proceed and change stage" message, and
+- terminates the connection.
+-
+-
+- In the next example, the initiator and target authenticate each
+- other via SPKM2:
+-
+- I-> Login (CSG,NSG=0,0 T=0)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- AuthMethod=SPKM1,SPKM2
+-
+- T-> Login-PR (CSG,NSG=0,0 T=0)
+- AuthMethod=SPKM2
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- SPKM_REQ=<spkm-req>
+-
+- (spkm-req is the SPKM-REQ token with the mutual-state bit in the
+- options field of the REQ-TOKEN not set)
+-
+- If the authentication is successful, the target proceeds with:
+-
+- T-> Login (CSG,NSG=0,1 T=1)
+-
+- The initiator may proceed:
+-
+- I-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- And at the end:
+-
+- I-> Login (CSG,NSG=1,3 T=1)
+- optional iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,3 T=1) "login accept"
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 222]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- In the next example, the initiator and target authenticate each
+- other via SRP:
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- AuthMethod=KRB5,SRP,None
+-
+- T-> Login-PR (CSG,NSG=0,0 T=0)
+- AuthMethod=SRP
+-
+- I-> Login (CSG,NSG=0,0 T=0)
+- SRP_U=<user>
+- TargetAuth=Yes
+-
+- T-> Login (CSG,NSG=0,0 T=0)
+- SRP_GROUP=SRP-1536,SRP-1024
+- SRP_s=<s>
+-
+- I-> Login (CSG,NSG=0,0 T=0)
+- SRP_GROUP=SRP-1536
+- SRP_A=<A>
+-
+- T-> Login (CSG,NSG=0,0 T=0)
+- SRP_B=<B>
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- SRP_M=<M>
+-
+- If the initiator authentication is successful, the target
+- proceeds:
+-
+- T-> Login (CSG,NSG=0,1 T=1)
+- SRP_HM=<H(A | M | K)>
+-
+- Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945].
+-
+- If the target authentication is not successful, the initiator
+- terminates the connection; otherwise, it proceeds.
+-
+- I-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 223]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- And at the end:
+-
+- I-> Login (CSG,NSG=1,3 T=1)
+- optional iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,3 T=1) "login accept"
+-
+- If the initiator authentication is not successful, the target
+- responds with:
+-
+- T-> Login "login reject"
+-
+- Instead of the T-> Login SRP_HM=<H(A | M | K)> message and
+- terminates the connection.
+-
+- In the next example, the initiator and target authenticate each
+- other via SRP:
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- AuthMethod=KRB5,SRP,None
+-
+- T-> Login-PR (CSG,NSG=0,0 T=0)
+- AuthMethod=SRP
+-
+- I-> Login (CSG,NSG=0,0 T=0)
+- SRP_U=<user>
+- TargetAuth=No
+-
+- T-> Login (CSG,NSG=0,0 T=0)
+- SRP_GROUP=SRP-1536
+- SRP_s=<s>
+-
+- I-> Login (CSG,NSG=0,0 T=0)
+- SRP_GROUP=SRP-1536
+- SRP_A=<A>
+-
+- T-> Login (CSG,NSG=0,0 T=0)
+- SRP_B=<B>
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- SRP_M=<M>
+-
+- If the initiator authentication is successful, the target
+- proceeds:
+-
+- T-> Login (CSG,NSG=0,1 T=1)
+-
+-
+-
+-Satran, et al. Standards Track [Page 224]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-
+- I-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- And at the end:
+-
+- I-> Login (CSG,NSG=1,3 T=1)
+- optional iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,3 T=1) "login accept"
+-
+- In the next example the initiator and target authenticate each other
+- via CHAP:
+-
+- I-> Login (CSG,NSG=0,0 T=0)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- AuthMethod=KRB5,CHAP,None
+-
+- T-> Login-PR (CSG,NSG=0,0 T=0)
+- AuthMethod=CHAP
+-
+- I-> Login (CSG,NSG=0,0 T=0)
+- CHAP_A=<A1,A2>
+-
+- T-> Login (CSG,NSG=0,0 T=0)
+- CHAP_A=<A1>
+- CHAP_I=<I>
+- CHAP_C=<C>
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- CHAP_N=<N>
+- CHAP_R=<R>
+- CHAP_I=<I>
+- CHAP_C=<C>
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 225]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- If the initiator authentication is successful, the target
+- proceeds:
+-
+- T-> Login (CSG,NSG=0,1 T=1)
+- CHAP_N=<N>
+- CHAP_R=<R>
+-
+- If the target authentication is not successful, the initiator
+- aborts the connection; otherwise, it proceeds.
+-
+- I-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+- T-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- And at the end:
+-
+- I-> Login (CSG,NSG=1,3 T=1)
+- optional iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,3 T=1) "login accept"
+-
+- If the initiator authentication is not successful, the target
+- responds with:
+-
+- T-> Login "login reject"
+-
+- Instead of the Login CHAP_R=<response> "proceed and change
+- stage" message and terminates the connection.
+-
+- In the next example, only the initiator is authenticated by the
+- target via CHAP:
+-
+- I-> Login (CSG,NSG=0,1 T=0)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- AuthMethod=KRB5,CHAP,None
+-
+- T-> Login-PR (CSG,NSG=0,0 T=0)
+- AuthMethod=CHAP
+-
+- I-> Login (CSG,NSG=0,0 T=0)
+- CHAP_A=<A1,A2>
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 226]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- T-> Login (CSG,NSG=0,0 T=0)
+- CHAP_A=<A1>
+- CHAP_I=<I>
+- CHAP_C=<C>
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- CHAP_N=<N>
+- CHAP_R=<R>
+-
+- If the initiator authentication is successful, the target
+- proceeds:
+-
+- T-> Login (CSG,NSG=0,1 T=1)
+-
+- I-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- And at the end:
+-
+- I-> Login (CSG,NSG=1,3 T=1)
+- optional iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,3 T=1) "login accept"
+-
+- In the next example, the initiator does not offer any security
+- parameters. It therefore may offer iSCSI parameters on the Login PDU
+- with the T bit set to 1, and the target may respond with a final
+- Login Response PDU immediately:
+-
+- I-> Login (CSG,NSG=1,3 T=1)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- ... iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,3 T=1) "login accept"
+- ... ISCSI parameters
+-
+- In the next example, the initiator does offer security
+- parameters on the Login PDU, but the target does not choose
+- any (i.e., chooses the "None" values):
+-
+- I-> Login (CSG,NSG=0,1 T=1)
+- InitiatorName=iqn.1999-07.com.os:hostid.77
+- TargetName=iqn.1999-07.com.example:diskarray.sn.88
+- AuthMethod=KRB5,SRP,None
+-
+-
+-
+-Satran, et al. Standards Track [Page 227]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-
+- T-> Login-PR (CSG,NSG=0,1 T=1)
+- AuthMethod=None
+-
+- I-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,0 T=0)
+- ... iSCSI parameters
+-
+- And at the end:
+-
+- I-> Login (CSG,NSG=1,3 T=1)
+- optional iSCSI parameters
+-
+- T-> Login (CSG,NSG=1,3 T=1) "login accept"
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 228]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Appendix D. SendTargets Operation
+-
+- To reduce the amount of configuration required on an initiator, iSCSI
+- provides the SendTargets text request. The initiator uses the
+- SendTargets request to get a list of targets to which it may have
+- access, as well as the list of addresses (IP address and TCP port) on
+- which these targets may be accessed.
+-
+- To make use of SendTargets, an initiator must first establish one of
+- two types of sessions. If the initiator establishes the session
+- using the key "SessionType=Discovery", the session is a discovery
+- session, and a target name does not need to be specified. Otherwise,
+- the session is a normal, operational session. The SendTargets
+- command MUST only be sent during the Full Feature Phase of a normal
+- or discovery session.
+-
+- A system that contains targets MUST support discovery sessions on
+- each of its iSCSI IP address-port pairs, and MUST support the
+- SendTargets command on the discovery session. In a discovery
+- session, a target MUST return all path information (target name and
+- IP address-port pairs and portal group tags) for the targets on the
+- target network entity which the requesting initiator is authorized to
+- access.
+-
+- A target MUST support the SendTargets command on operational
+- sessions; these will only return path information about the target to
+- which the session is connected, and do not need to return information
+- about other target names that may be defined in the responding
+- system.
+-
+- An initiator MAY make use of the SendTargets as it sees fit.
+-
+- A SendTargets command consists of a single Text request PDU. This
+- PDU contains exactly one text key and value. The text key MUST be
+- SendTargets. The expected response depends upon the value, as well
+- as whether the session is a discovery or operational session.
+-
+- The value must be one of:
+-
+- All
+-
+- The initiator is requesting that information on all relevant
+- targets known to the implementation be returned. This value
+- MUST be supported on a discovery session, and MUST NOT be
+- supported on an operational session.
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 229]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- <iSCSI-target-name>
+-
+- If an iSCSI target name is specified, the session should respond
+- with addresses for only the named target, if possible. This
+- value MUST be supported on discovery sessions. A discovery
+- session MUST be capable of returning addresses for those
+- targets that would have been returned had value=All had been
+- designated.
+-
+- <nothing>
+-
+- The session should only respond with addresses for the target to
+- which the session is logged in. This MUST be supported on
+- operational sessions, and MUST NOT return targets other than
+- the one to which the session is logged in.
+-
+- The response to this command is a text response that contains a list
+- of zero or more targets and, optionally, their addresses. Each
+- target is returned as a target record. A target record begins with
+- the TargetName text key, followed by a list of TargetAddress text
+- keys, and bounded by the end of the text response or the next
+- TargetName key, which begins a new record. No text keys other than
+- TargetName and TargetAddress are permitted within a SendTargets
+- response.
+-
+- For the format of the TargetName, see Section 12.4 TargetName.
+-
+- In a discovery session, a target MAY respond to a SendTargets request
+- with its complete list of targets, or with a list of targets that is
+- based on the name of the initiator logged in to the session.
+-
+- A SendTargets response MUST NOT contain target names if there are no
+- targets for the requesting initiator to access.
+-
+- Each target record returned includes zero or more TargetAddress
+- fields.
+-
+- Each target record starts with one text key of the form:
+-
+- TargetName=<target-name-goes-here>
+-
+- Followed by zero or more address keys of the form:
+-
+- TargetAddress=<hostname-or-ipaddress>[:<tcp-port>],
+- <portal-group-tag>
+-
+- The hostname-or-ipaddress contains a domain name, IPv4 address, or
+- IPv6 address, as specified for the TargetAddress key.
+-
+-
+-
+-Satran, et al. Standards Track [Page 230]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- A hostname-or-ipaddress duplicated in TargetAddress responses for a
+- given node (the port is absent or equal) would probably indicate that
+- multiple address families are in use at once (IPV6 and IPV4).
+-
+- Each TargetAddress belongs to a portal group, identified by its
+- numeric portal group tag (as in Section 12.9 TargetPortalGroupTag).
+- The iSCSI target name, together with this tag, constitutes the SCSI
+- port identifier; the tag only needs to be unique within a given
+- target's name list of addresses.
+-
+- Multiple-connection sessions can span iSCSI addresses that belong to
+- the same portal group.
+-
+- Multiple-connection sessions cannot span iSCSI addresses that belong
+- to different portal groups.
+-
+- If a SendTargets response reports an iSCSI address for a target, it
+- SHOULD also report all other addresses in its portal group in the
+- same response.
+-
+- A SendTargets text response can be longer than a single Text Response
+- PDU, and makes use of the long text responses as specified.
+-
+- After obtaining a list of targets from the discovery target session,
+- an iSCSI initiator may initiate new sessions to log in to the
+- discovered targets for full operation. The initiator MAY keep the
+- discovery session open, and MAY send subsequent SendTargets commands
+- to discover new targets.
+-
+- Examples:
+-
+- This example is the SendTargets response from a single target that
+- has no other interface ports.
+-
+- Initiator sends text request that contains:
+-
+- SendTargets=All
+-
+- Target sends a text response that contains:
+-
+- TargetName=iqn.1993-11.com.example:diskarray.sn.8675309
+-
+- All the target had to return in the simple case was the target name.
+- It is assumed by the initiator that the IP address and TCP port for
+- this target are the same as used on the current connection to the
+- default iSCSI target.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 231]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- The next example has two internal iSCSI targets, each accessible via
+- two different ports with different IP addresses. The following is
+- the text response:
+-
+- TargetName=iqn.1993-11.com.example:diskarray.sn.8675309
+- TargetAddress=10.1.0.45:3000,1 TargetAddress=10.1.1.45:3000,2
+- TargetName=iqn.1993-11.com.example:diskarray.sn.1234567
+- TargetAddress=10.1.0.45:3000,1 TargetAddress=10.1.1.45:3000,2
+-
+- Both targets share both addresses; the multiple addresses are likely
+- used to provide multi-path support. The initiator may connect to
+- either target name on either address. Each of the addresses has its
+- own portal group tag; they do not support spanning
+- multiple-connection sessions with each other. Keep in mind that the
+- portal group tags for the two named targets are independent of one
+- another; portal group "1" on the first target is not necessarily the
+- same as portal group "1" on the second target.
+-
+- In the above example, a DNS host name or an IPv6 address could have
+- been returned instead of an IPv4 address.
+-
+- The next text response shows a target that supports spanning sessions
+- across multiple addresses, and further illustrates the use of the
+- portal group tags:
+-
+- TargetName=iqn.1993-11.com.example:diskarray.sn.8675309
+-
+- TargetAddress=10.1.0.45:3000,1 TargetAddress=10.1.1.46:3000,1
+- TargetAddress=10.1.0.47:3000,2 TargetAddress=10.1.1.48:3000,2
+- TargetAddress=10.1.1.49:3000,3
+-
+- In this example, any of the target addresses can be used to reach the
+- same target. A single-connection session can be established to any
+- of these TCP addresses. A multiple-connection session could span
+- addresses .45 and .46 or .47 and .48, but cannot span any other
+- combination. A TargetAddress with its own tag (.49) cannot be
+- combined with any other address within the same session.
+-
+- This SendTargets response does not indicate whether .49 supports
+- multiple connections per session; it is communicated via the
+- MaxConnections text key upon login to the target.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 232]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Appendix E. Algorithmic Presentation of Error Recovery Classes
+-
+- This appendix illustrates the error recovery classes using a
+- pseudo-programming-language. The procedure names are chosen to be
+- obvious to most implementers. Each of the recovery classes described
+- has initiator procedures as well as target procedures. These
+- algorithms focus on outlining the mechanics of error recovery
+- classes, and do not exhaustively describe all other aspects/cases.
+- Examples of this approach are:
+-
+-
+- - Handling for only certain Opcode types is shown.
+-
+- - Only certain reason codes (e.g., Recovery in Logout command)
+- are outlined.
+-
+- - Resultant cases, such as recovery of Synchronization on a
+- header digest error are considered out-of-scope in these
+- algorithms. In this particular example, a header digest error
+- may lead to connection recovery if some type of sync and
+- steering layer is not implemented.
+-
+- These algorithms strive to convey the iSCSI error recovery concepts
+- in the simplest terms, and are not designed to be optimal.
+-
+-E.1. General Data Structure and Procedure Description
+-
+- This section defines the procedures and data structures that are
+- commonly used by all the error recovery algorithms. The structures
+- may not be the exhaustive representations of what is required for a
+- typical implementation.
+-
+- Data structure definitions -
+- struct TransferContext {
+- int TargetTransferTag;
+- int ExpectedDataSN;
+- };
+-
+- struct TCB { /* task control block */
+- Boolean SoFarInOrder;
+- int ExpectedDataSN; /* used for both R2Ts, and Data */
+- int MissingDataSNList[MaxMissingDPDU];
+- Boolean FbitReceived;
+- Boolean StatusXferd;
+- Boolean CurrentlyAllegiant;
+- int ActiveR2Ts;
+- int Response;
+- char *Reason;
+-
+-
+-
+-Satran, et al. Standards Track [Page 233]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- struct TransferContext
+- TransferContextList[MaxOutStandingR2T];
+- int InitiatorTaskTag;
+- int CmdSN;
+-
+- int SNACK_Tag;
+-
+- };
+-
+- struct Connection {
+- struct Session SessionReference;
+- Boolean SoFarInOrder;
+- int CID;
+- int State;
+-
+- int CurrentTimeout;
+- int ExpectedStatSN;
+- int MissingStatSNList[MaxMissingSPDU];
+- Boolean PerformConnectionCleanup;
+- };
+-
+- struct Session {
+- int NumConnections;
+- int CmdSN;
+- int Maxconnections;
+- int ErrorRecoveryLevel;
+- struct iSCSIEndpoint OtherEndInfo;
+- struct Connection ConnectionList[MaxSupportedConns];
+- };
+-
+- Procedure descriptions -
+- Receive-a-In-PDU(transport connection, inbound PDU);
+- check-basic-validity(inbound PDU);
+- Start-Timer(timeout handler, argument, timeout value);
+- Build-And-Send-Reject(transport connection, bad PDU, reason code);
+-
+-E.2. Within-command Error Recovery Algorithms
+-
+-E.2.1. Procedure Descriptions
+-
+- Recover-Data-if-Possible(last required DataSN, task control
+- block);
+- Build-And-Send-DSnack(task control block);
+- Build-And-Send-RDSnack(task control block);
+- Build-And-Send-Abort(task control block);
+- SCSI-Task-Completion(task control block);
+- Build-And-Send-A-Data-Burst(transport connection, data-descriptor,
+- task control block);
+-
+-
+-
+-Satran, et al. Standards Track [Page 234]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Build-And-Send-R2T(transport connection, data-descriptor,
+- task control block);
+- Build-And-Send-Status(transport connection, task control block);
+- Transfer-Context-Timeout-Handler(transfer context);
+-
+-
+- Notes:
+-
+- - One procedure used in this section: Handle-Status-SNACK-
+- request is defined in Within-connection recovery algorithms.
+-
+- - The Response processing pseudo-code, shown in the target
+- algorithms, applies to all solicited PDUs that carry StatSN -
+- SCSI Response, Text Response etc.
+-
+-E.2.2. Initiator Algorithms
+-
+-Recover-Data-if-Possible(LastRequiredDataSN, TCB)
+-{
+- if (operational ErrorRecoveryLevel > 0) {
+- if (# of missing PDUs is trackable) {
+- Note the missing DataSNs in TCB.
+- if (the task spanned a change in
+- MaxRecvDataSegmentLength) {
+- if (TCB.StatusXferd is TRUE)
+- drop the status PDU;
+- Build-And-Send-RDSnack(TCB);
+- } else {
+- Build-And-Send-DSnack(TCB);
+- }
+- } else {
+- TCB.Reason = "Protocol service CRC error";
+- }
+- } else {
+- TCB.Reason = "Protocol service CRC error";
+- }
+- if (TCB.Reason == "Protocol service CRC error") {
+- Clear the missing PDU list in the TCB.
+- if (TCB.StatusXferd is not TRUE)
+- Build-And-Send-Abort(TCB);
+- }
+-}
+-
+-Receive-a-In-PDU(Connection, CurrentPDU)
+-{
+- check-basic-validity(CurrentPDU);
+- if (Header-Digest-Bad) discard, return;
+- Retrieve TCB for CurrentPDU.InitiatorTaskTag.
+-
+-
+-
+-Satran, et al. Standards Track [Page 235]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- if ((CurrentPDU.type == Data)
+- or (CurrentPDU.type = R2T)) {
+- if (Data-Digest-Bad for Data) {
+- send-data-SNACK = TRUE;
+- LastRequiredDataSN = CurrentPDU.DataSN;
+- } else {
+- if (TCB.SoFarInOrder = TRUE) {
+- if (current DataSN is expected) {
+- Increment TCB.ExpectedDataSN.
+- } else {
+-
+- TCB.SoFarInOrder = FALSE;
+- send-data-SNACK = TRUE;
+- }
+- } else {
+- if (current DataSN was considered missing) {
+- remove current DataSN from missing PDU list.
+- } else if (current DataSN is higher than expected)
+-{
+- send-data-SNACK = TRUE;
+- } else {
+- discard, return;
+- }
+- Adjust TCB.ExpectedDataSN if appropriate.
+- }
+- LastRequiredDataSN = CurrentPDU.DataSN - 1;
+- }
+- if (send-data-SNACK is TRUE and
+- task is not already considered failed) {
+- Recover-Data-if-Possible(LastRequiredDataSN, TCB);
+- }
+- if (missing data PDU list is empty) {
+- TCB.SoFarInOrder = TRUE;
+- }
+- if (CurrentPDU.type == R2T) {
+- Increment ActiveR2Ts for this task.
+-
+- Create a data-descriptor for the data burst.
+- Build-And-Send-A-Data-Burst(Connection, data-descriptor,
+-
+- TCB);
+- }
+- } else if (CurrentPDU.type == Response) {
+- if (Data-Digest-Bad) {
+- send-status-SNACK = TRUE;
+- } else {
+- TCB.StatusXferd = TRUE;
+- Store the status information in TCB.
+-
+-
+-
+-Satran, et al. Standards Track [Page 236]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- if (ExpDataSN does not match) {
+- TCB.SoFarInOrder = FALSE;
+- Recover-Data-if-Possible(current DataSN, TCB);
+- }
+- if (missing data PDU list is empty) {
+- TCB.SoFarInOrder = TRUE;
+- }
+- }
+- } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT
+- SHOWN */
+- }
+- if ((TCB.SoFarInOrder == TRUE) and
+- (TCB.StatusXferd == TRUE)) {
+- SCSI-Task-Completion(TCB);
+- }
+-}
+-
+-E.2.3. Target Algorithms
+-
+-Receive-a-In-PDU(Connection, CurrentPDU)
+-{
+- check-basic-validity(CurrentPDU);
+- if (Header-Digest-Bad) discard, return;
+- Retrieve TCB for CurrentPDU.InitiatorTaskTag.
+- if (CurrentPDU.type == Data) {
+- Retrieve TContext from CurrentPDU.TargetTransferTag;
+- if (Data-Digest-Bad) {
+- Build-And-Send-Reject(Connection, CurrentPDU,
+- Payload-Digest-Error);
+- Note the missing data PDUs in MissingDataRange[].
+- send-recovery-R2T = TRUE;
+- } else {
+- if (current DataSN is not expected) {
+- Note the missing data PDUs in MissingDataRange[].
+- send-recovery-R2T = TRUE;
+- }
+- if (CurrentPDU.Fbit == TRUE) {
+- if (current PDU is solicited) {
+- Decrement TCB.ActiveR2Ts.
+- }
+- if ((current PDU is unsolicited and
+- data received is less than I/O length and
+- data received is less than FirstBurstLength)
+- or (current PDU is solicited and the length of
+- this burst is less than expected)) {
+- send-recovery-R2T = TRUE;
+- Note the missing data in MissingDataRange[].
+- }
+-
+-
+-
+-Satran, et al. Standards Track [Page 237]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- }
+- }
+- Increment TContext.ExpectedDataSN.
+- if (send-recovery-R2T is TRUE and
+- task is not already considered failed) {
+- if (operational ErrorRecoveryLevel > 0) {
+- Increment TCB.ActiveR2Ts.
+- Create a data-descriptor for the data burst
+- from MissingDataRange.
+- Build-And-Send-R2T(Connection, data-descriptor, TCB);
+- } else {
+- if (current PDU is the last unsolicited)
+- TCB.Reason = "Not enough unsolicited data";
+- else
+- TCB.Reason = "Protocol service CRC error";
+- }
+- }
+- if (TCB.ActiveR2Ts == 0) {
+- Build-And-Send-Status(Connection, TCB);
+- }
+- } else if (CurrentPDU.type == SNACK) {
+- snack-failure = FALSE;
+- if (operational ErrorRecoveryLevel > 0) {
+- if (CurrentPDU.type == Data/R2T) {
+- if (the request is satisfiable) {
+-
+- if (request for Data) {
+- Create a data-descriptor for the data burst
+- from BegRun and RunLength.
+- Build-And-Send-A-Data-Burst(Connection,
+-
+- data-descriptor, TCB);
+- } else { /* R2T */
+- Create a data-descriptor for the data burst
+- from BegRun and RunLength.
+- Build-And-Send-R2T(Connection, data-descriptor,
+- TCB);
+- }
+- } else {
+- snack-failure = TRUE;
+- }
+- } else if (CurrentPDU.type == status) {
+- Handle-Status-SNACK-request(Connection, CurrentPDU);
+- } else if (CurrentPDU.type == DataACK) {
+- Consider all data upto CurrentPDU.BegRun as
+- acknowledged.
+- Free up the retransmission resources for that data.
+- } else if (CurrentPDU.type == R-Data SNACK) {
+-
+-
+-
+-Satran, et al. Standards Track [Page 238]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Create a data descriptor for a data burst covering
+- all unacknowledged data.
+- Build-And-Send-A-Data-Burst(Connection,
+- data-descriptor, TCB);
+- TCB.SNACK_Tag = CurrentPDU.SNACK_Tag;
+- if (there's no more data to send) {
+- Build-And-Send-Status(Connection, TCB);
+- }
+- }
+- } else { /* operational ErrorRecoveryLevel = 0 */
+- snack-failure = TRUE;
+-
+- }
+- if (snack-failure == TRUE) {
+- Build-And-Send-Reject(Connection, CurrentPDU,
+- SNACK-Reject);
+- if (TCB.StatusXferd != TRUE) {
+- TCB.Reason = "SNACK Rejected";
+- Build-And-Send-Status(Connection, TCB);
+- }
+- }
+-
+- } else { /* REST UNRELATED TO WITHIN-COMMAND-RECOVERY, NOT SHOWN */
+- }
+-}
+-
+-Transfer-Context-Timeout-Handler(TContext)
+-{
+- Retrieve TCB and Connection from TContext.
+- Decrement TCB.ActiveR2Ts.
+- if (operational ErrorRecoveryLevel > 0 and
+- task is not already considered failed) {
+- Note the missing data PDUs in MissingDataRange[].
+- Create a data-descriptor for the data burst
+- from MissingDataRange[].
+- Build-And-Send-R2T(Connection, data-descriptor, TCB);
+- } else {
+- TCB.Reason = "Protocol service CRC error";
+- if (TCB.ActiveR2Ts = 0) {
+- Build-And-Send-Status(Connection, TCB);
+- }
+- }
+-}
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 239]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-E.3. Within-connection Recovery Algorithms
+-
+-E.3.1. Procedure Descriptions
+-
+-Procedure descriptions:
+-Recover-Status-if-Possible(transport connection,
+- currently received PDU);
+-Evaluate-a-StatSN(transport connection, currently received PDU);
+-Retransmit-Command-if-Possible(transport connection, CmdSN);
+-Build-And-Send-SSnack(transport connection);
+-Build-And-Send-Command(transport connection, task control block);
+-Command-Acknowledge-Timeout-Handler(task control block);
+-Status-Expect-Timeout-Handler(transport connection);
+-Build-And-Send-Nop-Out(transport connection);
+-Handle-Status-SNACK-request(transport connection, status SNACK
+-PDU);
+-Retransmit-Status-Burst(status SNACK, task control block);
+-Is-Acknowledged(beginning StatSN, run length);
+-
+-Implementation-specific tunables:
+-InitiatorProactiveSNACKEnabled
+-
+- Notes:
+-
+- - The initiator algorithms only deal with unsolicited Nop-In PDUs
+- for generating status SNACKs. A solicited Nop-In PDU has an
+- assigned StatSN, which, when out of order, could trigger the
+- out of order StatSN handling in Within-command algorithms,
+- again leading to Recover-Status-if-Possible.
+-
+-
+- - The pseudo-code shown may result in the retransmission of
+- unacknowledged commands in more cases than necessary. This
+- will not, however, affect the correctness of the operation
+- because the target is required to discard the duplicate CmdSNs.
+-
+- - The procedure Build-And-Send-Async is defined in the Connection
+- recovery algorithms.
+-
+- - The procedure Status-Expect-Timeout-Handler describes how
+- initiators may proactively attempt to retrieve the Status if
+- they so choose. This procedure is assumed to be triggered much
+- before the standard ULP timeout.
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 240]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-E.3.2. Initiator Algorithms
+-
+-Recover-Status-if-Possible(Connection, CurrentPDU)
+-{
+- if ((Connection.state == LOGGED_IN) and
+- connection is not already considered failed) {
+- if (operational ErrorRecoveryLevel > 0) {
+- if (# of missing PDUs is trackable) {
+- Note the missing StatSNs in Connection
+- that were not already requested with SNACK;
+- Build-And-Send-SSnack(Connection);
+- } else {
+- Connection.PerformConnectionCleanup = TRUE;
+- }
+- } else {
+- Connection.PerformConnectionCleanup = TRUE;
+- }
+- if (Connection.PerformConnectionCleanup == TRUE) {
+- Start-Timer(Connection-Cleanup-Handler, Connection, 0);
+- }
+- }
+-}
+-
+-Retransmit-Command-if-Possible(Connection, CmdSN)
+-{
+-
+- if (operational ErrorRecoveryLevel > 0) {
+- Retrieve the InitiatorTaskTag, and thus TCB for the CmdSN.
+- Build-And-Send-Command(Connection, TCB);
+- }
+-}
+-
+-Evaluate-a-StatSN(Connection, CurrentPDU)
+-{
+- send-status-SNACK = FALSE;
+- if (Connection.SoFarInOrder == TRUE) {
+- if (current StatSN is the expected) {
+- Increment Connection.ExpectedStatSN.
+- } else {
+- Connection.SoFarInOrder = FALSE;
+- send-status-SNACK = TRUE;
+- }
+- } else {
+- if (current StatSN was considered missing) {
+- remove current StatSN from the missing list.
+- } else {
+- if (current StatSN is higher than expected){
+- send-status-SNACK = TRUE;
+-
+-
+-
+-Satran, et al. Standards Track [Page 241]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- } else {
+- send-status-SNACK = FALSE;
+- discard the PDU;
+- }
+- }
+- Adjust Connection.ExpectedStatSN if appropriate.
+- if (missing StatSN list is empty) {
+- Connection.SoFarInOrder = TRUE;
+- }
+- }
+- return send-status-SNACK;
+-}
+-
+-Receive-a-In-PDU(Connection, CurrentPDU)
+-{
+- check-basic-validity(CurrentPDU);
+- if (Header-Digest-Bad) discard, return;
+- Retrieve TCB for CurrentPDU.InitiatorTaskTag.
+- if (CurrentPDU.type == Nop-In) {
+- if (the PDU is unsolicited) {
+- if (current StatSN is not expected) {
+- Recover-Status-if-Possible(Connection,
+- CurrentPDU);
+- }
+- if (current ExpCmdSN is not Session.CmdSN) {
+- Retransmit-Command-if-Possible(Connection,
+- CurrentPDU.ExpCmdSN);
+- }
+- }
+- } else if (CurrentPDU.type == Reject) {
+- if (it is a data digest error on immediate data) {
+- Retransmit-Command-if-Possible(Connection,
+- CurrentPDU.BadPDUHeader.CmdSN);
+- }
+- } else if (CurrentPDU.type == Response) {
+- send-status-SNACK = Evaluate-a-StatSN(Connection,
+- CurrentPDU);
+- if (send-status-SNACK == TRUE)
+- Recover-Status-if-Possible(Connection, CurrentPDU);
+- } else { /* REST UNRELATED TO WITHIN-CONNECTION-RECOVERY,
+- * NOT SHOWN */
+- }
+-}
+-
+-Command-Acknowledge-Timeout-Handler(TCB)
+-{
+- Retrieve the Connection for TCB.
+- Retransmit-Command-if-Possible(Connection, TCB.CmdSN);
+-
+-
+-
+-Satran, et al. Standards Track [Page 242]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-}
+-
+-Status-Expect-Timeout-Handler(Connection)
+-{
+- if (operational ErrorRecoveryLevel > 0) {
+- Build-And-Send-Nop-Out(Connection);
+- } else if (InitiatorProactiveSNACKEnabled){
+- if ((Connection.state == LOGGED_IN) and
+- connection is not already considered failed) {
+- Build-And-Send-SSnack(Connection);
+- }
+- }
+-}
+-
+-E.3.3. Target Algorithms
+-
+-Handle-Status-SNACK-request(Connection, CurrentPDU)
+-{
+- if (operational ErrorRecoveryLevel > 0) {
+- if (request for an acknowledged run) {
+- Build-And-Send-Reject(Connection, CurrentPDU,
+- Protocol-Error);
+- } else if (request for an untransmitted run) {
+- discard, return;
+- } else {
+- Retransmit-Status-Burst(CurrentPDU, TCB);
+- } else {
+- Build-And-Send-Async(Connection, DroppedConnection,
+- DefaultTime2Wait,
+- DefaultTime2Retain);
+- }
+-}
+-
+-E.4. Connection Recovery Algorithms
+-
+-E.4.1. Procedure Descriptions
+-
+-Build-And-Send-Async(transport connection, reason code,
+- minimum time, maximum time);
+-Pick-A-Logged-In-Connection(session);
+-Build-And-Send-Logout(transport connection, logout connection
+- identifier, reason code);
+-PerformImplicitLogout(transport connection, logout connection
+- identifier, target information);
+-PerformLogin(transport connection, target information);
+-CreateNewTransportConnection(target information);
+-Build-And-Send-Command(transport connection, task control block);
+-Connection-Cleanup-Handler(transport connection);
+-
+-
+-
+-Satran, et al. Standards Track [Page 243]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Connection-Resource-Timeout-Handler(transport connection);
+-Quiesce-And-Prepare-for-New-Allegiance(session, task control
+-block);
+-Build-And-Send-Logout-Response(transport connection,
+- CID of connection in recovery, reason
+-code);
+-Build-And-Send-TaskMgmt-Response(transport connection,
+- task mgmt command PDU, response code);
+-Establish-New-Allegiance(task control block, transport
+-connection);
+-Schedule-Command-To-Continue(task control block);
+-
+-Notes:
+- - Transport exception conditions, such as unexpected connection
+- termination, connection reset, and hung connection while the
+- connection is in the full-feature phase, are all assumed to be
+- asynchronously signaled to the iSCSI layer using the
+- Transport_Exception_Handler procedure.
+-
+-E.4.2. Initiator Algorithms
+-
+- Receive-a-In-PDU(Connection, CurrentPDU) {
+- check-basic-validity(CurrentPDU);
+- if (Header-Digest-Bad) discard, return;
+-
+- Retrieve TCB from CurrentPDU.InitiatorTaskTag.
+- if (CurrentPDU.type == Async) {
+- if (CurrentPDU.AsyncEvent == ConnectionDropped) {
+- Retrieve the AffectedConnection for
+- CurrentPDU.Parameter1.
+- AffectedConnection.CurrentTimeout =
+- CurrentPDU.Parameter3;
+- AffectedConnection.State = CLEANUP_WAIT;
+- Start-Timer(Connection-Cleanup-Handler,
+- AffectedConnection,
+- CurrentPDU.Parameter2);
+- } else if (CurrentPDU.AsyncEvent == LogoutRequest)) {
+- AffectedConnection = Connection;
+- AffectedConnection.State = LOGOUT_REQUESTED;
+- AffectedConnection.PerformConnectionCleanup = TRUE;
+- AffectedConnection.CurrentTimeout =
+- CurrentPDU.Parameter3;
+- Start-Timer(Connection-Cleanup-Handler,
+- AffectedConnection, 0);
+- } else if (CurrentPDU.AsyncEvent == SessionDropped)) {
+- for (each Connection) {
+- Connection.State = CLEANUP_WAIT;
+- Connection.CurrentTimeout = CurrentPDU.Parameter3;
+-
+-
+-
+-Satran, et al. Standards Track [Page 244]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Start-Timer(Connection-Cleanup-Handler,
+- Connection, CurrentPDU.Parameter2);
+- }
+- Session.state = FAILED;
+- }
+-
+- } else if (CurrentPDU.type == LogoutResponse) {
+- Retrieve the CleanupConnection for CurrentPDU.CID.
+- if (CurrentPDU.Response = failure) {
+- CleanupConnection.State = CLEANUP_WAIT;
+- } else {
+- CleanupConnection.State = FREE;
+- }
+- } else if (CurrentPDU.type == LoginResponse) {
+- if (this is a response to an implicit Logout) {
+- Retrieve the CleanupConnection.
+- if (successful) {
+- CleanupConnection.State = FREE;
+- Connection.State = LOGGED_IN;
+- } else {
+- CleanupConnection.State = CLEANUP_WAIT;
+- DestroyTransportConnection(Connection);
+- }
+- }
+- } else { /* REST UNRELATED TO CONNECTION-RECOVERY,
+-
+- * NOT SHOWN */
+- }
+- if (CleanupConnection.State == FREE) {
+- for (each command that was active on CleanupConnection) {
+- /* Establish new connection allegiance */
+- NewConnection = Pick-A-Logged-In-Connection(Session);
+- Build-And-Send-Command(NewConnection, TCB);
+- }
+- } }
+-
+- Connection-Cleanup-Handler(Connection) {
+- Retrieve Session from Connection.
+- if (Connection can still exchange iSCSI PDUs) {
+- NewConnection = Connection;
+- } else {
+- Start-Timer(Connection-Resource-Timeout-Handler,
+- Connection, Connection.CurrentTimeout);
+- if (there are other logged-in connections) {
+- NewConnection = Pick-A-Logged-In-
+- Connection(Session);
+- } else {
+- NewConnection =
+-
+-
+-
+-Satran, et al. Standards Track [Page 245]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- CreateTransportConnection(Session.OtherEndInfo);
+- Initiate an implicit Logout on NewConnection for
+- Connection.CID.
+- return;
+- }
+- }
+- Build-And-Send-Logout(NewConnection, Connection.CID,
+- RecoveryRemove); }
+-
+- Transport_Exception_Handler(Connection) {
+- Connection.PerformConnectionCleanup = TRUE;
+- if (the event is an unexpected transport disconnect) {
+- Connection.State = CLEANUP_WAIT;
+-
+- Connection.CurrentTimeout = DefaultTime2Retain;
+- Start-Timer(Connection-Cleanup-Handler, Connection,
+- DefaultTime2Wait);
+-
+- } else {
+- Connection.State = FREE;
+- } }
+-
+-E.4.3. Target Algorithms
+-
+- Receive-a-In-PDU(Connection, CurrentPDU)
+- {
+- check-basic-validity(CurrentPDU);
+- if (Header-Digest-Bad) discard, return;
+- else if (Data-Digest-Bad) {
+- Build-And-Send-Reject(Connection, CurrentPDU,
+- Payload-Digest-Error);
+- discard, return;
+- }
+- Retrieve TCB and Session.
+- if (CurrentPDU.type == Logout) {
+- if (CurrentPDU.ReasonCode = RecoveryRemove) {
+- Retrieve the CleanupConnection from CurrentPDU.CID).
+- for (each command active on CleanupConnection) {
+- Quiesce-And-Prepare-for-New-Allegiance(Session,
+- TCB);
+- TCB.CurrentlyAllegiant = FALSE;
+- }
+- Cleanup-Connection-State(CleanupConnection);
+- if ((quiescing successful) and (cleanup successful)) {
+- Build-And-Send-Logout-Response(Connection,
+- CleanupConnection.CID, Success);
+- } else {
+- Build-And-Send-Logout-Response(Connection,
+-
+-
+-
+-Satran, et al. Standards Track [Page 246]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- CleanupConnection.CID, Failure);
+- }
+- }
+- } else if ((CurrentPDU.type == Login) and
+- operational ErrorRecoveryLevel == 2) {
+- Retrieve the CleanupConnection from CurrentPDU.CID).
+- for (each command active on CleanupConnection) {
+- Quiesce-And-Prepare-for-New-Allegiance(Session, TCB);
+- TCB.CurrentlyAllegiant = FALSE;
+- }
+- Cleanup-Connection-State(CleanupConnection);
+- if ((quiescing successful) and (cleanup successful)) {
+- Continue with the rest of the Login processing;
+- } else {
+- Build-And-Send-Login-Response(Connection,
+- CleanupConnection.CID, Target Error);
+- }
+- }
+-
+- } else if (CurrentPDU.type == TaskManagement) {
+- if (CurrentPDU.function == "TaskReassign") {
+- if (Session.ErrorRecoveryLevel < 2) {
+- Build-And-Send-TaskMgmt-Response(Connection,
+- CurrentPDU, "Allegiance reassignment
+- not supported");
+- } else if (task is not found) {
+- Build-And-Send-TaskMgmt-Response(Connection,
+- CurrentPDU, "Task not in task set");
+- } else if (task is currently allegiant) {
+- Build-And-Send-TaskMgmt-Response(Connection,
+- CurrentPDU, "Task still allegiant");
+- } else {
+- Establish-New-Allegiance(TCB, Connection);
+- TCB.CurrentlyAllegiant = TRUE;
+- Schedule-Command-To-Continue(TCB);
+- }
+- }
+- } else { /* REST UNRELATED TO CONNECTION-RECOVERY,
+- * NOT SHOWN */
+- }
+- }
+-
+- Transport_Exception_Handler(Connection)
+- {
+- Connection.PerformConnectionCleanup = TRUE;
+- if (the event is an unexpected transport disconnect) {
+- Connection.State = CLEANUP_WAIT;
+- Start-Timer(Connection-Resource-Timeout-Handler,
+-
+-
+-
+-Satran, et al. Standards Track [Page 247]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Connection,
+-
+- (DefaultTime2Wait+DefaultTime2Retain));
+- if (this Session has full-feature phase connections
+- left)
+- {
+- DifferentConnection =
+- Pick-A-Logged-In-Connection(Session);
+- Build-And-Send-Async(DifferentConnection,
+- DroppedConnection, DefaultTime2Wait,
+- DefaultTime2Retain);
+- }
+- } else {
+- Connection.State = FREE;
+- }
+- }
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 248]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Appendix F. Clearing Effects of Various Events on Targets
+-
+-F.1. Clearing Effects on iSCSI Objects
+-
+- The following tables describe the target behavior on receiving the
+- events specified in the rows of the table. The second table is an
+- extension of the first table and defines clearing actions for more
+- objects on the same events. The legend is:
+-
+- Y = Yes (cleared/discarded/reset on the event specified in the
+- row). Unless otherwise noted, the clearing action is only
+- applicable for the issuing initiator port.
+- N = No (not affected on the event specified in the row, i.e.,
+- stays at previous value).
+- NA = Not Applicable or Not Defined.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 249]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- +-----+-----+-----+-----+-----+
+- |IT(1)|IC(2)|CT(5)|ST(6)|PP(7)|
+- +---------------------+-----+-----+-----+-----+-----+
+- |connection failure(8)|Y |Y |N |N |Y |
+- +---------------------+-----+-----+-----+-----+-----+
+- |connection state |NA |NA |Y |N |NA |
+- |timeout (9) | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |session timeout/ |Y |Y |Y |Y |Y(14)|
+- |closure/reinstatement| | | | | |
+- |(10) | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |session continuation |NA |NA |N(11)|N |NA |
+- |(12) | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |successful connection|Y |Y |Y |N |Y(13)|
+- |close logout | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |session failure (18) |Y |Y |N |N |Y |
+- +---------------------+-----+-----+-----+-----+-----+
+- |successful recovery |Y |Y |N |N |Y(13)|
+- |Logout | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |failed Logout |Y |Y |N |N |Y |
+- +---------------------+-----+-----+-----+-----+-----+
+- |connection Login |NA |NA |NA |Y(15)|NA |
+- |(leading) | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |connection Login |NA |NA |N(11)|N |Y |
+- |(non-leading) | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |target cold reset(16)|Y |Y |Y |Y |Y |
+- +---------------------+-----+-----+-----+-----+-----+
+- |target warm reset(16)|Y |Y |Y |Y |Y |
+- +---------------------+-----+-----+-----+-----+-----+
+- |LU reset(19) |Y |Y |Y |Y |Y |
+- +---------------------+-----+-----+-----+-----+-----+
+- |powercycle(16) |Y |Y |Y |Y |Y |
+- +---------------------+-----+-----+-----+-----+-----+
+-
+- 1. Incomplete TTTs - Target Transfer Tags on which the target is
+- still expecting PDUs to be received. Examples include TTTs received
+- via R2T, NOP-IN, etc.
+-
+- 2. Immediate Commands - immediate commands, but waiting for
+- execution on a target. For example, Abort Task Set.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 250]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 5. Connection Tasks - tasks that are active on the iSCSI connection
+- in question.
+-
+- 6. Session Tasks - tasks that are active on the entire iSCSI
+- session. A union of "connection tasks" on all participating
+- connections.
+-
+- 7. Partial PDUs (if any) - PDUs that are partially sent and waiting
+- for transport window credit to complete the transmission.
+-
+- 8. Connection failure is a connection exception condition - one of
+- the transport connections shutdown, transport connections reset, or
+- transport connections timed out, which abruptly terminated the iSCSI
+- full-feature phase connection. A connection failure always takes the
+- connection state machine to the CLEANUP_WAIT state.
+-
+- 9. Connection state timeout happens if a connection spends more time
+- that agreed upon during Login negotiation in the CLEANUP_WAIT state,
+- and this takes the connection to the FREE state (M1 transition in
+- connection cleanup state diagram).
+-
+- 10. These are defined in Section 5.3.5 Session Reinstatement,
+- Closure, and Timeout.
+-
+- 11. This clearing effect is "Y" only if it is a connection
+- reinstatement and the operational ErrorRecoveryLevel is less than 2.
+-
+- 12. Session continuation is defined in Section 5.3.6 Session
+- Continuation and Failure.
+-
+- 13. This clearing effect is only valid if the connection is being
+- logged out on a different connection and when the connection being
+- logged out on the target may have some partial PDUs pending to be
+- sent. In all other cases, the effect is "NA".
+-
+- 14. This clearing effect is only valid for a "close the session"
+- logout in a multi-connection session. In all other cases, the effect
+- is "NA".
+-
+- 15. Only applicable if this leading connection login is a session
+- reinstatement. If this is not the case, it is "NA".
+-
+- 16. This operation affects all logged-in initiators.
+-
+- 18. Session failure is defined in Section 5.3.6 Session Continuation
+- and Failure.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 251]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 19. This operation affects all logged-in initiators and the clearing
+- effects are only applicable to the LU being reset.
+-
+- +-----+-----+-----+-----+-----+
+- |DC(1)|DD(2)|SS(3)|CS(4)|DS(5)|
+- +---------------------+-----+-----+-----+-----+-----+
+- |connection failure |N |Y |N |N |N |
+- +---------------------+-----+-----+-----+-----+-----+
+- |connection state |Y |NA |Y |N |NA |
+- |timeout | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |session timeout/ |Y |Y |Y(7) |Y |NA |
+- |closure/reinstatement| | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |session continuation |N(11)|NA*12|NA |N |NA*13|
+- +---------------------+-----+-----+-----+-----+-----+
+- |successful connection|Y |Y |Y |N |NA |
+- |close Logout | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |session failure |N |Y |N |N |N |
+- +---------------------+-----+-----+-----+-----+-----+
+- |successful recovery |Y |Y |Y |N |N |
+- |Logout | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |failed Logout |N |Y(9) |N |N |N |
+- +---------------------+-----+-----+-----+-----+-----+
+- |connection Login |NA |NA |N(8) |N(8) |NA |
+- |(leading | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |connection Login |N(11)|NA*12|N(8) |N |NA*13|
+- |(non-leading) | | | | | |
+- +---------------------+-----+-----+-----+-----+-----+
+- |target cold reset |Y |Y |Y |Y(10)|NA |
+- +---------------------+-----+-----+-----+-----+-----+
+- |target warm reset |Y |Y |N |N |NA |
+- +---------------------+-----+-----+-----+-----+-----+
+- |LU reset |N |Y |N |N |N |
+- +---------------------+-----+-----+-----+-----+-----+
+- |powercycle |Y |Y |Y |Y(10)|NA |
+- +---------------------+-----+-----+-----+-----+-----+
+-
+- 1. Discontiguous Commands - commands allegiant to the connection in
+- question and waiting to be reordered in the iSCSI layer. All "Y"s in
+- this column assume that the task causing the event (if indeed the
+- event is the result of a task) is issued as an immediate command,
+- because the discontiguities can be ahead of the task.
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 252]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- 2. Discontiguous Data - data PDUs received for the task in question
+- and waiting to be reordered due to prior discontiguities in DataSN.
+-
+- 3. StatSN
+-
+- 4. CmdSN
+-
+- 5. DataSN
+-
+- 7. It clears the StatSN on all the connections.
+-
+- 8. This sequence number is instantiated on this event.
+-
+- 9. A logout failure drives the connection state machine to the
+- CLEANUP_WAIT state, similar to the connection failure event. Hence,
+- it has a similar effect on this and several other protocol aspects.
+-
+- 10. This is cleared by virtue of the fact that all sessions with all
+- initiators are terminated.
+-
+- 11. This clearing effect is "Y" if it is a connection reinstatement.
+-
+- 12. This clearing effect is "Y" only if it is a connection
+- reinstatement and the operational ErrorRecoveryLevel is 2.
+-
+- 13. This clearing effect is "N" only if it is a connection
+- reinstatement and the operational ErrorRecoveryLevel is 2.
+-
+-F.2. Clearing Effects on SCSI Objects
+-
+- The only iSCSI protocol action that can effect clearing actions on
+- SCSI objects is the "I_T nexus loss" notification (Section 4.3.5.1
+- Loss of Nexus notification). [SPC3] describes the clearing effects
+- of this notification on a variety of SCSI attributes. In addition,
+- SCSI standards documents (such as [SAM2] and [SBC]) define additional
+- clearing actions that may take place for several SCSI objects on SCSI
+- events such as LU resets and power-on resets.
+-
+- Since iSCSI defines a target cold reset as a protocol-equivalent to a
+- target power-cycle, the iSCSI target cold reset must also be
+- considered as the power-on reset event in interpreting the actions
+- defined in the SCSI standards.
+-
+- When the iSCSI session is reconstructed (between the same SCSI ports
+- with the same nexus identifier) reestablishing the same I_T nexus,
+- all SCSI objects that are defined to not clear on the "I_T nexus
+- loss" notification event, such as persistent reservations, are
+- automatically associated to this new session.
+-
+-
+-
+-Satran, et al. Standards Track [Page 253]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Acknowledgements
+-
+- This protocol was developed by a design team that, in addition to the
+- authors, included Daniel Smith, Ofer Biran, Jim Hafner and John
+- Hufferd (IBM), Mark Bakke (Cisco), Randy Haagens (HP), Matt Wakeley
+- (Agilent, now Sierra Logic), Luciano Dalle Ore (Quantum), and Paul
+- Von Stamwitz (Adaptec, now TrueSAN Networks).
+-
+- Furthermore, a large group of people contributed to this work through
+- their review, comments, and valuable insights. We are grateful to
+- all of them. We especially thank those people who found the time and
+- patience to take part in our weekly phone conferences and
+- intermediate meetings in Almaden and Haifa, which helped shape this
+- document: Prasenjit Sarkar, Meir Toledano, John Dowdy, Steve Legg,
+- Alain Azagury (IBM), Dave Nagle (CMU), David Black (EMC), John Matze
+- (Veritas - now Okapi Software), Steve DeGroote, Mark Schrandt
+- (Cisco), Gabi Hecht (Gadzoox), Robert Snively and Brian Forbes
+- (Brocade), Nelson Nachum (StorAge), and Uri Elzur (Broadcom). Many
+- others helped edit and improve this document within the IPS working
+- group. We are especially grateful to David Robinson and Raghavendra
+- Rao (Sun), Charles Monia, Joshua Tseng (Nishan), Somesh Gupta
+- (Silverback), Michael Krause, Pierre Labat, Santosh Rao, Matthew
+- Burbridge, Bob Barry, Robert Elliott, Nick Martin (HP), Stephen
+- Bailey (Sandburst), Steve Senum, Ayman Ghanem, Dave Peterson (Cisco),
+- Barry Reinhold (Trebia Networks), Bob Russell (UNH), Eddy Quicksall
+- (iVivity, Inc.), Bill Lynn and Michael Fischer (Adaptec), Vince
+- Cavanna, Pat Thaler (Agilent), Jonathan Stone (Stanford), Luben
+- Tuikov (Splentec), Paul Koning (EqualLogic), Michael Krueger
+- (Windriver), Martins Krikis (Intel), Doug Otis (Sanlight), John
+- Marberg (IBM), Robert Griswold and Bill Moody (Crossroads), Bill
+- Studenmund (Wasabi Systems), Elizabeth Rodriguez (Brocade) and Yaron
+- Klein (Sanrad). The recovery chapter was enhanced with the help of
+- Stephen Bailey (Sandburst), Somesh Gupta (Silverback), and Venkat
+- Rangan (Rhapsody Networks). Eddy Quicksall contributed some examples
+- and began the Definitions section. Michael Fischer and Bob Barry
+- started the Acronyms section. Last, but not least, we thank Ralph
+- Weber for keeping us in line with T10 (SCSI) standardization.
+-
+- We would like to thank Steve Hetzler for his unwavering support and
+- for coming up with such a good name for the protocol, and Micky
+- Rodeh, Jai Menon, Clod Barrera, and Andy Bechtolsheim for helping
+- make this work happen.
+-
+- In addition to this document, we recommend you acquaint yourself with
+- the following in order to get a full understanding of the iSCSI
+- specification: "iSCSI Naming & Discovery"[RFC3721], "Bootstrapping
+- Clients using the iSCSI Protocol" [BOOT], "Securing Block Storage
+- Protocols over IP" [RFC3723] documents, "iSCSI Requirements and
+-
+-
+-
+-Satran, et al. Standards Track [Page 254]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+- Design Considerations" [RFC3347] and "SCSI Command Ordering
+- Considerations with iSCSI" [CORD].
+-
+- The "iSCSI Naming & Discovery" document is authored by:
+-
+- Mark Bakke (Cisco), Jim Hafner, John Hufferd, Kaladhar Voruganti
+- (IBM), and Marjorie Krueger (HP).
+-
+- The "Bootstrapping Clients using the iSCSI Protocol" document is
+- authored by:
+-
+- Prasenjit Sarkar (IBM), Duncan Missimer (HP), and Costa
+- Sapuntzakis (Cisco).
+-
+- The "Securing Block Storage Protocols over IP" document is authored
+- by:
+-
+- Bernard Aboba (Microsoft), Joshua Tseng (Nishan), Jesse Walker
+- (Intel), Venkat Rangan (Rhapsody Networks), and Franco
+- Travostino (Nortel Networks).
+-
+- The "iSCSI Requirements and Design Considerations" document is
+- authored by:
+-
+- Marjorie Krueger, Randy Haagens (HP), Costa Sapuntzakis, and Mark
+- Bakke (Cisco).
+-
+- The "SCSI Command Ordering Considerations with iSCSI" document is
+- authored by:
+-
+- Mallikarjun Chadalapaka, Rob Elliot (HP)
+-
+- We are grateful to all of them for their good work and for helping us
+- correlate this document with the ones they produced.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 255]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Authors' Addresses
+-
+- Julian Satran
+- IBM Research Laboratory in Haifa
+- Haifa University Campus - Mount Carmel
+- Haifa 31905, Israel
+-
+- Phone +972.4.829.6264
+- EMail: Julian_Satran at il.ibm.com
+-
+-
+- Kalman Meth
+- IBM Research Laboratory in Haifa
+- Haifa University Campus - Mount Carmel
+- Haifa 31905, Israel
+-
+- Phone +972.4.829.6341
+- EMail: meth at il.ibm.com
+-
+-
+- Costa Sapuntzakis
+- Stanford University
+- 353 Serra Mall Dr #407
+- Stanford, CA 94305
+-
+- Phone: +1.650.723.2458
+- EMail: csapuntz at alum.mit.edu
+-
+-
+- Efri Zeidner
+- XIV Ltd.
+- 1 Azrieli Center,
+- Tel-Aviv 67021, Israel
+-
+- Phone: +972.3.607.4722
+- EMail: efri at xiv.co.il
+-
+-
+- Mallikarjun Chadalapaka
+- Hewlett-Packard Company
+- 8000 Foothills Blvd.
+- Roseville, CA 95747-5668, USA
+-
+- Phone: +1.916.785.5621
+- EMail: cbm at rose.hp.com
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 256]
+-
+-RFC 3720 iSCSI April 2004
+-
+-
+-Full Copyright Statement
+-
+- Copyright (C) The Internet Society (2004). This document is subject
+- to the rights, licenses and restrictions contained in BCP 78, and
+- except as set forth therein, the authors retain all their rights.
+-
+- This document and the information contained herein are provided on an
+- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+-
+-Intellectual Property
+-
+- The IETF takes no position regarding the validity or scope of any
+- Intellectual Property Rights or other rights that might be claimed to
+- pertain to the implementation or use of the technology described in
+- this document or the extent to which any license under such rights
+- might or might not be available; nor does it represent that it has
+- made any independent effort to identify any such rights. Information
+- on the procedures with respect to rights in RFC documents can be
+- found in BCP 78 and BCP 79.
+-
+- Copies of IPR disclosures made to the IETF Secretariat and any
+- assurances of licenses to be made available, or the result of an
+- attempt made to obtain a general license or permission for the use of
+- such proprietary rights by implementers or users of this
+- specification can be obtained from the IETF on-line IPR repository at
+- http://www.ietf.org/ipr.
+-
+- The IETF invites any interested party to bring to its attention any
+- copyrights, patents or patent applications, or other proprietary
+- rights that may cover technology that may be required to implement
+- this standard. Please address the information to the IETF at ietf-
+- ipr at ietf.org.
+-
+-Acknowledgement
+-
+- Funding for the RFC Editor function is currently provided by the
+- Internet Society.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Satran, et al. Standards Track [Page 257]
+-
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc3722.txt open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc3722.txt
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc3722.txt 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc3722.txt 1969-12-31 18:00:00.000000000 -0600
+@@ -1,451 +0,0 @@
+-
+-
+-
+-
+-
+-
+-Network Working Group M. Bakke
+-Request for Comments: 3722 Cisco
+-Category: Standards Track April 2004
+-
+-
+- String Profile for Internet Small Computer
+- Systems Interface (iSCSI) Names
+-
+-Status of this Memo
+-
+- This document specifies an Internet standards track protocol for the
+- Internet community, and requests discussion and suggestions for
+- improvements. Please refer to the current edition of the "Internet
+- Official Protocol Standards" (STD 1) for the standardization state
+- and status of this protocol. Distribution of this memo is unlimited.
+-
+-Copyright Notice
+-
+- Copyright (C) The Internet Society (2004). All Rights Reserved.
+-
+-Abstract
+-
+- This document describes how to prepare internationalized iSCSI names
+- to increase the likelihood that name input and comparison work in
+- ways that make sense for typical users throughout the world.
+-
+- The Internet Small Computer Systems Interface (iSCSI) protocol
+- provides a way for hosts to access SCSI devices over an IP network.
+- The iSCSI end-points, called initiators and targets, each have a
+- globally-unique name that must be transcribable, as well as easily
+- compared.
+-
+-1. Introduction
+-
+- The iSCSI protocol [RFC3720] provides a way for hosts to access SCSI
+- [SAM2] devices over an IP network. The iSCSI end-points, called
+- initiators and targets, each have a globally-unique name, defined in
+- [RFC3721].
+-
+- An iSCSI name is a string of UTF-8 [RFC3629] characters that includes
+- a type designator, a naming authority based on domain names, and a
+- unique part within the naming authority. The unique part may be
+- generated based on anything the naming authority deems useful, and
+- may include user input.
+-
+- These names may need to be transcribed (sent between two
+- administrators via email, voice, paper, etc), so a case-insensitive
+- comparison would be desirable. However, these names must often be
+-
+-
+-
+-Bakke Standards Track [Page 1]
+-
+-RFC 3722 String Profile for iSCSI Names April 2004
+-
+-
+- compared by initiator and target implementations, most of which are
+- done in simple, embedded software. This makes case-sensitive
+- comparison highly desirable for these implementors.
+-
+- However, a completely case-sensitive implementation would result in
+- identifiers such as "example-name" and "Example-Name" being
+- different, which could lead to confusion as these names are
+- transcribed.
+-
+- The goal, then, is to generate iSCSI names that can be transcribed
+- and entered by users, and also compared byte-for-byte, with minimal
+- confusion. To attain these goals, iSCSI names are generalized using
+- a normalized character set (converted to lower case or equivalent),
+- with no white space allowed, and very limited punctuation.
+-
+- For those using only ASCII characters (U+0000 to U+007F), the
+- following characters are allowed:
+-
+- - ASCII dash character ('-' = U+002d)
+- - ASCII dot character ('.' = U+002e)
+- - ASCII colon character (':' = U+003a)
+- - ASCII lower-case characters ('a'..'z' = U+0061..U+007a)
+- - ASCII digit characters ('0'..'9' = U+0030..U+0039)
+-
+- In addition, any upper-case characters input via a user interface
+- MUST be mapped to their lower-case equivalents.
+-
+- This document specifies the valid character set for iSCSI names,
+- along with the rules for normalizing and generating iSCSI names based
+- on user input or other information that contains international
+- characters.
+-
+- In particular, it defines the following, as required by [RFC3454]:
+-
+- - The intended applicability of the profile: internationalized iSCSI
+- names.
+-
+- - The character repertoire that is the input and output to
+- stringprep: Unicode 3.2, specified in section 3.
+-
+- - The mappings used: specified in section 4.
+-
+- - The Unicode normalization used: specified in section 5.
+-
+- - The characters that are prohibited as output: specified in section
+- 6.
+-
+- This profile MUST be used with the iSCSI protocol.
+-
+-
+-
+-Bakke Standards Track [Page 2]
+-
+-RFC 3722 String Profile for iSCSI Names April 2004
+-
+-
+-2. Terminology
+-
+- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+- document are to be interpreted as described in [RFC2119].
+-
+- Examples in this document use the notation for code points and names
+- from the Unicode Standard [Unicode3.2] and ISO/IEC 10646 [ISO10646].
+- For example, the letter "a" may be represented as either "U+0061" or
+- "LATIN SMALL LETTER A". In the lists of prohibited characters, the
+- "U+" is left off to make the lists easier to read. The comments for
+- character ranges are shown in square brackets (such as "[SYMBOLS]")
+- and do not come from the standards.
+-
+-3. Character Repertoire
+-
+- This profile uses Unicode 3.2, as defined in [RFC3454] Appendix A.
+-
+-4. Mapping
+-
+- This profile specifies mapping using the following tables from
+- [RFC3454]. The following mapping tables MUST be used when generating
+- iSCSI names from Unicode characters.
+-
+- Table B.1
+- Table B.2
+-
+-5. Normalization
+-
+- Unicode normalization form KC MUST be used with this profile, as
+- described in [RFC3454].
+-
+-6. Prohibited Output
+-
+- This profile specifies prohibiting using the following tables from
+- [RFC3454]. Characters appearing within these tables MUST NOT be used
+- within an iSCSI name.
+-
+- Table C.1.1
+- Table C.1.2
+- Table C.2.1
+- Table C.2.2
+- Table C.3
+- Table C.4
+- Table C.5
+- Table C.6
+-
+-
+-
+-
+-
+-Bakke Standards Track [Page 3]
+-
+-RFC 3722 String Profile for iSCSI Names April 2004
+-
+-
+- Table C.7
+- Table C.8
+- Table C.9
+-
+- Important note: this profile MUST be used with the iSCSI protocol.
+- The iSCSI protocol has additional naming rules that are checked
+- outside of this profile.
+-
+- In addition, this profile adds the following prohibitions. The full
+- set of prohibited characters are those from the tables above plus
+- those listed individually below.
+-
+-6.1. Inappropriate Characters from Common Input Mechanisms
+-
+- u+3002 is used as if it were u+002e in many domain name input
+- mechanisms used by applications, particularly in Asia. The character
+- u+3002 MUST NOT be used in an iSCSI name.
+-
+- 3002; ideographic full stop
+-
+-6.2. Currently-prohibited ASCII characters
+-
+- Some of the ASCII characters that are currently prohibited in iSCSI
+- names by [RFC3721] are also used in protocol elements such as URIs.
+- Some examples are described in [RFC2396] and [RFC2732]. Note that
+- there are many other RFCs that define additional URI schemes.
+-
+- The other characters in the range U+0000 to U+007F that are not
+- currently allowed are prohibited in iSCSI names to reserve them for
+- future use in protocol elements. Note that the dash (U+002D), dot
+- (U+002E), and colon (U+003A) are not prohibited.
+-
+- The following characters MUST NOT be used in iSCSI names:
+-
+- 0000-002C; [ASCII CONTROL CHARACTERS and SPACE through ,]
+- 002F; [ASCII /]
+- 003B-0040; [ASCII ; through @]
+- 005B-0060; [ASCII [ through `]
+- 007B-007F; [ASCII { through DEL]
+-
+-7. Bidirectional Characters
+-
+- This profile specifies checking bidirectional strings as described in
+- [RFC3454] section 6.
+-
+-
+-
+-
+-
+-
+-
+-Bakke Standards Track [Page 4]
+-
+-RFC 3722 String Profile for iSCSI Names April 2004
+-
+-
+-8. Unassigned Code Points in Internationalized Domain Names
+-
+- If the processing in [RFC3720] specifies that a list of unassigned
+- code points be used, the system uses table A.1 from [RFC3454] as its
+- list of unassigned code points.
+-
+-9. Security Considerations
+-
+- ISO/IEC 10646 has many characters that look similar. In many cases,
+- users of security protocols might do visual matching, such as when
+- comparing the names of trusted third parties. This profile does
+- nothing to map similar-looking characters together.
+-
+- iSCSI names may be used by an initiator to verify that a target it
+- has discovered is the correct one, and by a target to verify that an
+- initiator is to be allowed access. If these names are interpreted
+- and compared differently by different iSCSI implementations, an
+- initiator could gain access to the wrong target, or could be denied
+- access to a legitimate target.
+-
+-10. IANA Considerations
+-
+- This is a profile of stringprep. It has been registered in the IANA
+- "Stringprep Profiles" registry. This process is described in the
+- IANA Considerations section of [RFC3454].
+-
+-11. Summary
+-
+- This document describes a stringprep profile to be used with programs
+- generating names for iSCSI initiators and targets.
+-
+-12. Acknowledgements
+-
+- This document was produced as a result of discussions on iSCSI name
+- formats with Joe Czap, Jim Hafner, Howard Hall, Jack Harwood, John
+- Hufferd, Marjorie Krueger, Lawrence Lamers, Todd Sperry, Joshua
+- Tseng, and Kaladhar Voruganti, as well as discussions on the
+- normalization of names into identifiers with Paul Hoffman and Marc
+- Blanchet.
+-
+- Thanks also to Bob Snively for suggesting the use of the nameprep
+- process for iSCSI name normalization.
+-
+- Most of this document was copied from the stringprep profile for
+- Internationalized Domain Names [RFC3491], written by Paul Hoffman and
+- Marc Blanchet.
+-
+-
+-
+-
+-
+-Bakke Standards Track [Page 5]
+-
+-RFC 3722 String Profile for iSCSI Names April 2004
+-
+-
+-13. References
+-
+-13.1. Normative References
+-
+- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+- Requirement Levels", BCP 14, RFC 2119, March 1997.
+-
+- [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+- Internationalized Strings ("stringprep")", RFC 3454,
+- December 2002.
+-
+- [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M.
+- and E. Zeidner, "Internet Small Computer Systems
+- Interface (iSCSI)", RFC 3720, April 2004.
+-
+-13.2. Informative References
+-
+- [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+- Resource Identifiers", RFC 2396, August 1998.
+-
+- [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
+- Literal IPv6 Addresses in URL's", RFC 2732, December
+- 1999.
+-
+- [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+- Profile for Internationalized Domain Names", RFC 3491,
+- March 2003.
+- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+- 10646", STD 63, RFC 3629, November 2003.
+-
+- [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K. and M.
+- Krueger, "Internet Small Computer Systems Interface
+- (iSCSI) Naming and Discovery", RFC 3721, April 2004.
+-
+- [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.
+-
+- [Unicode3.2] The Unicode Standard, Version 3.2.0: The Unicode
+- Consortium. The Unicode Standard, Version 3.2.0 is
+- defined by The Unicode Standard, Version 3.0 (Reading,
+- MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
+- amended by the Unicode Standard Annex #27: Unicode 3.1
+- (http://www.unicode.org/unicode/reports/tr27/) and by
+- the Unicode Standard Annex #28: Unicode 3.2
+- (http://www.unicode.org/unicode/reports/tr28/).
+-
+-
+-
+-
+-
+-
+-
+-Bakke Standards Track [Page 6]
+-
+-RFC 3722 String Profile for iSCSI Names April 2004
+-
+-
+- [ISO10646] ISO/IEC 10646-1:2000. International Standard --
+- Information technology -- Universal Multiple-Octet Coded
+- Character Set (UCS) -- Part 1: Architecture and Basic
+- Multilingual Plane.
+-
+-14. Author's Address
+-
+- Mark Bakke
+- Cisco Systems, Inc.
+- 6450 Wedgwood Road
+- Maple Grove, MN
+- USA 55311
+-
+- Voice: +1 763-398-1000
+- EMail: mbakke at cisco.com
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Bakke Standards Track [Page 7]
+-
+-RFC 3722 String Profile for iSCSI Names April 2004
+-
+-
+-15. Full Copyright Statement
+-
+- Copyright (C) The Internet Society (2004). This document is subject
+- to the rights, licenses and restrictions contained in BCP 78, and
+- except as set forth therein, the authors retain all their rights.
+-
+- This document and the information contained herein are provided on an
+- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+-
+-Intellectual Property
+-
+- The IETF takes no position regarding the validity or scope of any
+- Intellectual Property Rights or other rights that might be claimed to
+- pertain to the implementation or use of the technology described in
+- this document or the extent to which any license under such rights
+- might or might not be available; nor does it represent that it has
+- made any independent effort to identify any such rights. Information
+- on the procedures with respect to rights in RFC documents can be
+- found in BCP 78 and BCP 79.
+-
+- Copies of IPR disclosures made to the IETF Secretariat and any
+- assurances of licenses to be made available, or the result of an
+- attempt made to obtain a general license or permission for the use of
+- such proprietary rights by implementers or users of this
+- specification can be obtained from the IETF on-line IPR repository at
+- http://www.ietf.org/ipr.
+-
+- The IETF invites any interested party to bring to its attention any
+- copyrights, patents or patent applications, or other proprietary
+- rights that may cover technology that may be required to implement
+- this standard. Please address the information to the IETF at ietf-
+- ipr at ietf.org.
+-
+-Acknowledgement
+-
+- Funding for the RFC Editor function is currently provided by the
+- Internet Society.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Bakke Standards Track [Page 8]
+-
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc4018.txt open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc4018.txt
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc4018.txt 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc4018.txt 1969-12-31 18:00:00.000000000 -0600
+@@ -1,1291 +0,0 @@
+-
+-
+-
+-
+-
+-
+-Network Working Group M. Bakke
+-Request for Comments: 4018 Cisco
+-Category: Standards Track J. Hufferd
+- K. Voruganti
+- IBM
+- M. Krueger
+- HP
+- T. Sperry
+- Adaptec
+- April 2005
+-
+-
+- Finding Internet Small Computer Systems Interface (iSCSI) Targets
+- and Name Servers by Using Service Location Protocol version 2 (SLPv2)
+-
+-Status of This Memo
+-
+- This document specifies an Internet standards track protocol for the
+- Internet community, and requests discussion and suggestions for
+- improvements. Please refer to the current edition of the "Internet
+- Official Protocol Standards" (STD 1) for the standardization state
+- and status of this protocol. Distribution of this memo is unlimited.
+-
+-Copyright Notice
+-
+- Copyright (C) The Internet Society (2005).
+-
+-Abstract
+-
+- The iSCSI protocol provides a way for hosts to access SCSI devices
+- over an IP network. This document defines the use of the Service
+- Location Protocol (SLP) by iSCSI hosts, devices, and management
+- services, along with the SLP service type templates that describe the
+- services they provide.
+-
+-Table of Contents
+-
+- 1. Introduction................................................ 2
+- 2. Notation Conventions........................................ 2
+- 3. Terminology................................................. 3
+- 4. Using SLP for iSCSI Service Discovery....................... 4
+- 5. iSCSI SLP Templates......................................... 11
+- 6. Security Considerations..................................... 18
+- 7. IANA Considerations......................................... 19
+- 8. Summary..................................................... 19
+- 9. Normative References........................................ 19
+- 10. Informative References...................................... 20
+- 11. Acknowledgements............................................ 21
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 1]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+-1. Introduction
+-
+- iSCSI [RFC3720] is a protocol used to transport SCSI [SAM2] commands,
+- data, and status across an IP network. This protocol is connection-
+- oriented and is currently defined over TCP. iSCSI uses a client-
+- server relationship. The client end of the connection is an
+- initiator, and it sends SCSI commands; the server end of the
+- connection is called a target, and it receives and executes the
+- commands.
+-
+- There are several methods an iSCSI initiator can use to find the
+- targets to which it should connect. Two of these methods can be
+- accomplished without the use of SLP:
+-
+- - Each target and its address can be statically configured on the
+- initiator.
+-
+- - Each address providing targets can be configured on the initiator;
+- iSCSI provides a mechanism by which the initiator can query the
+- address for a list of targets.
+-
+- The above methods are further defined in "iSCSI Naming and Discovery
+- Requirements" [RFC3721].
+-
+- Each of the above methods requires a small amount of configuration to
+- be done on each initiator. The ability to discover targets and name
+- services without having to configure initiators is a desirable
+- feature. The Service Location Protocol (SLP) [RFC2608] is an IETF
+- standards track protocol providing several features that will
+- simplify locating iSCSI services. This document describes how SLP
+- can be used in iSCSI environments to discover targets, addresses
+- providing targets, and storage management servers.
+-
+-2. Notation Conventions
+-
+- In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+- "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+- and "OPTIONAL" are to be interpreted as described in [RFC2119].
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 2]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+-3. Terminology
+-
+- Here are some definitions that may aid readers who are unfamiliar
+- with SLP, SCSI, or iSCSI. Some of these definitions have been
+- reproduced from [RFC2608] and "Finding an RSIP Server with SLP"
+- [RFC3105].
+-
+- User Agent (UA) A process working on the client's behalf
+- to establish contact with some service.
+- The UA retrieves service information from
+- the Service Agents or Directory Agents.
+-
+- Service Agent (SA) A process working on behalf of one or more
+- services to advertise the services and
+- their capabilities.
+-
+- Directory Agent (DA) A process that collects service
+- advertisements. There can only be one DA
+- present per given host.
+-
+- Scope A named set of services, typically making
+- up a logical administrative group.
+-
+- Service Advertisement A URL, attributes, and a lifetime
+- (indicating how long the advertisement is
+- valid) providing service access
+- information and capabilities description
+- for a particular service.
+-
+- Initiator A logical entity, typically within a host,
+- that sends SCSI commands to targets to be
+- executed. An initiator is usually present
+- in the form of a device driver.
+-
+- Target A logical entity, typically within a
+- storage controller or gateway that
+- receives SCSI commands from an initiator
+- and executes them. A target includes one
+- or more Logical Units (LUs); each LU is a
+- SCSI device, such as a disk or tape drive.
+-
+- iSCSI Name A UTF-8 character string that serves as a
+- unique identifier for iSCSI initiators and
+- targets. Its format and usage is further
+- defined in [RFC3721].
+-
+- iSCSI Client A logical entity, typically a host that
+- includes at least one iSCSI Initiator.
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 3]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- iSCSI Server A logical entity, typically a storage
+- controller or gateway that includes at
+- least one iSCSI Target.
+-
+- Storage Management Server An addressable entity that provides
+- management services that benefit an iSCSI
+- environment. "Storage management server"
+- is used as a generic term and does not
+- indicate a specific protocol or service.
+-
+-4. Using SLP for iSCSI Service Discovery
+-
+- Two entities are involved in iSCSI discovery. The end result is that
+- an iSCSI initiator (e.g., a host) discovers iSCSI targets, usually
+- provided by storage controllers or gateways.
+-
+- iSCSI targets are registered with SLP as a set of service URLs, one
+- for each address on which the target may be accessed. Initiators
+- discover these targets by using SLP service requests. Targets that
+- do not directly support SLP or that are under the control of a
+- management service may be registered by a proxy service agent as part
+- of the software providing this service.
+-
+- iSCSI entities may also use SLP to discover higher-level management
+- services when these are needed.
+-
+- This section first describes the use of SLP for discovery of targets
+- by iSCSI initiators, it then describes the use of SLP to discover
+- storage management servers.
+-
+- This document assumes that SLPv2 will be used for discovering iSCSI-
+- related services; no attempt is made to include support for SLPv1.
+-
+-4.1. Discovering iSCSI Targets with SLP
+-
+- The following diagram shows the relationship among iSCSI clients,
+- servers, initiators, and targets. An iSCSI client includes at least
+- one iSCSI initiator, and an SLP user agent (UA). An iSCSI server
+- includes at least one iSCSI target an SLP service agent (SA). Some
+- entities, such as extended copy engines, include both initiators and
+- targets. These include both an SA, for its targets to be discovered,
+- and a UA, for its initiator(s) to discover other targets.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 4]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- +---------------------------------+
+- | iSCSI Client |
+- | +-----------+ |
+- | | iSCSI | |
+- | | initiator | |
+- | | "myhost" | |
+- | +-----------+ |
+- | |
+- +--------------------------+------+
+- | iSCSI Driver | UA |
+- +--------------------------+------+
+- | TCP/UDP/IP |
+- +----------------+----------------+
+- | Interface 1 | Interface 2 |
+- +----------------+----------------+
+- | |
+- +------------+ | | +------------+
+- | SLP DA | | | | SLP DA |
+- | (optional) |----+ IP Networks +----| (optional) |
+- +------------+ | | +------------+
+- | |
+- +-----------------+-----------------|
+- | Interface 1 | Interface 2 |
+- | 192.0.2.131 | 192.0.2.3 |
+- +-----------------+-----------------+
+- | TCP/UDP/IP |
+- +---------------------------+-------+
+- | iSCSI Driver | SA |
+- +---------------------------+-------|
+- | |
+- | +--------+ +--------+ +---------+ |
+- | | iSCSI | | iSCSI | | iSCSI | |
+- | | target | | target | | target | |
+- | | "one" | | "two" | | "three" | |
+- | +--------+ +--------+ +---------+ |
+- | iSCSI Server |
+- +-----------------------------------+
+-
+- In the above drawing, the iSCSI server has three iSCSI targets that
+- the client could discover, named "one", "two" and "three". The iSCSI
+- client has an iSCSI initiator with the name "myhost". The iSCSI
+- client may use the initiator name in its SLP Service Requests as a
+- filter to discover only targets that are configured to accept iSCSI
+- connections from "myhost".
+-
+- Each iSCSI target and initiator has a unique name, called an iSCSI
+- Name. This identifier is the same regardless of the network path
+- (through adapter cards, networks, and interfaces on the storage
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 5]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- device) over which the target is discovered and accessed. For this
+- example, the iSCSI names "one", "two", and "three" are used for the
+- targets; the initiator uses the name "myhost". An actual iSCSI name
+- would incorporate more structure, including a naming authority, and
+- is not described here.
+-
+- Each of the iSCSI targets in the drawing can appear at two addresses,
+- since two network interfaces are present. Each target would have two
+- service URLs, unless a single service URL included a DNS host name
+- mapping to both addresses.
+-
+- An iSCSI target URL consists of its fully qualified host name or IP
+- address, the TCP port on which it is listening, and its iSCSI name.
+- An iSCSI server must register each of its individual targets at each
+- of its network addresses.
+-
+- The iSCSI server constructs a service advertisement of the type
+- "service:iscsi:target" for each of the service URLs it wishes to
+- register. The advertisement contains a lifetime, along with other
+- attributes that are defined in the service template.
+-
+- If the server in the above drawing is listening at TCP port 3260 for
+- both network addresses, the service URLs registered would be
+-
+- - 192.0.2.131:3260/one
+-
+- - 192.0.2.131:3260/two
+-
+- - 192.0.2.131:3260/three
+-
+- - 192.0.2.3:3260/one
+-
+- - 192.0.2.3:3260/two
+-
+- - 192.0.2.3:3260/three
+-
+- The remainder of the discovery procedure is identical to that used by
+- any client/server pair implementing SLP:
+-
+- 1. If an SLP DA is found, the SA contacts the DA and registers the
+- service advertisement. Whether or not one or more SLPv2 DAs are
+- discovered, the SA maintains the advertisement itself and answers
+- multicast UA queries directly.
+-
+- 2. When the iSCSI initiator requires contact information for an
+- iSCSI target, the UA either contacts the DA by using unicast or
+- the SA by using multicast. If a UA is configured with the
+- address of the SA, it may avoid multicast and may contact an SA
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 6]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- by using unicast. The UA includes a query based on the
+- attributes to indicate the characteristics of the target(s) it
+- requires.
+-
+- 3. Once the UA has the host name or address of the iSCSI server, as
+- well as the port number and iSCSI Target Name, it can begin the
+- normal iSCSI login to the target.
+-
+- As information contained in the iSCSI target template may exceed
+- common network datagram sizes, the SLP implementation for both UAs
+- and SAs supporting this template MUST implement SLP over TCP.
+-
+-4.1.1. Finding Targets Based on Initiator Credentials
+-
+- To be allowed access to an iSCSI target, an initiator must be
+- authenticated. The initiator may be required by the target to
+- produce one or more of the following credentials:
+-
+- - An iSCSI Initiator Name
+-
+- - An IP address
+-
+- - A CHAP, SRP, or Kerberos credential
+-
+- - Any combination of the above
+-
+- Most iSCSI targets allow access to only one or two initiators. In
+- the ideal discovery scenario, an initiator would send an SLP request
+- and receive responses ONLY for targets to which the initiator is
+- guaranteed a successful login. To achieve this goal, the iSCSI
+- target template contains the following attributes, each of which
+- allows a list of values:
+-
+- 1. auth-name: This attribute contains the list of initiator names
+- allowed to access this target, or the value "any", indicating
+- that no specific initiator name is required.
+-
+- 2. auth-addr: This attribute contains the list of host names
+- and/or IP addresses that will be allowed access to this target,
+- or the value "any", indicating that no specific address or
+- host name is required. If a large number of addresses is to
+- be allowed (perhaps a subnet), this attribute may contain the
+- value "any".
+-
+-
+-
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 7]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- 3. auth-cred: This attribute contains a list of "method/identifier"
+- credentials that will be allowed access to the target, provided
+- they can produce the correct password or other verifier during
+- the login process. If no specific credentials are required, the
+- value "any" is used.
+-
+- The list of valid method strings for auth-cred are defined in
+- [RFC3720], section 11.1, "AuthMethod". The identifier used after the
+- "/" is defined by the specific AuthMethod, also in [RFC3720].
+- Examples showing initiator searches based on auth-xxxx attributes are
+- shown in the target-specific template section below.
+-
+- Also note that the auth-xxxx attributes are considered security
+- policy information. If these attributes are distributed, IPsec MUST
+- be implemented as specified in the Security Implementation section
+- below.
+-
+-4.1.2. Supporting Access by Multiple Identities to the Same Target
+-
+- If a target is to allow access to multiple host identities, more than
+- one combination of auth-xxxx attributes will have to be allowed. In
+- some of these cases, it is not possible to express the entire set of
+- valid combinations of auth-xxxx attributes within a single registered
+- service URL. For example, if a target can be addressed by
+-
+- auth-name=myhost1 AND auth-cred=CHAP/user1 (identity1)
+-
+- OR
+-
+- auth-name-myhost2 AND auth-cred=CHAP/user2 (identity2)
+-
+- the above cannot be specified in a single registered service URL,
+- since (auth-name=myhost1, auth-name=myhost2, auth-cred=CHAP/user1,
+- auth-cred=CHAP/user2) would allow either auth-name to be used with
+- either auth-cred. This necessitates the ability to register a target
+- and address under more than one service URL; one for (identity1) and
+- one for (identity2).
+-
+- Because service URLs must be unique, (identity1) and (identity2) must
+- each be registered under a unique service URL. For systems that
+- support the configuration of multiple identities to access a target,
+- the service URL must contain an additional, opaque string defining
+- the identity. This appears after the iSCSI name in the URL string
+- and is separated by a "/". Each registered (target-address, target-
+- name, initiator-identity) tuple can then register a set of auth-xxxx
+- attributes.
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 8]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+-4.1.3. Using SLP in a Non-multicast Environment
+-
+- In some networks, the use of multicast for discovery purposes is
+- either unavailable or not allowed. These include public or service-
+- provider networks that are placed between an iSCSI client and a
+- server. These are probably most common between two iSCSI gateways,
+- one at a storage service provider site, and one at a customer site.
+-
+- In these networks, an initiator may allow the addresses of one or
+- more SAs to be configured instead of or in addition to its DA
+- configuration. The initiator would then make unicast SLP service
+- requests directly to these SAs, without the use of multicast to
+- discover them first.
+-
+- This functionality is well within the scope of the current SLP
+- protocol. The main consequence for implementors is that an initiator
+- configured to make direct unicast requests to an SA will have to add
+- this to the SLP API, if it is following the service location API
+- defined in [RFC2614].
+-
+-4.2. Discovering Storage Management Services with SLP
+-
+- Storage management servers can be built to manage and control access
+- to targets in a variety of ways. They can provide extended services
+- beyond discovery, which could include storage allocation and
+- management. None of these services are defined here; the intent of
+- this document is to allow these services to be discovered by both
+- clients and servers, in addition to the target discovery already
+- being performed.
+-
+- The following drawing shows an iSCSI client, an iSCSI server, and a
+- storage management server. To simplify the drawing, the second IP
+- network is not shown but is assumed to exist. The storage management
+- server would use its own protocol (smsp) to provide capabilities to
+- iSCSI clients and servers; these clients and servers can both use SLP
+- to discover the storage management server.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 9]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- +---------------------------+
+- | iSCSI Client |
+- | |
+- | +-----------+ |
+- | | iSCSI | |
+- | | initiator | |
+- | +-----------+ |
+- | |
+- +---------------+------+----+ +------------+
+- | iSCSI Driver | smsp | UA | | SLP DA |
+- +---------------+------+----+ | |
+- | TCP/UDP/IP | | (optional) |
+- +---------------+------+----+ +------------+
+- | |
+- | IP Network |
+- ------------------------------------------
+- | |
+- | |
+- +---------------+-----------+ +---------------------+
+- | TCP/UDP/IP | | TCP/UDP/IP |
+- +---------------+------+----+ +---------------------+
+- | iSCSI Driver | smsp | UA | | SA | smsp |
+- +---------------+------+----+ +---------------------+
+- | | | |
+- | +--------+ +--------+ | | storage mgmt server |
+- | | iSCSI | | iSCSI | | | |
+- | | target | | target | | +---------------------+
+- | | 1 | | 2 | |
+- | +--------+ +--------+ |
+- | |
+- | iSCSI Server |
+- +---------------------------+
+-
+- Note the difference between the storage management server model and
+- the previously defined target discovery model. When target discovery
+- was used, the iSCSI Server implemented an SA, to be discovered by the
+- initiator's UA. In the storage management server model, the iSCSI
+- clients and servers both implement UAs, and the management server
+- implements the SA.
+-
+- A storage management server's URL contains the domain name or IP
+- address and TCP or UDP port number. No other information is
+- required.
+-
+- The storage management server constructs a service advertisement of
+- the type "service:iscsi:sms" for each of the addresses at which it
+- appears. The advertisement contains the URL and a lifetime, along
+- with other attributes that are defined in the service template.
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 10]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- The remainder of the discovery procedure is identical to that used to
+- discover iSCSI targets, except that both initiators and targets would
+- normally be "clients" of the storage management service.
+-
+- Targets that support a storage management service implement a UA in
+- addition to the SA. A target may alternatively just implement the UA
+- and allow the storage management service to advertise its targets
+- appropriately by providing an SA and registering the appropriate
+- service:iscsi:target registrations on the target's behalf: The target
+- device would not have to advertise its own targets. This has no
+- impact on the initiator.
+-
+- This allows the initiators' discovery of targets to be completely
+- interoperable regardless of which storage management service is used,
+- or whether one is used at all, or whether the target registrations
+- are provided directly by the target or by the management service.
+-
+-4.3. Internationalization Considerations
+-
+- SLP allows internationalized strings to be registered and retrieved.
+- Attributes in the template that are not marked with an 'L' (literal)
+- will be registered in a localized manner. An "en" (English)
+- localization MUST be registered, and others MAY be registered.
+-
+- Attributes that include non-ASCII characters will be encoded by using
+- UTF-8, as discussed in [RFC3722] and [RFC3491].
+-
+-5. iSCSI SLP Templates
+-
+- Three templates are provided: an iSCSI target template, a management
+- service template, and an abstract template to encapsulate the two.
+-
+-5.1. The iSCSI Abstract Service Type Template
+-
+- This template defines the abstract service "service:iscsi". It is
+- used as a top-level service to encapsulate all other iSCSI-related
+- services.
+-
+- Name of submitter: Mark Bakke
+- Language of service template: en
+- Security Considerations: See section 6.
+-
+- Template Text:
+- -------------------------template begins here-----------------------
+- template-type=iscsi
+- template-version=1.0
+-
+- template-description=
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 11]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- This is an abstract service type. The purpose of the iscsi
+- service type is to encompass all of the services used to support
+- the iSCSI protocol.
+-
+- template-url-syntax=
+- url-path= ; Depends on the concrete service type.
+-
+- --------------------------template ends here------------------------
+-
+-5.2. The iSCSI Target Concrete Service Type Template
+-
+- This template defines the service "service:iscsi:target". An entity
+- containing iSCSI targets that wishes them discovered via SLP would
+- register each of them, with each of their addresses, as this service
+- type.
+-
+- Initiators (and perhaps management services) wishing to discover
+- targets in this way will generally use one of the following queries:
+-
+- 1. Find a specific target, given its iSCSI Target Name:
+-
+- Service: service:iscsi:target
+- Scope: initiator-scope-list
+- Query: (iscsi-name=iqn.2001-04.com.example:sn.456)
+-
+- 2. Find all of the iSCSI Target Names that may allow access to a
+- given initiator:
+-
+- Service: service:iscsi:target
+- Scope: initiator-scope-list
+- Query: (auth-name=iqn.1998-03.com.example:hostid.045A7B)
+-
+- 3. Find all of the iSCSI Target Names that may allow access to
+- any initiator:
+-
+- Service: service:iscsi:target
+- Scope: initiator-scope-list
+- Query: (auth-name=any)
+-
+- 4. Find all of the iSCSI Target Names that may allow access to
+- this initiator, or that will allow access to any initiator:
+-
+- Service: service:iscsi:target
+- Scope: initiator-scope-list
+- Query: &(auth-name=iqn.1998-03.com.example:hostid.045A7B)
+- (auth-name=any)
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 12]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- 5. Find all of the iSCSI Target Names that may allow access to
+- a given CHAP user name:
+-
+- Service: service:iscsi:target
+- Scope: initiator-scope-list
+- Query: (auth-cred=chap/my-user-name)
+-
+- 6. Find all of the iSCSI Target Names that may allow access to a
+- given initiator that supports two IP addresses, a CHAP credential
+- and SRP credential, and an initiator name:
+-
+- Service: service:iscsi:target
+- Scope: initiator-scope-list
+- Query: &(|(auth-name=iqn.com.example:host47)(auth-name=any)
+- |(auth-addr=192.0.2.3)(auth-addr=192.0.2.131)(auth-addr=any)
+- |(auth-cred=chap/foo)(auth-cred=srp/my-user-name)
+- (auth-cred=any))
+-
+- 7. Find the iSCSI Target Names from which the given initiator is
+- allowed to boot:
+-
+- Service: service:iscsi:target
+- Scope: initiator-scope-list
+- Query: (boot-list=iqn.1998-03.com.example:hostid.045A7B)
+-
+- 8. In addition, a management service may wish to discover all
+- targets:
+-
+- Service: service:iscsi:target
+- Scope: management-server-scope-list
+- Query: <empty-string>
+-
+- More details on booting from an iSCSI target are defined in [BOOT].
+-
+- Name of submitter: Mark Bakke
+- Language of service template: en
+- Security Considerations: see section 6.
+-
+- Template Text:
+- -------------------------template begins here-----------------------
+- template-type=iscsi:target
+- template-version=1.0
+-
+- template-description=
+-
+- This is a concrete service type. The iscsi:target service type is
+- used to register individual target addresses to be discovered
+- by others. UAs will generally search for these by including one of
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 13]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- the following:
+-
+- - the iSCSI target name
+- - iSCSI initiator identifiers (iSCSI name, credential, IP address)
+- - the service URL
+-
+- template-url-syntax=
+- url-path = hostport "/" iscsi-name [ "/" identity ]
+- hostport = host [ ":" port ]
+- host = hostname / hostnumber ; DNS name or IP address
+- hostname = *( domainlabel "." ) toplabel
+- alphanum = ALPHA / DIGIT
+- domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum
+- toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
+- hostnumber = ipv4-number / ipv6-addr ; IPv4 or IPv6 address
+- ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
+- ipv6-addr = "[" ipv6-number "]"
+- ipv6-number = 6( h16 ":" ) ls32
+- / "::" 5( h16 ":" ) ls32
+- / [ h16 ] "::" 4( h16 ":" ) ls32
+- / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
+- / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
+- / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
+- / [ *4( h16 ":" ) h16 ] "::" ls32
+- / [ *5( h16 ":" ) h16 ] "::" h16
+- / [ *6( h16 ":" ) h16 ] "::"
+- ls32 = ( h16 ":" h16 ) / ipv4-number
+- ; least-significant 32 bits of ipv6 address
+- h16 = 1*4HEXDIG
+- port = 1*DIGIT
+- iscsi-name = iscsi-char ; iSCSI target name
+- identity = iscsi-char ; optional identity string
+- iscsi-char = ALPHA / DIGIT / escaped / ":" / "-" / "."
+- ; Intended to allow UTF-8 encoded strings
+- escaped = 1*("\" HEXDIG HEXDIG)
+- ;
+- ; The iscsi-name part of the URL is required and must be the iSCSI
+- ; name of the target being registered.
+- ; A device representing multiple targets must individually
+- ; register each target/address combination with SLP.
+- ; The identity part of the URL is optional, and is used to
+- ; indicate an identity that is allowed to access this target.
+- ;
+- ; Example (split into two lines for clarity):
+- ; service:iscsi:target://192.0.2.3:3260/
+- ; iqn.2001-04.com.example:sn.45678
+- ;
+- ; IPv6 addresses are also supported; they use the notation
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 14]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- ; specified above and in [RFC3513], section 2.2
+-
+- iscsi-name = string
+- # The iSCSI Name of this target.
+- # This must match the iscsi-name in the url-path.
+-
+- portal-group = integer
+- # The iSCSI portal group tag for this address. Addresses sharing
+- # the same iscsi-name and portal-group tag can be used within the
+- # same iSCSI session. Portal groups are described in [RFC3720].
+-
+- transports = string M L
+- tcp
+- # This is a list of transport protocols that the registered
+- # entity supports. iSCSI is currently supported over TCP,
+- # but it is anticipated that it could be supported over other
+- # transports, such as SCTP, in the future.
+- tcp
+-
+- mgmt-entity = string O
+- # The fully qualified domain name, or IP address in dotted-decimal
+- # notation, of the management interface of the entity containing
+- # this target.
+- #
+-
+- alias = string O
+- # The alias string contains a descriptive name of the target.
+-
+- auth-name = string M X
+- # A list of iSCSI Initiator Names that can access this target.
+- # Normal iSCSI names will be 80 characters or less; max length
+- # is 255.
+- # Normally, only one or a few values will be in the list.
+- # Using the equivalence search on this will evaluate to "true"
+- # if any one of the items in this list matches the query.
+- # If this list contains the default name "any", any initiator
+- # is allowed to access this target, provided it matches
+- # the other auth-xxx attributes.
+- #
+- # This attribute contains security policy information. If this
+- # attribute is distributed via an Attribute Reply message,
+- # IPsec MUST be implemented.
+-
+- auth-addr = string M X
+- # A list of initiator IP addresses (or host names) which will
+- # be allowed access to this target. If this list contains the
+- # default name "any", any IP address is allowed access to this
+- # target, provided it matches the other auth-xxx attributes.
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 15]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- #
+- # This attribute contains security policy information. If this
+- # attribute is distributed via an Attribute Reply message,
+- # IPsec MUST be implemented.
+-
+- auth-cred = string M X
+- # A list of credentials which will be allowed access to the target
+- # (provided they can provide the correct password or other
+- # authenticator). Entries in this list are of the form
+- # "method/identifier", where the currently defined methods are
+- # "chap" and "srp", both of which take usernames as their
+- # identifiers.
+- #
+- # This attribute contains security policy information. If this
+- # attribute is distributed via an Attribute Reply message,
+- # IPsec MUST be implemented.
+-
+- boot-list = string M O
+- # A list of iSCSI Initiator Names that can boot from this target.
+- # This list works precisely like the auth-name attribute. A name
+- # appearing in this list must either appear in the access-list,
+- # or the access-list must contain the initiator name "iscsi".
+- # Otherwise, an initiator will be unable to find its boot
+- # target. If boot-list contains the name "iscsi", any host can boot
+- # from it, but I am not sure if this is useful to anyone. If this
+- # attribute is not registered, this target is not "bootable".
+- #
+- # Note that the LUN the host boots from is not specified here; a
+- # host will generally attempt to boot from LUN 0.
+- #
+- # It is quite possible that other attributes will need to be defined
+- # here for booting as well.
+- #
+- # This attribute contains security policy information. If this
+- # attribute is distributed via an Attribute Reply message,
+- # IPsec MUST be implemented.
+-
+- --------------------------template ends here------------------------
+-
+-5.3. iSCSI Storage Management Service Templates
+-
+- This template defines the service "service:iscsi:sms". An entity
+- supporting one or more iSCSI management service protocols may
+- register itself with SLP as this service type. iSCSI clients and
+- servers wishing to discover storage management services using SLP
+- will usually search for them by the protocol(s) they support:
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 16]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- Service: service:iscsi:sms
+- Scope: initiator-scope-list
+- Query: (protocols=isns)
+-
+- Name of submitter: Mark Bakke
+- Language of service template: en
+- Security Considerations: see section 6.
+-
+- Template Text:
+- -------------------------template begins here-----------------------
+- template-type=iscsi:sms
+- template-version=1.0
+-
+- template-description=
+- This is a concrete service type. The iscsi:sms service type
+- provides the capability for entities supporting iSCSI to discover
+- appropriate management services.
+-
+- template-url-syntax=
+- url-path = ; The URL of the management service [RFC2608].
+-
+- protocols = string M
+- # The list of protocols supported by this name service. This
+- # list may be expanded in the future. There is no default.
+- #
+- # "isns" - This management service supports the use of the iSNS
+- # protocol for access management, health monitoring, and
+- # discovery management services. This protocol is defined
+- # in [ISNS].
+- isns
+-
+- transports = string M L
+- tcp
+- # This is a list of transport protocols that the registered
+- # entity supports.
+- tcp, udp
+-
+- server-priority = integer
+- # The priority a client should give this server, when choosing
+- # between multiple servers with the same protocol type.
+- # When multiple servers are discovered for a given protocol type,
+- # this parameter indicates their relative precedence. Server
+- # precedence is protocol-specific; for some protocols, the primary
+- # server may have the highest server-priority value, while for
+-
+-
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 17]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- # others it may have the lowest. For example, with iSNS, the primary
+- # server has the lowest value (value 0).
+-
+- --------------------------template ends here------------------------
+-
+-6. Security Considerations
+-
+- The SLPv2 security model as specified in [RFC2608] does not provide
+- confidentiality but does provide an authentication mechanism for UAs
+- to ensure that service advertisements only come from trusted SAs,
+- with the exception that it does not provide a mechanism to
+- authenticate "zero-result responses". See [RFC3723] for a discussion
+- of the SLPv2 [RFC2608] security model.
+-
+- Once a target or management server is discovered, authentication and
+- authorization are handled by the iSCSI protocol, or by the management
+- server's protocol. It is the responsibility of the providers of
+- these services to ensure that an inappropriately advertised or
+- discovered service does not compromise their security.
+-
+- When no security is used for SLPv2, there is a risk of distribution
+- of false discovery information. The primary countermeasure for this
+- risk is authentication. When this risk is a significant concern,
+- IPsec SAs and iSCSI in-band authentication SHOULD be used for iSCSI
+- traffic subject to this risk to ensure that iSCSI traffic only flows
+- between endpoints that have participated in IKE authentication and
+- iSCSI in-band authentication. For example, if an attacker
+- distributes discovery information falsely claiming that it is an
+- iSCSI target, it will lack the secret information necessary to
+- complete IKE authentication or iSCSI in-band authentication
+- successfully and therefore will be prevented from falsely sending or
+- receiving iSCSI traffic.
+-
+- A risk remains of a denial of service attack based on repeated use of
+- false discovery information that will cause initiation of IKE
+- negotiation. The countermeasures for this are administrative
+- configuration of each iSCSI Target to limit the peers it is willing
+- to communicate with (i.e., by IP address range and/or DNS domain),
+- and maintenance of a negative authentication cache to avoid
+- repeatedly contacting an iSCSI Target that fails to authenticate.
+- These three measures (i.e., IP address range limits, DNS domain
+- limits, negative authentication cache) MUST be implemented.
+-
+- The auth-name, auth-addr, auth-cred, and boot-list attributes
+- comprise security policy information. When these are distributed,
+- IPsec MUST be implemented.
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 18]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+-6.1. Security Implementation
+-
+- Security for SLPv2 in an IP storage environment is specified in
+- [RFC3723]. IPsec is mandatory-to-implement for IPS clients and
+- servers. Thus, all IP storage clients, including those invoking SLP,
+- can be assumed to support IPsec. SLP servers, however, cannot be
+- assumed to implement IPsec, since there is no such requirement in
+- standard SLP. In particular, SLP Directory Agents (DA) may be
+- running on machines other than those running the IPS protocols.
+-
+- IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this
+- includes ESP with a non-null transform to provide both authentication
+- and confidentiality.
+-
+- When SLPv2 can be used to distribute auth-name, auth-addr, auth-cred,
+- and boot-list information (see section 5.2 above), IPsec MUST be
+- implemented, as these items are considered sensitive security policy
+- information. If IPsec is not implemented, auth-name, auth-addr,
+- auth-cred, and boot-list information MUST NOT be distributed via
+- SLPv2 and MUST NOT be used if discovered via SLPv2.
+-
+- Because the IP storage services have their own authentication
+- capabilities when located, SLPv2 authentication is OPTIONAL to
+- implement and use (as discussed in more detail in [RFC3723]).
+-
+-7. IANA Considerations
+-
+- This document describes three SLP Templates. They have been reviewed
+- and approved by the IESG and registered in the IANA's "SVRLOC
+- Templates" registry. This process is described in the IANA
+- Considerations section of [RFC2609].
+-
+-8. Summary
+-
+- This document describes how SLP can be used by iSCSI initiators to
+- find iSCSI targets and storage management servers. Service type
+- templates for iSCSI targets and storage management servers are
+- presented.
+-
+-9. Normative References
+-
+- [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
+- "Service Location Protocol, Version 2", RFC 2608, June
+- 1999.
+-
+- [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service
+- Templates and Service: Schemes", RFC 2609, June 1999.
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 19]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+- Requirement Levels", BCP 14, RFC 2119, March 1997.
+-
+- [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+- Profile for Internationalized Domain Names (IDN)", RFC
+- 3491, March 2003.
+-
+- [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
+- (IPv6) Addressing Architecture", RFC 3513, April 2003.
+-
+- [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
+- and E. Zeidner, "Internet Small Computer Systems
+- Interface (iSCSI)", RFC 3720, April 2004.
+-
+- [RFC3722] Bakke, M., "String Profile for Internet Small Computer
+- Systems Interface (iSCSI) Names", RFC 3722, April 2004.
+-
+- [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
+- Travostino, "Securing Block Storage Protocols over IP",
+- RFC 3723, April 2004.
+-
+-10. Informative References
+-
+- [RFC2614] Kempf, J. and E. Guttman, "An API for Service Location",
+- RFC 2614, June 1999.
+-
+- [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.
+-
+- [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M.
+- Krueger, "Internet Small Computer Systems Interface
+- (iSCSI) Naming and Discovery", RFC 3721, April 2004.
+-
+- [ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and
+- J. Souza, "Internet Storage Name Service", Work in
+- Progress, February 2004.
+-
+- [BOOT] Sarkar, P., Missimer, D. and C. Sapuntzakis, "A Standard
+- for Bootstrapping Clients using the iSCSI Protocol", Work
+- in Progress, March 2004.
+-
+- [RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with
+- SLP", RFC 3105, October 2001.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 20]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+-11. Acknowledgements
+-
+- This document was produced by the iSCSI Naming and Discovery team,
+- including Joe Czap, Jim Hafner, John Hufferd, and Kaladhar Voruganti
+- (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (Sanrad),
+- Marjorie Krueger (HP), Lawrence Lamers (San Valley), Todd Sperry
+- (Adaptec), and Joshua Tseng (Nishan). Thanks also to Julian Satran
+- (IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt
+- Peterson (Caldera) and James Kempf (Sun) for reviewing the document
+- from an SLP perspective.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 21]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+-Authors' Addresses
+-
+- Mark Bakke
+- Cisco Systems, Inc.
+- 7900 International Drive, Suite 400
+- Bloomington, MN
+- USA 55425
+-
+- EMail: mbakke at cisco.com
+-
+-
+- Kaladhar Voruganti
+- IBM Almaden Research Center
+- 650 Harry Road
+- San Jose, CA 95120
+-
+- EMail: kaladhar at us.ibm.com
+-
+-
+- John L. Hufferd
+- IBM Storage Systems Group
+- 5600 Cottle Road
+- San Jose, CA 95193
+-
+- Phone: +1 408 997-6136
+- EMail: jlhufferd at comcast.net
+-
+-
+- Marjorie Krueger
+- Hewlett-Packard Corporation
+- 8000 Foothills Blvd
+- Roseville, CA 95747-5668, USA
+-
+- Phone: +1 916 785-2656
+- EMail: marjorie_krueger at hp.com
+-
+-
+- Todd Sperry
+- Adaptec, Inc.
+- 691 South Milpitas Boulevard
+- Milpitas, Ca. 95035
+-
+- Phone: +1 408 957-4980
+- EMail: todd_sperry at adaptec.com
+-
+-
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 22]
+-
+-RFC 4018 iSCSI and SLPv2 April 2005
+-
+-
+-Full Copyright Statement
+-
+- Copyright (C) The Internet Society (2005).
+-
+- This document is subject to the rights, licenses and restrictions
+- contained in BCP 78, and except as set forth therein, the authors
+- retain all their rights.
+-
+- This document and the information contained herein are provided on an
+- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+-
+-Intellectual Property
+-
+- The IETF takes no position regarding the validity or scope of any
+- Intellectual Property Rights or other rights that might be claimed to
+- pertain to the implementation or use of the technology described in
+- this document or the extent to which any license under such rights
+- might or might not be available; nor does it represent that it has
+- made any independent effort to identify any such rights. Information
+- on the procedures with respect to rights in RFC documents can be
+- found in BCP 78 and BCP 79.
+-
+- Copies of IPR disclosures made to the IETF Secretariat and any
+- assurances of licenses to be made available, or the result of an
+- attempt made to obtain a general license or permission for the use of
+- such proprietary rights by implementers or users of this
+- specification can be obtained from the IETF on-line IPR repository at
+- http://www.ietf.org/ipr.
+-
+- The IETF invites any interested party to bring to its attention any
+- copyrights, patents or patent applications, or other proprietary
+- rights that may cover technology that may be required to implement
+- this standard. Please address the information to the IETF at ietf-
+- ipr at ietf.org.
+-
+-Acknowledgement
+-
+- Funding for the RFC Editor function is currently provided by the
+- Internet Society.
+-
+-
+-
+-
+-
+-
+-
+-Bakke & Hufferd Standards Track [Page 23]
+-
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc4171.txt open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc4171.txt
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/doc/rfc4171.txt 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/doc/rfc4171.txt 1969-12-31 18:00:00.000000000 -0600
+@@ -1,6891 +0,0 @@
+-
+-
+-
+-
+-
+-
+-Network Working Group J. Tseng
+-Request for Comments: 4171 Riverbed Technology
+-Category: Standards Track K. Gibbons
+- McDATA Corporation
+- F. Travostino
+- Nortel
+- C. Du Laney
+- Rincon Research Corporation
+- J. Souza
+- Microsoft
+- September 2005
+-
+-
+- Internet Storage Name Service (iSNS)
+-
+-Status of This Memo
+-
+- This document specifies an Internet standards track protocol for the
+- Internet community, and requests discussion and suggestions for
+- improvements. Please refer to the current edition of the "Internet
+- Official Protocol Standards" (STD 1) for the standardization state
+- and status of this protocol. Distribution of this memo is unlimited.
+-
+-Copyright Notice
+-
+- Copyright (C) The Internet Society (2005).
+-
+-Abstract
+-
+- This document specifies the Internet Storage Name Service (iSNS)
+- protocol, used for interaction between iSNS servers and iSNS clients,
+- which facilitates automated discovery, management, and configuration
+- of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP
+- network. iSNS provides intelligent storage discovery and management
+- services comparable to those found in Fibre Channel networks,
+- allowing a commodity IP network to function in a capacity similar to
+- that of a storage area network. iSNS facilitates a seamless
+- integration of IP and Fibre Channel networks due to its ability to
+- emulate Fibre Channel fabric services and to manage both iSCSI and
+- Fibre Channel devices. iSNS thereby provides value in any storage
+- network comprised of iSCSI devices, Fibre Channel devices (using iFCP
+- gateways), or any combination thereof.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 1]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-Table of Contents
+-
+- 1. Introduction................................................... 6
+- 1.1. Conventions Used in This Document........................ 6
+- 1.2. Purpose of This Document................................. 6
+- 2. iSNS Overview.................................................. 6
+- 2.1. iSNS Architectural Components ........................... 7
+- 2.1.1. iSNS Protocol (iSNSP) ........................... 7
+- 2.1.2. iSNS Client...................................... 7
+- 2.1.3. iSNS Server...................................... 7
+- 2.1.4. iSNS Database ................................... 7
+- 2.1.5. iSCSI............................................ 7
+- 2.1.6. iFCP............................................. 7
+- 2.2. iSNS Functional Overview................................. 8
+- 2.2.1. Name Registration Service........................ 8
+- 2.2.2. Discovery Domain and Login Control Service....... 8
+- 2.2.3. State Change Notification Service............... 10
+- 2.2.4. Open Mapping between
+- Fibre Channel and iSCSI Devices................. 11
+- 2.3. iSNS Usage Model........................................ 11
+- 2.3.1. iSCSI Initiator................................. 12
+- 2.3.2. iSCSI Target.................................... 12
+- 2.3.3. iSCSI-FC Gateway................................ 12
+- 2.3.4. iFCP Gateway.................................... 12
+- 2.3.5. Management Station.............................. 12
+- 2.4. Administratively Controlled iSNS Settings............... 13
+- 2.5. iSNS Server Discovery .................................. 14
+- 2.5.1. Service Location Protocol (SLP)................. 14
+- 2.5.2. Dynamic Host Configuration Protocol (DHCP)...... 14
+- 2.5.3. iSNS Heartbeat Message.......................... 14
+- 2.6. iSNS and Network Address Translation (NAT).............. 14
+- 2.7. Transfer of iSNS Database Records between iSNS Servers.. 15
+- 2.8. Backup iSNS Servers..................................... 17
+- 2.9. Transport Protocols..................................... 19
+- 2.9.1. Use of TCP for iSNS Communication............... 19
+- 2.9.2. Use of UDP for iSNS Communication............... 20
+- 2.9.3. iSNS Multicast and Broadcast Messages........... 20
+- 2.10. Simple Network Management Protocol (SNMP) Requirements.. 21
+- 3. iSNS Object Model............................................. 21
+- 3.1. Network Entity Object .................................. 22
+- 3.2. Portal Object .......................................... 22
+- 3.3. Storage Node Object..................................... 22
+- 3.4. Portal Group Object..................................... 23
+- 3.5. FC Device Object........................................ 24
+- 3.6. Discovery Domain Object................................. 24
+- 3.7. Discovery Domain Set Object............................. 24
+- 3.8. iSNS Database Model..................................... 24
+- 4. iSNS Implementation Requirements.............................. 25
+-
+-
+-
+-Tseng, et al. Standards Track [Page 2]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- 4.1. iSCSI Requirements...................................... 25
+- 4.1.1. Required Attributes for Support of iSCSI........ 26
+- 4.1.2. Examples: iSCSI Object Model Diagrams........... 28
+- 4.1.3. Required Commands and
+- Response Messages for Support of iSCSI.......... 30
+- 4.2. iFCP Requirements....................................... 31
+- 4.2.1. Required Attributes for Support of iFCP......... 31
+- 4.2.2. Example: iFCP Object Model Diagram.............. 32
+- 4.2.3. Required Commands and
+- Response Messages for Support of iFCP........... 34
+- 5. iSNSP Message Format.......................................... 35
+- 5.1. iSNSP PDU Header........................................ 35
+- 5.1.1. iSNSP Version................................... 36
+- 5.1.2. iSNSP Function ID............................... 36
+- 5.1.3. iSNSP PDU Length................................ 36
+- 5.1.4. iSNSP Flags..................................... 36
+- 5.1.5. iSNSP Transaction ID............................ 36
+- 5.1.6. iSNSP Sequence ID............................... 37
+- 5.2. iSNSP Message Segmentation and Reassembly............... 37
+- 5.3. iSNSP PDU Payload....................................... 37
+- 5.3.1. Attribute Value 4-Byte Alignment................ 38
+- 5.4. iSNSP Response Status Codes............................. 39
+- 5.5. Authentication for iSNS Multicast and Broadcast Messages 39
+- 5.6. Registration and Query Messages......................... 41
+- 5.6.1. Source Attribute................................ 42
+- 5.6.2. Message Key Attributes.......................... 42
+- 5.6.3. Delimiter Attribute............................. 42
+- 5.6.4. Operating Attributes............................ 43
+- 5.6.5. Registration and Query Request Message Types ... 44
+- 5.7. Response Messages....................................... 66
+- 5.7.1. Status Code..................................... 66
+- 5.7.2. Message Key Attributes in Response.............. 66
+- 5.7.3. Delimiter Attribute in Response................. 67
+- 5.7.4. Operating Attributes in Response................ 67
+- 5.7.5. Registration and Query Response Message Type.... 67
+- 5.8. Vendor-Specific Messages................................ 72
+- 6. iSNS Attributes............................................... 73
+- 6.1. iSNS Attribute Summary.................................. 73
+- 6.2. Entity Identifier-Keyed Attributes...................... 76
+- 6.2.1. Entity Identifier (EID)......................... 76
+- 6.2.2. Entity Protocol................................. 76
+- 6.2.3. Management IP Address .......................... 77
+- 6.2.4. Entity Registration Timestamp .................. 77
+- 6.2.5. Protocol Version Range.......................... 77
+- 6.2.6. Registration Period............................. 78
+- 6.2.7. Entity Index.................................... 78
+- 6.2.8. Entity Next Index............................... 79
+- 6.2.9. Entity ISAKMP Phase-1 Proposals................. 79
+-
+-
+-
+-Tseng, et al. Standards Track [Page 3]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- 6.2.10. Entity Certificate.............................. 79
+- 6.3. Portal-Keyed Attributes................................. 80
+- 6.3.1. Portal IP Address............................... 80
+- 6.3.2. Portal TCP/UDP Port............................. 80
+- 6.3.3. Portal Symbolic Name............................ 80
+- 6.3.4. Entity Status Inquiry Interval.................. 81
+- 6.3.5. ESI Port........................................ 82
+- 6.3.6. Portal Index.................................... 82
+- 6.3.7. SCN Port........................................ 82
+- 6.3.8. Portal Next Index............................... 83
+- 6.3.9. Portal Security Bitmap.......................... 83
+- 6.3.10. Portal ISAKMP Phase-1 Proposals................. 84
+- 6.3.11. Portal ISAKMP Phase-2 Proposals................. 84
+- 6.3.12. Portal Certificate.............................. 84
+- 6.4. iSCSI Node-Keyed Attributes............................. 84
+- 6.4.1. iSCSI Name...................................... 85
+- 6.4.2. iSCSI Node Type................................. 85
+- 6.4.3. iSCSI Node Alias................................ 86
+- 6.4.4. iSCSI Node SCN Bitmap .......................... 86
+- 6.4.5. iSCSI Node Index................................ 87
+- 6.4.6. WWNN Token...................................... 87
+- 6.4.7. iSCSI Node Next Index .......................... 89
+- 6.4.8. iSCSI AuthMethod................................ 89
+- 6.5. Portal Group (PG) Object-Keyed Attributes............... 89
+- 6.5.1. Portal Group iSCSI Name......................... 90
+- 6.5.2. PG Portal IP Addr............................... 90
+- 6.5.3. PG Portal TCP/UDP Port.......................... 90
+- 6.5.4. Portal Group Tag (PGT).......................... 90
+- 6.5.5. Portal Group Index.............................. 90
+- 6.5.6. Portal Group Next Index......................... 91
+- 6.6. FC Port Name-Keyed Attributes .......................... 91
+- 6.6.1. FC Port Name (WWPN)............................. 91
+- 6.6.2. Port ID (FC_ID)................................. 91
+- 6.6.3. FC Port Type.................................... 92
+- 6.6.4. Symbolic Port Name.............................. 92
+- 6.6.5. Fabric Port Name (FWWN)......................... 92
+- 6.6.6. Hard Address.................................... 92
+- 6.6.7. Port IP Address................................. 92
+- 6.6.8. Class of Service (COS).......................... 93
+- 6.6.9. FC-4 Types...................................... 93
+- 6.6.10. FC-4 Descriptor................................. 93
+- 6.6.11. FC-4 Features .................................. 93
+- 6.6.12. iFCP SCN Bitmap................................. 93
+- 6.6.13. Port Role....................................... 94
+- 6.6.14. Permanent Port Name (PPN)....................... 95
+- 6.7. Node-Keyed Attributes .................................. 95
+- 6.7.1. FC Node Name (WWNN)............................. 95
+- 6.7.2. Symbolic Node Name.............................. 95
+-
+-
+-
+-Tseng, et al. Standards Track [Page 4]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- 6.7.3. Node IP Address................................. 95
+- 6.7.4. Node IPA........................................ 96
+- 6.7.5. Proxy iSCSI Name................................ 96
+- 6.8. Other Attributes........................................ 96
+- 6.8.1. FC-4 Type Code.................................. 96
+- 6.8.2. iFCP Switch Name................................ 96
+- 6.8.3. iFCP Transparent Mode Commands.................. 97
+- 6.9. iSNS Server-Specific Attributes......................... 97
+- 6.9.1. iSNS Server Vendor OUI.......................... 98
+- 6.10. Vendor-Specific Attributes.............................. 98
+- 6.10.1. Vendor-Specific Server Attributes............... 98
+- 6.10.2. Vendor-Specific Entity Attributes............... 98
+- 6.10.3. Vendor-Specific Portal Attributes............... 99
+- 6.10.4. Vendor-Specific iSCSI Node Attributes........... 99
+- 6.10.5. Vendor-Specific FC Port Name Attributes......... 99
+- 6.10.6. Vendor-Specific FC Node Name Attributes......... 99
+- 6.10.7. Vendor-Specific Discovery Domain Attributes..... 99
+- 6.10.8. Vendor-Specific Discovery Domain Set Attributes. 99
+- 6.10.9. Other Vendor-Specific Attributes................ 99
+- 6.11. Discovery Domain Registration Attributes............... 100
+- 6.11.1. DD Set ID Keyed Attributes..................... 100
+- 6.11.2. DD ID Keyed Attributes......................... 101
+- 7. Security Considerations...................................... 103
+- 7.1. iSNS Security Threat Analysis ......................... 103
+- 7.2. iSNS Security Implementation and Usage Requirements.... 104
+- 7.3. Discovering Security Requirements of Peer Devices...... 105
+- 7.4. Configuring Security Policies of iFCP/iSCSI Devices.... 106
+- 7.5. Resource Issues........................................ 107
+- 7.6. iSNS Interaction with IKE and IPSec.................... 107
+- 8. IANA Considerations.......................................... 107
+- 8.1. Registry of Block Storage Protocols.................... 107
+- 8.2. Registry of Standard iSNS Attributes .................. 108
+- 8.3. Block Structure Descriptor (BSD) Registry.............. 108
+- 9. Normative References......................................... 109
+- 10. Informative References....................................... 110
+- Appendix A: iSNS Examples........................................ 112
+- A.1. iSCSI Initialization Example........................... 112
+- A.1.1. Simple iSCSI Target Registration............... 112
+- A.1.2. Target Registration and DD Configuration....... 114
+- A.1.3. Initiator Registration and Target Discovery.... 117
+- Acknowledgements................................................. 121
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 5]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-1. Introduction
+-
+-1.1. Conventions Used in This Document
+-
+- "iSNS" refers to the storage network model and associated services
+- covered in the text of this document.
+-
+- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+- document are to be interpreted as described in [RFC2119].
+-
+- All frame formats are in big endian network byte order.
+-
+- All unused fields and bitmaps, including those that are RESERVED,
+- SHOULD be set to zero when sending and ignored when receiving.
+-
+-1.2. Purpose of This Document
+-
+- This is a standards track document containing normative text
+- specifying the iSNS Protocol, used by iSCSI and iFCP devices to
+- communicate with the iSNS server. This document focuses on the
+- interaction between iSNS servers and iSNS clients; interactions among
+- multiple authoritative primary iSNS servers are a potential topic for
+- future work.
+-
+-2. iSNS Overview
+-
+- iSNS facilitates scalable configuration and management of iSCSI and
+- Fibre Channel (FCP) storage devices in an IP network by providing a
+- set of services comparable to that available in Fibre Channel
+- networks. iSNS thus allows a commodity IP network to function at a
+- level of intelligence comparable to a Fibre Channel fabric. iSNS
+- allows the administrator to go beyond a simple device-by-device
+- management model, where each storage device is manually and
+- individually configured with its own list of known initiators and
+- targets. Using the iSNS, each storage device subordinates its
+- discovery and management responsibilities to the iSNS server. The
+- iSNS server thereby serves as the consolidated configuration point
+- through which management stations can configure and manage the entire
+- storage network, including both iSCSI and Fibre Channel devices.
+-
+- iSNS can be implemented to support iSCSI and/or iFCP protocols as
+- needed; an iSNS implementation MAY provide support for one or both of
+- these protocols as desired by the implementor. Implementation
+- requirements within each of these protocols are further discussed in
+- Section 5. Use of iSNS is OPTIONAL for iSCSI and REQUIRED for iFCP.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 6]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-2.1. iSNS Architectural Components
+-
+-2.1.1. iSNS Protocol (iSNSP)
+-
+- The iSNS Protocol (iSNSP) is a flexible and lightweight protocol that
+- specifies how iSNS clients and servers communicate. It is suitable
+- for various platforms, including switches and targets as well as
+- server hosts.
+-
+-2.1.2. iSNS Client
+-
+- iSNS clients initiate transactions with iSNS servers using the iSNSP.
+- iSNS clients are processes that are co-resident in the storage
+- device, and that can register device attribute information, download
+- information about other registered clients in a common Discovery
+- Domain (DD), and receive asynchronous notification of events that
+- occur in their DD(s). Management stations are a special type of iSNS
+- client that have access to all DDs stored in the iSNS.
+-
+-2.1.3. iSNS Server
+-
+- iSNS servers respond to iSNS protocol queries and requests, and
+- initiate iSNS protocol State Change Notifications. Properly
+- authenticated information submitted by a registration request is
+- stored in an iSNS database.
+-
+-2.1.4. iSNS Database
+-
+- The iSNS database is the information repository for the iSNS
+- server(s). It maintains information about iSNS client attributes. A
+- directory-enabled implementation of iSNS may store client attributes
+- in an LDAP directory infrastructure.
+-
+-2.1.5. iSCSI
+-
+- iSCSI (Internet SCSI) is an encapsulation of SCSI for a new
+- generation of storage devices interconnected with TCP/IP [iSCSI].
+-
+-2.1.6. iFCP
+-
+- iFCP (Internet FCP) is a gateway-to-gateway protocol designed to
+- interconnect existing Fibre Channel and SCSI devices using TCP/IP.
+- iFCP maps the existing FCP standard and associated Fibre Channel
+- services to TCP/IP [iFCP].
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 7]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-2.2. iSNS Functional Overview
+-
+- There are four main functions of the iSNS:
+-
+- 1) A Name Service Providing Storage Resource Discovery
+-
+- 2) Discovery Domain (DD) and Login Control Service
+-
+- 3) State Change Notification Service
+-
+- 4) Open Mapping of Fibre Channel and iSCSI Devices
+-
+-2.2.1. Name Registration Service
+-
+- The iSNS provides a registration function to allow all entities in a
+- storage network to register and query the iSNS database. Both
+- targets and initiators can register in the iSNS database, as well as
+- query for information about other initiators and targets. This
+- allows, for example, a client initiator to obtain information about
+- target devices from the iSNS server. This service is modeled on the
+- Fibre Channel Generic Services Name Server described in FC-GS-4, with
+- extensions, operating within the context of an IP network.
+-
+- The naming registration service also provides the ability to obtain a
+- network-unique Domain ID for iFCP gateways when one is required.
+-
+-2.2.2. Discovery Domain and Login Control Service
+-
+- The Discovery Domain (DD) Service facilitates the partitioning of
+- Storage Nodes into more manageable groupings for administrative and
+- login control purposes. It allows the administrator to limit the
+- login process of each host to the more appropriate subset of targets
+- registered in the iSNS. This is particularly important for reducing
+- the number of unnecessary logins (iSCSI logins or Fibre Channel Port
+- Logins), and for limiting the amount of time that the host spends
+- initializing login relationships as the size of the storage network
+- scales up. Storage Nodes must be in at least one common enabled DD
+- in order to obtain information about each other. Devices can be
+- members of multiple DDs simultaneously.
+-
+- Login Control allows targets to delegate their access
+- control/authorization policies to the iSNS server. This is
+- consistent with the goal of centralizing management of those storage
+- devices using the iSNS server. The target node or device downloads
+- the list of authorized initiators from the iSNS. Each node or device
+- is uniquely identified by an iSCSI Name or FC Port Name. Only
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 8]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- initiators that match the required identification and authorization
+- provided by the iSNS will be allowed access by that target Node
+- during session establishment.
+-
+- Placing Portals of a Network Entity into Discovery Domains allows
+- administrators to indicate the preferred IP Portal interface through
+- which storage traffic should access specific Storage Nodes of that
+- Network Entity. If no Portals of a Network Entity have been placed
+- into a DD, then queries scoped to that DD SHALL report all Portals of
+- that Network Entity. If one or more Portals of a Network Entity have
+- been placed into a DD, then queries scoped to that DD SHALL report
+- only those Portals that have been explicitly placed in the DD.
+-
+- DDs can be managed offline through a separate management workstation
+- using the iSNSP or SNMP. If the target opts to use the Login Control
+- feature of the iSNS, the target delegates management of access
+- control policy (i.e., the list of initiators allowed to log in to
+- that target) to the management workstations that are managing the
+- configuration in the iSNS database.
+-
+- If administratively authorized, a target can upload its own Login
+- Control list. This is accomplished using the DDReg message and
+- listing the iSCSI name of each initiator to be registered in the
+- target's DD.
+-
+- An implementation MAY decide that newly registered devices that have
+- not explicitly been placed into a DD by the management station will
+- be placed into a "default DD" contained in a "default DDS" whose
+- initial DD Set Status value is "enabled". This makes them visible to
+- other devices in the default DD. Other implementations MAY decide
+- that they are registered with no DD, making them inaccessible to
+- source-scoped iSNSP messages.
+-
+- The iSNS server uses the Source Attribute of each iSNSP message to
+- determine the originator of the request and to scope the operation to
+- a set of Discovery Domains. In addition, the Node Type (specified in
+- the iFCP or iSCSI Node Type bitmap field) may also be used to
+- determine authorization for the specified iSNS operation. For
+- example, only Control Nodes are authorized to create or delete
+- discovery domains.
+-
+- Valid and active Discovery Domains (DDs) belong to at least one
+- active Discovery Domain Set (DDS). Discovery Domains that do not
+- belong to an activated DDS are not enabled. The iSNS server MUST
+- maintain the state of DD membership for all Storage Nodes, even for
+- those that have been deregistered. DD membership is persistent
+- regardless of whether a Storage Node is actively registered in the
+- iSNS database.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 9]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-2.2.3. State Change Notification Service
+-
+- The State Change Notification (SCN) service allows the iSNS Server to
+- issue notifications about network events that affect the operational
+- state of Storage Nodes. The iSNS client may register for
+- notifications on behalf of its Storage Nodes for notification of
+- events detected by the iSNS Server. SCNs notify iSNS clients of
+- explicit or implicit changes to the iSNS database; they do not
+- necessarily indicate the state of connectivity to peer storage
+- devices in the network. The response of a storage device to receipt
+- of an SCN is implementation-specific; the policy for responding to
+- SCNs is outside of the scope of this document.
+-
+- There are two types of SCN registrations: regular registrations and
+- management registrations. Management registrations result in
+- management SCNs, whereas regular registrations result in regular
+- SCNs. The type of registration and SCN message is indicated in the
+- SCN bitmap (see Sections 6.4.4 and 6.6.12).
+-
+- A regular SCN registration indicates that the Discovery Domain
+- Service SHALL be used to control the distribution of SCN messages.
+- Receipt of regular SCNs is limited to the discovery domains in which
+- the SCN-triggering event takes place. Regular SCNs do not contain
+- information about discovery domains.
+-
+- A management SCN registration can only by requested by Control Nodes.
+- Management SCNs resulting from management registrations are not bound
+- by the Discovery Domain service. Authorization to request management
+- SCN registrations may be administratively controlled.
+-
+- The iSNS server SHOULD be implemented with hardware and software
+- resources sufficient to support the expected number of iSNS clients.
+- However, if resources are unexpectedly exhausted, then the iSNS
+- server MAY refuse SCN service by returning an SCN Registration
+- Rejected (Status Code 17). The rejection might occur in situations
+- where the network size or current number of SCN registrations has
+- passed an implementation-specific threshold. A client not allowed to
+- register for SCNs may decide to monitor its sessions with other
+- storage devices directly.
+-
+-
+- The specific notification mechanism by which the iSNS server learns
+- of the events that trigger SCNs is implementation-specific, but can
+- include examples such as explicit notification messages from an iSNS
+- client to the iSNS server, or a hardware interrupt to a switch-hosted
+- iSNS server as a result of link failure.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 10]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-2.2.4. Open Mapping between Fibre Channel and iSCSI Devices
+-
+- The iSNS database stores naming and discovery information about both
+- Fibre Channel and iSCSI devices. This allows the iSNS server to
+- store mappings of a Fibre Channel device to a proxy iSCSI device
+- "image" in the IP network. Similarly, mappings of an iSCSI device to
+- a "proxy WWN" can be stored under the WWNN Token field for that iSCSI
+- device.
+-
+- Furthermore, through use of iSCSI-FC gateways, Fibre Channel-aware
+- management stations can interact with the iSNS server to retrieve
+- information about Fibre Channel devices, and use this information to
+- manage Fibre Channel and iSCSI devices. This allows management
+- functions such as Discovery Domains and State Change Notifications to
+- be applied seamlessly to both iSCSI and Fibre Channel devices,
+- facilitating integration of IP networks with Fibre Channel devices
+- and fabrics.
+-
+- Note that Fibre Channel attributes are stored as iFCP attributes, and
+- that the ability to store this information in the iSNS server is
+- useful even if the iFCP protocol is not implemented. In particular,
+- tag 101 can be used to store a "Proxy iSCSI Name" for Fibre Channel
+- devices registered in the iSNS server. This field is used to
+- associate the FC device with an iSCSI registration entry that is used
+- for the Fibre Channel device to communicate with iSCSI devices in the
+- IP network. Conversely, tag 37 (see Section 6.1) contains a WWNN
+- Token field, which can be used to store an FC Node Name (WWNN) value
+- used by iSCSI-FC gateways to represent an iSCSI device in the Fibre
+- Channel domain.
+-
+- By storing the mapping between Fibre Channel and iSCSI devices in the
+- iSNS server, this information becomes open to any authorized iSNS
+- client wishing to retrieve and use this information. In many cases,
+- this provides advantages over storing the information internally
+- within an iSCSI-FC gateway, where the mapping is inaccessible to
+- other devices except by proprietary mechanisms.
+-
+-2.3. iSNS Usage Model
+-
+- The following is a high-level description of how each type of device
+- in a storage network can utilize iSNS. Each type of device interacts
+- with the iSNS server as an iSNS client and must register itself in
+- the iSNS database in order to access services provided by the iSNS.
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 11]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-2.3.1. iSCSI Initiator
+-
+- An iSCSI initiator will query the iSNS server to discover the
+- presence and location of iSCSI target devices. It may also request
+- state change notifications (SCNs) so that it can be notified of new
+- targets that appear on the network after the initial bootup and
+- discovery. SCNs can also inform the iSCSI initiator of targets that
+- have been removed from or no longer available in the storage network,
+- so that incomplete storage sessions can be gracefully terminated and
+- resources for non-existent targets can be reallocated.
+-
+-2.3.2. iSCSI Target
+-
+- An iSCSI target allows itself to be discovered by iSCSI initiators by
+- registering its presence in the iSNS server. It may also register
+- for SCNs in order to detect the addition or removal of initiators for
+- resource allocation purposes. The iSCSI target device may also
+- register for Entity Status Inquiry (ESI) messages, which allow the
+- iSNS to monitor the target device's availability in the storage
+- network.
+-
+-2.3.3. iSCSI-FC Gateway
+-
+- An iSCSI-FC gateway bridges devices in a Fibre Channel network to an
+- iSCSI/IP network. It may use the iSNS server to store FC device
+- attributes discovered in the FC name server, as well as mappings of
+- FC device identifiers to iSCSI device identifiers. iSNS has the
+- capability to store all attributes of both iSCSI and Fibre Channel
+- devices; iSCSI devices are managed through direct interaction using
+- iSNS, while FC devices can be indirectly managed through iSNS
+- interactions with the iSCSI-FC gateway. This allows both iSCSI and
+- Fibre Channel devices to be managed in a seamless management
+- framework.
+-
+-2.3.4. iFCP Gateway
+-
+- An iFCP gateway uses iSNS to emulate the services provided by a Fibre
+- Channel name server for FC devices in its gateway region. iSNS
+- provides basic discovery and zoning configuration information to be
+- enforced by the iFCP gateway. When queried, iSNS returns information
+- on the N_Port network address used to establish iFCP sessions between
+- FC devices supported by iFCP gateways.
+-
+-2.3.5. Management Station
+-
+- A management station uses iSNS to monitor storage devices and to
+- enable or disable storage sessions by configuring discovery domains.
+- A management station usually interacts with the iSNS server as a
+-
+-
+-
+-Tseng, et al. Standards Track [Page 12]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Control Node endowed with access to all iSNS database records and
+- with special privileges to configure discovery domains. Through
+- manipulation of discovery domains, the management station controls
+- the scope of device discovery for iSNS clients querying the iSNS
+- server.
+-
+-2.4. Administratively Controlled iSNS Settings
+-
+- Some important operational settings for the iSNS server are
+- configured using administrative means, such as a configuration file,
+- a console port, an SNMP, or another implementation-specific method.
+- These administratively-controlled settings cannot be configured using
+- the iSNS Protocol, and therefore the iSNS server implementation MUST
+- provide for such an administrative control interface.
+-
+- The following is a list of parameters that are administratively
+- controlled for the iSNS server. In the absence of alternative
+- settings provided by the administrator, the following specified
+- default settings MUST be used.
+-
+- Setting Default Setting
+- ------- ---------------
+- ESI Non-Response Threshold 3 (see 5.6.5.13)
+- Management SCNs (Control Nodes only) enabled (see 5.6.5.8)
+- Default DD/DDS disabled
+- DD/DDS Modification
+- - Control Node enabled
+- - iSCSI Target Node Type disabled
+- - iSCSI Initiator Node Type disabled
+- - iFCP Target Port Role disabled
+- - iFCP Initiator Port Role disabled
+- Authorized Control Nodes N/A
+-
+- ESI Non-Response Threshold: determines the number of ESI messages
+- sent without receiving a response before the network
+- entity is deregistered from the iSNS database.
+-
+- Management SCN for Control Node: determines whether a registered
+- Control Node is permitted to register to receive
+- Management SCNs.
+-
+- Default DD/DDS: determines whether a newly registered device not
+- explicitly placed into a discovery domain (DD) and
+- discovery domain set (DDS) is placed into a default
+- DD/DDS.
+-
+- DD/DDS Modification: determines whether the specified type of Node is
+- allowed to add, delete or update DDs and DDSs.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 13]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Authorized Control Nodes: a list of Nodes identified by iSCSI Name or
+- FC Port Name WWPN that are authorized to register as
+- Control Nodes.
+-
+-2.5. iSNS Server Discovery
+-
+-2.5.1. Service Location Protocol (SLP)
+-
+- The Service Location Protocol (SLP) provides a flexible and scalable
+- framework for providing hosts with access to information about the
+- existence, location, and configuration of networked services,
+- including the iSNS server. SLP can be used by iSNS clients to
+- discover the IP address or FQDN of the iSNS server. To implement
+- discovery through SLP, a Service Agent (SA) should be cohosted in the
+- iSNS server, and a User Agent (UA) should be in each iSNS client.
+- Each client multicasts a discovery message requesting the IP address
+- of the iSNS server(s). The SA responds to this request. Optionally,
+- the location of the iSNS server can be stored in the SLP Directory
+- Agent (DA).
+-
+- Note that a complete description and specification of SLP can be
+- found in [RFC2608], and is beyond the scope of this document. A
+- service template for using SLP to locate iSNS servers can be found in
+- [iSCSI-SLP].
+-
+-2.5.2. Dynamic Host Configuration Protocol (DHCP)
+-
+- The IP address of the iSNS server can be stored in a DHCP server to
+- be downloaded by iSNS clients using a DHCP option. The DHCP option
+- number to be used for distributing the iSNS server location is found
+- in [iSNSOption].
+-
+-2.5.3. iSNS Heartbeat Message
+-
+- The iSNS heartbeat message is described in Section 5.6.5.14. It
+- allows iSNS clients within the broadcast or multicast domain of the
+- iSNS server to discover the location of the active iSNS server and
+- any backup servers.
+-
+-2.6. iSNS and Network Address Translation (NAT)
+-
+- The existence of NAT will have an impact upon information retrieved
+- from the iSNS server. If the iSNS client exists in an addressing
+- domain different from that of the iSNS server, then IP address
+- information stored in the iSNS server may not be correct when
+- interpreted in the domain of the iSNS client.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 14]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- There are several possible approaches to allow operation of iSNS
+- within a NAT network. The first approach is to require use of the
+- canonical TCP port number by both targets and initiators when
+- addressing targets across a NAT boundary, and for the iSNS client not
+- to query for nominal IP addresses. Rather, the iSNS client queries
+- for the DNS Fully Qualified Domain Name stored in the Entity
+- Identifier field when seeking addressing information. Once
+- retrieved, the DNS name can be interpreted in each address domain and
+- mapped to the appropriate IP address by local DNS servers.
+-
+- A second approach is to deploy a distributed network of iSNS servers.
+- Local iSNS servers are deployed inside and outside NAT boundaries,
+- with each local server storing relevant IP addresses for their
+- respective NAT domains. Updates among the network of decentralized,
+- local iSNS servers are handled using LDAP and appropriate NAT
+- translation rules implemented within the update mechanism in each
+- server.
+-
+- Finally, note that it is possible for an iSNS server in the private
+- addressing domain behind a NAT boundary to exclusively support iSNS
+- clients that are operating in the global IP addressing domain. If
+- this is the case, the administrator only needs to ensure that the
+- appropriate mappings are configured on the NAT gateways to allow the
+- iSNS clients to initiate iSNSP sessions to the iSNS server. All
+- registered addresses contained in the iSNS server are thus public IP
+- addresses for use outside the NAT boundary. Care should be taken to
+- ensure that there are no iSNS clients querying the server from inside
+- the NAT boundary.
+-
+-2.7. Transfer of iSNS Database Records between iSNS Servers
+-
+- Transfer of iSNS database records between iSNS servers has important
+- applications, including the following:
+-
+- 1) An independent organization needs to transfer storage information
+- to a different organization. Each organization independently
+- maintains its own iSNS infrastructure. To facilitate discovery
+- of storage assets of the peer organization using IP, iSNS
+- database records can be transferred between authoritative iSNS
+- servers from each organization. This allows storage sessions to
+- be established directly between devices residing in each
+- organization's storage network infrastructure over a common IP
+- network.
+-
+- 2) Multiple iSNS servers are desired for redundancy. Backup servers
+- need to maintain copies of the primary server's dynamically
+- changing database.
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 15]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- To support the above applications, information in an iSNS server can
+- be distributed to other iSNS servers either using the iSNS protocol,
+- or through out-of-band mechanisms using non-iSNS protocols. The
+- following examples illustrate possible methods for transferring data
+- records between iSNS servers. In the first example, a back-end LDAP
+- information base is used to support the iSNS server, and the data is
+- transferred using the LDAP protocol. Once the record transfer of the
+- remote device is completed, it becomes visible and accessible to
+- local devices using the local iSNS server. This allows local devices
+- to establish sessions with remote devices (provided that firewall
+- boundaries can be negotiated).
+-
+- +-------------------------+ +-------------------------+
+- |+------+ iSNSP | | iSNSP +-----+ |
+- ||dev A |<----->+------+ | | +------+<----->|dev C| |
+- |+------+ | | | | | | +-----+ |
+- |+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
+- ||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
+- |+------+ |server| | | |server| +-----+ |
+- |........ +--+---+ | WAN | +---+--+ |
+- |.dev C'. | | Link | | |
+- |........ | ============= | |
+- | | | | | |
+- | +--+---+ | | +---+--+ |
+- | | local|<--- <--- <--- <-|remote| |
+- | | LDAP | | LDAP: | | LDAP | |
+- | +------+ Xfer "dev C"| +------+ |
+- +-------------------------+ +-------------------------+
+- Enterprise Enterprise
+- Network A Network B
+-
+- In the above diagram, two business partners wish to share storage
+- "dev C". Using LDAP, the record for "dev C" can be transferred from
+- Network B to Network A. Once accessible to the local iSNS server in
+- Network A, local devices A and B can now discover and connect to "dev
+- C".
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 16]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- +-------------------------+ +-------------------------+
+- |+------+ iSNSP | | iSNSP +-----+ |
+- ||dev A |<----->+------+ | | +------+<----->|dev C| |
+- |+------+ | | | | | | +-----+ |
+- |+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
+- ||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
+- |+------+ |server| | | |server| +-----+ |
+- |........ +------+ | WAN | +---+--+ |
+- |.dev C'. ^ | Link | | |
+- |........ | ============= v |
+- | | | | |SNMP |
+- | | | | | |
+- | +--+----+ | | v |
+- | | SNMP |<--- <--- <--- <---- |
+- | | Mgmt | | SNMP: Xfer "dev C" |
+- | |Station| | | |
+- | +-------+ | | |
+- +-------------------------+ +-------------------------+
+- Enterprise Enterprise
+- Network A Network B
+-
+- The above diagram illustrates a second example of how iSNS records
+- can be shared. This method uses an SNMP-based management station to
+- retrieve (GET) the desired record for "dev C" manually, and then to
+- store (SET) it on the local iSNS server directly. Once the record is
+- transferred to the local iSNS server in Network A, "dev C" becomes
+- visible and accessible (provided that firewall boundaries can be
+- negotiated) to other devices in Network A.
+-
+- Other methods, including proprietary protocols, can be used to
+- transfer device records between iSNS servers. Further discussion and
+- explanation of these methodologies is beyond the scope of this
+- document.
+-
+-2.8. Backup iSNS Servers
+-
+- This section offers a broad framework for implementation and
+- deployment of iSNS backup servers. Server failover and recovery are
+- topics of continuing research, and adequate resolution of issues such
+- as split brain and primary server selection is dependent on the
+- specific implementation requirements and deployment needs. The
+- failover mechanisms discussed in this document focus on the
+- interaction between iSNS clients and iSNS servers. Specifically,
+- what is covered in this document includes the following:
+-
+- - iSNS client behavior and the iSNS protocol interaction between the
+- client and multiple iSNS servers, some of which are backup
+- servers.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 17]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- - Required failover behaviors of the collection of iSNS servers that
+- includes active and backup servers.
+-
+- However, note that this document does not specify the complete
+- functional failover requirements of each iSNS server. In particular,
+- it does not specify the complete set of protocol interactions among
+- the iSNS servers that are required to achieve stable failover
+- operation in an interoperable manner.
+-
+- For the purposes of this discussion, the specified backup mechanisms
+- pertain to interaction among different logical iSNS servers. Note
+- that it is possible to create multiple physical iSNS servers to form
+- a single logical iSNS server cluster, and thus to distribute iSNS
+- transaction processing among multiple physical servers. However, a
+- more detailed discussion of the interactions between physical servers
+- within a logical iSNS server cluster is beyond the scope of this
+- document.
+-
+- Multiple logical iSNS servers can be used to provide redundancy in
+- the event that the active iSNS server fails or is removed from the
+- network. The methods described in Section 2.7 above can be used to
+- transfer name server records to backup iSNS servers. Each backup
+- server maintains a redundant copy of the name server database found
+- in the primary iSNS server, and can respond to iSNS protocol messages
+- in the same way as the active server. Each backup server SHOULD
+- monitor the health and status of the active iSNS server, including
+- checking to make sure its own database is synchronized with the
+- active server's database. How each backup server accomplishes this
+- is implementation-dependent, and may (or may not) include using the
+- iSNS protocol. If the iSNS protocol is used, then the backup server
+- MAY register itself in the active server's iSNS database as a Control
+- Node, allowing it to receive state-change notifications.
+-
+- Generally, the administrator or some automated election process is
+- responsible for initial and subsequent designation of the primary
+- server and each backup server.
+-
+- A maximum of one logical backup iSNS server SHALL exist at any
+- individual IP address, in order to avoid conflicts from multiple
+- servers listening on the same canonical iSNS TCP or UDP port number.
+-
+- The iSNS heartbeat can also be used to coordinate the designation and
+- selection of primary and backup iSNS servers.
+-
+- Each backup server MUST note its relative precedence in the active
+- server's list of backup servers. If its precedence is not already
+- known, each backup server MAY learn it from the iSNS heartbeat
+- message, by noting the position of its IP address in the ordered list
+-
+-
+-
+-Tseng, et al. Standards Track [Page 18]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- of backup server IP addresses. For example, if it is the first
+- backup listed in the heartbeat message, then its backup precedence is
+- 1. If it is the third backup server listed, then its backup
+- precedence is 3.
+-
+- If a backup server establishes that it has lost connectivity to the
+- active server and other backup servers of higher precedence, then it
+- SHOULD assume that it is the active server. The method of
+- determining whether connectivity has been lost is implementation-
+- specific. One possible approach is to assume that if the backup
+- server does not receive iSNS heartbeat messages for a period of time,
+- then connectivity to the active server has been lost. Alternatively,
+- the backup server may establish TCP connections to the active server
+- and other backup servers, with loss of connectivity determined
+- through non-response to periodic echo or polling messages (using
+- iSNSP, SNMP, or other protocols).
+-
+- When a backup server becomes the active server, it SHALL assume all
+- active server responsibilities, including (if used) transmission of
+- the iSNS heartbeat message. If transmitting the iSNS heartbeat, the
+- backup server replaces the active Server IP Address and TCP/UDP Port
+- entries with its own IP address and TCP/UDP Port, and begins
+- incrementing the counter field from the last known value from the
+- previously-active iSNS server. However, it MUST NOT change the
+- original ordered list of backup server IP Address and TCP/UDP Port
+- entries. If the primary backup server or other higher-precedence
+- backup server returns, then the existing active server is responsible
+- for ensuring that the new active server's database is up-to-date
+- before demoting itself to its original status as backup.
+-
+- Since the primary and backup iSNS servers maintain a coordinated
+- database, no re-registration by an iSNS Client is required when a
+- backup server takes the active server role. Likewise, no re-
+- registration by an iSNS Client is required when the previous primary
+- server returns to the active server role.
+-
+-2.9. Transport Protocols
+-
+- The iSNS Protocol is transport-neutral. Query and registration
+- messages are transported over TCP or UDP. iSNS heartbeat messages
+- are transported using IP multicast or broadcast.
+-
+-2.9.1. Use of TCP for iSNS Communication
+-
+- It MUST be possible to use TCP for iSNS communication. The iSNS
+- server MUST accept TCP connections for client registrations. To
+- receive Entity Status Inquiry (ESI) (see Section 5.6.5.13) monitoring
+- the use of TCP, the client registers the Portal ESI Interval and the
+-
+-
+-
+-Tseng, et al. Standards Track [Page 19]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- port number of the TCP port that will be used to receive ESI
+- messages. The iSNS server initiates the TCP connection used to
+- deliver the ESI message. This TCP connection does not need to be
+- continuously open.
+-
+- To receive SCN notifications using TCP, the client registers the
+- iSCSI or iFCP SCN Bitmap and the port number of the TCP port in the
+- Portal used to receive SCNs. The iSNS server initiates the TCP
+- connection used to deliver the SCN message. This TCP connection does
+- not need to be continuously open.
+-
+- It is possible for an iSNS client to use the same TCP connection for
+- SCN, ESI, and iSNS queries. Alternatively, separate connections may
+- be used.
+-
+-2.9.2. Use of UDP for iSNS Communication
+-
+- The iSNS server MAY accept UDP messages for client registrations.
+- The iSNS server MUST accept registrations from clients requesting
+- UDP-based ESI and SCN messages.
+-
+- To receive UDP-based ESI monitoring messages, the client registers
+- the port number of the UDP port in at least one Portal to be used to
+- receive and respond to ESI messages from the iSNS server. If a
+- Network Entity has multiple Portals with registered ESI UDP Ports,
+- then ESI messages SHALL be delivered to every Portal registered to
+- receive such messages.
+-
+- To receive UDP-based SCN notification messages, the client registers
+- the port number of the UDP port in at least one Portal to be used to
+- receive SCN messages from the iSNS server. If a Network Entity has
+- multiple Portals with registered SCN UDP Ports, then SCN messages
+- SHALL be delivered to each Portal registered to receive such
+- messages.
+-
+- When using UDP to transport iSNS messages, each UDP datagram MUST
+- contain exactly one iSNS PDU (see Section 5).
+-
+-2.9.3. iSNS Multicast and Broadcast Messages
+-
+- iSNS multicast messages are transported using IP multicast or
+- broadcast. The iSNS heartbeat is the only iSNS multicast or
+- broadcast message. This message is originated by the iSNS server and
+- sent to all iSNS clients that are listening on the IP multicast
+- address allocated for the iSNS heartbeat.
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 20]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-2.10. Simple Network Management Protocol (SNMP) Requirements
+-
+- The iSNS Server may be managed via the iSNS MIB [iSNSMIB] using an
+- SNMP management framework [RFC3411]. For a detailed overview of the
+- documents that describe the current Internet-Standard Management
+- Framework, please refer to Section 7 of RFC 3410 [RFC3410]. The iSNS
+- MIB provides the ability to configure and monitor an iSNS server
+- without using the iSNS protocol directly. SNMP management frameworks
+- have several requirements for object indexing in order for objects to
+- be accessed or added.
+-
+- SNMP uses an Object Identifier (OID) for object identification. The
+- size of each OID is restricted to a maximum of 128 sub-identifiers.
+- Both the iSCSI and iFCP protocol contain identifiers, such as the
+- iSCSI Name, that are greater the 128 characters in length. Using
+- such identifiers as an index would result in more than 128 sub-
+- identifiers per OID. In order to support objects that have key
+- identifiers whose maximum length is longer than the maximum SNMP-
+- supported length, the iSNS server provides secondary non-zero integer
+- index identifiers. These indexes SHALL be persistent for as long as
+- the server is active. Furthermore, index values for recently
+- deregistered objects SHOULD NOT be reused in the short term. Object
+- attributes, including indexes, are described in detail in Section 6.
+-
+- For SNMP based management applications to create a new entry in a
+- table of objects, a valid OID must be available to specify the table
+- row. The iSNS server supports this by providing, for each type of
+- object that can be added via SNMP, an object attribute that returns
+- the next available non-zero integer index. This allows an SNMP
+- client to request an OID to be used for registering a new object in
+- the server. Object attributes, including next available index
+- attributes, are described in detail in Section 6.
+-
+-3. iSNS Object Model
+-
+- iSNS provides the framework for the registration, discovery, and
+- management of iSCSI devices and Fibre Channel-based devices (using
+- iFCP). This architecture framework provides elements needed to
+- describe various storage device objects and attributes that may exist
+- on an IP storage network. Objects defined in this architecture
+- framework include Network Entity, Portal, Storage Node, FC Device,
+- Discovery Domain, and Discovery Domain Set. Each of these objects is
+- described in greater detail in the following sections.
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 21]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-3.1. Network Entity Object
+-
+- The Network Entity object is a container of Storage Node objects and
+- Portal objects. It represents the infrastructure supporting access
+- to a unique set of one or more Storage Nodes. The Entity Identifier
+- attribute uniquely distinguishes a Network Entity, and is the key
+- used to register a Network Entity object in an iSNS server. All
+- Storage Nodes and Portals contained within a single Network Entity
+- object operate as a cohesive unit.
+-
+- Note that it is possible for a single physical device or gateway to
+- be represented by more than one logical Network Entity in the iSNS
+- database. For example, one of the Storage Nodes on a physical device
+- may be accessible from only a subset of the network interfaces (i.e.,
+- Portals) available on that device. In this case, a logical network
+- entity (i.e., a "shadow entity") is created and used to contain the
+- Portals and Storage Nodes that can operate cooperatively. No object
+- (Portals, Storage Nodes, etc.) can be contained in more than one
+- logical Network Entity.
+-
+- Similarly, it is possible for a logical Network Entity to be
+- supported by more than one physical device or gateway. For example,
+- multiple FC-iSCSI gateways may be used to bridge FC devices in a
+- single Fibre Channel network. Collectively, the multiple gateways
+- can be used to support a single logical Network Entity that is used
+- to contain all the devices in that Fibre Channel network.
+-
+-3.2. Portal Object
+-
+- The Portal object is an interface through which access to Storage
+- Nodes within the Network Entity can be obtained. The IP address and
+- TCP/UDP Port number attributes uniquely distinguish a Portal object,
+- and combined are the key used to register a Portal object in an iSNS
+- server. A Portal is contained in one and only one Network Entity,
+- and may be contained in one or more DDs (see Section 3.6).
+-
+-3.3. Storage Node Object
+-
+- The Storage Node object is the logical endpoint of an iSCSI or iFCP
+- session. In iFCP, the session endpoint is represented by the World
+- Wide Port Name (WWPN). In iSCSI, the session endpoint is represented
+- by the iSCSI Name of the device. For iSCSI, the iSCSI Name attribute
+- uniquely distinguishes a Storage Node, and is the key used to
+- register a Storage Node object in an iSNS Server. For iFCP, the FC
+- Port Name (WWPN) attribute uniquely distinguishes a Storage Node, and
+- is the key used to register a Storage Node object in the iSNS Server.
+- Storage Node is contained in only one Network Entity object and may
+- be contained in one or more DDs (see Section 3.6).
+-
+-
+-
+-Tseng, et al. Standards Track [Page 22]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-3.4. Portal Group Object
+-
+- The Portal Group (PG) object represents an association between a
+- Portal and an iSCSI Node. Each Portal and iSCSI Storage Node
+- registered in an Entity can be associated using a Portal Group (PG)
+- object. The PG Tag (PGT), if non-NULL, indicates that the associated
+- Portal provides access to the associated iSCSI Storage Node in the
+- Entity. All Portals that have the same PGT value for a specific
+- iSCSI Storage Node allow coordinated access to that node.
+-
+- A PG object MAY be registered when a Portal or iSCSI Storage Node is
+- registered. Each Portal to iSCSI Node association is represented by
+- one and only one PG object. In order for a Portal to provide access
+- to an iSCSI Node, the PGT of the PG object MUST be non-NULL. If the
+- PGT value registered for a specified Portal and iSCSI Node is NULL,
+- or if no PGT value is registered, then the Portal does not provide
+- access to that iSCSI Node in the Entity.
+-
+- The PGT value indicates whether access to an iSCSI Node can be
+- coordinated across multiple Portals. All Portals that have the same
+- PGT value for a specific iSCSI Node can provide coordinated access to
+- that iSCSI Node. According to the iSCSI Specification, coordinated
+- access to an iSCSI node indicates the capability of coordinating an
+- iSCSI session with connections that span these Portals [iSCSI].
+-
+- The PG object is uniquely distinguished by the iSCSI Name, Portal IP
+- Address, and Portal TCP Port values of the associated Storage Node
+- and Portal objects. These are represented in the iSNS Server by the
+- PG iSCSI Name, PG Portal IP Address, and PG Portal TCP/UDP Port
+- attributes, respectively. The PG object is also uniquely
+- distinguished in the iSNS Server by the PG Index value.
+-
+- A new PG object can only be registered by referencing its associated
+- iSCSI Storage Node or Portal object. A pre-existing PG object can be
+- modified or queried by using its Portal Group Index as message key,
+- or by referencing its associated iSCSI Storage Node or Portal object.
+- A 0-length Tag, Length, Value TLV is used to register a PGT NULL
+- value.
+-
+- The PG object is deregistered if and only if its associated iSCSI
+- Node and Portal objects are both removed.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 23]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-3.5. Device Object
+-
+- The FC Device represents the Fibre Channel Node. This object
+- contains information that may be useful in the management of the
+- Fibre Channel device. The FC Node Name (WWNN) attribute uniquely
+- distinguishes an FC Device, and is the key used to register an FC
+- Device object in the iSNS Server.
+-
+- The FC Device is contained in one or more Storage Node objects.
+-
+-3.6. Discovery Domain Object
+-
+- Discovery Domains (DD) are a security and management mechanism used
+- to administer access and connectivity to storage devices. For query
+- and registration purposes, they are considered containers for Storage
+- Node and Portal objects. A query by an iSNS client that is not from
+- a Control Node only returns information about objects with which it
+- shares at least one active DD. The only exception to this rule is
+- with Portals; if Storage Nodes of a Network Entity are registered in
+- the DD without Portals, then all Portals of that Network Entity are
+- implicit members of that DD. The Discovery Domain ID (DD_ID)
+- attribute uniquely distinguishes a Discovery Domain object, and is
+- the key used to register a Discovery Domain object in the iSNS
+- Server.
+-
+- A DD is considered active if it is a member of at least one active DD
+- Set. DDs that are not members of at least one enabled DDS are
+- considered disabled. A Storage Node can be a member of one or more
+- DDs. An enabled DD establishes connectivity among the Storage Nodes
+- in that DD.
+-
+-3.7. Discovery Domain Set Object
+-
+- The Discovery Domain Set (DDS) is a container object for Discovery
+- Domains (DDs). DDSs may contain one or more DDs. Similarly, each DD
+- can be a member of one or more DDSs. DDSs are a mechanism to store
+- coordinated sets of DD mappings in the iSNS server. Active DDs are
+- members of at least one active DD Set. Multiple DDSs may be
+- considered active at the same time. The Discovery Domain Set ID
+- (DDS_ID) attribute uniquely distinguishes a Discovery Domain Set
+- object, and is the key used to register a Discovery Domain Set object
+- in the iSNS Server.
+-
+-3.8. Database Model
+-
+- As presented to the iSNS client, each object of a specific type in
+- the iSNS database MUST have an implicit internal linear ordering
+- based on the key(s) for that object type. This ordering provides the
+-
+-
+-
+-Tseng, et al. Standards Track [Page 24]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- ability to respond to DevGetNext queries (see Section 5.6.5.3). The
+- ordering of objects in the iSNS database SHOULD NOT be changed with
+- respect to that implied ordering, as a consequence of object
+- insertions and deletions. That is, the relative order of surviving
+- object entries in the iSNS database SHOULD be preserved so that the
+- DevGetNext message encounters generally reasonable behavior.
+-
+- The following diagram shows the various objects described above and
+- their relationship to each other.
+-
+- +--------------+ +-----------+
+- | NETWORK |1 *| |
+- | ENTITY |----| PORTAL |
+- | | | |
+- +--------------+ +-----------+
+- |1 |1 |*
+- | | |
+- | |* |
+- | +----------+ |
+- | | PORTAL | |
+- | | GROUP | |
+- | +----------+ |
+- | |* |
+- | | |
+- |* |1 |*
+- +-----------+ +--------------+ +-----------+ +-----------+
+- | FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY |
+- | DEVICE |----| NODE |----| DOMAIN |----| DOMAIN |
+- | | | | | | | SET |
+- +-----------+ +--------------+ +-----------+ +-----------+
+-
+- * represents 0 to many possible relationships
+-
+-4. iSNS Implementation Requirements
+-
+- This section details specific requirements for support of each of
+- these IP storage protocols. Implementation requirements for security
+- are described in Section 7.
+-
+-4.1. iSCSI Requirements
+-
+- Use of iSNS in support of iSCSI is OPTIONAL. iSCSI devices MAY be
+- manually configured with the iSCSI Name and IP address of peer
+- devices, without the aid or intervention of iSNS. iSCSI devices may
+- also use SLP [RFC2608] to discover peer iSCSI devices. However, iSNS
+- is useful for scaling a storage network to a larger number of iSCSI
+- devices.
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 25]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-4.1.1. Required Attributes for Support of iSCSI
+-
+- The following attributes are available to support iSCSI. Attributes
+- indicated in the REQUIRED for Server column MUST be implemented by an
+- iSNS server used to support iSCSI. Attributes indicated in the
+- REQUIRED for Client column MUST be implemented by an iSCSI device
+- that elects to use the iSNS. Attributes indicated in the K (Key)
+- column uniquely identify the object type in the iSNS Server. A more
+- detailed description of each attribute is found in Section 6.
+-
+- REQUIRED for:
+- Object Attribute K Server Client
+- ------ --------- - ------ ------
+- NETWORK ENTITY Entity Identifier * * *
+- Entity Protocol * *
+- Management IP Address *
+- Timestamp *
+- Protocol Version Range *
+- Registration Period *
+- Entity Index *
+- Entity IKE Phase-1 Proposal
+- Entity Certificate
+-
+- PORTAL IP Address * * *
+- TCP/UDP Port * * *
+- Portal Symbolic Name *
+- ESI Interval *
+- ESI Port *
+- Portal Index *
+- SCN Port *
+- Portal Security Bitmap *
+- Portal IKE Phase-1 Proposal
+- Portal IKE Phase-2 Proposal
+- Portal Certificate
+-
+- PORTAL GROUP PG iSCSI Name * * *
+- PG IP Address * * *
+- PG TCP/UDP Port * * *
+- PG Tag * *
+- PG Index *
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 26]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- STORAGE NODE iSCSI Name * * *
+- iSCSI Node Type * *
+- Alias *
+- iSCSI SCN Bitmap *
+- iSCSI Node Index *
+- WWNN Token
+- iSCSI AuthMethod
+- iSCSI Node Certificate
+-
+- DISCOVERY DOMAIN DD ID * * *
+- DD Symbolic Name *
+- DD Member iSCSI Node Index *
+- DD Member iSCSI Name *
+- DD Member Portal Index *
+- DD Member Portal IP Addr *
+- DD Member Portal TCP/UDP *
+- DD Features *
+-
+- DISCOVERY DOMAIN DDS Identifier * *
+- SET DDS Symbolic Name *
+- DDS Status *
+-
+- All iSCSI user-specified and vendor-specified attributes are OPTIONAL
+- to implement and use.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 27]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-4.1.2. Examples: iSCSI Object Model Diagrams
+-
+- The following diagram models how a simple iSCSI-based initiator and
+- target is represented using database objects stored in the iSNS
+- server. In this implementation, each target and initiator is
+- attached to a single Portal.
+-
+- +----------------------------------------------------------------+
+- | IP Network |
+- +------------+--------------------------------------+------------+
+- | |
+- | |
+- +-----+------+------+-----+ +-----+------+------+-----+
+- | | PORTAL | | | | PORTAL | |
+- | | -IP Addr 1 | | | | -IP Addr 2 | |
+- | | -TCP Port 1 | | | | -TCP Port 2 | |
+- | +-----+ +-----+ | | +-----+ +-----+ |
+- | | | | | | | |
+- | +-----+ +-----+ | | +-----+ +-----+ |
+- | | PORTAL GROUP| | | | PORTAL GROUP| |
+- | | -Prtl Tag 1 | | | | -Prtl Tag 2 | |
+- | +-----+ +-----+ | | +-----+ +-----+ |
+- | | | | | | | |
+- | +--------+ +--------+ | | +-------+ +--------+ |
+- | | | | | | | |
+- | | STORAGE NODE | | | | STORAGE NODE | |
+- | | -iSCSI Name | | | | -iSCSI Name | |
+- | | -Alias: "server1"| | | | -Alias: "disk1"| |
+- | | -Type: initiator | | | | -Type: target | |
+- | | | | | | | |
+- | +-------------------+ | | +------------------+ |
+- | | | |
+- | NETWORK ENTITY | | NETWORK ENTITY |
+- | -Entity ID (FQDN): | | -Entity ID (FQDN): |
+- | "strg1.example.com" | | "strg2.example.net" |
+- | -Protocol: iSCSI | | -Protocol: iSCSI |
+- | | | |
+- +-------------------------+ +-------------------------+
+-
+- The object model can be expanded to describe more complex devices,
+- such as an iSCSI device with more than one storage controller, in
+- which each controller is accessible through any of multiple Portal
+- interfaces, possibly using multiple Portal Groups. The storage
+- controllers on this device can be accessed through alternate Portal
+- interfaces if any original interface should fail. The following
+- diagram describes such a device:
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 28]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- +---------------------------------------------------------------+
+- | IP Network |
+- +-------------------+-----------------------+-------------------+
+- | |
+- | |
+- +------------+------+------+---------+------+------+------------+
+- | | PORTAL 1 | | PORTAL 2 | |
+- | | -IP Addr 1 | | -IP Addr 2 | |
+- | | -TCP Port 1 | | -TCP Port 2 | |
+- | +-----+ +-----+ +-----+ +-----+ |
+- | | | | | |
+- | +---------------+ +---------------------+ +---------------+ |
+- | +-------+ +----------------+ +-------------------+ +------+ |
+- | | | | | | | |
+- | +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
+- | | | | | | | |
+- | | STORAGE NODE 1 | | STORAGE NODE 2 | | STORAGE NODE 3 | |
+- | | -iSCSI Name 1 | | -iSCSI Name 2 | | -iSCSI Name 3 | |
+- | | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| |
+- | | -Type: target | | -Type: target | | -Type: target | |
+- | | | | | | | |
+- | +-----------------+ +-----------------+ +-----------------+ |
+- | |
+- | NETWORK ENTITY |
+- | -Entity ID (FQDN): "dev1.example.com" |
+- | -Protocol: iSCSI |
+- | |
+- | Portal Group Object Table |
+- | Storage-Node Portal Portal-Group-Tag |
+- | 1 1 10 |
+- | 1 2 NULL (no access permitted) |
+- | 2 1 20 |
+- | 2 2 20 |
+- | 3 1 30 |
+- | 3 2 10 |
+- | |
+- +---------------------------------------------------------------+
+-
+- Storage Node 1 is accessible via Portal 1 with a PGT of 10. It does
+- not have a Portal Group Tag (PGT) assigned for Portal 2, so Storage
+- Node 1 cannot be accessed via Portal 2.
+-
+- Storage Node 2 can be accessed via both Portal 1 and Portal 2. Since
+- Storage Node 2 has the same PGT value assigned to both Portal 1 and
+- Portal 2, in this case 20, coordinated access via the Portals is
+- available [iSCSI].
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 29]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Storage Node 3 can be accessed via Portal 1 or Portal 2. However,
+- since Storage Node 3 has different PGT values assigned to each
+- Portal, in this case 10 and 30, access is not coordinated [iSCSI].
+- Because PGTs are assigned within the context of a Storage Node, the
+- PGT value of 10 used for Storage Node 1 and Storage Node 3 are not
+- interrelated.
+-
+-4.1.3. Required Commands and Response Messages for Support of iSCSI
+-
+- The following iSNSP messages and responses are available in support
+- of iSCSI. Messages indicated in the REQUIRED for Server column MUST
+- be implemented in iSNS servers used for iSCSI devices. Messages
+- indicated in the REQUIRED for Client column MUST be implemented in
+- iSCSI devices that elect to use the iSNS server.
+-
+- REQUIRED for:
+- Message Description Abbreviation Func_ID Server Client
+- ------------------- ------------ ------- ------ ------
+- RESERVED 0x0000
+- Device Attr Reg Request DevAttrReg 0x0001 * *
+- Dev Attr Query Request DevAttrQry 0x0002 * *
+- Dev Get Next Request DevGetNext 0x0003 *
+- Deregister Dev Request DevDereg 0x0004 * *
+- SCN Register Request SCNReg 0x0005 *
+- SCN Deregister Request SCNDereg 0x0006 *
+- SCN Event SCNEvent 0x0007 *
+- State Change Notification SCN 0x0008 *
+- DD Register DDReg 0x0009 * *
+- DD Deregister DDDereg 0x000A * *
+- DDS Register DDSReg 0x000B * *
+- DDS Deregister DDSDereg 0x000C * *
+- Entity Status Inquiry ESI 0x000D *
+- Name Service Heartbeat Heartbeat 0x000E
+- RESERVED 0x000F-0x00FF
+- Vendor Specific 0x0100-0x01FF
+- RESERVED 0x0200-0x7FFF
+-
+- The following are iSNSP response messages used in support of iSCSI:
+-
+- REQUIRED for:
+- Response Message Desc Abbreviation Func_ID Server Client
+- --------------------- ------------ ------- ------ ------
+- RESERVED 0x8000
+- Device Attr Register Rsp DevAttrRegRsp 0x8001 * *
+- Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
+- Device Get Next Rsp DevGetNextRsp 0x8003 *
+- Device Dereg Rsp DevDeregRsp 0x8004 * *
+- SCN Register Rsp SCNRegRsp 0x8005 *
+-
+-
+-
+-Tseng, et al. Standards Track [Page 30]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- SCN Deregister Rsp SCNDeregRsp 0x8006 *
+- SCN Event Rsp SCNEventRsp 0x8007 *
+- SCN Response SCNRsp 0x8008 *
+- DD Register Rsp DDRegRsp 0x8009 * *
+- DD Deregister Rsp DDDeregRsp 0x800A * *
+- DDS Register Rsp DDSRegRsp 0x800B * *
+- DDS Deregister Rsp DDSDeregRsp 0x800C * *
+- Entity Stat Inquiry Rsp ESIRsp 0x800D *
+- RESERVED 0x800E-0x80FF
+- Vendor Specific 0x8100-0x81FF
+- RESERVED 0x8200-0xFFFF
+-
+-4.2. iFCP Requirements
+-
+- In iFCP, use of iSNS is REQUIRED. No alternatives exist for support
+- of iFCP Naming & Discovery functions.
+-
+-4.2.1. Required Attributes for Support of iFCP
+-
+- The following table displays attributes that are used by iSNS to
+- support iFCP. Attributes indicated in the REQUIRED for Server column
+- MUST be implemented by the iSNS server that supports iFCP.
+- Attributes indicated in the REQUIRED for Client column MUST be
+- supported by iFCP gateways. Attributes indicated in the K (Key)
+- column uniquely identify the object type in the iSNS Server. A more
+- detailed description of each attribute is found in Section 6.
+-
+- REQUIRED for:
+- Object Attribute K Server Client
+- ------ --------- - ------ ------
+- NETWORK ENTITY Entity Identifier * * *
+- Entity Protocol * *
+- Management IP Address *
+- Timestamp *
+- Protocol Version Range *
+- Registration period
+- Entity Index
+- Entity IKE Phase-1 Proposal
+- Entity Certificate
+-
+- PORTAL IP Address * * *
+- TCP/UDP Port * * *
+- Symbolic Name *
+- ESI Interval *
+- ESI Port *
+- SCN Port *
+- Portal IKE Phase-1 Proposal
+- Portal IKE Phase-2 Proposal
+-
+-
+-
+-Tseng, et al. Standards Track [Page 31]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Portal Certificate
+- Security Bitmap *
+-
+- STORAGE NODE FC Port Name (WWPN) * * *
+- (FC Port) Port_ID * *
+- FC Port Type * *
+- Port Symbolic Name *
+- Fabric Port Name (FWWN) *
+- Hard Address *
+- Port IP Address *
+- Class of Service *
+- FC FC-4 Types *
+- FC FC-4 Descriptors *
+- FC FC-4 Features *
+- SCN Bitmap *
+- iFCP Port Role *
+- Permanent Port Name *
+-
+- FC DEVICE FC Node Name (WWNN) * * *
+- (FC Node) Node Symbolic Name *
+- Node IP Address *
+- Node IPA *
+- Proxy iSCSI Name
+-
+- DISCOVERY DOMAIN DD ID * * *
+- DD Symbolic Name *
+- DD Member FC Port Name *
+- DD Member Portal Index *
+- DD Member Portal IP Addr *
+- DD Member Portal TCP/UDP *
+-
+- DISCOVERY DOMAIN DDS ID * *
+- SET DDS Symbolic Name *
+- DDS Status *
+-
+- OTHER Switch Name
+- Preferred_ID
+- Assigned_ID
+- Virtual_Fabric_ID
+-
+- All iFCP user-specified and vendor-specified attributes are OPTIONAL
+- to implement and use.
+-
+-4.2.2. Example: iFCP Object Model Diagram
+-
+- The iFCP protocol allows native Fibre Channel devices or Fibre
+- Channel fabrics connected to an iFCP gateway to be directly
+- internetworked using IP.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 32]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- When supporting iFCP, the iSNS server stores Fibre Channel device
+- attributes, iFCP gateway attributes, and Fibre Channel fabric switch
+- attributes that might also be stored in an FC name server.
+-
+- The following diagram shows a representation of a gateway supporting
+- multiple Fibre Channel devices behind it. The two Portal objects
+- represent IP interfaces on the iFCP gateway that can be used to
+- access any of the three Storage Node objects behind it. Note that
+- the FC Device object is not contained in the Network Entity object.
+- However, each FC Device has a relationship to one or more Storage
+- Node objects.
+-
+- +--------------------------------------------------------+
+- | IP Network |
+- +--------+-----------------+-----------------------------+
+- | |
+- +-+------+------+---+------+------+----------------------+
+- | | PORTAL | | PORTAL | NETWORK ENTITY |
+- | | -IP Addr 1 | | -IP Addr 2 | -Entity ID (FQDN): |
+- | | -TCP Port 1 | | -TCP Port 2 | "gtwy1.example.com" |
+- | +-----+ +-----+ +-----+ +-----+ -Protocol: iFCP |
+- | | | | | |
+- | +-----+ +---------------+ +----------------------+ |
+- | +-----+ +---------------+ +-------------+ +------+ |
+- | | | | | | | |
+- | +-----+ +-----+ +----+ +------+ +----+ +------+ |
+- | |STORAGE NODE | |STORAGE NODE | |STORAGE NODE | |
+- | | -WWPN 1 | | -WWPN 2 | | -WWPN 3 | |
+- | | -Port ID 1 | | -Port ID 2 | | -Port ID 3 | |
+- | | -FWWN 1 | | -FWWN 2 | | -FWWN 3 | |
+- | | -FC COS | | -FC COS | | -FC COS | |
+- | +------+------+ +-------+-----+ +----+--------+ |
+- +--------|-------------------|------------|--------------+
+- | | |
+- +------+------+ +---+------------+---+
+- | FC DEVICE | | FC DEVICE |
+- | -WWNN 1 | | -WWNN 2 |
+- | | | |
+- +-------------+ +--------------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 33]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-4.2.3. Required Commands and Response Messages for Support of iFCP
+-
+- The iSNSP messages and responses displayed in the following tables
+- are available to support iFCP gateways. Messages indicated in the
+- REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server
+- used by iFCP gateways. Messages indicated in the REQUIRED TO USE
+- column MUST be supported by the iFCP gateways themselves.
+-
+- REQUIRED for:
+- Message Description Abbreviation Func ID Server Client
+- ------------------- ------------ ------- ------ ------
+- RESERVED 0x0000
+- Device Attr Reg Request DevAttrReg 0x0001 * *
+- Device Attr Query Request DevAttrQry 0x0002 * *
+- Device Get Next Request DevGetNext 0x0003 *
+- Device Dereg Request DevDereg 0x0004 * *
+- SCN Register Request SCNReg 0x0005 *
+- SCN Deregister Request SCNDereg 0x0006 *
+- SCN Event SCNEvent 0x0007 *
+- State Change Notification SCN 0x0008 *
+- DD Register DDReg 0x0009 * *
+- DD Deregister DDDereg 0x000A * *
+- DDS Register DDSReg 0x000B * *
+- DDS Deregister DDSDereg 0x000C * *
+- Entity Status Inquiry ESI 0x000D *
+- Name Service Heartbeat Heartbeat 0x000E *
+- Reserved Reserved 0x000F-0x0010
+- Request FC_DOMAIN_ID RqstDomId 0x0011
+- Release FC_DOMAIN_ID RlseDomId 0x0012
+- Get FC_DOMAIN_IDs GetDomId 0x0013
+- RESERVED 0x0014-0x00FF
+- Vendor Specific 0x0100-0x01FF
+- RESERVED 0x0200-0x7FFF
+-
+- The following are iSNSP response messages in support of iFCP:
+-
+- REQUIRED for:
+- Response Message Desc Abbreviation Func_ID Server Client
+- --------------------- ------------ ------- ------ ------
+- RESERVED 0x8000
+- Device Attr Reg Rsp DevAttrRegRsp 0x8001 * *
+- Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
+- Device Get Next Rsp DevGetNextRsp 0x8003 *
+- Device Deregister Rsp DevDeregRsp 0x8004 * *
+- SCN Register Rsp SCNRegRsp 0x8005 *
+- SCN Deregister Rsp SCNDeregRsp 0x8006 *
+- SCN Event Rsp SCNEventRsp 0x8007 *
+- SCN Rsp SCNRsp 0x8008 *
+-
+-
+-
+-Tseng, et al. Standards Track [Page 34]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- DD Register Rsp DDRegRsp 0x8009 * *
+- DD Deregister Rsp DDDeregRsp 0x800A * *
+- DDS Register Rsp DDSRegRsp 0x800B * *
+- DDS Deregister Rsp DDSDeregRsp 0x800C * *
+- Entity Status Inquiry Rsp ESIRsp 0x800D *
+- NOT USED 0x800E
+- RESERVED 0x800F-0x8010
+- Request FC_DOMAIN_ID Rsp RqstDomIdRsp 0x8011
+- Release FC_DOMAIN_ID Rsp RlseDomIdRsp 0x8012
+- Get FC_DOMAIN_IDs GetDomIdRsp 0x0013
+- RESERVED 0x8014-0x80FF
+- Vendor Specific 0x8100-0x81FF
+- RESERVED 0x8200-0xFFFF
+-
+-5. iSNSP Message Format
+-
+- The iSNSP message format is similar to the format of other common
+- protocols such as DHCP, DNS and BOOTP. An iSNSP message may be sent
+- in one or more iSNS Protocol Data Units (PDU). Each PDU is 4-byte
+- aligned. The following describes the format of the iSNSP PDU:
+-
+- Byte MSb LSb
+- Offset 0 15 16 31
+- +---------------------+----------------------+
+- 0 | iSNSP VERSION | FUNCTION ID | 4 Bytes
+- +---------------------+----------------------+
+- 4 | PDU LENGTH | FLAGS | 4 Bytes
+- +---------------------+----------------------+
+- 8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes
+- +---------------------+----------------------+
+- 12 | |
+- | PDU PAYLOAD | N Bytes
+- | ... |
+- +--------------------------------------------+
+- 12+N | AUTHENTICATION BLOCK (Multicast/Broadcast) | L Bytes
+- +--------------------------------------------+
+- Total Length = 12 + N + L
+-
+-5.1. iSNSP PDU Header
+-
+- The iSNSP PDU header contains the iSNSP VERSION, FUNCTION ID, PDU
+- LENGTH, FLAGS, TRANSACTION ID, and SEQUENCE ID fields as defined
+- below.
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 35]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.1.1. iSNSP Version
+-
+- The iSNSP version described in this document is 0x0001. All other
+- values are RESERVED. The iSNS server MAY reject messages for iSNSP
+- version numbers that it does not support.
+-
+-5.1.2. iSNSP Function ID
+-
+- The FUNCTION ID defines the type of iSNS message and the operation to
+- be executed. FUNCTION_ID values with the leading bit cleared
+- indicate query, registration, and notification messages, whereas
+- FUNCTION_ID values with the leading bit set indicate response
+- messages.
+-
+- See Section 4 under the appropriate protocol (i.e., iSCSI or iFCP)
+- for a mapping of the FUNCTION_ID value to the iSNSP Command or
+- Response message. All PDUs comprising an iSNSP message must have the
+- same FUNCTION_ID value.
+-
+-5.1.3. iSNSP PDU Length
+-
+- The iSNS PDU Length specifies the length of the PDU PAYLOAD field in
+- bytes. The PDU Payload contains TLV attributes for the operation.
+-
+- Additionally, response messages contain a success/failure code. The
+- PDU Length MUST be 4-byte aligned.
+-
+-5.1.4. iSNSP Flags
+-
+- The FLAGS field indicates additional information about the message
+- and the type of Network Entity that generated the message. The
+- following table displays the valid flags:
+-
+- Bit Position Enabled (1) means:
+- ------------ -----------------
+- 16 Sender is the iSNS client
+- 17 Sender is the iSNS server
+- 18 Authentication block is present
+- 19 Replace flag (for DevAttrReg)
+- 20 Last PDU of the iSNS message
+- 21 First PDU of the iSNS message
+- 22-31 RESERVED
+-
+-5.1.5. iSNSP Transaction ID
+-
+- The TRANSACTION ID MUST be set to a unique value for each
+- concurrently outstanding request message. Replies MUST use the same
+- TRANSACTION ID value as the associated iSNS request message. If a
+-
+-
+-
+-Tseng, et al. Standards Track [Page 36]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- message is retransmitted, the original TRANSACTION ID value MUST be
+- used. All PDUs comprising an iSNSP message must have the same
+- TRANSACTION ID value.
+-
+-5.1.6. iSNSP Sequence ID
+-
+- The SEQUENCE ID has a unique value for each PDU within a single
+- transaction. The SEQUENCE_ID value of the first PDU transmitted in a
+- given iSNS message MUST be zero (0), and each SEQUENCE_ID value in
+- each PDU MUST be numbered sequentially in the order in which the PDUs
+- are transmitted. Note that the two-byte SEQUENCE ID allows for up to
+- 65536 PDUs per iSNS message.
+-
+-5.2. iSNSP Message Segmentation and Reassembly
+-
+- iSNS messages may be carried in one or more iSNS PDUs. If only one
+- iSNS PDU is used to carry the iSNS message, then bit 21 (First PDU)
+- and bit 20 in the FLAGS field (Last PDU) SHALL both be set. If
+- multiple PDUs are used to carry the iSNS message, then bit 21 SHALL
+- be set in the first PDU of the message, and bit 20 SHALL be set in
+- the last PDU.
+-
+- All PDUs comprising the same iSNSP message SHALL have the same
+- FUNCTION_ID and TRANSACTION_ID values. Each PDU comprising an iSNSP
+- message SHALL have a unique SEQUENCE_ID value.
+-
+-5.3. iSNSP PDU Payload
+-
+- The iSNSP PDU PAYLOAD is of variable length and contains attributes
+- used for registration and query operations. The attribute data items
+- use a format similar to that of other protocols, such as DHCP
+- [RFC2131] options. Each iSNS attribute is specified in the PDU
+- Payload using Tag-Length-Value (TLV) data format, as shown below:
+-
+- Byte MSb LSb
+- Offset 0 31
+- +--------------------------------------------+
+- 0 | Attribute Tag | 4 Bytes
+- +--------------------------------------------+
+- 4 | Attribute Length (N) | 4 Bytes
+- +--------------------------------------------+
+- 8 | |
+- | Attribute Value | N Bytes
+- | |
+- +--------------------------------------------+
+- Total Length = 8 + N
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 37]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Attribute Tag: a 4-byte field that identifies the attribute as
+- defined in Section 6.1. This field contains the
+- tag value from the indicated table.
+-
+- Attribute Length: a 4-byte field that indicates the length, in bytes,
+- of the value field to follow in the TLV. For
+- variable-length attributes, the value field MUST
+- contain padding bytes, if necessary, in order to
+- achieve 4-byte alignment. A "zero-length TLV"
+- contains only the attribute tag and length fields.
+-
+- Attribute Value: a variable-length field containing the attribute
+- value and padding bytes (if necessary).
+-
+- The above format is used to identify each attribute in the PDU
+- Payload. Note that TLV boundaries need not be aligned with PDU
+- boundaries; PDUs may carry one or more TLVs, or any fraction thereof.
+- The Response Status Code, contained in response message PDU Payloads
+- and described below, is not in TLV format. PDU Payloads for messages
+- that do not contain iSNS attributes, such as the Name Service
+- Heartbeat, do not use the TLV format.
+-
+-5.3.1. Attribute Value 4-Byte Alignment
+-
+- All attribute values are aligned to 4-byte boundaries. For variable
+- length attributes, if necessary, the TLV length MUST be increased to
+- the next 4-byte boundary through padding with bytes containing zero
+- (0). If an attribute value is padded, a combination of the tag and
+- attribute value itself is used to determine the actual value length
+- and number of pad bytes. There is no explicit count of the number of
+- pad bytes provided in the TLV.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 38]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.4. iSNSP Response Status Codes
+-
+- All iSNSP response messages contain a 4-byte Status Code field as the
+- first field in the iSNSP PDU PAYLOAD. If the original iSNSP request
+- message was processed normally by the iSNS server, or by the iSNS
+- client for ESI and SCN messages, then this field SHALL contain a
+- status code of 0 (Successful). A non-zero status code indicates
+- rejection of the entire iSNS client request message.
+-
+- Status Code Status Description
+- ----------- -----------------
+- 0 Successful
+- 1 Unknown Error
+- 2 Message Format Error
+- 3 Invalid Registration
+- 4 RESERVED
+- 5 Invalid Query
+- 6 Source Unknown
+- 7 Source Absent
+- 8 Source Unauthorized
+- 9 No Such Entry
+- 10 Version Not Supported
+- 11 Internal Error
+- 12 Busy
+- 13 Option Not Understood
+- 14 Invalid Update
+- 15 Message (FUNCTION_ID) Not Supported
+- 16 SCN Event Rejected
+- 17 SCN Registration Rejected
+- 18 Attribute Not Implemented
+- 19 FC_DOMAIN_ID Not Available
+- 20 FC_DOMAIN_ID Not Allocated
+- 21 ESI Not Available
+- 22 Invalid Deregistration
+- 23 Registration Feature Not Supported
+- 24 and above RESERVED
+-
+-5.5. Authentication for iSNS Multicast and Broadcast Messages
+-
+- For iSNS multicast and broadcast messages (see Section 2.9.3), the
+- iSNSP provides authentication capability. The following section
+- details the iSNS Authentication Block, which is identical in format
+- to the SLP authentication block [RFC2608]. iSNS unicast messages
+- SHOULD NOT include the authentication block, but rather should rely
+- upon IPSec security mechanisms.
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 39]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- If a message contains an authentication block, then the
+- "Authentication block present" bit in the iSNSP PDU header FLAGS
+- field SHALL be enabled.
+-
+- If a PKI is available with an [X.509] Certificate Authority (CA),
+- then public key authentication of the iSNS server is possible. The
+- authentication block leverages the DSA with SHA-1 algorithm, which
+- can easily integrate into a public key infrastructure.
+-
+- The authentication block contains a digital signature for the
+- multicast message. The digital signature is calculated on a per-PDU
+- basis. The authentication block contains the following information:
+-
+- 1. A time stamp, to prevent replay attacks.
+- 2. A structured authenticator containing a signature calculated over
+- the time stamp and the message being secured.
+- 3. An indicator of the cryptographic algorithm that was used to
+- calculate the signature.
+- 4. An indicator of the keying material and algorithm parameters,
+- used to calculate the signature.
+-
+- The authentication block is described in the following figure:
+-
+- Byte MSb LSb
+- Offset 0 31
+- +----------------------------------+
+- 0 | BLOCK STRUCTURE DESCRIPTOR | 4 Bytes
+- +----------------------------------+
+- 4 | AUTHENTICATION BLOCK LENGTH | 4 Bytes
+- +----------------------------------+
+- 8 | TIMESTAMP | 8 Bytes
+- +----------------------------------+
+- 16 | SPI STRING LENGTH | 4 Bytes
+- +----------------------------------+
+- 20 | SPI STRING | N Bytes
+- +----------------------------------+
+- 20 + N | STRUCTURED AUTHENTICATOR | M Bytes
+- +----------------------------------+
+- Total Length = 20 + N + M
+-
+- BLOCK STRUCTURE DESCRIPTOR (BSD): Defines the structure and algorithm
+- to use for the STRUCTURED AUTHENTICATOR. BSD values from
+- 0x00000000 to 0x00007FFF are assigned by IANA, while
+- values 0x00008000 to 0x00008FFF are for private use.
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 40]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- AUTHENTICATION BLOCK LENGTH: Defines the length of the authentication
+- block, beginning with the BSD field and running through
+- the last byte of the STRUCTURED AUTHENTICATOR.
+-
+- TIMESTAMP: This is an 8-byte unsigned, fixed-point integer giving the
+- number of seconds since 00:00:00 GMT on January 1, 1970.
+-
+- SPI STRING LENGTH: The length of the SPI STRING field.
+-
+- SPI STRING (Security Parameters Index): Index to the key and
+- algorithm used by the message recipient to decode the
+- STRUCTURED AUTHENTICATOR field.
+-
+- STRUCTURED AUTHENTICATOR: Contains the digital signature. For the
+- default BSD value of 0x0002, this field SHALL contain the
+- binary ASN.1 encoding of output values from the DSA with
+- SHA-1 signature calculation as specified in Section 2.2.2
+- of [RFC3279].
+-
+-5.6. Registration and Query Messages
+-
+- The iSNSP registration and query message PDU Payloads contain a list
+- of attributes, and have the following format:
+-
+- +----------------------------------------+
+- | Source Attribute (Requests Only) |
+- +----------------------------------------+
+- | Message Key Attribute[1] (if present) |
+- +----------------------------------------+
+- | Message Key Attribute[2] (if present) |
+- +----------------------------------------+
+- | . . . |
+- +----------------------------------------+
+- | - Delimiter Attribute - |
+- +----------------------------------------+
+- | Operating Attribute[1] (if present) |
+- +----------------------------------------+
+- | Operating Attribute[2] (if present) |
+- +----------------------------------------+
+- | Operating Attribute[3] (if present) |
+- +----------------------------------------+
+- | . . . |
+- +----------------------------------------+
+-
+- Each Source, Message Key, Delimiter, and Operating attribute is
+- specified in the PDU Payload using the Tag-Length-Value (TLV) data
+- format. iSNS Registration and Query messages are sent by iSNS Clients
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 41]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- to the iSNS server IP Address and well-known TCP/UDP Port. The iSNS
+- Responses will be sent to the iSNS Client IP address and TCP/UDP port
+- number from the original request message.
+-
+-5.6.1. Source Attribute
+-
+- The Source Attribute is used to identify the Storage Node to the iSNS
+- server for queries and other messages that require source
+- identification. The Source Attribute uniquely identifies the source
+- of the message. Valid Source Attribute types are shown below.
+-
+- Valid Source Attributes
+- -----------------------
+- iSCSI Name
+- FC Port Name WWPN
+-
+- For a query operation, the Source Attribute is used to limit the
+- scope of the specified operation to the Discovery Domains of which
+- the source is a member. Special Control Nodes, identified by the
+- Source Attribute, may be administratively configured to perform the
+- specified operation on all objects in the iSNS database without
+- scoping to Discovery Domains.
+-
+- For messages that change the contents of the iSNS database, the iSNS
+- server MUST verify that the Source Attribute identifies either a
+- Control Node or a Storage Node that is a part of the Network Entity
+- containing the added, deleted, or modified objects.
+-
+-5.6.2. Message Key Attributes
+-
+- Message Key attributes are used to identify matching objects in the
+- iSNS database for iSNS query and registration messages. If present,
+- the Message Key MUST be a Registration or Query Key for an object as
+- described in Sections 5.6.5 and 6.1. A Message Key is not required
+- when a query spans the entire set of objects available to the Source
+- or a registration is for a new Entity.
+-
+- iSCSI Names used in the Message Key MUST be normalized according to
+- the stringprep template [STRINGPREP]. Entity Identifiers (EIDs) used
+- in the Message Key MUST be normalized according to the nameprep
+- template [NAMEPREP].
+-
+-5.6.3. Delimiter Attribute
+-
+- The Delimiter Attribute separates the Message Key attributes from the
+- Operating Attributes in a PDU Payload. The Delimiter Attribute has a
+- tag value of 0 and a length value of 0. The Delimiter Attribute is
+- always 8 bytes long (a 4-byte tag field and a 4-byte length field,
+-
+-
+-
+-Tseng, et al. Standards Track [Page 42]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- all containing zeros). If a Message Key is not required for a
+- message, then the Delimiter Attribute immediately follows the Source
+- Attribute.
+-
+-5.6.4. Operating Attributes
+-
+- The Operating Attributes are a list of one or more key and non-key
+- attributes related to the actual iSNS registration or query operation
+- being performed.
+-
+- Operating Attributes include object key attributes and non-key
+- attributes. Object key attributes uniquely identify iSNS objects.
+- Key attributes MUST precede the non-key attributes of each object in
+- the Operating Attributes. The tag value distinguishes the attribute
+- as an object key attribute (i.e., tag=1, 16&17, 32, 64, and 96) or a
+- non-key attribute. iSCSI Names used in the Operating Attributes MUST
+- be normalized according to the stringprep template [STRINGPREP].
+- Entity Identifiers (EIDs) used in the Operating Attributes MUST be
+- normalized according to the nameprep template [NAMEPREP].
+-
+- The ordering of Operating Attributes in the message is important for
+- determining the relationships among objects and their ownership of
+- non-key attributes. iSNS protocol messages that violate these
+- ordering rules SHALL be rejected with the Status Code of 2 (Message
+- Format Error). See the message descriptions for proper operating
+- attribute ordering requirements.
+-
+- Some objects are keyed by more than one object key attribute value.
+- For example, the Portal object is keyed by attribute tags 16 and 17.
+- When describing an object keyed by more than one key attribute, every
+- object key attribute of that object MUST be listed sequentially by
+- tag value in the message before non-key attributes of that object and
+- key attributes of the next object. A group of key attributes of this
+- kind is treated as a single logical key attribute when identifying an
+- object.
+-
+- Non-key attributes that immediately follow key attributes MUST be
+- attributes of the object referenced by the key attributes. All non-
+- key attributes of an object MUST be listed before the object key
+- attributes introducing the next object.
+-
+- Objects MUST be listed in inheritance order, according to their
+- containment order. Storage Node and Portal objects and their
+- respective attributes MUST follow the Network Entity object to which
+- they have a relationship. Similarly, FC Device objects MUST follow
+- the Storage Node object to which they have a relationship.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 43]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Vendor-specific objects defined by tag values in the range 1537-2048
+- have the same requirements described above.
+-
+-5.6.4.1. Operating Attributes for Query and Get Next Requests
+-
+- In Query and Get Next request messages, TLV attributes with length
+- value of 0 are used to indicate which Operating Attributes are to be
+- returned in the corresponding response. Operating Attribute values
+- that match the TLV attributes in the original message are returned in
+- the response message.
+-
+-5.6.5. Registration and Query Request Message Types
+-
+- The following describes each query and message type.
+-
+-5.6.5.1. Device Attribute Registration Request (DevAttrReg)
+-
+- The DevAttrReg message type is 0x0001. The DevAttrReg message
+- provides the means for iSNS clients to update existing objects or
+- register new objects. The value of the replace bit in the FLAGs
+- field determines whether the DevAttrReg message updates or replaces
+- an existing registration.
+-
+- The Source Attribute identifies the Node initiating the registration
+- request.
+-
+- The Message Key identifies the object the DevAttrReg message acts
+- upon. It MUST contain the key attribute(s) identifying an object.
+- This object MUST contain all attributes and related subordinate
+- object attributes that will be included in the Operating Attributes
+- of the DevAttrReg PDU Payload. The key attribute(s) identifying this
+- object MUST also be included among the Operating Attributes.
+-
+- If the Message Key contains an EID and no pre-existing objects match
+- the Message Key, then the DevAttrReg message SHALL create a new
+- Entity with the specified EID and any new object(s) specified by the
+- Operating Attributes. The replace bit SHALL be ignored.
+-
+- If the Message Key does not contain an EID, and no pre-existing
+- objects match the Message Key, then the DevAttrReg message SHALL be
+- rejected with a status code of 3 (Invalid Registration).
+-
+- If the Message Key is not present, then the DevAttrReg message
+- implicitly registers a new Network Entity. In this case, the replace
+- bit SHALL be ignored; a new Network Entity SHALL be created.
+- Existing entities, their objects, and their relationships remain
+- unchanged.
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 44]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- The replace bit determines the kind of operation conducted on the
+- object identified in the DevAttrReg Message Key. The replace bit
+- only applies to the DevAttrReg message; it is ignored for all other
+- message types.
+-
+- If the replace bit is set, then the objects, attributes, and
+- relationships specified in the Operating Attributes SHALL replace the
+- object identified by the Message Key. The object and all of its
+- subordinate objects SHALL be deregistered, and the appropriate SCNs
+- SHALL be sent by the iSNS server for the deregistered objects. The
+- objects listed in the Operating Attributes are then used to replace
+- the just-deregistered objects. Note that additional SCNs SHALL be
+- sent for the newly-registered objects, if appropriate. Existing
+- objects and relationships that are not identified or that are
+- subordinate to the object identified by the Message Key MUST NOT be
+- affected or changed.
+-
+- If the replace bit is not set, then the message updates the
+- attributes of the object identified by the Message Key and its
+- subordinate objects. Existing object containment relationships MUST
+- NOT be changed. For existing objects, key attributes MUST NOT be
+- modified, but new subordinate objects MAY be added.
+-
+- The Operating Attributes represent objects, attributes, and
+- relationships that are to be registered. Multiple related objects
+- and attributes MAY be registered in a single DevAttrReg message. The
+- ordering of the objects in this message indicates the structure of,
+- and associations among, the objects to be registered. At least one
+- object MUST be listed in the Operating Attributes. Additional
+- objects (if any) MUST be subordinate to the first object listed. Key
+- attributes MUST precede non-key attributes of each object. A given
+- object may only appear a maximum of once in the Operating Attributes
+- of a message. If the Node identified by the Source Attribute is not
+- a Control Node, then the objects in the operating attributes MUST be
+- members of the same Network Entity as the Source Node.
+-
+- For example, to establish relationships between a Network Entity
+- object and its Portal and Storage Node objects, the Operating
+- Attributes list the key and non-key attributes of the Network Entity
+- object, followed by the key and non-key attributes of each Portal and
+- Storage Node object to be linked to that Network Entity. Similarly,
+- an FC Device object that follows a Storage Node object is considered
+- subordinate to that Storage Node.
+-
+- New PG objects are registered when an associated Portal or iSCSI Node
+- object is registered. An explicit PG object registration MAY follow
+- a Portal or iSCSI Node object registration in a DevAttrReg message.
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 45]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- When a Portal is registered, the Portal attributes MAY immediately be
+- followed by a PGT attribute. The PGT attribute SHALL be followed by
+- the set of PG iSCSI Names representing nodes that will be associated
+- to the Portal using the indicated PGT value. Additional sets of PGTs
+- and PG iSCSI Names to be associated to the registered Portal MAY
+- follow. Indicated PGT values are assigned to the PG object
+- associated with the newly registered Portal and to the iSCSI Storage
+- Node(s) referenced immediately following the PGT attribute in the
+- operating attributes.
+-
+- When an iSCSI Storage Node is registered, the Storage Node attributes
+- MAY immediately be followed by a PGT attribute. The PGT attribute
+- SHALL be followed by the set of PG Portal IP-Address, PG TCP/UDP Port
+- pairs representing Portal objects that will be associated with the
+- Storage Node using the indicated PGT value. Additional sets of PGTs
+- and PG Portal IP-Address PG TCP/UDP Port pairs to be associated with
+- the registered Storage Node MAY follow. Indicated PGT values are
+- assigned to the PG object associated with the newly registered iSCSI
+- Storage Node and Portal object(s) referenced immediately following
+- the PGT attribute in the operating attributes.
+-
+- If the PGT value is not included in the Storage Node or Portal object
+- registration, and if a PGT value was not previously registered for
+- the relationship, then the PGT for the corresponding PG object SHALL
+- be registered with a value of 0x00000001. If the PGT attribute is
+- included in the registration message as a 0-length TLV, then the PGT
+- value for the corresponding PG object SHALL be registered as NULL. A
+- 0-length TLV for the PGT in an update registration message overwrites
+- the previous PGT value with NULL, indicating that there is no
+- relationship between the Storage Node and Portal.
+-
+- A maximum of one Network Entity object can be created or updated with
+- a single DevAttrReg message. Consequently, the Operating Attributes
+- MUST NOT contain more than one Network Entity object. There is no
+- limit to the number of Portal, Storage Node, and FC Device objects
+- that can listed in the Operating Attributes, provided they are all
+- subordinate to the listed Network Entity object.
+-
+- If the Message Key and Operating Attributes do not contain an EID
+- attribute, or if the EID attribute has a length of 0, then a new
+- Network Entity object SHALL be created and the iSNS server SHALL
+- supply a unique EID value for it. The assigned EID value SHALL be
+- included in the DevAttrReg Response message. If the Message Key and
+- Operating Attributes contain an EID that does not match the EID of an
+- existing Network Entity in the iSNS database, then a new Network
+- Entity SHALL be created and assigned the value contained in that EID
+- attribute. Finally, if the Message Key and Operating Attributes
+- contain an EID that matches the EID of an existing object in the iSNS
+-
+-
+-
+-Tseng, et al. Standards Track [Page 46]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- database, then the objects, attributes, and relationships specified
+- in the Operating Attributes SHALL be appended to the existing Network
+- Entity identified by the EID.
+-
+- A registration message that creates a new Network Entity object MUST
+- contain at least one Portal or one Storage Node. If the message does
+- not, then it SHALL be considered invalid and result in a response
+- with Status Code of 3 (Invalid Registration).
+-
+- If an iSNS Server does not support a registration feature, such as
+- explicit PG object registration, then the server SHALL return a
+- Status Code of 23 (Registration Feature Not Supported).
+-
+- Note that the iSNS server may modify or reject the registration of
+- certain attributes, such as ESI Interval. In addition, the iSNS
+- server may assign values for additional Operating Attributes that are
+- not explicitly registered in the original DevAttrReg message, such as
+- the EID and WWNN Token.
+-
+-5.6.5.2. Device Attribute Query Request (DevAttrQry)
+-
+- The DevAttrQry message type is 0x0002. The DevAttrQry message
+- provides an iSNS client with the means to query the iSNS server for
+- object attributes.
+-
+- The Source Attribute identifies the Node initiating the request. For
+- non-Control Nodes initiating the DevAttrQry message, the query is
+- scoped to the Discovery Domains of which the initiating Node is a
+- member. The DevAttrQry message SHALL only return information on
+- Storage Nodes and their related parent and subordinate objects, where
+- the Storage Node has a common Discovery Domain with the Node
+- identified in the Source Attribute.
+-
+- The Message Key may contain key or non-key attributes or no
+- attributes at all. If multiple attributes are used as the Message
+- Key, then they MUST all be from the same object type (e.g., IP
+- address and TCP/UDP Port are attributes of the Portal object type).
+- A Message Key with non-key attributes may match multiple instances of
+- the specific object type. A Message Key with zero-length TLV(s) is
+- scoped to every object of the type indicated by the zero-length
+- TLV(s). An empty Message Key field indicates the query is scoped to
+- the entire database accessible by the source Node.
+-
+- The DevAttrQry response message returns attributes of objects listed
+- in the Operating Attributes that are related to the Message Key of
+- the original DevAttrQry message. The Operating Attributes of the
+- DevAttrQry message contain zero-length TLVs that specify the
+- attributes that are to be returned in the DevAttrQryRsp message. A
+-
+-
+-
+-Tseng, et al. Standards Track [Page 47]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Message Key containing zero-length TLVs indicates that the set of
+- attributes specified in the Operating Attributes are to be returned
+- for each object matching the type indicated by the Message Key.
+-
+- If the Message Key contains non-zero length TLVs, then Operating
+- Attributes for the object matching the Message Key SHALL be returned
+- in the DevAttrQryRsp message. Each attribute type (i.e., zero-length
+- TLV) in the Operating Attributes indicates an attribute from the
+- object matching the Message Key, or from other objects in the same
+- Entity having a relationship to the object matching the Message Key,
+- is to be returned in the response. The ordering of the object keys
+- and associated attributes returned in the DevAttrQry response message
+- SHALL be the same as in the original query message. If no objects
+- match the Message Key, then the DevAttrQryRsp message SHALL NOT
+- return any operating attributes. Such a message and its
+- corresponding response SHALL NOT be considered an error.
+-
+- The Portal Group object determines whether a relationship exists
+- between a given Storage Node and Portal object. If the PGT of the
+- Portal Group is not NULL, then a relationship exists between the
+- indicated Storage Node and Portal; if the PGT is NULL, then no
+- relationship exists. Therefore, the value (NULL or not NULL) of the
+- PGT attribute of each Portal Group object determines the structure
+- and ordering of the DevAttrQry response to a query for Storage Nodes
+- and Portals.
+-
+- For example, an iSNS database contains a Network Entity having two
+- Portals and two Nodes. Each Storage Node has two Portal Groups, one
+- with a NULL PGT value for one Portal and another with a non-NULL PGT
+- value for the other Portal. The DevAttrQry message contains a
+- Message Key entry matching one of the Nodes, and Operating Attributes
+- with zero-length TLVs listing first the Node attributes, Portal
+- attributes, and then the PG attributes. The response message SHALL
+- therefore return first the matching Node object, then the requested
+- attributes of the one Portal object that can be used to access the
+- Storage Node (as indicated by the PGT), and finally the requested
+- attributes of the PG object used to access that Storage Node. The
+- order in which each object's attributes are listed is the same as the
+- ordering of the object's attributes in the Operating Attributes of
+- the original request message.
+-
+- If the Message Key Attribute contains zero-length TLV(s), then the
+- query returns requested attributes for all objects matching the
+- Message Key type (DD restrictions SHALL apply for non-Control Nodes).
+- If multiple objects match the Message Key type, then the attributes
+- for each object matching the Message Key MUST be listed before the
+- attributes for the next matching object are listed in the query
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 48]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- response. In other words, the process described above must be
+- iterated in the message response for each object that matches the
+- Message Key type specified by the zero-length TLV(s).
+-
+- For example, an iSNS database contains only one Network Entity having
+- two Portals and three Nodes. All PG objects in the Entity have a PGT
+- value of 0x00000001. In the DevAttrQry message, the Message Key
+- contains a zero-length TLV specifying a Node type, and Operating
+- Attributes listing first the Node attributes, and then the Portal
+- attributes. The response message will return, in the following
+- order, the attributes for the first, next, and last Node objects,
+- each followed by attributes for both Portals. If that same
+- DevAttrQry message had instead contained a zero-length TLV specifying
+- the Network Entity type, then the response message would have
+- returned attributes for all three Node objects, followed by
+- attributes for the two Portals.
+-
+- If there is no Message Key Attribute, then the query returns all
+- attributes in the iSNS database (once again, DD restrictions SHALL
+- apply for non-Control Nodes). All attributes matching the type
+- specified by each zero-length TLV in the Operating Attributes SHALL
+- be listed. All attributes of each type SHALL be listed before the
+- attributes matching the next zero-length TLV are listed.
+-
+- For example, an iSNS database contains two Entities, each having two
+- Nodes and two Portals. The DevAttrQry message contains no Message
+- Key attribute, and Operating Attributes list first the Portal
+- attributes, and then the Node attributes. The Operating Attributes
+- of the response message will return attributes from each of the four
+- Portals, followed by attributes from each of the four nodes.
+-
+- If a DevAttrQry message requests an attribute for which the iSNS
+- server has no value, then the server SHALL NOT return the requested
+- attribute in the query response. Such query and response messages
+- SHALL NOT be considered errors.
+-
+- Registration and query messages for iSNS server-specific attributes
+- (i.e., tags in the range 132 to 384) SHALL be formatted using the
+- identifying key attribute of the Storage Node originating the query
+- (i.e., iSCSI Name or FC Port Name WWPN) for both the Source Attribute
+- and Message Key attribute. Operating Attributes SHALL include the
+- TLV of the server-specific attribute being requested.
+-
+- DD membership can be discovered through the DevAttrQry message by
+- including either DD member attributes (i.e., DD Member iSCSI Index,
+- DD Member iSCSI Node, DD Member iFCP Node, DD Member Portal Index, DD
+- Member Portal IP Addr, and DD Member Portal TCP/UDP) or the object
+- key of the Storage Node or Portal (i.e., iSCSI Name, iSCSI Index,
+-
+-
+-
+-Tseng, et al. Standards Track [Page 49]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Portal IP Addr, Portal TCP/UDP Port, and Portal Index) in the
+- Operating Attributes. Using DD member attributes SHALL return both
+- registered and unregistered member Storage Nodes and/or Portals of a
+- DD. DevAttrQry messages using the Storage Node and/or Portal object
+- key SHALL return only member Storage Nodes or Portals that are
+- currently registered in the iSNS database.
+-
+- The DevAttrQry message SHALL support the following minimum set of
+- Message Key Attributes:
+-
+- Valid Message Key Attributes for Queries
+- ----------------------------------------
+- Entity Identifier
+- Entity Protocol
+- Portal IP-Address & Portal TCP/UDP Port
+- Portal Index
+- iSCSI Node Type
+- iSCSI Name
+- iSCSI Index
+- PG Index
+- FC Port Name WWPN
+- FC Port Type
+- FC-4 Type
+- Discovery Domain ID
+- Discovery Domain Set ID
+- Source Attribute (for server-specific attributes)
+- Switch Name (FC Device WWNN--for Virtual_Fabric_ID queries)
+-
+-5.6.5.3. Device Get Next Request (DevGetNext)
+-
+- The DevGetNext message type is 0x0003. This message provides the
+- iSNS client with the means to retrieve each and every instance of an
+- object type exactly once.
+-
+- The Source Attribute identifies the Node initiating the DevGetNext
+- request, and is used to scope the retrieval process to the Discovery
+- Domains of which the initiating Node is a member.
+-
+- The Message Key Attribute may be an Entity Identifier (EID), iSCSI
+- Name, iSCSI Index, Portal IP Address and TCP/UDP Port, Portal Index,
+- PG Index, FC Node Name WWNN, or FC Port Name WWPN. If the TLV length
+- of the Message Key Attribute(s) is zero, then the first object entry
+- in the iSNS database matching the Message Key type SHALL be returned
+- in the Message Key of the corresponding DevGetNextRsp message. If
+- non-zero-length TLV attributes are contained in the Message Key, then
+- the DevGetNext response message SHALL return the next object stored
+- after the object identified by the Message Key in the original
+- DevGetNext request message.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 50]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- If the Message Key provided matches the last object instance in the
+- iSNS database, then the Status Code of 9 (No Such Entry) SHALL be
+- returned in the response.
+-
+- The Operating Attributes can be used to specify the scope of the
+- DevGetNext request, and to specify the attributes of the next object,
+- which are to be returned in the DevGetNext response message. All
+- Operating Attributes MUST be attributes of the object type identified
+- by the Message Key. For example, if the Message Key is an Entity_ID
+- attribute, then the Operating Attributes MUST NOT contain attributes
+- of Portals.
+-
+- Non-zero-length TLV attributes in the Operating Attributes are used
+- to scope the DevGetNext message. Only the next object with attribute
+- values that match the non-zero-length TLV attributes SHALL be
+- returned in the DevGetNext response message.
+-
+- Zero-length TLV attributes MUST be listed after non-zero-length
+- attributes in the Operating Attributes of the DevGetNext request
+- message. Zero-length TLV attributes specify the attributes of the
+- next object which are to be returned in the DevGetNext response
+- message.
+-
+- Note that there are no specific requirements concerning the order in
+- which object entries are retrieved from the iSNS database; the
+- retrieval order of object entries using the DevGetNext message is
+- implementation specific.
+-
+- The iSNS client is responsible for ensuring that information acquired
+- through use of the DevGetNext message is accurate and up-to-date.
+- There is no assurance that the iSNS database will not change between
+- successive DevGetNext request messages. If the Message Key provided
+- does not match an existing database entry, then attributes for the
+- next object key following the provided Message Key SHALL be returned.
+- For example, an object entry may have been deleted between successive
+- DevGetNext messages. This may result in a DevGetNext request in
+- which the Message Key does not match an existing object entry. In
+- this case, attributes for the next object stored in the iSNS database
+- are returned.
+-
+-5.6.5.4. Device Deregister Request (DevDereg)
+-
+- The DevDereg message type is 0x0004. This message is used to remove
+- object entries from the iSNS database. One or more objects may be
+- removed through a single DevDereg message. Note that deregistered
+- Storage Node objects will retain membership in their Discovery
+- Domain(s) until explicit deregistration of the membership(s) or
+- Discovery Domain(s).
+-
+-
+-
+-Tseng, et al. Standards Track [Page 51]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Upon receiving the DevDereg, the iSNS server removes all objects
+- identified by the Operating Attribute(s), and all subordinate objects
+- that are solely dependent on those identified objects. For example,
+- removal of a Network Entity also results in removal of all associated
+- Portal, Portal Group, Storage Node, and FC Device objects associated
+- with that Network Entity. FC Device objects SHALL not be
+- deregistered in this manner unless all Storage Nodes associated with
+- them have been deregistered.
+-
+- The DevDereg request PDU Payload contains a Source Attribute and
+- Operating Attribute(s); there are no Message Key Attributes. If the
+- Node identified by the Source Attribute is not a Control Node, then
+- it MUST be from the same Network Entity as the object(s) identified
+- for removal by the Operating Attribute(s). Valid Operating
+- Attributes are shown below:
+-
+- Valid Operating Attributes for DevDereg
+- ---------------------------------------
+- Entity Identifier
+- Portal IP-Address & Portal TCP/UDP Port
+- Portal Index
+- iSCSI Name
+- iSCSI Index
+- FC Port Name WWPN
+- FC Node Name WWNN
+-
+- The removal of the object may result in SCN messages to the
+- appropriate iSNS clients.
+-
+- Attempted deregistration of non-existing entries SHALL not be
+- considered an error.
+-
+- If all Nodes and Portals associated with a Network Entity are
+- deregistered, then the Network Entity SHALL also be removed.
+-
+- If both the Portal and iSCSI Storage Node objects associated with a
+- Portal Group object are removed, then that Portal Group object SHALL
+- also be removed. The Portal Group object SHALL remain registered as
+- long as either of its associated Portal or iSCSI Storage Node objects
+- remain registered. If a deleted Storage Node or Portal object is
+- subsequently re-registered, then a relationship between the re-
+- registered object and an existing Portal or Storage Node object
+- registration, indicated by the PG object, SHALL be restored.
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 52]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.6.5.5. SCN Register Request (SCNReg)
+-
+- The SCNReg message type is 0x0005. The State Change Notification
+- Registration Request (SCNReg) message allows an iSNS client to
+- register a Storage Node to receive State Change Notification (SCN)
+- messages.
+-
+- The SCN notifies the Storage Node of changes to any Storage Nodes
+- within any DD of which it is a member. If the Storage Node is a
+- Control Node, it SHALL receive SCN notifications for changes in the
+- entire network. Note that whereas SCNReg sets the SCN Bitmap field,
+- the DevAttrReg message registers the UDP or TCP Port used by each
+- Portal to receive SCN messages. If no SCN Port fields of any Portals
+- of the Storage Node are registered to receive SCN messages, then the
+- SCNReg message SHALL be rejected with Status Code 17 (SCN
+- Registration Rejected).
+-
+- The SCNReg request PDU Payload contains a Source Attribute, a Message
+- Key Attribute, and an Operating Attribute. Valid Message Key
+- Attributes for a SCNReg are shown below:
+-
+- Valid Message Key Attributes for SCNReg
+- ---------------------------------------
+- iSCSI Name
+- FC Port Name WWPN
+-
+- The node with the iSCSI Name or FC Port Name WWPN attribute that
+- matches the Message Key in the SCNReg message is registered to
+- receive SCNs using the specified SCN bitmap. A maximum of one Node
+- SHALL be registered for each SCNReg message.
+-
+- The SCN Bitmap is the only operating attribute of this message, and
+- it always overwrites the previous contents of this field in the iSNS
+- database. The bitmap indicates the SCN event types for which the
+- Node is registering.
+-
+- Note that the settings of this bitmap determine whether the SCN
+- registration is for regular SCNs or management SCNs. Control Nodes
+- MAY conduct registrations for management SCNs; iSNS clients that are
+- not supporting Control Nodes MUST NOT conduct registrations for
+- management SCNs. Control Nodes that register for management SCNs
+- receive a copy of every SCN message generated by the iSNS server. It
+- is recommended that management registrations be used only when needed
+- in order to conserve iSNS server resources. In addition, a Control
+- Node that conducts such registrations should be prepared to receive
+- the anticipated volume of SCN message traffic.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 53]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.6.5.6. SCN Deregister Request (SCNDereg)
+-
+- The SCNDereg message type is 0x0006. The SCNDereg message allows an
+- iSNS client to stop receiving State Change Notification (SCN)
+- messages.
+-
+- The SCNDereg request message PDU Payload contains a Source Attribute
+- and Message Key Attribute(s). Valid Message Key Attributes for a
+- SCNDereg are shown below:
+-
+- Valid Message Key Attributes for SCNDereg
+- -----------------------------------------
+- iSCSI Name
+- FC Port Name WWPN
+-
+- The node with an iSCSI Name or FC Port Name WWPN attribute that
+- matches the Message Key Attributes in the SCNDereg message is
+- deregistered for SCNs. The SCN bitmap field of such Nodes are
+- cleared. A maximum of one Node SHALL be deregistered for each
+- SCNDereg message.
+-
+- There are no Operating Attributes in the SCNDereg message.
+-
+-5.6.5.7. SCN Event (SCNEvent)
+-
+- The SCNEvent message type is 0x0007. The SCNEvent is a message sent
+- by an iSNS client to request generation of a State Change
+- Notification (SCN) message by the iSNS server. The SCN, sent by the
+- iSNS server, then notifies iFCP, iSCSI, and Control Nodes within the
+- affected DD of the change indicated in the SCNEvent.
+-
+- Most SCNs are automatically generated by the iSNS server when Nodes
+- are registered or deregistered from the directory database. SCNs are
+- also generated when a network management application or Control Node
+- makes changes to the DD membership in the iSNS server. However, an
+- iSNS client can trigger an SCN by using SCNEvent.
+-
+- The SCNEvent message PDU Payload contains a Source Attribute, a
+- Message Key Attribute, and an Operating Attribute. Valid Key
+- Attributes for a SCNEvent are shown below:
+-
+- Valid Message Key Attributes for SCNEvent
+- -----------------------------------------
+- iSCSI Name
+- FC Port Name WWPN
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 54]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- The Operating Attributes section SHALL contain the SCN Event Bitmap
+- attribute. The bitmap indicates the event that caused the SCNEvent
+- to be generated.
+-
+-5.6.5.8. State Change Notification (SCN)
+-
+- The SCN message type is 0x0008. The SCN is a message generated by
+- the iSNS server, notifying a registered Storage Node of changes.
+- There are two types of SCN registrations: regular registrations and
+- management registrations. Regular SCNs notify iSNS clients of events
+- within the discovery domain. Management SCNs notify Control Nodes
+- that register for management SCNs of events occurring anywhere in the
+- network.
+-
+- If no active TCP connection to the SCN recipient exists, then the SCN
+- message SHALL be sent to one Portal of the registered Storage Node
+- that has a registered TCP or UDP Port value in the SCN Port field.
+- If more than one Portal of the Storage Node has a registered SCN Port
+- value, then the SCN SHALL be delivered to any one of the indicated
+- Portals, provided that the selected Portal is not the subject of the
+- SCN.
+-
+- The types of events that can trigger an SCN message, and the amount
+- of information contained in the SCN message, depend on the registered
+- SCN Event Bitmap for the Storage Node. The iSCSI Node SCN Bitmap is
+- described in Section 6.4.4. The iFCP SCN Bitmap is described in
+- Section 6.6.12.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 55]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- The format of the SCN PDU Payload is shown below:
+-
+- +----------------------------------------+
+- | Destination Attribute |
+- +----------------------------------------+
+- | Timestamp |
+- +----------------------------------------+
+- | Source SCN Bitmap 1 |
+- +----------------------------------------+
+- | Source Attribute [1] |
+- +----------------------------------------+
+- | Source Attribute [2](if present) |
+- +----------------------------------------+
+- | Source Attribute [3](if present) |
+- +----------------------------------------+
+- | Source Attribute [n](if present) |
+- +----------------------------------------+
+- | Source SCN Bitmap 2 (if present) |
+- +----------------------------------------+
+- | . . . |
+- +----------------------------------------+
+-
+- All PDU Payload attributes are in TLV format.
+-
+- The Destination Attribute is the Node identifier that is receiving
+- the SCN. The Destination Attribute can be an iSCSI Name or FC Port
+- Name.
+-
+- The Timestamp field, using the Timestamp TLV format, described in
+- Section 6.2.4, indicates the time the SCN was generated.
+-
+- The Source SCN Bitmap field indicates the type of SCN notification
+- (i.e., regular or management SCN), and the type of event that caused
+- the SCN to be generated; it does not necessarily correlate with the
+- original SCN bitmap registered in the iSNS server.
+-
+- Following the timestamp, the SCN message SHALL list the SCN bitmap,
+- followed by the key attribute (i.e., iSCSI Name or FC Port Name) of
+- the Storage Node affected by the SCN event. If the SCN is a
+- Management SCN, then the SCN message SHALL also list the DD_ID and/or
+- DDS_ID of the Discovery Domains and Discovery Domain Sets (if any)
+- that caused the change in state for that Storage Node. These
+- additional attributes (i.e., DD_ID and/or DDS_ID) shall immediately
+- follow the iSCSI Name or FC Port Name and precede the next SCN bitmap
+- for the next notification message (if any). The SCN bitmap is used
+- as a delineator for SCN messages providing multiple state change
+- notifications.
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 56]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- For example, a regular SCN for notifying an iSNS client of a new
+- Portal available for a particular iSCSI target would contain the SCN
+- bitmap followed by the iSCSI Name of the target device as the source
+- attribute. If the SCN were a management SCN, then the iSCSI Name
+- would be followed by the DD_ID(s) of the shared Discovery Domains
+- that allow the destination Storage Node to have visibility to the
+- affected Storage Node. If a Discovery Domain Set (DDS) was enabled
+- in order to provide this visibility, then the appropriate DDS_ID
+- would be included as well.
+-
+- A management SCN is also generated to notify a Control Node of the
+- creation, deletion, or modification of a Discovery Domain or
+- Discovery Domain Set. In this case, the DD_ID and/or DDS_ID of the
+- affected Discovery Domain and/or Discovery Domain Set would follow
+- the SCN bitmap.
+-
+- For example, a management SCN to notify a Control Node of a new DD
+- within a Discovery Domain Set would contain both the DD_ID and the
+- DDS_ID of the affected Discovery Domain and Discovery Domain Set
+- among the Source Attributes.
+-
+- See Sections 6.4.4 and 6.6.12 for additional information on the SCN
+- Bitmap.
+-
+-5.6.5.9. DD Register (DDReg)
+-
+- The DDReg message type is 0x0009. This message is used to create a
+- new Discovery Domain (DD), to update an existing DD Symbolic Name
+- and/or DD Features attribute, and to add DD members.
+-
+- DDs are uniquely defined using DD_IDs. DD registration attributes
+- are described in Section 6.11.
+-
+- The DDReg message PDU Payload contains the Source Attribute and
+- optional Message Key and Operating Attributes.
+-
+- The Message Key, if used, contains the DD_ID of the Discovery Domain
+- to be registered. If the Message Key contains a DD_ID of an existing
+- DD entry in the iSNS database, then the DDReg message SHALL attempt
+- to update the existing entry. If the DD_ID in the Message Key (if
+- used) does not match an existing DD entry, then the iSNS server SHALL
+- reject the DDReg message with a status code of 3 (Invalid
+- Registration). If the DD_ID is included in both the Message Key and
+- Operating Attributes, then the DD_ID value in the Message Key MUST be
+- the same as the DD_ID value in the Operating Attributes.
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 57]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- A DDReg message with no Message Key SHALL result in the attempted
+- creation of a new Discovery Domain (DD). If the DD_ID attribute
+- (with non-zero length) is included among the Operating Attributes in
+- the DDReg message, then the new Discovery Domain SHALL be assigned
+- the value contained in that DD_ID attribute. Otherwise, if the DD_ID
+- attribute is not contained among the Operating Attributes of the
+- DDReg message, or if the DD_ID is an operating attribute with a TLV
+- length of 0, then the iSNS server SHALL assign a DD_ID value. The
+- assigned DD_ID value is then returned in the DDReg Response message.
+- The Operating Attributes can also contain the DD Member iSCSI Node
+- Index, DD Member iSCSI Name, DD Member FC Port Name, DD Member Portal
+- IP Address, DD Member Portal TCP/UDP Port Number, or DD Member Portal
+- Index of members to be added to the DD. It may also contain the
+- DD_Symbolic_Name and/or DD_Features of the DD.
+-
+- This message SHALL add any DD members listed as Operating Attributes
+- to the Discovery Domain specified by the DD_ID. If the DD_Features
+- attribute is an Operating Attribute, then it SHALL be stored in the
+- iSNS server as the feature list for the specified DD. If the
+- DD_Symbolic_Name is an operating attribute and its value is unique
+- (i.e., it does not match the registered DD_Symbolic_Name for another
+- DD), then the value SHALL be stored in the iSNS database as the
+- DD_Symbolic_Name for the specified Discovery Domain. If the value
+- for the DD_Symbolic_Name is not unique, then the iSNS server SHALL
+- reject the attempted DD registration with a status code of 3 (Invalid
+- Registration).
+-
+- When creating a new DD, if the DD_Symbolic_Name is not included in
+- the Operating Attributes, or if it is included with a zero-length
+- TLV, then the iSNS server SHALL provide a unique DD_Symbolic_Name
+- value for the created DD. The assigned DD_Symbolic_Name value SHALL
+- be returned in the DDRegRsp message.
+-
+- When creating a new DD, if the DD_Features attribute is not included
+- in the Operating Attributes, then the iSNS server SHALL assign the
+- default value. The default value for DD_Features is 0.
+-
+- DD Member iSCSI Name, DD Member iFCP Node, DD Member Portal IP
+- Address, and DD Member TCP/UDP Port Number attributes included in the
+- Operating Attributes need not match currently existing iSNS database
+- entries. This allows, for example, a Storage Node to be added to a
+- DD even if the Storage Node is not currently registered in the iSNS
+- database. A Storage Node or Portal can thereby be added to a DD at
+- the time of the DDs creation, even if the Storage Node or Portal is
+- not currently active in the storage network.
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 58]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- If the Operating Attributes contain a DD Member iSCSI Name value for
+- a Storage Node that is currently not registered in the iSNS database,
+- then the iSNS server MUST allocate an unused iSCSI Node Index for
+- that Storage Node. The assigned iSCSI Node Index SHALL be returned
+- in the DDRegRsp message as the DD Member iSCSI Node Index. The
+- allocated iSCSI Node Index value SHALL be assigned to the Storage
+- Node if and when it registers in the iSNS database.
+-
+- If the Operating Attributes contain a DD Member Portal IP Addr and DD
+- Member Portal TCP/UDP value for a Portal that is not currently
+- registered in the iSNS database, then the iSNS server MUST allocate
+- an unused Portal Index value for that Portal. The assigned Portal
+- Index value SHALL be returned in the DDRegRsp message as the DD
+- Member Portal Index. The allocated Portal Index value SHALL be
+- assigned to the Portal if and when it registers in the iSNS database.
+-
+- DD Member iSCSI Node Index and DD Member Portal Index attributes that
+- are provided in the Operating Attributes MUST match a corresponding
+- iSCSI Node Index or Portal Index of an existing Storage Node or
+- Portal entry in the iSNS database. Furthermore, the DD Member iSCSI
+- Node Index and DD Member Portal Index SHALL NOT be used to add
+- Storage Nodes or Portals to a DD unless those Storage Nodes or
+- Portals are actively registered in the iSNS database.
+-
+-5.6.5.10. DD Deregister (DDDereg)
+-
+- The DDDereg message type is 0x000A. This message allows an iSNS
+- client to deregister an existing Discovery Domain (DD) and to remove
+- members from an existing DD.
+-
+- DDs are uniquely identified using DD_IDs. DD registration attributes
+- are described in Section 6.11.
+-
+- The DDDereg message PDU Payload contains a Source Attribute, Message
+- Key Attribute, and optional Operating Attributes.
+-
+- The Message Key Attribute for a DDDereg message is the DD ID for the
+- Discovery Domain being removed or having members removed. If the DD
+- ID matches an existing DD and there are no Operating Attributes, then
+- the DD SHALL be removed and a success Status Code returned. Any
+- existing members of that DD SHALL remain in the iSNS database without
+- membership in the just-removed DD.
+-
+- If the DD ID matches an existing DD and there are Operating
+- Attributes matching DD members, then the DD members identified by the
+- Operating Attributes SHALL be removed from the DD and a successful
+- Status Code returned.
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 59]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- If a DD Member iSCSI Name identified in the Operating Attributes
+- contains an iSCSI Name for a Storage Node that is not currently
+- registered in the iSNS database or contained in another DD, then the
+- association between that Storage Node and its pre-assigned iSCSI Node
+- Index SHALL be removed. The pre-assigned iSCSI Node Index value no
+- longer has an association to a specific iSCSI Name and can now be
+- re-assigned.
+-
+- If a DD Member Portal IP Address and DD Member TCP/UDP Port
+- identified in the Operating Attributes reference a Portal that is not
+- currently registered in the iSNS database or contained in another DD,
+- then the association between that Portal and its pre-assigned Portal
+- Index SHALL be removed. The pre-assigned Portal Index value can now
+- be reassigned.
+-
+- The attempted deregistration of non-existent DD entries SHALL not be
+- considered an error.
+-
+-5.6.5.11. DDS Register (DDSReg)
+-
+- The DDSReg message type is 0x000B. This message allows an iSNS
+- client to create a new Discovery Domain Set (DDS), to update an
+- existing DDS Symbolic Name and/or DDS Status, or to add DDS members.
+-
+- DDSs are uniquely defined using DDS_IDs. DDS registration attributes
+- are described in Section 6.11.1.
+-
+- The DDSReg message PDU Payload contains the Source Attribute and,
+- optionally, Message Key and Operating Attributes.
+-
+- The Message Key, if used, contains the DDS_ID of the Discover Domain
+- Set to be registered or modified. If the Message Key contains a
+- DDS_ID of an existing DDS entry in the iSNS database, then the DDSReg
+- message SHALL attempt to update the existing entry. If the DDS_ID in
+- the Message Key (if used) does not match an existing DDS entry, then
+- the iSNS server SHALL reject the DDSReg message with a status code of
+- 3 (Invalid Registration). If the DDS_ID is included in both the
+- Message Key and Operating Attributes, then the DDS_ID value in the
+- Message Key MUST be the same as the DDS_ID value in the Operating
+- Attributes.
+-
+- A DDSReg message with no Message Key SHALL result in the attempted
+- creation of a new Discovery Domain Set (DDS). If the DDS_ID
+- attribute (with non-zero length) is included among the Operating
+- Attributes in the DDSReg message, then the new Discovery Domain Set
+- SHALL be assigned the value contained in that DDS_ID attribute.
+- Otherwise, if the DDS_ID attribute is not contained among the
+- Operating Attributes of the DDSReg message, or if the DDS_ID is an
+-
+-
+-
+-Tseng, et al. Standards Track [Page 60]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- operating attribute with a TLV length of 0, then the iSNS server
+- SHALL assign a DDS_ID value. The assigned DDS_ID value is then
+- returned in the DDSReg Response message. The Operating Attributes
+- can also contain the DDS_Symbolic_Name, the DDS Status, and the
+- DD_IDs of Discovery Domains to be added to the DDS.
+-
+- When creating a new DDS, if the DDS Symbolic Name is included in the
+- Operating Attributes and its value is unique (i.e., it does not match
+- the registered DDS Symbolic Name for another DDS), then the value
+- SHALL be stored in the iSNS database as the DDS Symbolic Name for
+- that DDS. If the value for the DDS Symbolic Name is not unique, then
+- the iSNS server SHALL reject the attempted DDS registration with a
+- status code of 3 (Invalid Registration).
+-
+- When creating a new DDS, if the DDS Symbolic Name is not included in
+- the Operating Attributes, or if it is included with a zero-length
+- TLV, then the iSNS server SHALL provide a unique DDS Symbolic Name
+- value for the created DDS. The assigned DDS Symbolic Name value
+- SHALL be returned in the DDSRegRsp message.
+-
+- This message SHALL add any DD_IDs listed as Operating Attributes to
+- the Discovery Domain Set specified by the DDS_ID Message Key
+- Attribute. In addition, if the DDS_Symbolic_Name is an operating
+- attribute and the value is unique, then it SHALL be stored in the
+- iSNS database as the DDS_Symbolic_Name for the specified Discovery
+- Domain Set.
+-
+- If a DD_ID listed in the Operating Attributes does not match an
+- existing DD, then a new DD using the DD_ID SHALL be created. In this
+- case for the new DD, the iSNS server SHALL assign a unique value for
+- the DD Symbolic Name and SHALL set the DD Features attribute to the
+- default value of 0. These assigned values SHALL be returned in the
+- DDSRegRsp message.
+-
+-5.6.5.12. DDS Deregister (DDSDereg)
+-
+- The DDSDereg message type is 0x000C. This message allows an iSNS
+- client to deregister an existing Discovery Domain Set (DDS) or to
+- remove some DDs from an existing DDS.
+-
+- The DDSDereg message PDU Payload contains a Source Attribute, a
+- Message Key Attribute, and optional Operating Attributes.
+-
+- The Message Key Attribute for a DDSDereg message is the DDS ID for
+- the DDS being removed or having members removed. If the DDS ID
+- matches an existing DDS and there are no Operating Attributes, then
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 61]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- the DDS SHALL be removed and a success Status Code returned. Any
+- existing members of that DDS SHALL remain in the iSNS database
+- without membership in the just-removed DDS.
+-
+- If the DDS ID matches an existing DDS, and there are Operating
+- Attributes matching DDS members, then the DDS members SHALL be
+- removed from the DDS and a success Status Code returned.
+-
+- The attempted deregistration of non-existent DDS entries SHALL not be
+- considered an error.
+-
+-5.6.5.13. Entity Status Inquiry (ESI)
+-
+- The ESI message type is 0x000D. This message is sent by the iSNS
+- server, and is used to verify that an iSNS client Portal is reachable
+- and available. The ESI message is sent to the ESI UDP port provided
+- during registration, or to the TCP connection used for ESI
+- registration, depending on which communication type that is being
+- used.
+-
+- The ESI message PDU Payload contains the following attributes in TLV
+- format and in the order listed: the current iSNS timestamp, the EID,
+- the Portal IP Address, and the Portal TCP/UDP Port. The format of
+- this message is shown below:
+-
+- +----------------------------------------+
+- | Timestamp |
+- +----------------------------------------+
+- | Entity_ID |
+- +----------------------------------------+
+- | Portal IP Address |
+- +----------------------------------------+
+- | Portal TCP/UDP Port |
+- +----------------------------------------+
+-
+- The ESI response message PDU Payload contains a status code, followed
+- by the Attributes from the original ESI message.
+-
+- If the Portal fails to respond to an administratively-determined
+- number of consecutive ESI messages, then the iSNS server SHALL remove
+- that Portal from the iSNS database. If there are no other remaining
+- ESI-monitored Portals for the associated Network Entity, then the
+- Network Entity SHALL also be removed. The appropriate State Change
+- Notifications, if any, SHALL be triggered.
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 62]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.6.5.14. Name Service Heartbeat (Heartbeat)
+-
+- This message, if used, is only sent by the active iSNS server. It
+- allows iSNS clients and backup servers listening to a broadcast or
+- multicast address to discover the IP address of the primary and
+- backup iSNS servers. It also allows concerned parties to monitor the
+- health and status of the primary iSNS server.
+-
+- This message is NOT in TLV format. There is no response message to
+- the Name Service Heartbeat.
+-
+- MSb LSb
+- 0 31
+- +------------------------------------------------+
+- | Active Server IP-Address | 16 Bytes
+- +------------------------------------------------+
+- | iSNS TCP Port | iSNS UDP Port | 4 Bytes
+- +------------------------------------------------+
+- | Interval | 4 Bytes
+- +------------------------------------------------+
+- | Counter | 4 Bytes
+- +------------------------------------------------+
+- | RESERVED | Backup Servers | 4 Bytes
+- +------------------------------------------------+
+- | Primary Backup Server IP Address(if any) | 16 Bytes
+- +------------------------------------------------+
+- |Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes
+- +------------------------------------------------+
+- | 2nd Backup Server IP Address(if any) | 16 Bytes
+- +------------------------------------------------+
+- |Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes
+- +------------------------------------------------+
+- | . . . |
+- +------------------------------------------------+
+- | VENDOR SPECIFIC |
+- +------------------------------------------------+
+-
+- The heartbeat PDU Payload contains the following:
+-
+- Active Server IP Address: the IP Address of the active iSNS server in
+- IPv6 format. When this field contains an IPv4
+- value, it is stored as an IPv4-mapped IPv6 address.
+- That is, the most significant 10 bytes are set to
+- 0x00, with the next two bytes set to 0xFFFF
+- [RFC2373]. When this field contains an IPv6 value,
+- the entire 16-byte field is used.
+-
+- Active TCP Port: the TCP Port of the server currently in use.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 63]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Active UDP Port: the UDP Port of the server currently in use,
+- otherwise 0.
+-
+- Interval: the interval, in seconds, of the heartbeat.
+-
+- Counter: a count that begins at 0 when this server becomes
+- active. The count increments by one for each
+- heartbeat sent since this server became active.
+-
+- Backup Servers: the number of iSNS backup servers. The IP address,
+- TCP Port, and UDP Port of each iSNS backup server
+- follow this field. Note that if backup servers are
+- used, then the active iSNS server SHOULD be among
+- the list of backup servers.
+-
+- The content of the remainder of this message after the list of backup
+- servers is vendor-specific. Vendors may use additional fields to
+- coordinate between multiple iSNS servers, and/or to identify vendor-
+- specific features.
+-
+-5.6.5.15. Request FC_DOMAIN_ID (RqstDomId)
+-
+- The RqstDomId message type is 0x0011. This message is used for iFCP
+- Transparent Mode to allocate non-overlapping FC_DOMAIN_ID values
+- between 1 and 239. The iSNS server becomes the address assignment
+- authority for the entire iFCP fabric. To obtain multiple
+- FC_DOMAIN_ID values, this request must be repeated to the iSNS server
+- multiple times. iSNS clients that acquire FC_DOMAIN_ID values from
+- an iSNS server MUST register for ESI monitoring from that iSNS
+- server.
+-
+- The RqstDomId PDU Payload contains three TLV attributes in the
+- following order: the requesting Switch Name (WWN) as the Source
+- Attribute, the Virtual_Fabric_ID as the Message Key Attribute, and
+- Preferred ID as the operating attribute. The Virtual_Fabric_ID is a
+- string identifying the domain space for which the iSNS server SHALL
+- allocate non-overlapping integer FC_DOMAIN_ID values between 1 and
+- 239. The Preferred_ID is the nominal FC_DOMAIN_ID value requested by
+- the iSNS client. If the Preferred_ID value is available and has not
+- already been allocated for the Virtual_Fabric_ID specified in the
+- message, the iSNS server SHALL return the requested Preferred_ID
+- value as the Assigned_ID to the requesting client.
+-
+- The RqstDomId response contains a Status Code, and the TLV attribute
+- Assigned ID, which contains the integer value in the space requested.
+- If no further unallocated values are available from this space, the
+- iSNS server SHALL respond with the Status Code 18 "FC_DOMAIN_ID Not
+- Available".
+-
+-
+-
+-Tseng, et al. Standards Track [Page 64]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Once a FC_DOMAIN_ID value has been allocated to an iSNS client by the
+- iSNS server for a given Virtual_Fabric_ID, that FC_DOMAIN_ID value
+- SHALL NOT be reused until it has been deallocated, or until ESI
+- monitoring detects that the iSNS client no longer exists on the
+- network and objects for that client are removed from the iSNS
+- database.
+-
+- The iSNS server and client SHALL use TCP to transmit and receive
+- RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
+-
+-5.6.5.16. Release FC_DOMAIN_ID (RlseDomId)
+-
+- The RlseDomId message type is 0x0012. This message may be used by
+- iFCP Transparent Mode to release integer identifier values used to
+- assign 3-byte Fibre Channel PORT_ID values.
+-
+- The RlseDomId message contains three TLV attributes in the following
+- order: the requesting EID as the Source Attribute, the
+- Virtual_Fabric_ID as the Message Key Attribute, and Assigned_ID as
+- the operating attribute. Upon receiving the RlseDomId message, the
+- iSNS server SHALL deallocate the FC_DOMAIN_ID value contained in the
+- Assigned_ID attribute for the Virtual_Fabric_ID attribute specified.
+- Upon deallocation, that FC_DOMAIN_ID value can then be requested by
+- and assigned to a different iSNS client.
+-
+- The iSNS server and client SHALL use TCP to transmit and receive
+- RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
+-
+-5.6.5.17. Get FC_DOMAIN_IDs (GetDomId)
+-
+- The GetDomId message type is 0x0013. This message is used to learn
+- the currently-allocated FC_DOMAIN_ID values for a given
+- Virtual_Fabric_ID.
+-
+- The GetDomId message PDU Payload contains a Source Attribute and
+- Message Key Attribute.
+-
+- The Message Key Attribute for the GetDomId message is the
+- Virtual_Fabric_ID. The response to this message returns all the
+- FC_DOMAIN_ID values that have been allocated for the
+- Virtual_Fabric_ID specified.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 65]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.7. Messages
+-
+- The iSNSP response message PDU Payloads contain a Status Code,
+- followed by a list of attributes, and have the following format:
+-
+- MSb LSb
+- 0 31
+- +----------------------------------------+
+- | 4-byte STATUS CODE |
+- +----------------------------------------+
+- | Message Key Attribute[1] (if present) |
+- +----------------------------------------+
+- | Message Key Attribute[2] (if present) |
+- +----------------------------------------+
+- | . . . |
+- +----------------------------------------+
+- | - Delimiter Attribute - (if present) |
+- +----------------------------------------+
+- | Operating Attribute[1] (if present) |
+- +----------------------------------------+
+- | Operating Attribute[2] (if present) |
+- +----------------------------------------+
+- | Operating Attribute[3] (if present) |
+- +----------------------------------------+
+- | . . . |
+- +----------------------------------------+
+-
+- The iSNSP Response messages SHALL be sent to the iSNS Client IP
+- Address and the originating TCP/UDP Port that was used for the
+- associated registration and query message.
+-
+-5.7.1. Status Code
+-
+- The first field in an iSNSP response message PDU Payload is the
+- Status Code for the operation that was performed. The Status Code
+- encoding is defined in Section 5.4.
+-
+-5.7.2. Message Key Attributes in Response
+-
+- Depending on the specific iSNSP request, the response message MAY
+- contain Message Key Attributes. Message Key Attributes generally
+- contain the interesting key attributes that are affected by the
+- operation specified in the original iSNS registration or query
+- message.
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 66]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.7.3. Delimiter Attribute in Response
+-
+- The Delimiter Attribute separates the key and Operating Attributes in
+- a response message, if they exist. The Delimiter Attribute has a tag
+- value of 0 and a length value of 0. The Delimiter Attribute is
+- effectively 8 bytes long: a 4-byte tag containing 0x00000000, and a 4
+- Byte length field containing 0x00000000.
+-
+-5.7.4. Operating Attributes in Response
+-
+- The Operating Attributes in a response are the results related to the
+- iSNS registration or query operation being performed. Some response
+- messages will not have Operating Attributes.
+-
+-5.7.5. Registration and Query Response Message Types
+-
+- The following sections describe each query and message type.
+-
+-5.7.5.1. Device Attribute Registration Response (DevAttrRegRsp)
+-
+- The DevAttrRegRsp message type is 0x8001. The DevAttrRegRsp message
+- contains the results for the DevAttrReg message with the same
+- TRANSACTION ID.
+-
+- The Message Key in the DevAttrRegRsp message SHALL return the Message
+- Key in the original registration message. If the iSNS server
+- assigned the Entity Identifier for a Network Entity, then the Message
+- Key Attribute field SHALL contain the assigned Entity Identifier.
+-
+- The Operating Attributes of the DevAttrRegRsp message SHALL contain
+- the affected object's key and non-key attributes that have been
+- explicitly modified or created by the original DevAttrReg message.
+- Among the Operating Attributes, each modified or added non-key
+- attribute SHALL be listed after its key attribute(s) in the
+- DevAttrRegRsp message. Implicitly registered attributes MUST NOT be
+- returned in the DevAttrRegRsp message. Implicitly registered
+- attributes are those that are assigned a fixed default value or
+- secondary index value by the iSNS server.
+-
+- Implicitly registered PG objects (i.e., PG objects that are not
+- explicitly included in the registration or replace message) MUST NOT
+- have their key or non-key attributes returned in the DevAttrRegRsp
+- message. However, explicitly registered PG objects (i.e., those with
+- PGT values that are explicitly included in the registration or
+- replace message) SHALL have their PGT values returned in the
+- DevAttrRegRsp message.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 67]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- For example, three Portals are registered in the original DevAttrReg
+- request message. Due to lack of resources, the iSNS server needs to
+- modify the registered ESI Interval value of one of those Portals. To
+- accomplish this, the iSNS server returns the key attributes
+- identifying the Portal, followed by the non-key modified ESI Interval
+- attribute value, as Operating Attributes of the corresponding
+- DevAttrRegRsp message.
+-
+- If the iSNS server rejects a registration due to invalid attribute
+- values or types, then the indicated status code SHALL be 3 (Invalid
+- Registration). If this occurs, then the iSNS server MAY include the
+- list of invalid attributes in the Operating Attributes of the
+- DevAttrRsp message.
+-
+- Some attributes values (e.g., ESI Interval, Registration Period) in
+- the original registration message MAY be modified by the iSNS server.
+- This can occur only for a limited set of attribute types, as
+- indicated in the table in Section 6.1. When this occurs, the
+- registration SHALL be considered a success (with status code 0), and
+- the changed value(s) indicated in the Operating Attributes of the
+- DevAttrRsp message.
+-
+-5.7.5.2. Device Attribute Query Response (DevAttrQryRsp)
+-
+- The DevAttrQryRsp message type is 0x8002. The DevAttrQryRsp message
+- contains the results for the DevAttrQry message with the same
+- TRANSACTION ID.
+-
+- The Message Key in the DevAttrQryRsp message SHALL return the Message
+- Key in the original query message.
+-
+- If no Operating Attributes are included in the original query, then
+- all Operating Attributes SHALL be returned in the response.
+-
+- For a successful query result, the DevAttrQryRsp Operating Attributes
+- SHALL contain the results of the original DevAttrQry message.
+-
+-5.7.5.3. Device Get Next Response (DevGetNextRsp)
+-
+- The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message
+- contains the results for the DevGetNext message with the same
+- TRANSACTION ID.
+-
+- The Message Key Attribute field returns the object keys for the next
+- object after the Message Key Attribute in the original DevGetNext
+- message.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 68]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- The Operating Attribute field returns the Operating Attributes of the
+- next object as requested in the original DevGetNext message. The
+- values of the Operating Attributes are those associated with the
+- object identified by the Message Key Attribute field of the
+- DevGetNextRsp message.
+-
+-5.7.5.4. Deregister Device Response (DevDeregRsp)
+-
+- The DevDeregRsp message type is 0x8004. This message is the response
+- to the DevDereg request message.
+-
+- This message response does not contain a Message Key, but MAY contain
+- Operating Attributes.
+-
+- In the event of an error, this response message contains the
+- appropriate status code as well as a list of objects from the
+- original DevDereg message that were not successfully deregistered
+- from the iSNS database. This list of objects is contained in the
+- Operating Attributes of the DevDeregRsp message. Note that an
+- attempted deregistration of a non-existent object does not constitute
+- an error, and non-existent entries SHALL not be returned in the
+- DevDeregRsp message.
+-
+-5.7.5.5. SCN Register Response (SCNRegRsp)
+-
+- The SCNRegRsp message type is 0x8005. This message is the response
+- to the SCNReg request message.
+-
+- The SCNRegRsp message does not contain any Message Key or Operating
+- Attributes.
+-
+-5.7.5.6. SCN Deregister Response (SCNDeregRsp)
+-
+- The SCNDeregRsp message type is 0x8006. This message is the response
+- to the SCNDereg request message.
+-
+- The SCNDeregRsp message does not contain any Message Key or Operating
+- Attributes.
+-
+-5.7.5.7. SCN Event Response (SCNEventRsp)
+-
+- The SCNEventRsp message type is 0x8007. This message is the response
+- to the SCNEvent request message.
+-
+- The SCNEventRsp message does not contain any Message Key or Operating
+- Attributes.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 69]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.7.5.8. SCN Response (SCNRsp)
+-
+- The SCNRsp message type is 0x8008. This message is sent by an iSNS
+- client, and provides confirmation that the SCN message was received
+- and processed.
+-
+- The SCNRsp response contains the SCN Destination Attribute
+- representing the Node identifier that received the SCN.
+-
+-5.7.5.9. DD Register Response (DDRegRsp)
+-
+- The DDRegRsp message type is 0x8009. This message is the response to
+- the DDReg request message.
+-
+- The Message Key in the DDRegRsp message SHALL return the Message Key
+- in the original query message. If the original DDReg message did not
+- have a Message Key, then the DDRegRsp message SHALL not have a
+- Message Key.
+-
+- If the DDReg operation is successful, the DD ID of the DD created or
+- updated SHALL be returned as an operating attribute of the message.
+-
+- If the DD Symbolic Name attribute or DD Features attribute was
+- assigned or updated during the DDReg operation, then any new values
+- SHALL be returned as an operating attribute of the DDRegRsp message.
+-
+- If the iSNS server rejects a DDReg due to invalid attribute values or
+- types, then the indicated status code SHALL be 3 (Invalid
+- Registration). If this occurs, then the iSNS server MAY include the
+- list of invalid attributes in the Operating Attributes of the
+- DDRegRsp message.
+-
+-5.7.5.10. DD Deregister Response (DDDeregRsp)
+-
+- The DDDeregRsp message type is 0x800A. This message is the response
+- to the DDDereg request message.
+-
+- The DDDeregRsp message does not contain any Message Key or Operating
+- Attributes.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 70]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.7.5.11. DDS Register Response (DDSRegRsp)
+-
+- The DDSRegRsp message type is 0x800B. This message is the response
+- to the DDSReg request message.
+-
+- The Message Key in the DDSRegRsp message SHALL contain the Message
+- Key of the original DDSReg message. If the original DDSReg message
+- did not have a Message Key, then the DDSRegRsp message SHALL NOT have
+- a Message Key.
+-
+- If the DDSReg operation is successful, the DDS ID of the DDS created
+- or updated SHALL be returned as an operating attribute of the
+- message.
+-
+- If the DDS Symbolic Name attribute or DDS Status attribute was
+- assigned or updated during the DDSRegRsp operation, then any new
+- values SHALL be returned as an operating attribute of the DDSRegRsp
+- message.
+-
+- If the iSNS server rejects a DDSReg due to invalid attribute values
+- or types, then the indicated status code SHALL be 3 (Invalid
+- Registration). If this occurs, then the iSNS server MAY include the
+- list of invalid attributes in the Operating Attributes of the
+- DDSRegRsp message.
+-
+-5.7.5.12. DDS Deregister Response (DDSDeregRsp)
+-
+- The DDSDeregRsp message type is 0x800C. This message is the response
+- to the DDSDereg request message.
+-
+- The DDSDeregRsp message does not contain any Message Key or Operating
+- Attributes.
+-
+-5.7.5.13. Entity Status Inquiry Response (ESIRsp)
+-
+- The ESIRsp message type is 0x800D. This message is sent by an iSNS
+- client and provides confirmation that the ESI message was received
+- and processed.
+-
+- The ESIRsp response message PDU Payload contains the attributes from
+- the original ESI message. These attributes represent the Portal that
+- is responding to the ESI. The ESIRsp Attributes are in the order
+- they were provided in the original ESI message.
+-
+- Upon receiving the ESIRsp from the iSNS client, the iSNS server SHALL
+- update the timestamp attribute for that Network Entity and Portal.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 71]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-5.7.5.14. Request FC_DOMAIN_ID Response (RqstDomIdRsp)
+-
+- The RqstDomIdRsp message type is 0x8011. This message provides the
+- response for RqstDomId.
+-
+- The RqstDomId response contains a Status Code and the TLV attribute
+- Assigned ID, which contains the integer value in the space requested.
+- If no further unallocated values are available from this space, the
+- iSNS server SHALL respond with the Status Code 19 "FC_DOMAIN_ID Not
+- Available".
+-
+- Once a FC_DOMAIN_ID value is allocated by the iSNS server, it SHALL
+- NOT be reused until it has been deallocated by the iSNS client to
+- which the value was assigned, or until the ESI message detects that
+- the iSNS client no longer exists on the network.
+-
+- The iSNS server and client SHALL use TCP to transmit and receive
+- RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
+-
+-5.7.5.15. Release FC_DOMAIN_ID Response (RlseDomIdRsp)
+-
+- The RlseDomIdRsp message type is 0x8012. This message provides the
+- response for RlseDomId. The response contains an Error indicating
+- whether the request was successful. If the Assigned_ID value in the
+- original RlseDomId message is not allocated, then the iSNS server
+- SHALL respond with this message using the Status Code 20
+- "FC_DOMAIN_ID Not Allocated".
+-
+- The iSNS server and client SHALL use TCP to transmit and receive
+- RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
+-
+-5.7.5.16. Get FC_DOMAIN_IDs Response (GetDomIdRsp)
+-
+- The GetDomIdRsp message type is 0x8013. This message is used to
+- determine which FC_DOMAIN_ID values have been allocated for the
+- Virtual_Fabric_ID specified in the original GetDomId request message.
+-
+- The GetDomId response message PDU Payload contains a Status Code
+- indicating whether the request was successful, and a list of the
+- Assigned IDs from the space requested. The Assigned_ID attributes
+- are listed in TLV format.
+-
+-5.8. Vendor-Specific Messages
+-
+- Vendor-specific iSNSP messages have a functional ID of between 0x0100
+- and 0x01FF, whereas vendor-specific responses have a functional ID of
+- between 0x8100 and 0x81FF. The first Message Key Attribute in a
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 72]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- vendor-specific message SHALL be the company OUI (tag=256)
+- identifying the original creator of the proprietary iSNSP message.
+- The contents of the remainder of the message are vendor-specific.
+-
+-6. iSNS Attributes
+-
+- Attributes can be stored in the iSNS server using iSNSP registration
+- messages, and they can be retrieved using iSNSP query messages.
+- Unless otherwise indicated, these attributes are supplied by iSNS
+- clients using iSNSP registration messages.
+-
+-6.1. iSNS Attribute Summary
+-
+- The complete registry of iSNS attributes is maintained by IANA, and
+- the following table summarizes the initial set of iSNS attributes
+- available at the time of publication of this document.
+-
+- Attributes Length Tag Reg Key Query Key
+- ---------- ------ --- ------- ---------
+- Delimiter 0 0 N/A N/A
+- Entity Identifier (EID) 4-256 1 1 1|2|16&17|32|64
+- Entity Protocol 4 2 1 1|2|16&17|32|64
+- Management IP Address 16 3 1 1|2|16&17|32|64
+- Timestamp 8 4 -- 1|2|16&17|32|64
+- Protocol Version Range 4 5 1 1|2|16&17|32|64
+- Registration Period 4 6 1 1|2|16&17|32|64
+- Entity Index 4 7 1 1|2|16&17|32|64
+- Entity Next Index 4 8 -- 1|2|16&17|32|64
+- Entity ISAKMP Phase-1 var 11 1 1|2|16&17|32|64
+- Entity Certificate var 12 1 1|2|16&17|32|64
+- Portal IP Address 16 16 1 1|16&17|32|64
+- Portal TCP/UDP Port 4 17 1 1|16&17|32|64
+- Portal Symbolic Name 4-256 18 16&17 1|16&17|32|64
+- ESI Interval 4 19 16&17 1|16&17|32|64
+- ESI Port 4 20 16&17 1|16&17|32|64
+- Portal Index 4 22 16&17 1|16&17|32|64
+- SCN Port 4 23 16&17 1|16&17|32|64
+- Portal Next Index 4 24 -- 1|16&17|32|64
+- Portal Security Bitmap 4 27 16&17 1|16&17|32|64
+- Portal ISAKMP Phase-1 var 28 16&17 1|16&17|32|64
+- Portal ISAKMP Phase-2 var 29 16&17 1|16&17|32|64
+- Portal Certificate var 31 16&17 1|16&17|32|64
+- iSCSI Name 4-224 32 1 1|16&17|32|33
+- iSCSI Node Type 4 33 32 1|16&17|32
+- iSCSI Alias 4-256 34 32 1|16&17|32
+- iSCSI SCN Bitmap 4 35 32 1|16&17|32
+- iSCSI Node Index 4 36 32 1|16&17|32
+- WWNN Token 8 37 32 1|16&17|32
+-
+-
+-
+-Tseng, et al. Standards Track [Page 73]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- iSCSI Node Next Index 4 38 -- 1|16&17|32
+- iSCSI AuthMethod var 42 32 1|16&17|32
+- PG iSCSI Name 4-224 48 32|16&17 1|16&17|32|52
+- PG Portal IP Addr 16 49 32|16&17 1|16&17|32|52
+- PG Portal TCP/UDP Port 4 50 32|16&17 1|16&17|32|52
+- PG Tag (PGT) 4 51 32|16&17 1|16&17|32|52
+- PG Index 4 52 32|16&17 1|16&17|32|52
+- PG Next Index 4 53 -- 1|16&17|32|52
+- FC Port Name WWPN 8 64 1 1|16&17|64|66|96|128
+- Port ID 4 65 64 1|16&17|64
+- FC Port Type 4 66 64 1|16&17|64
+- Symbolic Port Name 4-256 67 64 1|16&17|64
+- Fabric Port Name 8 68 64 1|16&17|64
+- Hard Address 4 69 64 1|16&17|64
+- Port IP-Address 16 70 64 1|16&17|64
+- Class of Service 4 71 64 1|16&17|64
+- FC-4 Types 32 72 64 1|16&17|64
+- FC-4 Descriptor 4-256 73 64 1|16&17|64
+- FC-4 Features 128 74 64 1|16&17|64
+- iFCP SCN bitmap 4 75 64 1|16&17|64
+- Port Role 4 76 64 1|16&17|64
+- Permanent Port Name 8 77 -- 1|16&17|64
+- FC-4 Type Code 4 95 -- 1|16&17|64
+- FC Node Name WWNN 8 96 64 1|16&17|64|96
+- Symbolic Node Name 4-256 97 96 64|96
+- Node IP-Address 16 98 96 64|96
+- Node IPA 8 99 96 64|96
+- Proxy iSCSI Name 4-256 101 96 64|96
+- Switch Name 8 128 128 128
+- Preferred ID 4 129 128 128
+- Assigned ID 4 130 128 128
+- Virtual_Fabric_ID 4-256 131 128 128
+- iSNS Server Vendor OUI 4 256 -- SOURCE Attribute
+- Vendor-Spec iSNS Srvr 257-384 -- SOURCE Attribute
+- Vendor-Spec Entity 385-512 1 1|2|16&17|32|64
+- Vendor-Spec Portal 513-640 16&17 1|16&17|32|64
+- Vendor-Spec iSCSI Node 641-768 32 16&17|32
+- Vendor-Spec FC Port Name 769-896 64 1|16&17|64
+- Vendor-Spec FC Node Name 897-1024 96 64|96
+- Vendor-Specific DDS 1025-1280 2049 2049
+- Vendor-Specific DD 1281-1536 2065 2065
+- Other Vendor-Specific 1537-2048
+- DD_Set ID 4 2049 2049 1|32|64|2049|2065
+- DD_Set Sym Name 4-256 2050 2049 2049
+- DD_Set Status 4 2051 2049 2049
+- DD_Set_Next_ID 4 2052 -- 2049
+- DD_ID 4 2065 2049 1|32|64|2049|2065
+- DD_Symbolic Name 4-256 2066 2065 2065
+-
+-
+-
+-Tseng, et al. Standards Track [Page 74]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- DD_Member iSCSI Index 4 2067 2065 2065
+- DD_Member iSCSI Name 4-224 2068 2065 2065
+- DD_Member FC Port Name 8 2069 2065 2065
+- DD_Member Portal Index 4 2070 2065 2065
+- DD_Member Portal IP Addr 16 2071 2065 2065
+- DD_Member Portal TCP/UDP 4 2072 2065 2065
+- DD_Features 4 2078 2065 2065
+- DD_ID Next ID 4 2079 -- 2065
+-
+- The following are descriptions of the columns used in the above
+- table:
+-
+- Length: indicates the attribute length in bytes used for the TLV
+- format. Variable-length identifiers are NULL-terminated
+- and 4-byte aligned (NULLs are included in the length).
+-
+- Tag: the IANA-assigned integer tag value used to identify the
+- attribute. All undefined tag values are reserved.
+-
+- Reg Key: indicates the tag values for the object key in DevAttrReg
+- messages for registering a new attribute value in the
+- database. These tags represent attributes defined as
+- object keys in Section 4.
+-
+- Query Key: indicates the possible tag values for the Message Key and
+- object key that are used in the DevAttrQry messages for
+- retrieving a stored value from the iSNS database.
+-
+- The following is a summary of iSNS attribute tag values available for
+- future allocation by IANA at the time of publication:
+-
+- Tag Values Reg Key Query Key
+- ---------- ------- ---------
+- 9-10, 13-15 1 1|2|16&17|32|64
+- 21, 25-26, 30 16&17 1|16&17|32|64
+- 39-41, 44-47 32 1|16&17|32
+- 54-63 32|16&17 1|16&17|32|52
+- 78-82, 85-94 64 1|16&17|64
+- 102-127 96 64|96
+- 132-255 -- SOURCE Attribute
+- 2053-2064 2049 2049
+- 2073-2077 2065 2065
+- 2080-65535 To be assigned To be assigned
+-
+- Registration and query keys for attributes with tags in the range
+- 2080 to 65535 are to be documented in the RFC introducing the new
+- iSNS attributes. IANA will maintain registration of these values as
+- required by the new RFC.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 75]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- New iSNS attributes with any of the above tag values MAY also be
+- designated as "read-only" attributes. The new RFC introducing these
+- attributes as "read-only" SHALL document them as such, and IANA will
+- record their corresponding Registration Keys (Reg Keys) as "--".
+-
+-6.2. Entity Identifier-Keyed Attributes
+-
+- The following attributes are stored in the iSNS server using the
+- Entity Identifier attribute as the key.
+-
+-6.2.1. Entity Identifier (EID)
+-
+- The Entity Identifier (EID) is variable-length UTF-8 encoded NULL-
+- terminated text-based description for a Network Entity. This key
+- attribute uniquely identifies each Network Entity registered in the
+- iSNS server. The attribute length varies from 4 to 256 bytes
+- (including the NULL termination), and is a unique value within the
+- iSNS server.
+-
+- If the iSNS client does not provide an EID during registration, the
+- iSNS server SHALL generate one that is unique within the iSNS
+- database. If an EID is to be generated, then the EID attribute value
+- in the registration message SHALL be empty (0 length). The generated
+- EID SHALL be returned in the registration response.
+-
+- In environments where the iSNS server is integrated with a DNS
+- infrastructure, the Entity Identifier may be used to store the Fully
+- Qualified Domain Name (FQDN) of the iSCSI or iFCP device. FQDNs of
+- greater than 255 bytes MUST NOT be used.
+-
+- If FQDNs are not used, the iSNS server can be used to generate EIDs.
+- EIDs generated by the iSNS server MUST begin with the string "isns:".
+- iSNS clients MUST NOT generate and register EIDs beginning with the
+- string "isns:".
+-
+- This field MUST be normalized according to the nameprep template
+- [NAMEPREP] before it is stored in the iSNS database.
+-
+-6.2.2. Entity Protocol
+-
+- The Entity Protocol is a required 4-byte integer attribute that
+- indicates the block storage protocol used by the registered NETWORK
+- ENTITY. Values used for this attribute are assigned and maintained
+- by IANA. The initial set of protocols supported by iSNS is as
+- follows:
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 76]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Value Entity Protocol Type
+- ----- --------------------
+- 1 No Protocol
+- 2 iSCSI
+- 3 iFCP
+- All others To be assigned by IANA
+-
+- 'No Protocol' is used to indicate that the Network Entity does not
+- support an IP block storage protocol. A Control Node or monitoring
+- Node would likely (but not necessarily) use this value.
+-
+- This attribute is required during initial registration of the Network
+- Entity.
+-
+-6.2.3. Management IP Address
+-
+- This field contains the IP Address that may be used to manage the
+- Network Entity and all Storage Nodes contained therein via the iSNS
+- MIB [iSNSMIB]. Some implementations may also use this IP address to
+- support vendor-specific proprietary management protocols. The
+- Management IP Address is a 16-byte field that may contain an IPv4 or
+- IPv6 address. When this field contains an IPv4 value, it is stored
+- as an IPv4-mapped IPv6 address. That is, the most significant 10
+- bytes are set to 0x00, with the next two bytes set to 0xFFFF
+- [RFC2373]. When this field contains an IPv6 value, the entire 16-
+- byte field is used. If this field is not set, then in-band
+- management through the IP address of one of the Portals of the
+- Network Entity is assumed.
+-
+-6.2.4. Entity Registration Timestamp
+-
+- This field indicates the most recent time when the Network Entity
+- registration occurred or when an associated object attribute was
+- updated or queried by the iSNS client registering the Network Entity.
+- The time format is, in seconds, the update period since the standard
+- base time of 00:00:00 GMT on January 1, 1970. This field cannot be
+- explicitly registered. This timestamp TLV format is also used in the
+- SCN and ESI messages.
+-
+-6.2.5. Protocol Version Range
+-
+- This field contains the minimum and maximum version of the block
+- storage protocol supported by the Network Entity. The most
+- significant two bytes contain the maximum version supported, and the
+- least significant two bytes contain the minimum version supported.
+- If a range is not registered, then the Network Entity is assumed to
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 77]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- support all versions of the protocol. The value 0xffff is a wildcard
+- that indicates no minimum or maximum. If the Network Entity does not
+- support a protocol, then this field SHALL be set to 0.
+-
+-6.2.6. Registration Period
+-
+- This 4-byte unsigned integer field indicates the maximum period, in
+- seconds, that the registration SHALL be maintained by the server
+- without receipt of an iSNS message from the iSNS client that
+- registered the Network Entity. Entities that are not registered for
+- ESI monitoring MUST have a non-zero Registration Period. If a
+- Registration Period is not requested by the iSNS client and Entity
+- Status Inquiry (ESI) messages are not enabled for that client, then
+- the Registration Period SHALL be set to a non-zero value by the iSNS
+- server. This implementation-specific value for the Registration
+- Period SHALL be returned in the registration response to the iSNS
+- client. The Registration Period may be set to zero, indicating its
+- non-use, only if ESI messages are enabled for that Network Entity.
+-
+- The registration SHALL be removed from the iSNS database if an iSNS
+- Protocol message is not received from the iSNS client before the
+- registration period has expired. Receipt of any iSNS Protocol
+- message from the iSNS client automatically refreshes the Entity
+- Registration Period and Entity Registration Timestamp. To prevent a
+- registration from expiring, the iSNS client should send an iSNS
+- Protocol message to the iSNS server at intervals shorter than the
+- registration period. Such a message can be as simple as a query for
+- one of its own attributes, using its associated iSCSI Name or FC Port
+- Name WWPN as the Source attribute.
+-
+- For an iSNS client that is supporting a Network Entity with multiple
+- Storage Node objects, receipt of an iSNS message from any Storage
+- Node of that Network Entity is sufficient to refresh the registration
+- for all Storage Node objects of the Network Entity.
+-
+- If ESI support is requested as part of a Portal registration, the ESI
+- Response message received from the iSNS client by the iSNS server
+- SHALL refresh the registration.
+-
+-6.2.7. Entity Index
+-
+- The Entity Index is an unsigned non-zero integer value that uniquely
+- identifies each Network Entity registered in the iSNS server. Upon
+- initial registration of a Network Entity, the iSNS server assigns an
+- unused value for the Entity Index. Each Network Entity in the iSNS
+- database MUST be assigned a value for the Entity Index that is not
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 78]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- assigned to any other Network Entity. Furthermore, Entity Index
+- values for recently deregistered Network Entities SHOULD NOT be
+- reused in the short term.
+-
+- The Entity Index MAY be used to represent the Network Entity in
+- situations when the Entity Identifier is too long or otherwise
+- inappropriate. An example of this is when SNMP is used for
+- management, as described in Section 2.10.
+-
+-6.2.8. Entity Next Index
+-
+- This is a virtual attribute containing a 4-byte integer value that
+- indicates the next available (i.e., unused) Entity Index value. This
+- attribute may only be queried; the iSNS server SHALL return an error
+- code of 3 (Invalid Registration) to any client that attempts to
+- register a value for this attribute. A Message Key is not required
+- when exclusively querying for this attribute.
+-
+- The Entity Next Index MAY be used by an SNMP client to create an
+- entry in the iSNS server. SNMP requirements are described in Section
+- 2.10.
+-
+-6.2.9. Entity ISAKMP Phase-1 Proposals
+-
+- This field contains the IKE Phase-1 proposal, listing in decreasing
+- order of preference the protection suites acceptable to protect all
+- IKE Phase-2 messages sent and received by the Network Entity. This
+- includes Phase-2 SAs from the iSNS client to the iSNS server as well
+- as to peer iFCP and/or iSCSI devices. This attribute contains the SA
+- payload, proposal payload(s), and transform payload(s) in the ISAKMP
+- format defined in [RFC2408].
+-
+- This field should be used if the implementer wishes to define a
+- single phase-1 SA security configuration used to protect all phase-2
+- IKE traffic. If the implementer desires to have a different phase-1
+- SA security configuration to protect each Portal interface, then the
+- Portal Phase-1 Proposal (Section 6.3.10) should be used.
+-
+-6.2.10. Entity Certificate
+-
+- This attribute contains one or more X.509 certificates that are bound
+- to the Network Entity. This certificate is uploaded and registered
+- to the iSNS server by clients wishing to allow other clients to
+- authenticate themselves and to access the services offered by that
+- Network Entity. The format of the X.509 certificate is found in
+- [RFC3280]. This certificate MUST contain a Subject Name with an
+- empty sequence and MUST contain a SubjectAltName extension encoded
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 79]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- with the dNSName type. The Entity Identifier (Section 6.2.1) of the
+- identified Entity MUST be stored in the SubjectAltName field of the
+- certificate.
+-
+-6.3. Portal-Keyed Attributes
+-
+- The following Portal attributes are registered in the iSNS database
+- using the combined Portal IP-Address and Portal TCP/UDP Port as the
+- key. Each Portal is associated with one Entity Identifier object
+- key.
+-
+-6.3.1. Portal IP Address
+-
+- This attribute is the IP address of the Portal through which a
+- Storage Node can transmit and receive storage data. The Portal IP
+- Address is a 16-byte field that may contain an IPv4 or IPv6 address.
+- When this field contains an IPv4 address, it is stored as an IPv4-
+- mapped IPv6 address. That is, the most significant 10 bytes are set
+- to 0x00, with the next 2 bytes set to 0xFFFF [RFC2373]. When this
+- field contains an IPv6 address, the entire 16-byte field is used.
+- The Portal IP Address and the Portal TCP/UDP Port number (see 6.3.2
+- below) are used as a key to identify a Portal uniquely. It is a
+- required attribute for registration of a Portal.
+-
+-6.3.2. Portal TCP/UDP Port
+-
+- The TCP/UDP port of the Portal through which a Storage Node can
+- transmit and receive storage data. Bits 16 to 31 represents the
+- TCP/UDP port number. Bit 15 represents the port type. If bit 15 is
+- set, then the port type is UDP. Otherwise it is TCP. Bits 0 to 14
+- are reserved.
+-
+- If the field value is 0, then the port number is the implied
+- canonical port number and type of the protocol indicated by the
+- associated Entity Type.
+-
+- The Portal IP Address and the Portal TCP/UDP Port number are used as
+- a key to identify a Portal uniquely. It is a required attribute for
+- registration of a Portal.
+-
+-6.3.3. Portal Symbolic Name
+-
+- A variable-length UTF-8 encoded NULL-terminated text-based
+- description of up to 256 bytes. The Portal Symbolic Name is a user-
+- readable description of the Portal entry in the iSNS server.
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 80]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.3.4. Entity Status Inquiry Interval
+-
+- This field indicates the requested time, in seconds, between Entity
+- Status Inquiry (ESI) messages sent from the iSNS server to this
+- Network Entity. ESI messages can be used to verify that a Portal
+- registration continues to be valid. To request monitoring by the
+- iSNS server, an iSNS client registers a non-zero value for this
+- Portal attribute using a DevAttrReg message. The client MUST
+- register an ESI Port on at least one of its Portals to receive the
+- ESI monitoring.
+-
+- If the iSNS server does not receive an expected response to an ESI
+- message, it SHALL attempt an administratively configured number of
+- re-transmissions of the ESI message. The ESI Interval period begins
+- with the iSNS server's receipt of the last ESI Response. All re-
+- transmissions MUST be sent before twice the ESI Interval period has
+- passed. If no response is received from any of the ESI messages,
+- then the Portal SHALL be deregistered. Note that only Portals that
+- have registered a value in their ESI Port field can be deregistered
+- in this way.
+-
+- If all Portals associated with a Network Entity that have registered
+- for ESI messages are deregistered due to non-response, and if no
+- registrations have been received from the client for at least two ESI
+- Interval periods, then the Network Entity and all associated objects
+- (including Storage Nodes) SHALL be deregistered.
+-
+- If the iSNS server is unable to support ESI messages or the ESI
+- Interval requested, it SHALL either reject the ESI request by
+- returning an "ESI Not Available" Status Code or modify the ESI
+- Interval attribute by selecting its own suitable value and returning
+- that value in the Operating Attributes of the registration response
+- message.
+-
+- If at any time an iSNS client that is registered for ESI messages has
+- not received an ESI message to any of its Portals as expected, then
+- the client MAY attempt to query the iSNS server using a DevAttrQry
+- message using its Entity_ID as the key. If the query result is the
+- error "no such entry", then the client SHALL close all remaining TCP
+- connections to the iSNS server and assume that it is no longer
+- registered in the iSNS database. Such a client MAY attempt re-
+- registration.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 81]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.3.5. ESI Port
+-
+- This field contains the TCP or UDP port used for ESI monitoring by
+- the iSNS server at the Portal IP Address. Bits 16 to 31 represent
+- the port number. If bit 15 is set, then the port type is UDP.
+- Otherwise, the port is TCP. Bits 0 to 14 are reserved.
+-
+- If the iSNS client registers a valid TCP or UDP port number in this
+- field, then the client SHALL allow ESI messages to be received at the
+- indicated TCP or UDP port. If a TCP port is registered and a pre-
+- existing TCP connection from that TCP port to the iSNS server does
+- not already exist, then the iSNS client SHALL accept new TCP
+- connections from the iSNS server at the indicated TCP port.
+-
+- The iSNS server SHALL return an error if a Network Entity is
+- registered for ESI monitoring and none of the Portals of that Network
+- Entity has an entry for the ESI Port field. If multiple Portals have
+- a registered ESI port, then the ESI message may be delivered to any
+- one of the indicated Portals.
+-
+-6.3.6. Portal Index
+-
+- The Portal Index is a 4-byte non-zero integer value that uniquely
+- identifies each Portal registered in the iSNS database. Upon initial
+- registration of a Portal, the iSNS server assigns an unused value for
+- the Portal Index of that Portal. Each Portal in the iSNS database
+- MUST be assigned a value for the Portal Index that is not assigned to
+- any other Portal. Furthermore, Portal Index values for recently
+- deregistered Portals SHOULD NOT be reused in the short term.
+-
+- The Portal Index MAY be used to represent a registered Portal in
+- situations where the Portal IP-Address and Portal TCP/UDP Port is
+- unwieldy to use. An example of this is when SNMP is used for
+- management, as described in Section 2.10.
+-
+-6.3.7. SCN Port
+-
+- This field contains the TCP or UDP port used by the iSNS client to
+- receive SCN messages from the iSNS server. When a value is
+- registered for this attribute, an SCN message may be received on the
+- indicated port for any of the Storage Nodes supported by the Portal.
+- Bits 16 to 31 contain the port number. If bit 15 is set, then the
+- port type is UDP. Otherwise, the port type is TCP. Bits 0 to 14 are
+- reserved.
+-
+- If the iSNS client registers a valid TCP or UDP port number in this
+- field, then the client SHALL allow SCN messages to be received at the
+- indicated TCP or UDP port. If a TCP port is registered and a pre-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 82]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- existing TCP connection from that TCP port to the iSNS server does
+- not already exist, then the iSNS client SHALL accept new TCP
+- connections from the iSNS server at the indicated TCP port.
+-
+- The iSNS server SHALL return an error if an SCN registration message
+- is received and none of the Portals of the Network Entity has an
+- entry for the SCN Port. If multiple Portals have a registered SCN
+- Port, then the SCN SHALL be delivered to any one of the indicated
+- Portals of that Network Entity.
+-
+-6.3.8. Portal Next Index
+-
+- This is a virtual attribute containing a 4-byte integer value that
+- indicates the next available (i.e., unused) Portal Index value. This
+- attribute may only be queried; the iSNS server SHALL return an error
+- code of 3 (Invalid Registration) to any client that attempts to
+- register a value for this attribute. A Message Key is not required
+- when exclusively querying for this attribute.
+-
+- The Portal Next Index MAY be used by an SNMP client to create an
+- entry in the iSNS server. SNMP requirements are described in Section
+- 2.10.
+-
+-6.3.9. Portal Security Bitmap
+-
+- This 4-byte field contains flags that indicate security attribute
+- settings for the Portal. Bit 31 (Lsb) of this field must be 1
+- (enabled) for this field to contain significant information. If Bit
+- 31 is enabled, this signifies that the iSNS server can be used to
+- store and distribute security policies and settings for iSNS clients
+- (i.e., iSCSI devices). Bit 30 must be 1 for bits 25-29 to contain
+- significant information. All other bits are reserved for non-
+- IKE/IPSec security mechanisms to be specified in the future.
+-
+- Bit Position Flag Description
+- ------------ ----------------
+- 25 1 = Tunnel Mode Preferred; 0 = No Preference
+- 26 1 = Transport Mode Preferred; 0 = No Preference
+- 27 1 = Perfect Forward Secrecy (PFS) Enabled;
+- 0 = PFS Disabled
+- 28 1 = Aggressive Mode Enabled; 0 = Disabled
+- 29 1 = Main Mode Enabled; 0 = MM Disabled
+- 30 1 = IKE/IPSec Enabled; 0 = IKE/IPSec Disabled
+- 31 (Lsb) 1 = Bitmap VALID; 0 = INVALID
+- All others RESERVED
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 83]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.3.10. Portal ISAKMP Phase-1 Proposals
+-
+- This field contains the IKE Phase-1 proposal listing in decreasing
+- order of preference of the protection suites acceptable to protect
+- all IKE Phase-2 messages sent and received by the Portal. This
+- includes Phase-2 SAs from the iSNS client to the iSNS server as well
+- as to peer iFCP and/or iSCSI devices. This attribute contains the SA
+- payload, proposal payload(s), and transform payload(s) in the ISAKMP
+- format defined in [RFC2408].
+-
+- This field should be used if the implementer wishes to define phase-1
+- SA security configuration on a per-Portal basis, as opposed to on a
+- per-Network Entity basis. If the implementer desires to have a
+- single phase-1 SA security configuration to protect all phase-2
+- traffic regardless of the interface used, then the Entity Phase-1
+- Proposal (Section 6.2.9) should be used.
+-
+-6.3.11. Portal ISAKMP Phase-2 Proposals
+-
+- This field contains the IKE Phase-2 proposal, in ISAKMP format
+- [RFC2408], listing in decreasing order of preference the security
+- proposals acceptable to protect traffic sent and received by the
+- Portal. This field is used only if bits 31, 30, and 29 of the
+-
+- Security Bitmap (see 6.3.9) are enabled. This attribute contains the
+- SA payload, proposal payload(s), and associated transform payload(s)
+- in the ISAKMP format defined in [RFC2408].
+-
+-6.3.12. Portal Certificate
+-
+- This attribute contains one or more X.509 certificates that are a
+- credential of the Portal. This certificate is used to identify and
+- authenticate communications to the IP address and TCP/UDP Port
+- supported by the Portal. The format of the X.509 certificate is
+- specified in [RFC3280]. This certificate MUST contain a Subject Name
+- with an empty sequence and MUST contain a SubjectAltName extension
+- encoded with the iPAddress type. The Portal IP Address (Section
+- 6.3.1) of the identified Portal SHALL be stored in the SubjectAltName
+- field of the certificate.
+-
+-6.4. iSCSI Node-Keyed Attributes
+-
+- The following attributes are stored in the iSNS database using the
+- iSCSI Name attribute as the key. Each set of Node-Keyed attributes
+- is associated with one Entity Identifier object key.
+-
+- Although the iSCSI Name key is associated with one Entity Identifier,
+- it is unique across the entire iSNS database.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 84]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.4.1. iSCSI Name
+-
+- This is a variable-length UTF-8 encoded NULL-terminated text-based
+- description of up to 224 bytes. This key attribute is required for
+- iSCSI Storage Nodes and is provided by the iSNS client. The
+- registered iSCSI Name MUST conform to the format described in [iSCSI]
+- for iSCSI Names. The maximum size for an iSCSI Name is 223 bytes.
+- Including the NULL character and 4-byte alignment (see Section
+- 5.3.1), the maximum iSCSI Name field size is 224 bytes.
+-
+- If an iSCSI Name is registered without an EID key, then a Network
+- Entity SHALL be created and an EID assigned. The assigned EID SHALL
+- be returned in the registration response as an operating attribute.
+-
+- This field MUST be normalized according to the stringprep template
+- [STRINGPREP] before it is stored in the iSNS database.
+-
+-6.4.2. iSCSI Node Type
+-
+- This required 32-bit field is a bitmap indicating the type of iSCSI
+- Storage Node. The bit positions are defined below. A set bit (1)
+- indicates that the Node has the corresponding characteristics.
+-
+- Bit Position Node Type
+- ------------ ---------
+- 29 Control
+- 30 Initiator
+- 31 (Lsb) Target
+- All others RESERVED
+-
+- If the Target bit is set to 1, then the Node represents an iSCSI
+- target. The Target bit MAY be set by iSNS clients using the iSNSP.
+-
+- If the Initiator bit is set to 1, then the Node represents an iSCSI
+- initiator. The Initiator bit MAY be set by iSNS clients using the
+- iSNSP.
+-
+- If the control bit is set to 1, then the Node represents a gateway, a
+- management station, a backup iSNS server, or another device that is
+- not an initiator or target, but that requires the ability to send and
+- receive iSNSP messages, including state change notifications.
+- Setting the control bit is an administrative task that MUST be
+- performed on the iSNS server; iSNS clients SHALL NOT be allowed to
+- change this bit using the iSNSP.
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 85]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- This field MAY be used by the iSNS server to distinguish among
+- permissions by different iSCSI Node types for accessing various iSNS
+- functions. More than one Node Type bit may be simultaneously
+- enabled.
+-
+-6.4.3. iSCSI Node Alias
+-
+- This is a variable-length UTF-8 encoded NULL-terminated text-based
+- description of up to 256 bytes. The Alias is a user-readable
+- description of the Node entry in the iSNS database.
+-
+-6.4.4. iSCSI Node SCN Bitmap
+-
+- The iSCSI Node SCN Bitmap indicates events for which the registering
+- iSNS client wishes to receive a notification message. The following
+- table displays events that result in notifications, and the bit field
+- in the SCN Bitmap that, when enabled, results in the corresponding
+- notification.
+-
+- Note that this field is of dual use: it is used in the SCN
+- registration process to define interested events that will trigger an
+- SCN message, and it is also contained in each SCN message itself, to
+- indicate the type of event that triggered the SCN message. A set bit
+- (1) indicates the corresponding type of SCN.
+-
+- Bit Position Flag Description
+- ------------ ----------------
+- 24 INITIATOR AND SELF INFORMATION ONLY
+- 25 TARGET AND SELF INFORMATION ONLY
+- 26 MANAGEMENT REGISTRATION/SCN
+- 27 OBJECT REMOVED
+- 28 OBJECT ADDED
+- 29 OBJECT UPDATED
+- 30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
+- 31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
+- All others RESERVED
+-
+- DD/DDS MEMBER REMOVED indicates that an existing member of a
+- Discovery Domain and/or Discovery Domain Set has been removed.
+-
+- DD/DDS MEMBER ADDED indicates that a new member was added to an
+- existing DD and/or DDS.
+-
+- OBJECT REMOVED, OBJECT ADDED, and OBJECT UPDATED indicate a Network
+- Entity, Portal, Storage Node, FC Device, DD, and/or DDS object was
+- removed from, added to, or updated in the Discovery Domain or in the
+- iSNS database (Control Nodes only).
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 86]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Regular SCNs provide information about objects that are updated in,
+- added to or removed from Discovery Domains of which the Storage Node
+- is a member. An SCN or SCN registration is considered a regular SCN
+- or regular SCN registration if the MANAGEMENT REGISTRATION/SCN flag
+- is cleared. All iSNS clients may register for regular SCNs.
+-
+- Management SCNs provide information about all changes to the network,
+- regardless of discovery domain membership. Registration for
+- management SCNs is indicated by setting bit 26 to 1. Only Control
+- Nodes may register for management SCNs. Bits 30 and 31 may only be
+- enabled if bit 26 is set to 1.
+-
+- TARGET AND SELF INFORMATION ONLY SCNs (bit 25) provides information
+- only about changes to target devices, or if the iSCSI Storage Node
+- itself has undergone a change. Similarly, INITIATOR AND SELF
+- INFORMATION ONLY SCNs (bit 24) provides information only about
+- changes to initiator Nodes, or to the target itself.
+-
+-6.4.5. iSCSI Node Index
+-
+- The iSCSI Node Index is a 4-byte non-zero integer value used as a key
+- that uniquely identifies each iSCSI Storage Node registered in the
+- iSNS database. Upon initial registration of the iSCSI Storage Node,
+- the iSNS server assigns an unused value for the iSCSI Node Index.
+- Each iSCSI Node MUST be assigned a value for the iSCSI Node Index
+- that is not assigned to any other iSCSI Storage Node. Furthermore,
+- iSCSI Node Index values for recently deregistered iSCSI Storage Nodes
+- SHOULD NOT be reused in the short term.
+-
+- The iSCSI Node Index may be used as a key to represent a registered
+- Node in situations where the iSCSI Name is too long to be used as a
+- key. An example of this is when SNMP is used for management, as
+- described in Section 2.10.
+-
+- The value assigned for the iSCSI Node Index SHALL persist as long as
+- the iSCSI Storage Node is registered in the iSNS database or a member
+- of a Discovery Domain. An iSCSI Node Index value that is assigned
+- for a Storage Node SHALL NOT be used for any other Storage Node as
+- long as the original node is registered in the iSNS database or a
+- member of a Discovery Domain.
+-
+-6.4.6. WWNN Token
+-
+- This field contains a globally unique 64-bit integer value that can
+- be used to represent the World Wide Node Name of the iSCSI device in
+- a Fibre Channel fabric. This identifier is used during the device
+- registration process and MUST conform to the requirements in [FC-FS].
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 87]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- The FC-iSCSI gateway uses the value found in this field to register
+- the iSCSI device in the Fibre Channel name server. It is stored in
+- the iSNS server to prevent conflict when "proxy" WWNN values are
+- assigned to iSCSI initiators establishing storage sessions to devices
+- in the FC fabric.
+-
+- If the iSNS client does not assign a value for WWNN Token, then the
+- iSNS server SHALL provide a value for this field upon initial
+- registration of the iSCSI Storage Node. The process by which the
+- WWNN Token is assigned by the iSNS server MUST conform to the
+- following requirements:
+-
+- 1. The assigned WWNN Token value MUST be unique among all WWN
+- entries in the existing iSNS database, and among all devices that
+- can potentially be registered in the iSNS database.
+-
+- 2. Once the value is assigned, the iSNS server MUST persistently
+- save the mapping between the WWNN Token value and registered
+- iSCSI Name. That is, successive re-registrations of the iSCSI
+- Storage Node keyed by the same iSCSI Name maintain the original
+- mapping to the associated WWNN Token value in the iSNS server.
+- Similarly, the mapping SHALL be persistent across iSNS server
+- reboots. Once assigned, the mapping can only be changed if a
+- DevAttrReg message from an authorized iSNS client explicitly
+- provides a different WWNN Token value.
+-
+- 3. Once a WWNN Token value has been assigned and mapped to an iSCSI
+- name, that WWNN Token value SHALL NOT be reused or mapped to any
+- other iSCSI name.
+-
+- 4. The assigned WWNN Token value MUST conform to the formatting
+- requirements of [FC-FS] for World Wide Names (WWNs).
+-
+- An iSNS client, such as an FC-iSCSI gateway or the iSCSI initiator,
+- MAY register its own WWNN Token value or overwrite the iSNS Server-
+- supplied WWNN Token value, if it wishes to supply its own iSCSI-FC
+- name mapping. This is accomplished using the DevAttrReg message with
+- the WWNN Token (tag=37) as an operating attribute. Once overwritten,
+- the new WWNN Token value MUST be stored and saved by the iSNS server,
+- and all requirements specified above continue to apply. If an iSNS
+- client attempts to register a value for this field that is not unique
+- in the iSNS database or that is otherwise invalid, then the
+- registration SHALL be rejected with an Status Code of 3 (Invalid
+- Registration).
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 88]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- There MAY be matching records in the iSNS database for the Fibre
+- Channel device specified by the WWNN Token. These records may
+- contain device attributes for that FC device registered in the Fibre
+- Channel fabric name server.
+-
+-6.4.7. iSCSI Node Next Index
+-
+- This is a virtual attribute containing a 4-byte integer value that
+- indicates the next available (i.e., unused) iSCSI Node Index value.
+- This attribute may only be queried; the iSNS server SHALL return an
+- error code of 3 (Invalid Registration) to any client that attempts to
+- register a value for this attribute. A Message Key is not required
+- when exclusively querying for this attribute.
+-
+- The iSCSI Node Next Index MAY be used by an SNMP client to create an
+- entry in the iSNS server. SNMP requirements are described in Section
+- 2.10.
+-
+-6.4.8. iSCSI AuthMethod
+-
+- This attribute contains a NULL-terminated string of UTF-8 text
+- listing the iSCSI authentication methods enabled for this iSCSI
+- Storage Node, in order of preference. The text values used to
+- identify iSCSI authentication methods are embedded in this string
+- attribute and delineated by a comma. The text values are identical
+- to those found in the main iSCSI document [iSCSI]; additional
+- vendor-specific text values are also possible.
+-
+- Text Value Description Reference
+- ---------- ----------- ---------
+- KB5 Kerberos V5 [RFC1510]
+- SPKM1 Simple Public Key GSS-API [RFC2025]
+- SPKM2 Simple Public Key GSS-API [RFC2025]
+- SRP Secure Remote Password [RFC2945]
+- CHAP Challenge Handshake Protocol [RFC1994]
+- none No iSCSI Authentication
+-
+-6.5. Portal Group (PG) Object-Keyed Attributes
+-
+- The following attributes are used to associate Portal and iSCSI
+- Storage Node objects. PG objects are stored in the iSNS database
+- using the PG iSCSI Name, the PG Portal IP Address, and the PG Portal
+- TCP/UDP Port as keys. New PG objects are implicitly or explicitly
+- created at the time that the corresponding Portal and/or iSCSI
+- Storage Node objects are registered. Section 3.4 has a general
+- discussion of PG usage. For further details on use of Portal Groups,
+- see [iSCSI].
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 89]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.5.1. Portal Group iSCSI Name
+-
+- This is the iSCSI Name for the iSCSI Storage Node that is associated
+- with the PG object. This name MAY represent an iSCSI Storage Node
+- not currently registered in the server.
+-
+-6.5.2. PG Portal IP Addr
+-
+- This is the Portal IP Address attribute for the Portal that is
+- associated with the PG object. This Portal IP Address MAY be that of
+- a Portal that is not currently registered in the server.
+-
+-6.5.3. PG Portal TCP/UDP Port
+-
+- This is the Portal TCP/UDP Port attribute for the Portal that is
+- associated with the PG object. This Portal TCP/UDP Port MAY be that
+- of a Portal that is not currently registered in the server.
+-
+-6.5.4. Portal Group Tag (PGT)
+-
+- This field is used to group Portals in order to coordinate
+- connections in a session across Portals to a specified iSCSI Node.
+- The PGT is a value in the range of 0-65535, or NULL. A NULL PGT
+- value is registered by using 0 for the length in the TLV during
+- registration. The two least significant bytes of the value contain
+- the PGT for the object. The two most significant bytes are reserved.
+- If a PGT value is not explicitly registered for an iSCSI Storage Node
+- and Portal pair, then the PGT value SHALL be implicitly registered as
+- 0x00000001.
+-
+-6.5.5. Portal Group Index
+-
+- The PG Index is a 4-byte non-zero integer value used as a key that
+- uniquely identifies each PG object registered in the iSNS database.
+- Upon initial registration of a PG object, the iSNS server MUST assign
+- an unused value for the PG Index. Furthermore, PG Index values for
+- recently deregistered PG objects SHOULD NOT be reused in the short
+- term.
+-
+- The PG Index MAY be used as the key to reference a registered PG in
+- situations where a unique index for each PG object is required. It
+- MAY also be used as the message key in an iSNS message to query or
+- update a pre-existing PG object. An example of this is when SNMP is
+- used for management, as described in Section 2.10. The value
+- assigned for the PG Index SHALL persist as long as the server is
+- active.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 90]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.5.6. Portal Group Next Index
+-
+- The PG Next Index is a virtual attribute containing a 4-byte integer
+- value that indicates the next available (i.e., unused) PG Index
+- value. This attribute may only be queried; the iSNS server SHALL
+- return an error code of 3 (Invalid Registration) to any client that
+- attempts to register a value for this attribute. A Message Key is
+- not required when exclusively querying for this attribute.
+-
+- The Portal Group Next Index MAY be used by an SNMP client to create
+- an entry in the iSNS server. SNMP requirements are described in
+- Section 2.10.
+-
+-6.6. FC Port Name-Keyed Attributes
+-
+- The following attributes are registered in the iSNS database using
+- the FC Port World Wide Name (WWPN) attribute as the key. Each set of
+- FC Port-Keyed attributes is associated with one Entity Identifier
+- object key.
+-
+- Although the FC Port World Wide Name is associated with one Entity
+- Identifier, it is also globally unique.
+-
+-6.6.1. FC Port Name (WWPN)
+-
+- This 64-bit identifier uniquely defines the FC Port, and it is the
+- World Wide Port Name (WWPN) of the corresponding Fibre Channel
+- device. This attribute is the key for the iFCP Storage Node. This
+- globally unique identifier is used during the device registration
+- process, and it uses a value conforming to IEEE EUI-64 [EUI-64].
+-
+-6.6.2. Port ID (FC_ID)
+-
+- The Port Identifier is a Fibre Channel address identifier assigned to
+- an N_Port or NL_Port during fabric login. The format of the Port
+- Identifier is defined in [FC-FS]. The least significant 3 bytes
+- contain this address identifier. The most significant byte is
+- RESERVED.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 91]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.6.3. FC Port Type
+-
+- Indicates the type of FC port. Encoded values for this field are
+- listed in the following table:
+-
+- Type Description
+- ---- -----------
+- 0x0000 Unidentified/Null Entry
+- 0x0001 Fibre Channel N_Port
+- 0x0002 Fibre Channel NL_Port
+- 0x0003 Fibre Channel F/NL_Port
+- 0x0004-0080 RESERVED
+- 0x0081 Fibre Channel F_Port
+- 0x0082 Fibre Channel FL_Port
+- 0x0083 RESERVED
+- 0x0084 Fibre Channel E_Port
+- 0x0085-00FF RESERVED
+- 0xFF11 RESERVED
+- 0xFF12 iFCP Port
+- 0xFF13-FFFF RESERVED
+-
+-6.6.4. Symbolic Port Name
+-
+- This is a variable-length UTF-8 encoded NULL-terminated text-based
+- description of up to 256 bytes that is associated with the iSNS-
+- registered FC Port Name in the network.
+-
+-6.6.5. Fabric Port Name (FWWN)
+-
+- This 64-bit identifier uniquely defines the fabric port. If the port
+- of the FC Device is attached to a Fibre Channel fabric port with a
+- registered Port Name, then that fabric Port Name SHALL be indicated
+- in this field.
+-
+-6.6.6. Hard Address
+-
+- This field is the requested hard address 24-bit NL Port Identifier,
+- included in the iSNSP for compatibility with Fibre Channel Arbitrated
+- Loop devices and topologies. The least significant 3 bytes of this
+- field contain the address. The most significant byte is RESERVED.
+-
+-6.6.7. Port IP Address
+-
+- The Fibre Channel IP address associated with the FC Port. When this
+- field contains an IPv4 value, it is stored as an IPv4-mapped IPv6
+- address. That is, the most significant 10 bytes are set to 0x00,
+- with the next two bytes set to 0xFFFF [RFC2373]. When an IPv6 value
+- is contained in this field, then the entire 16-byte field is used.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 92]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.6.8. Class of Service (COS)
+-
+- This 32-bit bit-map field indicates the Fibre Channel Class of
+- Service types that are supported by the registered port. In the
+- following table, a set bit (1) indicates a Class of Service
+- supported.
+-
+- Bit Position Description
+- ------------ -----------
+- 29 Fibre Channel Class 2 Supported
+- 28 Fibre Channel Class 3 Supported
+-
+-6.6.9. FC-4 Types
+-
+- This 32-byte field indicates the FC-4 protocol types supported by the
+- associated port. This field can be used to support Fibre Channel
+- devices and is consistent with FC-GS-4.
+-
+-6.6.10. FC-4 Descriptor
+-
+- This is a variable-length UTF-8 encoded NULL-terminated text-based
+- description of up to 256 bytes that is associated with the iSNS-
+- registered device port in the network. This field can be used to
+- support Fibre Channel devices and is consistent with FC-GS-4.
+-
+-6.6.11. FC-4 Features
+-
+- This is a 128-byte array, 4 bits per type, for the FC-4 protocol
+- types supported by the associated port. This field can be used to
+- support Fibre Channel devices and is consistent with FC-GS-4.
+-
+-6.6.12. iFCP SCN Bitmap
+-
+- This field indicates the events the iSNS client is interested in.
+- These events can cause SCNs to be generated. SCNs provide
+- information about objects that are updated in, added to or removed
+- from Discovery Domains of which the source and destination are a
+- member. Management SCNs provide information about all changes to the
+- network. A set bit (1) indicates the type of SCN for the bitmap as
+- follows:
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 93]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Bit Position Flag Description
+- ------------ ----------------
+- 24 INITIATOR AND SELF INFORMATION ONLY
+- 25 TARGET AND SELF INFORMATION ONLY
+- 26 MANAGEMENT REGISTRATION/SCN
+- 27 OBJECT REMOVED
+- 28 OBJECT ADDED
+- 29 OBJECT UPDATED
+- 30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
+- 31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
+- All others RESERVED
+-
+- Further information on the use of the bit positions specified above
+- can be found in Section 6.4.4.
+-
+-6.6.13. Port Role
+-
+- This required 32-bit field is a bitmap indicating the type of iFCP
+- Storage Node. The bit fields are defined below. A set bit indicates
+- the Node has the corresponding characteristics.
+-
+- Bit Position Node Type
+- ------------ ---------
+- 29 Control
+- 30 FCP Initiator
+- 31 (Lsb) FCP Target
+- All Others RESERVED
+-
+- If the 'Target' bit is set to 1, then the port represents an FC
+- target. Setting of the 'Target' bit MAY be performed by iSNS clients
+- using the iSNSP.
+-
+- If the 'Initiator' bit is set to 1, then the port represents an FC
+- initiator. Setting of the 'Initiator' bit MAY be performed by iSNS
+- clients using the iSNSP.
+-
+- If the 'Control' bit is set to 1, then the port represents a gateway,
+- a management station, an iSNS backup server, or another device.
+-
+- This is usually a special device that is neither an initiator nor a
+- target, which requires the ability to send and receive iSNSP
+- messages, including state-change notifications. Setting the control
+- bit is an administrative task that MUST be administratively
+- configured on the iSNS server; iSNS clients SHALL NOT be allowed to
+- change this bit using the iSNSP.
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 94]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- This field MAY be used by the iSNS server to distinguish among
+- permissions by different iSNS clients. For example, an iSNS server
+- implementation may be administratively configured to allow only
+- targets to receive ESIs, or to permit only Control Nodes to add,
+- modify, or delete discovery domains.
+-
+-6.6.14. Permanent Port Name (PPN)
+-
+- The Permanent Port Name can be used to support Fibre Channel devices
+- and is consistent with the PPN description in FC-GS-4 [FC-GS-4]. The
+- format of the PPN is identical to the FC Port Name WWPN attribute
+- format.
+-
+-6.7. Node-Keyed Attributes
+-
+- The following attributes are registered in the iSNS database using
+- the FC Node Name (WWNN) attribute as the key. Each set of FC Node-
+- Keyed attributes represents a single device and can be associated
+- with many FC Ports.
+-
+- The FC Node Name is unique across the entire iSNS database.
+-
+-6.7.1. FC Node Name (WWNN)
+-
+- The FC Node Name is a 64-bit identifier that is the World Wide Node
+- Name (WWNN) of the corresponding Fibre Channel device. This
+- attribute is the key for the FC Device. This globally unique
+- identifier is used during the device registration process, and it
+- uses a value conforming to IEEE EUI-64 [EUI-64].
+-
+-6.7.2. Symbolic Node Name
+-
+- This is a variable-length UTF-8 encoded NULL-terminated text-based
+- description of up to 256 bytes that is associated with the iSNS-
+- registered FC Device in the network.
+-
+-6.7.3. Node IP Address
+-
+- This IP address is associated with the device Node in the network.
+- This field is included for compatibility with Fibre Channel. When
+- this field contains an IPv4 value, it is stored as an IPv4-mapped
+- IPv6 address. That is, the most significant 10 bytes are set to
+- 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When an IPv6
+- value is contained in this field, the entire 16-byte field is used.
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 95]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.7.4. Node IPA
+-
+- This field is the 8-byte Fibre Channel Initial Process Associator
+- (IPA) associated with the device Node in the network. The initial
+- process associator is used for communication between Fibre Channel
+- devices.
+-
+-6.7.5. Proxy iSCSI Name
+-
+- This is a variable-length UTF-8 encoded NULL-terminated text-based
+- field that contains the iSCSI Name used to represent the FC Node in
+- the IP network. It is used as a pointer to the matching iSCSI Name
+- entry in the iSNS server. Its value is usually registered by an FC-
+- iSCSI gateway connecting the IP network to the fabric containing the
+- FC device.
+-
+- Note that if this field is used, there SHOULD be a matching entry in
+- the iSNS database for the iSCSI device specified by the iSCSI name.
+- The database entry should include the full range of iSCSI attributes
+- needed for discovery and management of the "iSCSI proxy image" of the
+- FC device.
+-
+-6.8. Other Attributes
+-
+- The following are not attributes of the previously-defined objects.
+-
+-6.8.1. FC-4 Type Code
+-
+- This is a 4-byte field used to provide a FC-4 type during a FC-4 Type
+- query. The FC-4 types are consistent with the FC-4 Types as defined
+- in FC-FS. Byte 0 contains the FC-4 type. All other bytes are
+- reserved.
+-
+-6.8.2. iFCP Switch Name
+-
+- The iFCP Switch Name is a 64-bit World Wide Name (WWN) identifier
+- that uniquely identifies a distinct iFCP gateway in the network.
+- This globally unique identifier is used during the switch
+- registration/FC_DOMAIN_ID assignment process. The iFCP Switch Name
+- value used MUST conform to the requirements stated in [FC-FS] for
+- World Wide Names. The iSNS server SHALL track the state of all
+- FC_DOMAIN_ID values that have been allocated to each iFCP Switch
+- Name. If a given iFCP Switch Name is deregistered from the iSNS
+- database, then all FC_DOMAIN_ID values allocated to that iFCP Switch
+- Name SHALL be returned to the unused pool of values.
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 96]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.8.3. iFCP Transparent Mode Commands
+-
+-6.8.3.1. Preferred ID
+-
+- This is a 4-byte unsigned integer field, and it is the requested
+- value that the iSNS client wishes to use for the FC_DOMAIN_ID. The
+- iSNS server SHALL grant the iSNS client the use of the requested
+- value as the FC_DOMAIN_ID, if the requested value has not already
+- been allocated. If the requested value is not available, the iSNS
+- server SHALL return a different value that has not been allocated.
+-
+-6.8.3.2. Assigned ID
+-
+- This is a 4-byte unsigned integer field that is used by an iFCP
+- gateway to reserve its own unique FC_DOMAIN_ID value from the range 1
+- to 239. When a FC_DOMAIN_ID is no longer required, it SHALL be
+- released by the iFCP gateway using the RlseDomId message. The iSNS
+- server MUST use the Entity Status Inquiry message to determine
+- whether an iFCP gateway is still present on the network.
+-
+-6.8.3.3. Virtual_Fabric_ID
+-
+- This is a variable-length UTF-8 encoded NULL-terminated text-based
+- field of up to 256 bytes. The Virtual_Fabric_ID string is used as a
+- key attribute to identify a range of non-overlapping FC_DOMAIN_ID
+- values to be allocated using RqstDomId. Each Virtual_Fabric_ID
+- string submitted by an iSNS client SHALL have its own range of non-
+- overlapping FC_DOMAIN_ID values to be allocated to iSNS clients.
+-
+-
+-6.9. iSNS Server-Specific Attributes
+-
+- Access to the following attributes may be administratively
+- controlled. These attributes are specific to the iSNS server
+- instance; the same value is returned for all iSNS clients accessing
+- the iSNS server. Only query messages may be performed on these
+- attributes. Attempted registrations of values for these attributes
+- SHALL return a status code of 3 (Invalid Registration).
+-
+- A query for an iSNS Server-Specific attribute MUST contain the
+- identifying key attribute (i.e., iSCSI Name or FC Port Name WWPN) of
+- the Node originating the registration or query message as the Source
+- and Message Key attributes. The Operating Attributes are the
+- server-specific attributes being registered or queried.
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 97]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.9.1. iSNS Server Vendor OUI
+-
+- This attribute is the OUI (Organizationally Unique Identifier)
+- [802-1990] identifying the specific vendor implementing the iSNS
+- server. This attribute can only be queried; iSNS clients SHALL NOT be
+- allowed to register a value for the iSNS Server Vendor OUI.
+-
+-6.10. Vendor-Specific Attributes
+-
+- iSNS server implementations MAY define vendor-specific attributes for
+- private use. These attributes MAY be used to store optional data
+- that is registered and/or queried by iSNS clients in order to gain
+- optional capabilities. Note that any implementation of vendor-
+- specific attributes in the iSNS server SHALL NOT impose any form of
+- mandatory behavior on the part of the iSNS client.
+-
+- The tag values used for vendor-specific and user-specific use are
+- defined in Section 6.1. To avoid misinterpreting proprietary
+- attributes, the vendor's own OUI (Organizationally Unique Identifier)
+- MUST be placed in the upper three bytes of the attribute value field
+- itself.
+-
+- The OUI is defined in IEEE Std 802-1990 and is the same constant used
+- to generate 48 bit Universal LAN MAC addresses. A vendor's own iSNS
+- implementation will then be able to recognize the OUI in the
+- attribute field and be able to execute vendor-specific handling of
+- the attribute.
+-
+-6.10.1. Vendor-Specific Server Attributes
+-
+- Attributes with tags in the range 257 to 384 are vendor-specific or
+- site-specific attributes of the iSNS server. Values for these
+- attributes are administratively set by the specific vendor providing
+- the iSNS server implementation. Query access to these attributes may
+- be administratively controlled. These attributes are unique for each
+- logical iSNS server instance. Query messages for these attributes
+- SHALL use the key identifier (i.e., iSCSI Name or FC Port Name WWPN)
+- for both the Source attribute and Message Key attribute. These
+- attributes can only be queried; iSNS clients SHALL NOT be allowed to
+- register a value for server attributes.
+-
+-6.10.2. Vendor-Specific Entity Attributes
+-
+- Attributes in the range 385 to 512 are vendor-specific or site-
+- specific attributes used to describe the Network Entity object.
+- These attributes are keyed by the Entity Identifier attribute
+- (tag=1).
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 98]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.10.3. Vendor-Specific Portal Attributes
+-
+- Attributes in the range 513 to 640 are vendor-specific or site-
+- specific attributes used to describe the Portal object. These
+- attributes are keyed by the Portal IP-Address (tag=16) and Portal
+- TCP/UDP Port (tag=17).
+-
+-6.10.4. Vendor-Specific iSCSI Node Attributes
+-
+- Attributes in the range 641 to 768 are vendor-specific or site-
+- specific attributes used to describe the iSCSI Node object. These
+- attributes are keyed by the iSCSI Name (tag=32).
+-
+-6.10.5. Vendor-Specific FC Port Name Attributes
+-
+- Attributes in the range 769 to 896 are vendor-specific or site-
+- specific attributes used to describe the N_Port Port Name object.
+- These attributes are keyed by the FC Port Name WWPN (tag=64).
+-
+-6.10.6. Vendor-Specific FC Node Name Attributes
+-
+- Attributes in the range 897 to 1024 are vendor-specific or site-
+- specific attributes used to describe the FC Node Name object. These
+- attributes are keyed by the FC Node Name WWNN (tag=96).
+-
+-6.10.7. Vendor-Specific Discovery Domain Attributes
+-
+- Attributes in the range 1025 to 1280 are vendor-specific or site-
+- specific attributes used to describe the Discovery Domain object.
+- These attributes are keyed by the DD_ID (tag=104).
+-
+-6.10.8. Vendor-Specific Discovery Domain Set Attributes
+-
+- Attributes in the range 1281 to 1536 are vendor-specific or site-
+- specific attributes used to describe the Discovery Domain Set object.
+- These attributes are keyed by the DD Set ID (tag=101)
+-
+-6.10.9. Other Vendor-Specific Attributes
+-
+- Attributes in the range 1537 to 2048 can be used for key and non-key
+- attributes that describe new vendor-specific objects specific to the
+- vendor's iSNS server implementation.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 99]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.11. Discovery Domain Registration Attributes
+-
+-6.11.1. DD Set ID Keyed Attributes
+-
+-6.11.1.1. Discovery Domain Set ID (DDS ID)
+-
+- The DDS ID is an unsigned non-zero integer identifier used in the
+- iSNS directory database as a key to indicate a Discovery Domain Set
+- uniquely. A DDS is a collection of Discovery Domains that can be
+- enabled or disabled by a management station. This value is used as a
+- key for DDS attribute queries. When a Discovery Domain is
+- registered, it is initially not in any DDS.
+-
+- If the iSNS client does not provide a DDS_ID in a DDS registration
+- request message, the iSNS server SHALL generate a DDS_ID value that
+- is unique within the iSNS database for that new DDS. The created DDS
+- ID SHALL be returned in the response message. The DDS ID value of 0
+- is reserved, and the DDS ID value of 1 is used for the default DDS
+- (see Section 2.2.2).
+-
+-6.11.1.2. Discovery Domain Set Symbolic Name
+-
+- A variable-length UTF-8 encoded NULL-terminated text-based field of
+- up to 256 bytes. This is a user-readable field used to assist a
+- network administrator in tracking the DDS function. When a client
+- registers a DDS symbolic name, the iSNS server SHALL verify it is
+- unique. If the name is not unique, then the DDS registration SHALL
+- be rejected with an "Invalid Registration" Status Code. The invalid
+- attribute(s), in this case the DDS symbolic name, SHALL be included
+- in the response.
+-
+-6.11.1.3. Discovery Domain Set Status
+-
+- The DDS_Status field is a 32-bit bitmap indicating the status of the
+- DDS. Bit 0 of the bitmap indicates whether the DDS is Enabled (1) or
+- Disabled (0). The default value for the DDS Enabled flag is Disabled
+- (0).
+-
+- Bit Position DDS Status
+- ------------ ---------
+- 31 (Lsb) DDS Enabled (1) / DDS Disabled (0)
+- All others RESERVED
+-
+-6.11.1.4. Discovery Domain Set Next ID
+-
+- This is a virtual attribute containing a 4-byte integer value that
+- indicates the next available (i.e., unused) Discovery Domain Set
+- Index value. This attribute may only be queried; the iSNS server
+-
+-
+-
+-Tseng, et al. Standards Track [Page 100]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- SHALL return an error code of 3 (Invalid Registration) to any client
+- that attempts to register a value for this attribute. A Message Key
+- is not required when exclusively querying for this attribute.
+-
+- The Discovery Domain Set Next Index MAY be used by an SNMP client to
+- create an entry in the iSNS server. SNMP requirements are described
+- in Section 2.10.
+-
+-6.11.2. DD ID Keyed Attributes
+-
+-6.11.2.1. Discovery Domain ID (DD ID)
+-
+- The DD ID is an unsigned non-zero integer identifier used in the iSNS
+- directory database as a key to identify a Discovery Domain uniquely.
+- This value is used as the key for any DD attribute query. If the
+- iSNS client does not provide a DD_ID in a DD registration request
+- message, the iSNS server SHALL generate a DD_ID value that is unique
+- within the iSNS database for that new DD (i.e., the iSNS client will
+- be registered in a new DD). The created DD ID SHALL be returned in
+- the response message. The DD ID value of 0 is reserved, and the DD
+- ID value of 1 is used for the default DD (see Section 2.2.2).
+-
+-6.11.2.2. Discovery Domain Symbolic Name
+-
+- A variable-length UTF-8 encoded NULL-terminated text-based field of
+- up to 256 bytes. When a client registers a DD symbolic name, the
+- iSNS server SHALL verify it is unique. If the name is not unique,
+- then the DD registration SHALL be rejected with an "Invalid
+- Registration" Status Code. The invalid attribute(s), in this case
+- the DD symbolic name, SHALL be included in the response.
+-
+-6.11.2.3. Discovery Domain Member: iSCSI Node Index
+-
+- This is the iSCSI Node Index of a Storage Node that is a member of
+- the DD. The DD may have a list of 0 to n members. The iSCSI Node
+- Index is one alternative representation of membership in a Discovery
+- Domain, the other alternative being the iSCSI Name. The Discovery
+- Domain iSCSI Node Index is a 4-byte non-zero integer value.
+-
+- The iSCSI Node Index can be used to represent a DD member in
+- situations where the iSCSI Name is too long to be used. An example
+- of this is when SNMP is used for management, as described in Section
+- 2.10.
+-
+- The iSCSI Node Index and the iSCSI Name stored as a member in a DD
+- SHALL be consistent with the iSCSI Node Index and iSCSI Name
+- attributes registered for the Storage Node object in the iSNS server.
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 101]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-6.11.2.4. Discovery Domain Member: iSCSI Name
+-
+- A variable-length UTF-8 encoded NULL-terminated text-based field of
+- up to 224 bytes. It indicates membership for the specified iSCSI
+- Storage Node in the Discovery Domain. Note that the referenced
+- Storage Node does not need to be actively registered in the iSNS
+- database before the iSNS client uses this attribute. There is no
+- limit to the number of members that may be in a DD. Membership is
+- represented by the iSCSI Name of the iSCSI Storage Node.
+-
+-6.11.2.5. Discovery Domain Member: FC Port Name
+-
+- This 64-bit identifier attribute indicates membership for an iFCP
+- Storage Node (FC Port) in the Discovery Domain. Note that the
+- referenced Storage Node does not need to be actively registered in
+- the iSNS database before the iSNS client uses this attribute. There
+- is no limit to the number of members that may be in a DD. Membership
+- is represented by the FC Port Name (WWPN) of the iFCP Storage Node.
+-
+-6.11.2.6. Discovery Domain Member: Portal Index
+-
+- This attribute indicates membership in the Discovery Domain for a
+- Portal. It is an alternative representation for Portal membership to
+- the Portal IP Address and Portal TCP/UDP Port. The referenced Portal
+- MUST be actively registered in the iSNS database before the iSNS
+- client uses this attribute.
+-
+-6.11.2.7. Discovery Domain Member: Portal IP Address
+-
+- This attribute and the Portal TCP/UDP Port attribute indicate
+- membership in the Discovery Domain for the specified Portal. Note
+- that the referenced Portal does not need to be actively registered in
+- the iSNS database before the iSNS client uses this attribute.
+-
+-6.11.2.8. Discovery Domain Member: Portal TCP/UDP Port
+-
+- This attribute and the Portal IP Address attribute indicate
+- membership in the Discovery Domain for the specified Portal. Note
+- that the referenced Portal does not need to be actively registered in
+- the iSNS database before the iSNS client uses this attribute.
+-
+-6.11.2.9. Discovery Domain Features
+-
+- The Discovery Domain Features is a bitmap indicating the features of
+- this DD. The bit positions are defined below. A bit set to 1
+- indicates the DD has the corresponding characteristics.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 102]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Bit Position DD Feature
+- ------------ ----------
+- 31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)
+- All others RESERVED
+-
+- Boot List: this feature indicates that the target(s) in this DD
+- provides boot capabilities for the member initiators, as described in
+- [iSCSI-boot].
+-
+-6.11.2.10. Discovery Domain Next ID
+-
+- This is a virtual attribute containing a 4-byte integer value that
+- indicates the next available (i.e., unused) Discovery Domain Index
+- value. This attribute may only be queried; the iSNS server SHALL
+- return an error code of 3 (Invalid Registration) to any client that
+- attempts to register a value for this attribute. A Message Key is
+- not required when exclusively querying for this attribute.
+-
+-7. Security Considerations
+-
+-7.1. iSNS Security Threat Analysis
+-
+- When the iSNS protocol is deployed, the interaction between iSNS
+- server and iSNS clients is subject to the following security threats:
+-
+- a) An attacker could alter iSNS protocol messages, such as to direct
+- iSCSI and iFCP devices to establish connections with rogue peer
+- devices, or to weaken/eliminate IPSec protection for iSCSI or
+- iFCP traffic.
+-
+- b) An attacker could masquerade as the real iSNS server using false
+- iSNS heartbeat messages. This could cause iSCSI and iFCP devices
+- to use rogue iSNS servers.
+-
+- c) An attacker could gain knowledge about iSCSI and iFCP devices by
+- snooping iSNS protocol messages. Such information could aid an
+- attacker in mounting a direct attack on iSCSI and iFCP devices,
+- such as a denial-of-service attack or outright physical theft.
+-
+- To address these threats, the following capabilities are needed:
+-
+- a) Unicast iSNS protocol messages may need to be authenticated. In
+- addition, to protect against threat c), confidentiality support
+- is desirable and is REQUIRED when certain functions of iSNS
+- server are utilized.
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 103]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- b) Multicast iSNS protocol messages such as the iSNS heartbeat
+- message may need to be authenticated. These messages need not be
+- confidential since they do not leak critical information.
+-
+-7.2. iSNS Security Implementation and Usage Requirements
+-
+- If the iSNS server is used to distribute authorizations for
+- communications between iFCP and iSCSI peer devices, IPsec ESP with
+- null transform MUST be implemented, and non-null transform MAY be
+- implemented. If a non-null transform is implemented, then the DES
+- encryption algorithm SHOULD NOT be used.
+-
+- If the iSNS server is used to distribute security policy for iFCP and
+- iSCSI devices, then authentication, data integrity, and
+- confidentiality MUST be supported and used. Where confidentiality is
+- desired or required, IPSec ESP with non-null transform SHOULD be
+- used, and the DES encryption algorithm SHOULD NOT be used.
+-
+- If the iSNS server is used to provide the boot list for clients, as
+- described in Section 6.11.2.9, then the iSCSI boot client SHOULD
+- implement a secure iSNS connection.
+-
+- In order to protect against an attacker masquerading as an iSNS
+- server, client devices MUST support the ability to authenticate
+- broadcast or multicast messages such as the iSNS heartbeat. The iSNS
+- authentication block (which is identical in format to the SLP
+- authentication block) SHALL be used for this purpose. iSNS clients
+- MUST implement the iSNS authentication block and MUST support BSD
+- value 0x002. If the iSNS server supports broadcast or multicast iSNS
+- messages (i.e., the heartbeat), then the server MUST implement the
+- iSNS authentication block and MUST support BSD value 0x002. Note
+- that the authentication block is used only for iSNS broadcast or
+- multicast messages and MUST NOT be used in unicast iSNS messages.
+-
+- There is no requirement that the communicating identities in iSNS
+- protocol messages be kept confidential. Specifically, the identity
+- and location of the iSNS server is not considered confidential.
+-
+- For protecting unicast iSNS protocol messages, iSNS servers
+- supporting security MUST implement ESP in tunnel mode and MAY
+- implement transport mode.
+-
+- All iSNS implementations supporting security MUST support the replay
+- protection mechanisms of IPsec.
+-
+- iSNS security implementations MUST support both IKE Main Mode and
+- Aggressive Mode for authentication, negotiation of security
+- associations, and key management, using the IPSec DOI [RFC2407].
+-
+-
+-
+-Tseng, et al. Standards Track [Page 104]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- Manual keying SHOULD NOT be used since it does not provide the
+- necessary rekeying support. Conforming iSNS security implementations
+- MUST support authentication using a pre-shared key, and MAY support
+- certificate-based peer authentication using digital signatures. Peer
+- authentication using the public key encryption methods outlined in
+- IKEs Sections 5.2 and 5.3 [RFC2409] SHOULD NOT be supported.
+-
+- Conforming iSNS implementations MUST support both IKE Main Mode and
+- Aggressive Mode. IKE Main Mode with pre-shared key authentication
+- SHOULD NOT be used when either of the peers use dynamically assigned
+- IP addresses. Although Main Mode with pre-shared key authentication
+- offers good security in many cases, situations where dynamically
+- assigned addresses are used force the use of a group pre-shared key,
+- which is vulnerable to man-in-the-middle attack. IKE Identity
+- Payload ID_KEY_ID MUST NOT be used.
+-
+- When digital signatures are used for authentication, either IKE Main
+- Mode or IKE Aggressive Mode MAY be used. In all cases, access to
+- locally stored secret information (pre-shared key or private key for
+- digital signing) MUST be suitably restricted, since compromise of the
+- secret information nullifies the security properties of the IKE/IPsec
+- protocols.
+-
+- When digital signatures are used to achieve authentication, an IKE
+- negotiator SHOULD use IKE Certificate Request Payload(s) to specify
+- the certificate authority (or authorities) that are trusted in
+- accordance with its local policy. IKE negotiators SHOULD check the
+- pertinent Certificate Revocation List (CRL) before accepting a PKI
+- certificate for use in IKE's authentication procedures.
+-
+- When the iSNS server is used without security, IP block storage
+- protocol implementations MUST support a negative cache for
+- authentication failures. This allows implementations to avoid
+- continually contacting discovered endpoints that fail authentication
+- within IPsec or at the application layer (in the case of iSCSI
+- Login). The negative cache need not be maintained within the IPsec
+- implementation, but rather within the IP block storage protocol
+- implementation.
+-
+-7.3. Discovering Security Requirements of Peer Devices
+-
+- Once communication between iSNS clients and the iSNS server has been
+- secured through use of IPSec, the iSNS client devices have the
+- capability to discover the security settings that they need to use
+- for their peer-to-peer communications using the iSCSI and/or iFCP
+- protocols. This provides a potential scaling advantage over device-
+- by-device configuration of individual security policies for each
+- iSCSI and iFCP device.
+-
+-
+-
+-Tseng, et al. Standards Track [Page 105]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- The iSNS server stores security settings for each iSCSI and iFCP
+- device interface. These security settings, which can be retrieved by
+- authorized hosts, include use or non-use of IPSec, IKE, Main Mode,
+- and Aggressive Mode. For example, IKE may not be enabled for a
+- particular interface of a peer device. If a peer device can learn of
+- this in advance by consulting the iSNS server, it will not need to
+- waste time and resources attempting to initiate an IKE phase 1
+- session with that peer device interface.
+-
+- If iSNS is used for this purpose, then the minimum information that
+- should be learned from the iSNS server is the use or non-use of IKE
+- and IPSec by each iFCP or iSCSI peer device interface. This
+- information is encoded in the Security Bitmap field of each Portal of
+- the peer device, and is applicable on a per-interface basis for the
+- peer device. iSNS queries for acquiring security configuration data
+- about peer devices MUST be protected by IPSec/ESP authentication.
+-
+-7.4. Configuring Security Policies of iFCP/iSCSI Devices
+-
+- Use of iSNS for distribution of security policies offers the
+- potential to reduce the burden of manual device configuration, and to
+- decrease the probability of communications failures due to
+- incompatible security policies. If iSNS is used to distribute
+- security policies, then IPSec authentication, data integrity, and
+- confidentiality MUST be used to protect all iSNS protocol messages.
+-
+- The complete IKE/IPSec configuration of each iFCP and/or iSCSI device
+- can be stored in the iSNS server, including policies that are used
+- for IKE Phase 1 and Phase 2 negotiations between client devices. The
+- IKE payload format includes a series of one or more proposals that
+- the iSCSI or iFCP device will use when negotiating the appropriate
+- IPsec policy to use to protect iSCSI or iFCP traffic.
+-
+- In addition, the iSCSI Authentication Methods used by each iSCSI
+- device can also be stored in the iSNS server. The iSCSI AuthMethod
+- field (tag=42) contains a null-terminated string embedded with the
+- text values indicating iSCSI authentication methods to be used by
+- that iSCSI device.
+-
+- Note that iSNS distribution of security policy is not necessary if
+- the security settings can be determined by other means, such as
+- manual configuration or IPsec security policy distribution. If a
+- network entity has already obtained its security configuration via
+- other mechanisms, then it MUST NOT request security policy via iSNS.
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 106]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-7.5. Resource Issues
+-
+- The iSNS protocol is lightweight and will not generate a significant
+- amount of traffic. iSNS traffic is characterized by occasional
+- registration, notification, and update messages that do not consume
+- significant amounts of bandwidth. Even software-based IPSec
+- implementations should not have a problem handling the traffic loads
+- generated by the iSNS protocol.
+-
+- To fulfill iSNS security requirements, the only additional resources
+- needed beyond what is already required for iSCSI and iFCP involve the
+- iSNS server. Because iSCSI and iFCP end nodes are already required
+- to implement IKE and IPSec, these existing requirements can also be
+- used to fulfill IKE and IPSec requirements for iSNS clients.
+-
+-7.6. iSNS Interaction with IKE and IPSec
+-
+- When IPSec security is enabled, each iSNS client with at least one
+- Storage Node that is registered in the iSNS database SHALL maintain
+- at least one phase-1 security association with the iSNS server. All
+- iSNS protocol messages between iSNS clients and the iSNS server SHALL
+- be protected by a phase-2 security association.
+-
+- When a Network Entity is removed from the iSNS database, the iSNS
+- server SHALL send a phase-1 delete message to the associated iSNS
+- client IKE peer, and tear down all phase-1 and phase-2 SAs associated
+- with that iSNS client.
+-
+-8. IANA Considerations
+-
+- The well-known TCP and UDP port number for iSNS is 3205.
+-
+- The standards action of this RFC creates two registries to be
+- maintained by IANA in support of iSNSP and assigns initial values for
+- both registries. The first registry is of Block Storage Protocols
+- supported by iSNS. The second registry is a detailed registry of
+- standard iSNS attributes that can be registered to and queried from
+- the iSNS server. Note that this RFC uses the registry created for
+- Block Structure Descriptor (BSD) in Section 15 of Service Location
+- Protocol, Version 2 [RFC2608].
+-
+-8.1. Registry of Block Storage Protocols
+-
+- In order to maintain a registry of block storage protocols supported
+- by iSNSP, IANA will assign a 32-bit unsigned integer number for each
+- block storage protocol supported by iSNS. This number is stored in
+- the iSNS database as the Entity Protocol. The initial set of values
+- to be maintained by IANA for Entity Protocol is indicated in the
+-
+-
+-
+-Tseng, et al. Standards Track [Page 107]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- table in Section 6.2.2. Additional values for new block storage
+- protocols to be supported by iSNS SHALL be assigned by the IPS WG
+- Chairperson, or by a Designated Expert [RFC2434] appointed by the
+- IETF Transport Area Director.
+-
+-8.2. Registry of Standard iSNS Attributes
+-
+- IANA is responsible for creating and maintaining the Registry of
+- Standard iSNS Attributes. The initial list of iSNS attributes is
+- described in Section 6. For each iSNS attribute this information
+- MUST include, its tag value, the attribute length, and the tag values
+- for the set of permissible registration and query keys that can be
+- used for that attribute. The initial list of iSNS attributes to be
+- maintained by IANA is indicated in Section 6.1.
+-
+- Additions of new standard attributes to the Registry of Standard iSNS
+- Attributes SHALL require IETF Consensus [RFC2434]. The RFC required
+- for this process SHALL specify use of tag values reserved for IANA
+- allocation in Section 6.1. The RFC SHALL specify as a minimum, the
+- new attribute tag value, attribute length, and the set of permissible
+- registration and query keys that can be used for the new attribute.
+- The RFC SHALL also include a discussion of the reasons for the new
+- attribute(s) and how the new attribute(s) are to be used.
+-
+- As part of the process of obtaining IETF Consensus, the proposed RFC
+- and its supporting documentation SHALL be made available to the IPS
+- WG mailing list or, if the IPS WG is disbanded at the time, to a
+- mailing list designated by the IETF Transport Area Director. The
+- review and comment period SHALL last at least three months before the
+- IPS WG Chair or a person designated by the IETF Transport Area
+- Director decides either to reject the proposal or to forward the
+- draft to the IESG for publication as an RFC. When the specification
+- is published as an RFC, then IANA will register the new iSNS
+- attribute(s) and make the registration available to the community.
+-
+-8.3. Block Structure Descriptor (BSD) Registry
+-
+- Note that IANA is already responsible for assigning and maintaining
+- values used for the Block Structure Descriptor for the iSNS
+- Authentication Block (see Section 5.5). Section 15 of [RFC2608]
+- describes the process for allocation of new BSD values.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 108]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-9. Normative References
+-
+- [iSCSI] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
+- and E. Zeidner, "Internet Small Computer Systems
+- Interface (iSCSI)", RFC 3720, April 2004.
+-
+- [iFCP] Monia, C., Mullendore, R., Travostino, F., Jeong, W.,
+- and M. Edwards, "iFCP - A Protocol for Internet Fibre
+- Channel Storage Networking", RFC 4172, September 2005.
+-
+- [iSNSOption] Monia, C., Tseng, J., and K. Gibbons, The IPv4 Dynamic
+- Host Configuration Protocol (DHCP) Option for the
+- Internet Storage Name Service, RFC 4174, September 2005.
+-
+- [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
+- "Service Location Protocol, Version 2 ", RFC 2608, June
+- 1999.
+-
+- [iSCSI-SLP] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and
+- T. Sperry, "Finding Internet Small Computer Systems
+- Interface (iSCSI) Targets and Name Servers by Using
+- Service Location Protocol version 2 (SLP), RFC 4018,
+- April 2005.
+-
+- [iSCSI-boot] Sarkar, P., Missimer, D., and C. Sapuntzakis,
+- "Bootstrapping Clients using the Internet Samll Computer
+- System Interface (iSCSI) Protocol", RFC 4173, September
+- 2005.
+-
+- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+- Requirement Levels", BCP 14, RFC 2119, March 1997.
+-
+- [STRINGPREP] Bakke, M., "String Profile for Internet Small Computer
+- Systems Interface (iSCSI) Names", RFC 3722, April 2004.
+-
+- [NAMEPREP] Hoffman, P. Nameprep: A Stringprep Profile for
+- Internationalized Domain Names, July 2002.
+-
+- [RFC2407] Piper, D., "The Internet IP Security Domain of
+- Interpretation for ISAKMP", RFC 2407, November 1998.
+-
+- [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J.
+- Turner, "Internet Security Association and Key
+- Management Protocol (ISAKMP)", RFC 2408, November 1998.
+-
+- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+- (IKE)", RFC 2409, November 1998.
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 109]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- [EUI-64] Guidelines for 64-bit Global Identifier (EUI-64)
+- Registration Authority, May 2001, IEEE
+-
+- [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
+- Identifiers for the Internet X.509 Public Key
+- Infrastructure Certificate and Certificate Revocation
+- List (CRL) Profile", RFC 3279, April 2002.
+-
+- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+- X.509 Public Key Infrastructure Certificate and
+- Certificate Revocation List (CRL) Profile", RFC 3280,
+- April 2002.
+-
+- [802-1990] IEEE Standards for Local and Metropolitan Area Networks:
+- Overview and Architecture, Technical Committee on
+- Computer Communications of the IEEE Computer Society,
+- May 31, 1990
+-
+- [FC-FS] Fibre Channel Framing and Signaling Interface, NCITS
+- Working Draft Project 1331-D
+-
+-10. Informative References
+-
+- [iSNSMIB] Gibbons, K., et al., "Definitions of Managed Objects for
+- iSNS (Internet Storage name Service)", Work in Progress,
+- July 2003.
+-
+- [X.509] ITU-T Recommendation X.509 (1997 E): Information
+- Technology - Open Systems Interconnection - The
+- Directory: Authentication Framework, June 1997
+-
+- [FC-GS-4] Fibre Channel Generic Services-4 (work in progress),
+- NCITS Working Draft Project 1505-D
+-
+- [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
+- Authentication Service (V5)", RFC 1510, September 1993.
+-
+- [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
+- (SPKM)", RFC 2025, October 1996.
+-
+- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+- October 1998.
+-
+- [RFC2945] Wu, T., "The SRP Authentication and Key Exchange
+- System", RFC 2945, September 2000.
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 110]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
+- Protocol (CHAP)", RFC 1994, August 1996.
+-
+- [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
+- 2131, March 1997.
+-
+- [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+- "Introduction and Applicability Statements for
+- Internet-Standard Management Framework", RFC 3410,
+- December 2002.
+-
+- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
+- Architecture for Describing Simple Network Management
+- Protocol (SNMP) Management Frameworks", STD 62, RFC
+- 3411, December 2002.
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 111]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-Appendix A: iSNS Examples
+-
+-A.1. iSCSI Initialization Example
+-
+- This example assumes an SLP Service Agent (SA) has been implemented
+- on the iSNS host, and an SLP User Agent (UA) has been implemented on
+- the iSNS initiator. See [RFC2608] for further details on SAs and
+- UAs. This example also assumes that the target is configured to use
+- the iSNS server, and have its access control policy subordinated to
+- the iSNS server.
+-
+-A.1.1. Simple iSCSI Target Registration
+-
+- In this example, a simple target with a single iSCSI name registers
+- with the iSNS server. The target is represented in the iSNS by an
+- Entity containing one Storage Node, one Portal, and an implicitly
+- registered Portal Group that provides a relationship between the
+- Storage Node and Portal. The target has not been assigned a Fully
+- Qualified Domain Name (FQDN) by the administrator. In this example,
+- because a PG object is not explicitly registered, a Portal Group with
+- a PGT of 1 is implicitly registered. In this example SLP is used to
+- discover the location of the iSNS Server. An alternative is to use
+- the iSNS DHCP option [iSNSOption] to discover the iSNS server.
+-
+- +--------------------------+------------------+-------------------+
+- | iSCSI Target Device | iSNS Server |Management Station |
+- +--------------------------+------------------+-------------------+
+- |Discover iSNS--SLP------->| |/*mgmt station is |
+- | |<--SLP--iSNS Here:| administratively |
+- | | 192.0.2.100 | authorized to view|
+- | | | all DDs. Device |
+- | DevAttrReg--------->| | NAMEabcd was |
+- |Src:(tag=32) "NAMEabcd" | | previously placed |
+- |Key: <none present> | | into DDabcd along |
+- |Oper Attrs: | | with devpdq and |
+- |tag=1: NULL | | devrst. |
+- |tag=2: "iSCSI" | | |
+- |tag=16: 192.0.2.5 | | |
+- |tag=17: 5001 | | |
+- |tag=32: "NAMEabcd" | | |
+- |tag=33: target | | |
+- |tag=34: "disk 1" | | |
+- | |<---DevAttrRegRsp | |
+- | |SUCCESS | |
+- | |Key:(tag=1) "isns:0001" |
+- | |Oper Attrs: | |
+- | |tag=1: "isns:0001"| |
+- | |tag=2: "iSCSI" | |
+-
+-
+-
+-Tseng, et al. Standards Track [Page 112]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- | |tag=16: 192.0.2.5 | |
+- | |tag=17: 5001 | |
+- | |tag=32: "NAMEabcd"|/* previously |
+- | |tag=33: target | placed in a DD */ |
+- | |tag=34: "disk 1" | |
+- | | | |
+- | | SCN-------->| |
+- | |(or SNMP notification) |
+- | |dest:(tag=32):"MGMTname1" |
+- | |time:(tag=4): <current time> |
+- | |tag=35: "MGT-SCN, OBJ-ADD" |
+- | |tag=32: "NAMEabcd"| |
+- | | |<-------SCNRsp |
+- | DevAttrQry--------->| | |
+- |Src:(tag=32) "NAMEabcd" | | |
+- |Key:(tag=33) "initiator" | | |
+- |Oper Attrs: | | |
+- |tag=16: NULL | | |
+- |tag=17: NULL | | |
+- |tag=32: NULL | | |
+- |/*Query asks for all initr| | |
+- |devices' IP address, port |<---DevAttrQryRsp | |
+- |number, and Name*/ |SUCCESS | |
+- | |tag=16:192.0.2.1 | |
+- | |tag=17:50000 | |
+- | |tag=32:"devpdq" | |
+- | |tag=16:192.0.2.2 | |
+- | |tag=17:50000 | |
+- | |tag=32:"devrst" | |
+- |/*************************| |<-----DevAttrQry |
+- |Our target "NAMEabcd" | |src: "MGMTname1" |
+- |discovers two initiators | key:(tag=32)"NAMEabcd"
+- |in shared DDs. It will | |Op Attrs: |
+- |accept iSCSI logins from | |tag=16: NULL |
+- |these two identified | |tag=17: NULL |
+- |initiators presented by | |tag=32: NULL |
+- |iSNS | | |
+- |*************************/| DevAttrQryRsp--->| |
+- | |SUCCESS | |
+- | |tag=16: 192.0.2.5 | |
+- | |tag=17: 5001 | |
+- | |tag=32: "NAMEabcd"| |
+- +--------------------------+------------------+-------------------+
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 113]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-A.1.2. Target Registration and DD Configuration
+-
+- In this example, a more complex target, with two Storage Nodes and
+- two Portals using ESI monitoring, registers with the iSNS. This
+- target has been configured with a Fully Qualified Domain Name (FQDN)
+- in the DNS servers, and the user wishes to use this identifier for
+- the device. The target explicitly registers Portal Groups to
+- describe how each Portal provides access to each Storage Node. One
+- target Storage Node allows coordinated access through both Portals.
+- The other Storage Node allows access, but not coordinated access,
+- through both Portals.
+-
+- +--------------------------+------------------+-------------------+
+- | iSCSI Target Device | iSNS Server |Management Station |
+- +--------------------------+------------------+-------------------+
+- |Discover iSNS--SLP--> | |/*mgmt station is |
+- | |<--SLP--iSNS Here:| administratively |
+- | | 192.0.2.100 | authorized to view|
+- | DevAttrReg--> | | all DDs */ |
+- |Src: | | |
+- |tag=32: "NAMEabcd" | | |
+- |Msg Key: | | |
+- |tag=1: "jbod1.example.com"| | |
+- |Oper Attrs: | | |
+- |tag=1: "jbod1.example.com"| | |
+- |tag=2: "iSCSI" | | |
+- |tag=16: 192.0.2.4 | | |
+- |tag=17: 5001 | | |
+- |tag=19: 5 | | |
+- |tag=20: 5002 | | |
+- |tag=16: 192.0.2.5 | | |
+- |tag=17: 5001 | | |
+- |tag=19: 5 | | |
+- |tag=20: 5002 | | |
+- |tag=32: "NAMEabcd" | | |
+- |tag=33: "Target" | | |
+- |tag=34: "Storage Array 1" | | |
+- |tag=51: 10 | | |
+- |tag=49: 192.0.2.4 | | |
+- |tag=50: 5001 | | |
+- |tag=49: 192.0.2.5 | | |
+- |tag=50: 5001 | | |
+- |tag=32: "NAMEefgh" | | |
+- |tag=33: "Target" | | |
+- |tag=34: "Storage Array 2" |/*****************| |
+- |tag=51: 20 |jbod1.example.com is |
+- |tag=49: 192.0.2.4 |now registered in | |
+- |tag=50: 5001 |iSNS, but is not | |
+-
+-
+-
+-Tseng, et al. Standards Track [Page 114]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- |tag=51: 30 |in any DD. Therefore, |
+- |tag=49: 192.0.2.5 |no other devices | |
+- |tag=50: 5001 |can "see" it. | |
+- | |*****************/| |
+- | |<--DevAttrRegRsp | |
+- | |SUCCESS | |
+- | |Msg Key: | |
+- | |tag=1: "jbod1.example.com" |
+- | |Oper Attrs: | |
+- | |tag=1: "jbod1.example.com" |
+- | |tag=2: "iSCSI" | |
+- | |tag=16: 192.0.2.4 | |
+- | |tag=17: 5001 | |
+- | |tag=19: 5 | |
+- | |tag=20: 5002 | |
+- | |tag=16: 192.0.2.5 | |
+- | |tag=17: 5001 | |
+- | |tag=19: 5 | |
+- | |tag=20: 5002 | |
+- | |tag=32: "NAMEabcd"| |
+- | |tag=33: "Target" | |
+- | |tag=34: "Storage Array 1" |
+- | |tag=48: "NAMEabcd"| |
+- | |tag=49: 192.0.2.4 | |
+- | |tag=50: 5001 | |
+- | |tag=51: 10 | |
+- | |tag=48: "NAMEabcd"| |
+- | |tag=49: 192.0.2.5 | |
+- | |tag=50: 5001 | |
+- | |tag=51: 10 | |
+- | |tag=32: "NAMEefgh"| |
+- | |tag=33: "Target" | |
+- | |tag=34: "Storage Array 2" |
+- | |tag=43: X.509 cert| |
+- | |tag=48: "NAMEefgh"| |
+- | |tag=49: 192.0.2.4 | |
+- | |tag=50: 5001 | |
+- | |tag=51: 20 | |
+- | |tag=48: "NAMEefgh"| |
+- | |tag=49: 192.0.2.5 | |
+- | |tag=50: 5001 | |
+- | |tag=51: 30 | |
+- | | | |
+- | | SCN------> | |
+- | | (or SNMP notification) |
+- | |dest:(tag=32)"mgmt.example.com" |
+- | |time:(tag=4): <current time> |
+- | |tag=35: "MGT-SCN, OBJ-ADD" |
+-
+-
+-
+-Tseng, et al. Standards Track [Page 115]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- | |tag=32: "NAMEabcd"| |
+- | |tag=35: "MGT-SCN, OBJ-ADD" |
+- | |tag=32: "NAMEefgh"| |
+- | | |<--SCNRsp |
+- | | |SUCCESS |
+- | | tag=32:"mgmt.example.com"|
+- | | | |
+- | | |<--DevAttrQry |
+- | | |Src: |
+- | | tag=32:"mgmt.example.com"
+- | | |Msg Key: |
+- | | |tag=32: "NAMEabcd" |
+- | | |Oper Attrs: |
+- | | |tag=16: <0-length> |
+- | | |tag=17: <0-length> |
+- | | |tag=32: <0-length> |
+- | | | |
+- | | DevAttrQryRsp--> | |
+- | |SUCCESS | |
+- | |Msg Key: | |
+- | |tag=32: "NAMEabcd"| |
+- | |Oper Attrs: | |
+- | |tag=16: 192.0.2.4 | |
+- | |tag=17: 5001 | |
+- | |tag=32:"NAMEabcd" | |
+- | |tag=16: 192.0.2.5 | |
+- | |tag=17: 5001 | |
+- | |tag=32:"NAMEabcd" | |
+- | | |Src: |
+- | | tag=32:"mgmt.example.com"
+- | | |Msg Key: |
+- | | |tag=32: "NAMEefgh" |
+- | | |Oper Attrs: |
+- | | |tag=16: <0-length> |
+- | | |tag=17: <0-length> |
+- | | |tag=32: <0-length> |
+- | | | |
+- | | DevAttrQryRsp--> | |
+- | |SUCCESS | |
+- | |Msg Key: | |
+- | |tag=32: "NAMEefgh"| |
+- | |Oper Attrs: | |
+- | |tag=16: 192.0.2.4 | |
+- | |tag=17: 5001 | |
+- | |tag=32:"NAMEefgh" | |
+- | |tag=16: 192.0.2.5 |/**Mgmt Station ***|
+- | |tag=17: 5001 |displays device, |
+- | |tag=32:"NAMEefgh" |the operator decides
+-
+-
+-
+-Tseng, et al. Standards Track [Page 116]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- | | |to place "NAMEabcd"|
+- | | |into Domain "DDxyz"|
+- |/*************************| |******************/|
+- |Target is now registered | | |
+- |in iSNS. It is then placed| |<--DDReg |
+- |in a pre-existing DD with | |Src: |
+- |DD_ID 123 by a management | tag=32:"mgmt.example.com"
+- |station. | |Msg Key: |
+- |*************************/| |tag=2065: 123 |
+- | | |Oper Attrs: |
+- | | |tag=2068: "NAMEabcd"
+- | | DDRegRsp-----> | |
+- | |SUCCESS | |
+- | |Msg Key: | |
+- | |tag=2065: 123 | |
+- | |Oper Attrs: | |
+- | |tag=2065: 123 | |
+- +--------------------------+------------------+-------------------+
+-
+-A.1.3. Initiator Registration and Target Discovery
+-
+- The following example illustrates a new initiator registering with
+- the iSNS, and discovering the target NAMEabcd from the example in
+- A.1.2.
+-
+- +--------------------------+------------------+-------------------+
+- | iSCSI Initiator | iSNS |Management Station |
+- +--------------------------+------------------+-------------------+
+- |Discover iSNS--SLP--> | |/*mgmt station is |
+- | |<--SLP--iSNS Here:| administratively |
+- | | 192.36.53.1 | authorized to view|
+- |DevAttrReg--> | | all DDs ********/ |
+- |Src: | | |
+- |tag=32: "NAMEijkl" | | |
+- |Msg Key: | | |
+- |tag=1: "svr1.example.com" | | |
+- |Oper Attrs: | | |
+- |tag=1: "svr1.example.com" | | |
+- |tag=2: "iSCSI" | | |
+- |tag=16: 192.20.3.1 |/*****************| |
+- |tag=17: 5001 |Device not in any | |
+- |tag=19: 5 |DD, so it is | |
+- |tag=20: 5002 |inaccessible by | |
+- |tag=32: "NAMEijkl" |other devices | |
+- |tag=33: "Initiator" |*****************/| |
+- |tag=34: "Server1" | | |
+- |tag=51: 11 | | |
+- |tag=49: 192.20.3.1 | | |
+-
+-
+-
+-Tseng, et al. Standards Track [Page 117]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- |tag=50: 5001 | | |
+- | |<--DevAttrRegRsp | |
+- | |SUCCESS | |
+- | |Msg Key: | |
+- | |tag=1: "svr1.example.com" |
+- | |Oper Attrs: | |
+- | |tag=1: "svr1.example.com" |
+- | |tag=2: "iSCSI" | |
+- | |tag=16: 192.20.3.1| |
+- | |tag=17: 5001 | |
+- | |tag=19: 5 | |
+- | |tag=20: 5002 | |
+- | |tag=32: "NAMEijkl"| |
+- | |tag=33: "Initiator" |
+- | |tag=34: "Server1" | |
+- | |tag=48: "NAMEijkl"| |
+- | |tag=49: 192.20.3.1| |
+- | |tag=50: 5001 | |
+- | |tag=51: 11 | |
+- | | | |
+- | | SCN------> | |
+- | | (or SNMP notification) |
+- | |dest:(tag=32)"mgmt.example.com" |
+- | |time:(tag=4): <current time> |
+- | |tag=35: "MGT-SCN, OBJ-ADD" |
+- | |tag=32: "NAMEijkl"| |
+- | | | |
+- | | |<------SCNRsp |
+- | | |SUCCESS |
+- | | tag=32:"mgmt.example.com"
+- | | | |
+- |SCNReg--> | | |
+- |Src: | | |
+- |tag=32: "NAMEijkl" | | |
+- |Msg Key: | | |
+- |tag=32: "NAMEijkl" | | |
+- |Oper Attrs: | | |
+- |tag=35: <TARG&SELF, OBJ-RMV/ADD/UPD> | |
+- | |<--SCNRegRsp | |
+- | |SUCCESS | |
+- | | | |
+- | | |<----DevAttrQry |
+- | | |Src: |
+- | | tag=32:"mgmt.example.com"
+- | | |Msg Key: |
+- | | |tag=32: "NAMEijkl" |
+- | | |Oper Attrs: |
+- | | |tag=16: <0-length> |
+-
+-
+-
+-Tseng, et al. Standards Track [Page 118]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- | | |tag=17: <0-length> |
+- | | |tag=32: <0-length> |
+- | | DevAttrQryRsp--->| |
+- | |SUCCESS | |
+- | |Msg Key: | |
+- | |tag=32: "NAMEijkl"| |
+- | |Oper Attrs: | |
+- | |tag=16:192.20.3.1 | |
+- | |tag=17: 5001 | |
+- | |tag=32:"NAMEijkl" | |
+- | | |/**Mgmt Station ***|
+- | | |displays device, the
+- | | |operator decides to|
+- | | |place "NAMEijkl" into
+- | | |pre-existing Disc |
+- | | |Domain "DDxyz" with|
+- | | |device NAMEabcd |
+- | | |******************/|
+- | | |<--DDReg |
+- | | |Src: |
+- | | tag=32:"mgmt.example.com"
+- | | |Msg Key: |
+- | | |tag=2065: 123 |
+- | | |Oper Attrs: |
+- | | |tag=2068: "NAMEijkl"
+- | | | |
+- | | DDRegRsp---->| |
+- | |SUCCESS | |
+- | |Msg Key: | |
+- | |tag=2065: 123 | |
+- | |Oper Attrs: | |
+- | |tag=2065: 123 |/******************|
+- | | |"NAMEijkl" has been|
+- | | |moved to "DDxyz" |
+- | | |******************/|
+- | | SCN------>| |
+- | |dest:(tag=32)"mgmt.example.com" |
+- | |time:(tag=4): <current time> |
+- | |tag=35: <MGT-SCN, DD/DDS-MBR-ADD> |
+- | |tag=2065: 123 | |
+- | |tag=2068: "NAMEijkl" |
+- | | | |
+- | | |<------SCNRsp |
+- | | |SUCCESS |
+- | | tag=32:"mgmt.example.com"
+- | |<-----SCN | |
+- | |dest:(tag=32)"NAMEijkl" |
+- | |time:(tag=4): <current time> |
+-
+-
+-
+-Tseng, et al. Standards Track [Page 119]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- | |tag=35: <TARG&SELF, OBJ-ADD> |
+- | |tag=32: "NAMEijkl"| |
+- | SCNRsp------> | | |
+- |SUCCESS | | |
+- |tag=32:"NAMEijkl" | | |
+- | | | |
+- | |/*****************| |
+- | |Note that NAMEabcd| |
+- | |also receives an | |
+- | |SCN that NAMEijkl | |
+- | |is in the same DD | |
+- | |*****************/| |
+- | (to "NAMEabcd")|<-----SCN | |
+- | |dest:(tag=32)"NAMEabcd" |
+- | |time:(tag=4): <current time> |
+- | |tag=35: <INIT&SELF, OBJ-ADD> |
+- | |tag=32: "NAMEijkl"| |
+- | SCNRsp------> | | |
+- |SUCCESS | | |
+- |tag=32:"NAMEabcd" | | |
+- | | | |
+- | DevAttrQry----------->| | |
+- |Src: | | |
+- |tag=32: "NAMEijkl" | | |
+- |Msg Key: | | |
+- |tag=33: "Target" | | |
+- |Oper Attrs: | | |
+- |tag=16: <0-length> | | |
+- |tag=17: <0-length> | | |
+- |tag=32: <0-length> | | |
+- |tag=34: <0-length> | | |
+- |tag=43: <0-length> | | |
+- |tag=48: <0-length> | | |
+- |tag=49: <0-length> | | |
+- |tag=50: <0-length> | | |
+- |tag=51: <0-length> | | |
+- | |<--DevAttrQryRsp | |
+- | |SUCCESS | |
+- | |Msg Key: | |
+- | |tag=33:"Target" | |
+- | |Oper Attrs: | |
+- | |tag=16: 192.0.2.4 | |
+- | |tag=17: 5001 | |
+- | |tag=32: "NAMEabcd"| |
+- | |tag=34: "Storage Array 1" |
+- | |tag=16: 192.0.2.5 | |
+- | |tag=17: 5001 | |
+- | |tag=32: "NAMEabcd"| |
+-
+-
+-
+-Tseng, et al. Standards Track [Page 120]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+- | |tag=34: "Storage Array 1" |
+- | |tag=43: X.509 cert| |
+- | |tag=48: "NAMEabcd"| |
+- | |tag=49: 192.0.2.4 | |
+- | |tag=50: 5001 | |
+- | |tag=51: 10 | |
+- | |tag=48: "NAMEabcd"| |
+- | |tag=49: 192.0.2.5 | |
+- | |tag=50: 5001 | |
+- | |tag=51: 10 | |
+- | | | |
+- |/***The initiator has discovered | |
+- |the target, and has everything | |
+- |needed to complete iSCSI login | |
+- |The same process occurs on the | |
+- |target side; the SCN prompts the | |
+- |target to download the list of | |
+- |authorized initiators from the | |
+- |iSNS (i.e., those initiators in the | |
+- |same DD as the target.************/ | |
+- +--------------------------+------------------+-------------------+
+-
+-Acknowledgements
+-
+- Numerous individuals contributed to the creation of this document
+- through their careful review and submissions of comments and
+- recommendations. We acknowledge the following persons for their
+- technical contributions to this document: Mark Bakke (Cisco), John
+- Hufferd (IBM), Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe Czap
+- (IBM), John Dowdy (IBM), Tom McSweeney (IBM), Jim Hafner (IBM), Chad
+- Gregory (Intel), Yaron Klein (Sanrad), Larry Lamers (Adaptec), Jack
+- Harwood (EMC), David Black (EMC), David Robinson (Sun), Alan Warwick
+- (Microsoft), Bob Snead (Microsoft), Fa Yoeu (Intransa), Joe White
+- (McDATA), Charles Monia (McDATA), Larry Hofer (McDATA), Ken Hirata
+- (Vixel), Howard Hall (Pirus), Malikarjun Chadalapaka (HP), Marjorie
+- Krueger (HP), Siva Vaddepuri (McDATA), and Vinai Singh (American
+- Megatrends).
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 121]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-Authors' Addresses
+-
+- Josh Tseng
+- Riverbed Technology
+- 501 2nd Street, Suite 410
+- San Francisco, CA 94107
+-
+- Phone: (650)274-2109
+- EMail: joshtseng at yahoo.com
+-
+-
+- Kevin Gibbons
+- McDATA Corporation
+- 4555 Great America Parkway
+- Santa Clara, CA 95054-1208
+-
+- Phone: (408) 567-5765
+- EMail: kevin.gibbons at mcdata.com
+-
+-
+- Franco Travostino
+- Nortel
+- 600 Technology Park Drive
+- Billerica, MA 01821 USA
+-
+- Phone: (978) 288-7708
+- EMail: travos at nortel.com
+-
+-
+- Curt du Laney
+- Rincon Research Corporation
+- 101 North Wilmot Road, Suite 101
+- Tucson AZ 85711
+-
+- Phone: (520) 519-4409
+- EMail: cdl at rincon.com
+-
+-
+- Joe Souza
+- Microsoft Corporation
+- One Microsoft Way
+- Redmond, WA 98052-6399
+-
+- Phone: (425) 706-3135
+- EMail: joes at exmsft.com
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 122]
+-
+-RFC 4171 Internet Storage Name Service (iSNS) September 2005
+-
+-
+-Full Copyright Statement
+-
+- Copyright (C) The Internet Society (2005).
+-
+- This document is subject to the rights, licenses and restrictions
+- contained in BCP 78, and except as set forth therein, the authors
+- retain all their rights.
+-
+- This document and the information contained herein are provided on an
+- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+-
+-Intellectual Property
+-
+- The IETF takes no position regarding the validity or scope of any
+- Intellectual Property Rights or other rights that might be claimed to
+- pertain to the implementation or use of the technology described in
+- this document or the extent to which any license under such rights
+- might or might not be available; nor does it represent that it has
+- made any independent effort to identify any such rights. Information
+- on the procedures with respect to rights in RFC documents can be
+- found in BCP 78 and BCP 79.
+-
+- Copies of IPR disclosures made to the IETF Secretariat and any
+- assurances of licenses to be made available, or the result of an
+- attempt made to obtain a general license or permission for the use of
+- such proprietary rights by implementers or users of this
+- specification can be obtained from the IETF on-line IPR repository at
+- http://www.ietf.org/ipr.
+-
+- The IETF invites any interested party to bring to its attention any
+- copyrights, patents or patent applications, or other proprietary
+- rights that may cover technology that may be required to implement
+- this standard. Please address the information to the IETF at ietf-
+- ipr at ietf.org.
+-
+-Acknowledgement
+-
+- Funding for the RFC Editor function is currently provided by the
+- Internet Society.
+-
+-
+-
+-
+-
+-
+-
+-Tseng, et al. Standards Track [Page 123]
+-
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/Makefile.in
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/Makefile.in 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/Makefile.in 2012-03-05 23:02:46.000000000 -0600
+@@ -32,7 +32,6 @@ LIBOBJS = server.o \
+ security.o \
+ authblock.o \
+ policy.o \
+- pki.o \
+ register.o \
+ query.o \
+ getnext.o \
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/objects.h open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/objects.h
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/objects.h 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/objects.h 2012-03-05 23:02:46.000000000 -0600
+@@ -83,6 +83,7 @@ struct isns_object {
+
+ isns_attr_list_t ie_attrs;
+ isns_object_t * ie_container;
++ uint32_t ie_container_idx;
+ isns_object_template_t *ie_template;
+
+ isns_relation_t * ie_relation;
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/security.h open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/security.h
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/security.h 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/security.h 2012-03-05 23:03:38.000000000 -0600
+@@ -6,11 +6,16 @@
+
+ #ifndef ISNS_SECURITY_H
+ #define ISNS_SECURITY_H
+-
+-#include <openssl/evp.h>
+ #include "buffer.h"
+ #include "util.h"
+
++
++#ifdef WITH_SECURITY
++#include <openssl/evp.h>
++#else
++#define EVP_PKEY void
++#endif
++
+ /*
+ * Security context
+ */
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/socket.c open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/socket.c
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/socket.c 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/socket.c 2012-03-05 23:02:46.000000000 -0600
+@@ -562,7 +562,7 @@ void
+ isns_net_stream_accept(isns_socket_t *sock)
+ {
+ isns_socket_t *child;
+- size_t optlen;
++ socklen_t optlen;
+ int fd, passcred = 0;
+
+ fd = accept(sock->is_desc, NULL, NULL);
+@@ -805,7 +805,7 @@ isns_net_stream_xmit(isns_socket_t *sock
+ void
+ isns_net_stream_hup(isns_socket_t *sock)
+ {
+- sock->is_poll_mask &= ~POLLIN;
++ sock->is_poll_mask &= ~(POLLIN|POLLOUT);
+ /* POLLHUP while connecting means we failed */
+ if (sock->is_state == ISNS_SOCK_CONNECTING)
+ isns_net_stream_error(sock, ECONNREFUSED);
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/util.h open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/util.h
+--- open-iscsi-2.0-872-rc4-bnx2i/utils/open-isns/util.h 2010-07-11 04:05:58.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.work/utils/open-isns/util.h 2012-03-05 23:03:38.000000000 -0600
+@@ -9,6 +9,7 @@
+
+ #include <sys/types.h>
+ #include <stdint.h>
++#include <stdlib.h>
+ #include <stdio.h>
+ #include <stddef.h>
+ #include <string.h> // for strdup
diff --git a/iscsi-initiator-utils-sync-uio-0.7.0.8.patch b/iscsi-initiator-utils-sync-uio-0.7.2.1.patch
similarity index 97%
rename from iscsi-initiator-utils-sync-uio-0.7.0.8.patch
rename to iscsi-initiator-utils-sync-uio-0.7.2.1.patch
index 9f59671..b95600e 100644
--- a/iscsi-initiator-utils-sync-uio-0.7.0.8.patch
+++ b/iscsi-initiator-utils-sync-uio-0.7.2.1.patch
@@ -1,6 +1,6 @@
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/aclocal.m4 open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/aclocal.m4
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/aclocal.m4 open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/aclocal.m4
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/aclocal.m4 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/aclocal.m4 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/aclocal.m4 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,7277 @@
+# generated automatically by aclocal 1.9.6 -*- Autoconf -*-
+
@@ -7279,9 +7279,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/aclocal.m4 open-iscsi-2.0-872-
+AC_SUBST([am__untar])
+]) # _AM_PROG_TAR
+
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/ChangeLog open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/ChangeLog
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/ChangeLog open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/ChangeLog
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/ChangeLog 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/ChangeLog 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/ChangeLog 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,7 @@
+Version 0.4.1 (July 20, 2009)
+ * Fix from Mike Christie to determine page size from getpagesize()
@@ -7290,9 +7290,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/ChangeLog open-iscsi-2.0-872-r
+ * Update documentation to indicate IPv6 is not supported
+ * Fix code to catch the message from the CNIC that the network
+ interface is going down.
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/compile open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/compile
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/compile open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/compile
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/compile 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/compile 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/compile 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,142 @@
+#! /bin/sh
+# Wrapper for compilers which do not understand `-c -o'.
@@ -7436,9 +7436,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/compile open-iscsi-2.0-872-rc4
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.guess open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/config.guess
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.guess open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/config.guess
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.guess 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/config.guess 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/config.guess 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,1548 @@
+#! /bin/sh
+# Attempt to guess a canonical system name.
@@ -8988,9 +8988,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.guess open-iscsi-2.0-87
+# time-stamp-format: "%:y-%02m-%02d"
+# time-stamp-end: "'"
+# End:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.h.in open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/config.h.in
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.h.in open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/config.h.in
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.h.in 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/config.h.in 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/config.h.in 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,111 @@
+/* config.h.in. Generated from configure.ac by autoheader. */
+
@@ -9103,9 +9103,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.h.in open-iscsi-2.0-872
+
+/* Define to `unsigned' if <sys/types.h> does not define. */
+#undef size_t
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.sub open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/config.sub
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.sub open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/config.sub
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.sub 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/config.sub 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/config.sub 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,1695 @@
+#! /bin/sh
+# Configuration validation subroutine script.
@@ -10802,13 +10802,13 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/config.sub open-iscsi-2.0-872-
+# time-stamp-format: "%:y-%02m-%02d"
+# time-stamp-end: "'"
+# End:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/configure
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/configure
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/configure 2011-08-03 20:01:16.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/configure 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,22786 @@
+#! /bin/sh
+# Guess values for system-dependent variables and create Makefiles.
-+# Generated by GNU Autoconf 2.59 for iscsiuio 0.7.0.12.
++# Generated by GNU Autoconf 2.59 for iscsiuio 0.7.0.14.
+#
+# Report bugs to <eddie.wai at broadcom.com>.
+#
@@ -11231,8 +11231,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-r
+# Identity of this package.
+PACKAGE_NAME='iscsiuio'
+PACKAGE_TARNAME='iscsiuio'
-+PACKAGE_VERSION='0.7.0.12'
-+PACKAGE_STRING='iscsiuio 0.7.0.12'
++PACKAGE_VERSION='0.7.0.14'
++PACKAGE_STRING='iscsiuio 0.7.0.14'
+PACKAGE_BUGREPORT='eddie.wai at broadcom.com'
+
+# Factoring default headers for most tests.
@@ -11762,7 +11762,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-r
+ # Omit some internal or obsolete options to make the list less imposing.
+ # This message is too long to be a string in the A/UX 3.1 sh.
+ cat <<_ACEOF
-+\`configure' configures iscsiuio 0.7.0.12 to adapt to many kinds of systems.
++\`configure' configures iscsiuio 0.7.0.14 to adapt to many kinds of systems.
+
+Usage: $0 [OPTION]... [VAR=VALUE]...
+
@@ -11828,7 +11828,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-r
+
+if test -n "$ac_init_help"; then
+ case $ac_init_help in
-+ short | recursive ) echo "Configuration of iscsiuio 0.7.0.12:";;
++ short | recursive ) echo "Configuration of iscsiuio 0.7.0.14:";;
+ esac
+ cat <<\_ACEOF
+
@@ -11969,7 +11969,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-r
+test -n "$ac_init_help" && exit 0
+if $ac_init_version; then
+ cat <<\_ACEOF
-+iscsiuio configure 0.7.0.12
++iscsiuio configure 0.7.0.14
+generated by GNU Autoconf 2.59
+
+Copyright (C) 2003 Free Software Foundation, Inc.
@@ -11983,7 +11983,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-r
+This file contains any messages produced by compilers while
+running configure, to aid debugging if configure makes a mistake.
+
-+It was created by iscsiuio $as_me 0.7.0.12, which was
++It was created by iscsiuio $as_me 0.7.0.14, which was
+generated by GNU Autoconf 2.59. Invocation command line was
+
+ $ $0 $@
@@ -32534,7 +32534,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-r
+} >&5
+cat >&5 <<_CSEOF
+
-+This file was extended by iscsiuio $as_me 0.7.0.12, which was
++This file was extended by iscsiuio $as_me 0.7.0.14, which was
+generated by GNU Autoconf 2.59. Invocation command line was
+
+ CONFIG_FILES = $CONFIG_FILES
@@ -32597,7 +32597,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-r
+
+cat >>$CONFIG_STATUS <<_ACEOF
+ac_cs_version="\\
-+iscsiuio config.status 0.7.0.12
++iscsiuio config.status 0.7.0.14
+configured by $0, generated by GNU Autoconf 2.59,
+ with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\"
+
@@ -33592,9 +33592,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure open-iscsi-2.0-872-r
+ $ac_cs_success || { (exit 1); exit 1; }
+fi
+
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure.ac open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/configure.ac
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure.ac open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/configure.ac
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure.ac 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/configure.ac 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/configure.ac 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,92 @@
+dnl iscsiuio uIP user space stack configure.ac file
+dnl
@@ -33609,9 +33609,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure.ac open-iscsi-2.0-87
+dnl
+
+PACKAGE=iscsiuio
-+VERSION=0.7.0.12
++VERSION=0.7.2.1
+
-+AC_INIT(iscsiuio, 0.7.0.12, eddie.wai at broadcom.com)
++AC_INIT(iscsiuio, 0.7.2.1, eddie.wai at broadcom.com)
+
+AM_INIT_AUTOMAKE($PACKAGE, $VERSION)
+AC_CONFIG_HEADER(config.h)
@@ -33688,9 +33688,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/configure.ac open-iscsi-2.0-87
+src/uip/Makefile
+src/unix/Makefile
+src/unix/libs/Makefile])
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/COPYING open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/COPYING
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/COPYING open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/COPYING
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/COPYING 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/COPYING 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/COPYING 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,674 @@
+ GNU GENERAL PUBLIC LICENSE
+ Version 3, 29 June 2007
@@ -34366,9 +34366,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/COPYING open-iscsi-2.0-872-rc4
+the library. If this is what you want to do, use the GNU Lesser General
+Public License instead of this License. But first, please read
+<http://www.gnu.org/philosophy/why-not-lgpl.html>.
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/depcomp open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/depcomp
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/depcomp open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/depcomp
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/depcomp 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/depcomp 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/depcomp 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,589 @@
+#! /bin/sh
+# depcomp - compile a program generating dependencies as side-effects
@@ -34959,18 +34959,18 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/depcomp open-iscsi-2.0-872-rc4
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/docs/iscsiuio.8 open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/docs/iscsiuio.8
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/docs/iscsiuio.8 open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/docs/iscsiuio.8
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/docs/iscsiuio.8 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/docs/iscsiuio.8 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/docs/iscsiuio.8 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,77 @@
-+.\" Copyright (c) 2010-2011 Broadcom Corporation
++.\" Copyright (c) 2010-2012 Broadcom Corporation
+.\" This is free documentation; you can redistribute it and/or
+.\" modify it under the terms of the GNU General Public License as
+.\" published by the Free Software Foundation.
+.\"
-+.\" bnx2.4,v 0.7.0.12
++.\" bnx2.4,v 0.7.2.1
+.\"
-+.TH iscsiuio 8 "08/04/2011" "Broadcom Corporation"
++.TH iscsiuio 8 "03/05/2012" "Broadcom Corporation"
+.\"
+.\" NAME part
+.\"
@@ -35040,10 +35040,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/docs/iscsiuio.8 open-iscsi-2.0
+Benjamin Li \- benli at broadcom.com
+.P
+Eddie Wai \- eddie.wai at broadcom.com
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/config.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/config.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/config.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/config.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/config.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/config.h 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,94 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/config.h 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,76 @@
+/*
+ * iSCSI Configuration
+ *
@@ -35068,6 +35068,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/config.h open-iscsi-2.
+
+#include <netdb.h>
+#include "list.h"
++#include "iscsi_net_util.h"
+
+/* ISIDs now have a typed naming authority in them. We use an OUI */
+#define DRIVER_ISID_0 0x00
@@ -35077,18 +35078,33 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/config.h open-iscsi-2.
+/* max len of interface */
+#define ISCSI_MAX_IFACE_LEN 65
+
-+#if (ISCSID_VERSION == 872) /* 2.0-872 (RHEL 6.0) */
-+
+#define ISCSI_HWADDRESS_BUF_SIZE 18
+#define ISCSI_TRANSPORT_NAME_MAXLEN 16
++#define ISCSI_MAX_STR_LEN 80
+
+typedef struct iface_rec {
+ struct list_head list;
+ /* iscsi iface record name */
+ char name[ISCSI_MAX_IFACE_LEN];
++ uint32_t iface_num;
+ /* network layer iface name (eth0) */
+ char netdev[IFNAMSIZ];
+ char ipaddress[NI_MAXHOST];
++ char subnet_mask[NI_MAXHOST];
++ char gateway[NI_MAXHOST];
++ char bootproto[ISCSI_MAX_STR_LEN];
++ char ipv6_linklocal[NI_MAXHOST];
++ char ipv6_router[NI_MAXHOST];
++ char ipv6_autocfg[NI_MAXHOST];
++ char linklocal_autocfg[NI_MAXHOST];
++ char router_autocfg[NI_MAXHOST];
++ uint16_t vlan_id;
++ uint8_t vlan_priority;
++ char vlan_state[ISCSI_MAX_STR_LEN];
++ char state[ISCSI_MAX_STR_LEN]; /* 0 = disable,
++ * 1 = enable */
++ uint16_t mtu;
++ uint16_t port;
+ /*
+ * TODO: we may have to make this bigger and interconnect
+ * specific for infinniband
@@ -35101,46 +35117,12 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/config.h open-iscsi-2.
+ */
+ char alias[TARGET_NAME_MAXLEN + 1];
+ char iname[TARGET_NAME_MAXLEN + 1];
-+
-+ char vlan[ISCSI_MAX_IFACE_LEN];
-+} iface_rec_t;
-+
-+#else /* 2.0-871 (RHEL 5.5) */
-+/* number of possible connections per session */
-+#define ISCSI_CONN_MAX 1
-+
-+#define ISCSI_TRANSPORT_NAME_MAXLEN 16
-+
-+typedef struct iface_rec {
-+ struct list_head list;
-+ /* iscsi iface record name */
-+ char name[ISCSI_MAX_IFACE_LEN];
-+ /* network layer iface name (eth0) */
-+ char netdev[IFNAMSIZ];
-+ char ipaddress[NI_MAXHOST];
-+
-+ /*
-+ * TODO: we may have to make this bigger and interconnect
-+ * specific for infinniband
-+ */
-+ char hwaddress[ISCSI_MAX_IFACE_LEN];
-+ char transport_name[ISCSI_TRANSPORT_NAME_MAXLEN];
-+ /*
-+ * This is only used for boot now, but the iser guys
-+ * can use this for their virtualization idea.
-+ */
-+ char alias[TARGET_NAME_MAXLEN + 1];
-+ char iname[TARGET_NAME_MAXLEN + 1];
-+
-+ char vlan[ISCSI_MAX_IFACE_LEN];
+} iface_rec_t;
+
-+#endif /* ISCSID_VERSION */
-+
+#endif /* CONFIG_H */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/fw_context.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/fw_context.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/fw_context.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/fw_context.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/fw_context.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/fw_context.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/fw_context.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,64 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
@@ -35206,9 +35188,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/fw_context.h open-iscs
+extern void fw_free_targets(struct list_head *list);
+
+#endif /* FWPARAM_CONTEXT_H_ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_if.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/iscsi_if.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_if.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/iscsi_if.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_if.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/iscsi_if.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/iscsi_if.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,473 @@
+/*
+ * iSCSI User/Kernel Shares (Defines, Constants, Protocol definitions, etc)
@@ -35683,9 +35665,24 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_if.h open-iscsi-
+};
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_proto.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/iscsi_proto.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_net_util.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/iscsi_net_util.h
+--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_net_util.h 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/iscsi_net_util.h 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,11 @@
++#ifndef __ISCSI_NET_UTIL_h__
++#define __ISCSI_NET_UTIL_h__
++
++#define ISCSI_HWADDRESS_BUF_SIZE 18
++
++extern int net_get_transport_name_from_netdev(char *netdev, char *transport);
++extern int net_get_netdev_from_hwaddress(char *hwaddress, char *netdev);
++extern int net_setup_netdev(char *netdev, char *local_ip, char *mask,
++ char *gateway, char *remote_ip, int needs_bringup);
++
++#endif
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_proto.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/iscsi_proto.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_proto.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/iscsi_proto.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/iscsi_proto.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,637 @@
+/*
+ * RFC 3720 (iSCSI) protocol data types
@@ -36324,9 +36321,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/iscsi_proto.h open-isc
+/************************* RFC 3720 End *****************************/
+
+#endif /* ISCSI_PROTO_H */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/list.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/list.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/list.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/list.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/list.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/list.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/list.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,93 @@
+#ifndef __LIST_H__
+#define __LIST_H__
@@ -36421,9 +36418,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/list.h open-iscsi-2.0-
+}
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/mgmt_ipc.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/mgmt_ipc.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/mgmt_ipc.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/mgmt_ipc.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/mgmt_ipc.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/mgmt_ipc.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/mgmt_ipc.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,147 @@
+/*
+ * iSCSI Daemon/Admin Management IPC
@@ -36572,9 +36569,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/mgmt_ipc.h open-iscsi-
+void mgmt_ipc_handle(int accept_fd);
+
+#endif /* MGMT_IPC_H */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/sysdeps.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/sysdeps.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/sysdeps.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/sysdeps.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/sysdeps.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/sysdeps.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/sysdeps.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,27 @@
+/*
+ * wrapping of libc features and kernel interfaces
@@ -36603,9 +36600,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/sysdeps.h open-iscsi-2
+extern size_t strlcat(char *dst, const char *src, size_t size);
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/uip_mgmt_ipc.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/uip_mgmt_ipc.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/uip_mgmt_ipc.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/uip_mgmt_ipc.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/uip_mgmt_ipc.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/include/uip_mgmt_ipc.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/include/uip_mgmt_ipc.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,66 @@
+/*
+ * uIP iSCSI Daemon/Admin Management IPC
@@ -36659,11 +36656,11 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/uip_mgmt_ipc.h open-is
+
+typedef enum iscsid_uip_mgmt_ipc_err {
+ ISCSID_UIP_MGMT_IPC_OK = 0,
-+ ISCISD_UIP_MGMT_IPC_ERR = 1,
-+ ISCISD_UIP_MGMT_IPC_ERR_NOT_FOUND = 2,
-+ ISCISD_UIP_MGMT_IPC_ERR_NOMEM = 3,
-+ ISCISD_UIP_MGMT_IPC_DEVICE_UP = 4,
-+ ISCISD_UIP_MGMT_IPC_DEVICE_INITIALIZING = 5,
++ ISCSID_UIP_MGMT_IPC_ERR = 1,
++ ISCSID_UIP_MGMT_IPC_ERR_NOT_FOUND = 2,
++ ISCSID_UIP_MGMT_IPC_ERR_NOMEM = 3,
++ ISCSID_UIP_MGMT_IPC_DEVICE_UP = 4,
++ ISCSID_UIP_MGMT_IPC_DEVICE_INITIALIZING = 5,
+} iscsid_uip_mgmt_ipc_err_e;
+
+/* IPC Response */
@@ -36673,9 +36670,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/include/uip_mgmt_ipc.h open-is
+} iscsid_uip_rsp_t;
+
+#endif /* UIP_MGMT_IPC_H */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/INSTALL open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/INSTALL
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/INSTALL open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/INSTALL
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/INSTALL 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/INSTALL 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/INSTALL 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,291 @@
+Installation Instructions
+*************************
@@ -36968,9 +36965,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/INSTALL open-iscsi-2.0-872-rc4
+`configure' also accepts some other, not widely useful, options. Run
+`configure --help' for more details.
+
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/install-sh open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/install-sh
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/install-sh open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/install-sh
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/install-sh 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/install-sh 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/install-sh 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,519 @@
+#!/bin/sh
+# install - install a program, script, or datafile
@@ -37491,9 +37488,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/install-sh open-iscsi-2.0-872-
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/iscsiuiolog open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/iscsiuiolog
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/iscsiuiolog open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/iscsiuiolog
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/iscsiuiolog 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/iscsiuiolog 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/iscsiuiolog 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,11 @@
+/var/log/iscsiuio.log {
+ weekly
@@ -37506,9 +37503,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/iscsiuiolog open-iscsi-2.0-872
+ endscript
+}
+
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/ltmain.sh open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/ltmain.sh
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/ltmain.sh open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/ltmain.sh
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/ltmain.sh 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/ltmain.sh 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/ltmain.sh 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,6911 @@
+# ltmain.sh - Provide generalized library-building support services.
+# NOTE: Changing this file will not affect anything until you rerun configure.
@@ -44421,9 +44418,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/ltmain.sh open-iscsi-2.0-872-r
+# mode:shell-script
+# sh-indentation:2
+# End:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/Makefile.am
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/Makefile.am
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/Makefile.am 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/Makefile.am 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/Makefile.am 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,25 @@
+SUBDIRS= src
+
@@ -44450,9 +44447,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/Makefile.am open-iscsi-2.0-872
+install-brcm:
+ -rm -f $(sbindir)/brcm_iscsiuio
+ -ln -s $(sbindir)/iscsiuio $(sbindir)/brcm_iscsiuio
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/Makefile.in
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/Makefile.in
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/Makefile.in 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/Makefile.in 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/Makefile.in 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,629 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
@@ -45083,9 +45080,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/Makefile.in open-iscsi-2.0-872
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/missing open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/missing
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/missing open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/missing
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/missing 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/missing 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/missing 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,367 @@
+#! /bin/sh
+# Common stub for a few missing GNU programs while installing.
@@ -45454,21 +45451,21 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/missing open-iscsi-2.0-872-rc4
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/README open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/README
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/README open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/README
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/README 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/README 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,219 @@
-+Broadcom iSCSI Userspace Tools
-+Version 0.7.0.12
-+Aug 04, 2011
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/README 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,224 @@
++Iscsiuio Userspace Tool
++Version 0.7.2.1
++Mar 05, 2012
+------------------------------------------------------
+
-+This tools is to be used in conjunction with the Broadcom NetXtreme II Linux
++This tool is to be used in conjunction with the Broadcom NetXtreme II Linux
+driver (Kernel module name: 'bnx2' and 'bnx2x'), Broadcom CNIC driver,
+and the Broadcom iSCSI driver (Kernel module name: 'bnx2i').
-+This user space driver is used in conjunction with the following
++This user space tool is used in conjunction with the following
+Broadcom Network Controllers:
-+ bnx2: BCM5708, BCM5709 devices
++ bnx2: BCM5706, BCM5708, BCM5709 devices
+ bnx2x: BCM57710, BCM57711, BCM57711E, BCM57712, BCM57712E,
+ BCM57800, BCM57810, BCM57840 devices
+
@@ -45600,7 +45597,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/README open-iscsi-2.0-872-rc4-
+physical net_ifacename (without the VLAN identifier) must be used
+to specify the HBA device. For the proper CNIC routing, the
+corresponding L2 interface which has the associated VLAN interface must
-+be on the same subnet.
++have an IP address on the same subnet.
+
+The following attributes need to be filled when offloading via the
+VLAN interface:
@@ -45612,7 +45609,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/README open-iscsi-2.0-872-rc4-
+
+Setting IP address:
+
-+On RHEL5.4, RHEL5.5, RHEL5.6, RHEL6.0, SLES11SP1 distributions,
++On RHEL5.4, RHEL5.5+, RHEL6.0+, and SLES11SP1 distributions,
+discovery login is done over the Linux TCP/IP stack and L2 network
+interface. The ethx interface corresponding to the HBA must
+therefore be in the same IP subnet in order to reach the iSCSI
@@ -45629,7 +45626,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/README open-iscsi-2.0-872-rc4-
+Setting Netmask and Gateway addresses:
+
+With the current limitations of the iface file, there are no entries
-+to allow the user to enter neither a netmask or gateway IP address.
++to allow the user to enter a netmask or gateway IP address.
+
+The only way to explicitly configure these options is to use DHCP
+addressing. Then the netmask/gateway are set on the DHCP server.
@@ -45641,8 +45638,18 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/README open-iscsi-2.0-872-rc4-
+Debugging:
+=======================================
+
-+The iscsiuio daemon will output messages to the log file,
-+'/var/log/iscsiuio.log'. These messages can be used to help debug any issues.
++By default, the iscsiuio daemon does not output any messages to the log file,
++'/var/log/iscsiuio.log'. Message logging is only enabled when the daemon is
++run under debug mode.
++
++To run the daemon in debug mode please pass the parameter '-d <debug level>'
++
++where the following debug levels are defined:
++
++DEBUG 4 - Print all messages
++INFO 3 - Print messages needed to follow the uIP code (default)
++WARN 2 - Print warning messages
++ERROR 1 - Only print critical errors
+
+A sample banner message:
+
@@ -45650,23 +45657,17 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/README open-iscsi-2.0-872-rc4-
+INFO [Mon Jun 20 11:23:14 2011]Build date: Mon Jun 20 11:22:05 PDT 2011
+INFO [Mon Jun 20 11:23:14 2011]Debug mode enabled
+
++These messages can be used to help debug any issues.
++
+When debugging issues like the iscsid, the iscsiuio daemon can be run
+in the foreground and the maximum debugging level should be used.
+
+To place the daemon in foreground mode please pass the parameter '-f'
-+To run the daemon in debug mode please pass the parameter '-d <debug level>'
-+
-+where the following debug levels are defined:
-+
-+DEBUG 4 - Print all messages
-+INFO 3 - Print messages needed to follow the uIP code (default)
-+WARN 2 - Print warning messages
-+ERROR 1 - Only print critical errors
+
+Note: The messages to the log file are not flushed unless debugging is enabled.
+
+Note: If the daemon iscsiuio is running, one will not be able to
-+ trample over the exisiting binary. One might see the following message:
++ trample over the existing binary. One might see the following message:
+
+ 'cannot create regular file `/sbin/iscsiuio': Text file busy'
+
@@ -45676,23 +45677,140 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/README open-iscsi-2.0-872-rc4-
+containing the iscsiuio logs. This is because full debugging will log
+packet activity which on a busy network will quickly fill the logs.
+
-+Note: If the bnx2i and cnic drivers are unloaed, Then uIP will also need to be restarted so that it can determine the drvier version.
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/RELEASE.TXT open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/RELEASE.TXT
++Note: If the bnx2i and cnic drivers are unloaded, then iscsiuio will also
++need to be restarted so that it can determine the iscsid version.
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/RELEASE.TXT open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/RELEASE.TXT
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/RELEASE.TXT 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/RELEASE.TXT 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,1429 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/RELEASE.TXT 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,1545 @@
+ Release Notes
+ Broadcom uIP Linux Driver
-+ Version 0.7.0.12
-+ 08/04/2011
++ Version 0.7.2.1
++ 03/05/2012
+
+ Broadcom Corporation
+ 5300 California Avenue,
+ Irvine, CA 92617
+
-+ Copyright (c) 2004 - 2011 Broadcom Corporation
++ Copyright (c) 2004 - 2012 Broadcom Corporation
+ All rights reserved
+
++uIP v0.7.2.1 (Mar 05, 2012)
++=======================================================
++ Fixes
++ -----
++ 1. Problem: Cont00060368 - segfault observed after failing both
++ mpio paths
++ Change: Various memory leaks were identified and resolved in
++ the nic cleanup path
++ Impact: All
++
++ 2. Problem: Cont00060734 - ifupdown-mtu change stress with active
++ session causes iscsiuio to fail
++ Change: Fixed a race condition between the nic enable thread
++ and when DHCP fails
++ Impact: All
++
++ 3. Problem: Cont00061459 - MC assert observed when logging into
++ iSCSI target (NPAR BW change)
++ Cause: The if_down message from one NIC was flushed upon
++ the reception of another if_down message from another
++ NIC
++ Change: Fixed the if_down handling on the global netlink queue
++ flush.
++ Impact: All
++
++ 4. Problem: Cont00061708 - Unable to log into target after running
++ driver load/unload
++ Cause: A bug was introduced in the previous bug fix (CQ61459)
++ where a pthread_cond_broadcast call was erroneously
++ enabled
++ Change: Restored this back
++ Impact: All
++
++ Enhancements
++ ------------
++ 1. Change: Default iscsiuio logging to off. Use the '-d'
++ option to enable
++ 2. Change: Disable HP SD mode
++ 3. Change: Updated README
++
++
++uIP v0.7.0.14 (Oct 25, 2011)
++=======================================================
++ Fixes
++ -----
++ 1. Problem: Cont00057840 - RHEL6.2 inbox: Unable to connect to
++ targets with 5709
++ Cause: For cases when the bnx2/bnx2x driver gets removed, the
++ uio database that was built by cnic would have the device
++ ->net reference removed. This has caused an unnecessary
++ timeout of 5s for each stale uio entry in the database.
++ Change: Adjusted the routine which seeks the device->net entry
++ to include more logic instead of hard waiting for 5s.
++
++ 2. Problem: Cont00058256 - Sessions fail after loginstress to via
++ simultaneous ipv4 and ipv6 dhcp
++ Cause: Switching between DHCPv4/v6 coupled with VLAN exposed
++ a drawback in our nic_iface architecture design where
++ VLAN is not specified by iscsid.
++ Change: The code was optimized and improved the performance when
++ switching between DHCPv4/v6+VLAN. However, the ultimate
++ fix is to make use of the net config parameters introduced
++ in the newer open-iscsi util which will identify the
++ specific VLAN nic_iface to use.
++
++ 3. Problem: Cont00058602 - Can't iboot using IPv6 offload path
++ Cause: The bug was exposed by a fix in 0.7.0.14c where the
++ IPv6 router solicitation timeout exceeded the nic
++ enable thread timeout.
++ Change: The IPv6 router solicitation timeout has been adjusted
++
++ 4. Problem: Cont00058678 - Can not iboot target from ipv6 path
++ using VLAN
++ Cause: A bug was found in the path request path where the vlan
++ iface's protocol family was not used correctly in the
++ iface search
++ Change: This has been corrected
++
++ 5. Problem: Cont00058994 - DOS vulnerability in uip during UDP flood
++ Cause: The warning messages from the UDP handler was logging
++ at a rate faster than the log file logrotate rate
++ Therefore, the system's OOM eventually got kicked in to
++ start terminating running processes which includes iscsiuio
++ Change: Moved several UDP warning messages from the default log
++ level to the debug log level
++ Impact: All (minor)
++
++ 6. Problem: Cont00059288 - Show segfault w/ Xen kernel
++ Cause: The bnx2x chip_id was not read correctly from the PCIe BAR1
++ under the Xen kernel. The error was in the mmap area.
++ Change: Corrected the mmapping of the PCI MMIO space.
++ Impact: Xen kernels
++
++ Enhancements
++ ------------
++ 1. Change: Added support for RHEL6.2 for out-of-box release
++ 2. Change: Updated the man page with -h and -p info
++ 3. Change: Updated the -h info
++ 4. Change: Added support for bnx2x-1.71.00
++ 5. Change: Changed the log file open error to a warning and let
++ the daemon progress
++ 6. Change: Added oom_adjust call to prevent OOM Killer from killing
++ iscsiuio when memory is low
++ 7. Change: Added mlockall setting to prevent page swap
++
++
++uIP v0.7.0.13 (Aug 10, 2011)
++=======================================================
++ Fixes
++ -----
++ 1. Problem: Cont00057768 - iscsiuio logrotate causes daemon failure
++ Cause: The logrotate script will send a SIGUSR1 signal to notify
++ the iscsiuio daemon of such action. However, the daemon
++ wasn't programmed to catch this signal.
++ Change: Restored the catching of this signal
++
+
+uIP v0.7.0.12 (Aug 04, 2011)
+=======================================================
@@ -47110,9 +47228,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/RELEASE.TXT open-iscsi-2.0-872
+
+ Impact: Linux
+
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,88 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -47202,9 +47320,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi
+void brcm_iscsi_appcall(struct uip_stack *ustack)
+{
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,90 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -47296,9 +47414,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/brcm_iscsi
+#endif /* __BRCM_ISCSI_H__ */
+/** @} */
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/Makefile.am
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/Makefile.am
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.am 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/Makefile.am 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/Makefile.am 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,12 @@
+INCLUDES = -I${top_srcdir}/src/unix \
+ -I${top_srcdir}/src/uip \
@@ -47312,14 +47430,14 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.a
+
+lib_apps_brcm_iscsi_a_CFLAGS = $(AM_CFLAGS) \
+ -DBYTE_ORDER=@ENDIAN@
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.brcm-iscsi open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/Makefile.brcm-iscsi
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.brcm-iscsi open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/Makefile.brcm-iscsi
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.brcm-iscsi 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/Makefile.brcm-iscsi 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/Makefile.brcm-iscsi 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1 @@
+APP_SOURCES += brcm-iscsi.c
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/Makefile.in
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/Makefile.in
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.in 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/brcm-iscsi/Makefile.in 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/brcm-iscsi/Makefile.in 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,445 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
@@ -47766,9 +47884,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/brcm-iscsi/Makefile.i
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpc.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/dhcpc.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpc.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/dhcpc.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpc.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/dhcpc.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/dhcpc.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,423 @@
+/*
+ * Copyright (c) 2005, Swedish Institute of Computer Science
@@ -48193,9 +48311,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpc.c open-is
+}
+
+/*---------------------------------------------------------------------------*/
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpc.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/dhcpc.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpc.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/dhcpc.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpc.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/dhcpc.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/dhcpc.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,88 @@
+/*
+ * Copyright (c) 2005, Swedish Institute of Computer Science
@@ -48285,9 +48403,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpc.h open-is
+#define UIP_UDP_APPCALL dhcpc_appcall
+
+#endif /* __DHCPC_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpv6.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/dhcpv6.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpv6.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/dhcpv6.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpv6.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/dhcpv6.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/dhcpv6.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,515 @@
+/*
+ * Copyright (c) 2011, Broadcom Corporation
@@ -48804,9 +48922,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpv6.c open-i
+ }
+ }
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpv6.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/dhcpv6.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpv6.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/dhcpv6.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpv6.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/dhcpv6.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/dhcpv6.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,263 @@
+/*
+ * Copyright (c) 2011, Broadcom Corporation
@@ -49071,9 +49189,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/dhcpv6.h open-i
+void dhcpv6_init(pDHCPV6_CONTEXT dhcpv6_context);
+
+#endif /* __IDHCPV6_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/Makefile.am
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/Makefile.am
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.am 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/Makefile.am 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/Makefile.am 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,14 @@
+INCLUDES = -I${top_srcdir}/src/unix \
+ -I${top_srcdir}/src/uip \
@@ -49089,14 +49207,14 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.am ope
+ -DBYTE_ORDER=@ENDIAN@
+
+
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.dhcpc open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/Makefile.dhcpc
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.dhcpc open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/Makefile.dhcpc
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.dhcpc 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/Makefile.dhcpc 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/Makefile.dhcpc 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1 @@
+APP_SOURCES += dhcpc.c timer.c
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/Makefile.in
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/Makefile.in
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.in 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/dhcpc/Makefile.in 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/dhcpc/Makefile.in 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,460 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
@@ -49558,14 +49676,14 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/dhcpc/Makefile.in ope
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/Makefile.am
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/Makefile.am
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/Makefile.am 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/Makefile.am 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/Makefile.am 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1 @@
+SUBDIRS = dhcpc brcm-iscsi
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/Makefile.in
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/Makefile.in
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/Makefile.in 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/Makefile.in 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/Makefile.in 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,471 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
@@ -50038,20 +50156,20 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/Makefile.in open-iscs
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/README open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/README
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/README open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/README
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/apps/README 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/apps/README 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/apps/README 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,2 @@
+This directory contains a few example applications. They are not all
+heavily tested, however.
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/Makefile.am
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/Makefile.am
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/Makefile.am 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/Makefile.am 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/Makefile.am 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1 @@
+SUBDIRS = apps uip unix
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/Makefile.in
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/Makefile.in
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/Makefile.in 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/Makefile.in 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/Makefile.in 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,471 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
@@ -50524,9 +50642,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/Makefile.in open-iscsi-2.0
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/README open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/README
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/README open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/README
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/README 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/README 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/README 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,13 @@
+uIP is a very small implementation of the TCP/IP stack that is written
+by Adam Dunkels <adam at sics.se>. More information can be obtained
@@ -50541,9 +50659,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/README open-iscsi-2.0-872-
+lib/ - Library code used by some applications
+uip/ - uIP TCP/IP stack code
+unix/ - uIP as a user space process under FreeBSD or Linux
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/clock.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/clock.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/clock.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/clock.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/clock.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/clock.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/clock.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,88 @@
+/**
+ * \defgroup clock Clock interface
@@ -50633,9 +50751,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/clock.h open-iscsi-2.0
+#endif /* __CLOCK_H__ */
+
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/debug.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/debug.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/debug.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/debug.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/debug.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/debug.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/debug.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,9 @@
+#ifndef __DEBUG_H__
+#define __DEBUG_H__
@@ -50646,9 +50764,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/debug.h open-iscsi-2.0
+#endif
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/icmpv6.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/icmpv6.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/icmpv6.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/icmpv6.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/icmpv6.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/icmpv6.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/icmpv6.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,312 @@
+/*
+ * Copyright (c) 2011, Broadcom Corporation
@@ -50962,9 +51080,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/icmpv6.h open-iscsi-2.
+#endif
+
+#endif /* __ICMPV6_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,1269 @@
+/*
+ * Copyright (c) 2011, Broadcom Corporation
@@ -52235,9 +52353,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6.c open-iscsi-2.0-
+{
+ ipv6_context->flags |= IPV6_FLAGS_DISABLE_DHCPV6;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,366 @@
+/*
+ * Copyright (c) 2011, Broadcom Corporation
@@ -52605,9 +52723,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6.h open-iscsi-2.0-
+ pIPV6_ADDR ip_addr);
+
+#endif /* __IPV6_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_ndpc.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6_ndpc.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_ndpc.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6_ndpc.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_ndpc.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6_ndpc.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6_ndpc.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,408 @@
+/*
+ * Copyright (c) 2011, Broadcom Corporation
@@ -53017,9 +53135,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_ndpc.c open-iscsi
+}
+
+/*---------------------------------------------------------------------------*/
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_ndpc.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6_ndpc.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_ndpc.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6_ndpc.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_ndpc.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6_ndpc.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6_ndpc.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,97 @@
+/*
+ * Copyright (c) 2011, Broadcom Corporation
@@ -53118,9 +53236,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_ndpc.h open-iscsi
+#define UIP_NDP_CALL ndpc_call
+
+#endif /* __NDPC_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_pkt.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6_pkt.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_pkt.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6_pkt.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_pkt.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/ipv6_pkt.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/ipv6_pkt.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,49 @@
+/*
+ * Copyright (c) 2011, Broadcom Corporation
@@ -53171,9 +53289,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/ipv6_pkt.h open-iscsi-
+void ipv6_send_udp_packet(pIPV6_CONTEXT ipv6_context, u16_t packet_len);
+
+#endif /* __IPV6_PKT_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc-addrlabels.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/lc-addrlabels.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc-addrlabels.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/lc-addrlabels.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc-addrlabels.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/lc-addrlabels.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/lc-addrlabels.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,82 @@
+/*
+ * Copyright (c) 2004-2005, Swedish Institute of Computer Science.
@@ -53257,9 +53375,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc-addrlabels.h open-i
+#endif /* __LC_ADDRLABELS_H__ */
+
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/lc.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/lc.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/lc.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/lc.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,131 @@
+/*
+ * Copyright (c) 2004-2005, Swedish Institute of Computer Science.
@@ -53392,9 +53510,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc.h open-iscsi-2.0-87
+
+/** @} */
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc-switch.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/lc-switch.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc-switch.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/lc-switch.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc-switch.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/lc-switch.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/lc-switch.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,76 @@
+/*
+ * Copyright (c) 2004-2005, Swedish Institute of Computer Science.
@@ -53472,9 +53590,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/lc-switch.h open-iscsi
+#endif /* __LC_SWITCH_H__ */
+
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/Makefile.am
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/Makefile.am
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.am 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/Makefile.am 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/Makefile.am 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,17 @@
+INCLUDES = -I${top_srcdir}/src/unix \
+ -I${top_srcdir}/src/apps/dhcpc \
@@ -53493,9 +53611,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.am open-iscsi
+ ipv6.c
+
+lib_iscsi_uip_a_CFLAGS = -DBYTE_ORDER=@ENDIAN@
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/Makefile.in
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/Makefile.in
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.in 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/Makefile.in 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/Makefile.in 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,561 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
@@ -54058,9 +54176,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.in open-iscsi
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.include open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/Makefile.include
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.include open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/Makefile.include
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.include 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/Makefile.include 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/Makefile.include 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,47 @@
+
+
@@ -54109,9 +54227,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/Makefile.include open-
+
+libapps.a: ${addprefix $(OBJECTDIR)/, $(APP_SOURCES:.c=.o)}
+ $(AR) rc $@ $^
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/psock.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/psock.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/psock.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/psock.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/psock.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/psock.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/psock.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,345 @@
+/*
+ * Copyright (c) 2004, Swedish Institute of Computer Science.
@@ -54458,9 +54576,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/psock.c open-iscsi-2.0
+}
+
+/*---------------------------------------------------------------------------*/
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/psock.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/psock.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/psock.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/psock.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/psock.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/psock.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/psock.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,384 @@
+/*
+ * Copyright (c) 2004, Swedish Institute of Computer Science.
@@ -54846,9 +54964,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/psock.h open-iscsi-2.0
+#endif /* __PSOCK_H__ */
+
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/pt.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/pt.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/pt.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/pt.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/pt.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/pt.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/pt.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,323 @@
+/*
+ * Copyright (c) 2004-2005, Swedish Institute of Computer Science.
@@ -55173,9 +55291,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/pt.h open-iscsi-2.0-87
+#endif /* __PT_H__ */
+
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/timer.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/timer.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/timer.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/timer.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/timer.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/timer.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/timer.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,128 @@
+/**
+ * \addtogroup timer
@@ -55305,9 +55423,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/timer.c open-iscsi-2.0
+/*---------------------------------------------------------------------------*/
+
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/timer.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/timer.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/timer.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/timer.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/timer.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/timer.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/timer.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,85 @@
+/**
+ * \defgroup timer Timer library
@@ -55394,9 +55512,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/timer.h open-iscsi-2.0
+#endif /* __TIMER_H__ */
+
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arch.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_arch.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arch.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_arch.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arch.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_arch.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_arch.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,138 @@
+/**
+ * \addtogroup uip
@@ -55536,9 +55654,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arch.h open-iscsi-
+/** @} */
+
+#endif /* __UIP_ARCH_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arp.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_arp.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arp.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_arp.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arp.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_arp.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_arp.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,485 @@
+#include <errno.h>
+//#include <net/ethernet.h>
@@ -56025,9 +56143,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arp.c open-iscsi-2
+
+/** @} */
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arp.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_arp.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arp.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_arp.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arp.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_arp.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_arp.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,196 @@
+/**
+ * \addtogroup uip
@@ -56225,9 +56343,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_arp.h open-iscsi-2
+/** @} */
+
+#endif /* __UIP_ARP_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,2450 @@
+#include <netinet/in.h>
+#include <netinet/ip6.h>
@@ -57531,7 +57649,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.c open-iscsi-2.0-8
+ u16_t len = ntohs(ipv6_hdr->ip6_plen);
+ if (len <= ustack->uip_len) {
+ } else {
-+ LOG_WARN(PFX
++ LOG_DEBUG(PFX
+ "ip: packet shorter than reported in IP header"
+ ":IPv6_BUF(ustack)->len: %d ustack->uip_len: "
+ "%d", len, ustack->uip_len);
@@ -57543,7 +57661,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.c open-iscsi-2.0-8
+ ustack->uip_len = (tcp_ipv4_hdr->len[0] << 8) +
+ tcp_ipv4_hdr->len[1];
+ } else {
-+ LOG_WARN(PFX
++ LOG_DEBUG(PFX
+ "ip: packet shorter than reported in IP header"
+ ":tcp_ipv4_hdr->len: %d ustack->uip_len:%d.",
+ (tcp_ipv4_hdr->len[0] << 8) +
@@ -57736,7 +57854,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.c open-iscsi-2.0-8
+ if (UDPBUF(ustack)->udpchksum != 0 && uip_udpchksum(ustack) != 0xffff) {
+ ++ustack->stats.udp.drop;
+ ++ustack->stats.udp.chkerr;
-+ LOG_WARN(PFX "udp: bad checksum.");
++ LOG_DEBUG(PFX "udp: bad checksum.");
+ goto drop;
+ }
+#else /* UIP_UDP_CHECKSUMS */
@@ -58679,9 +58797,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.c open-iscsi-2.0-8
+}
+
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_eth.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_eth.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_eth.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_eth.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_eth.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_eth.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_eth.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -58733,9 +58851,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_eth.c open-iscsi-2
+
+ return 0;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_eth.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_eth.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_eth.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_eth.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_eth.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip_eth.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip_eth.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,43 @@
+#ifndef __UIP_ETH_H__
+#define __UIP_ETH_H__
@@ -58780,9 +58898,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip_eth.h open-iscsi-2
+int is_vlan_packet(struct uip_vlan_eth_hdr *hdr);
+
+#endif /* __UIP_ETH_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,1611 @@
+
+/**
@@ -60395,9 +60513,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip.h open-iscsi-2.0-8
+#endif /* __UIP_H__ */
+
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip-neighbor.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip-neighbor.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip-neighbor.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip-neighbor.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip-neighbor.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip-neighbor.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip-neighbor.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,221 @@
+/*
+ * Copyright (c) 2006, Swedish Institute of Computer Science.
@@ -60620,9 +60738,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip-neighbor.c open-is
+}
+
+/*---------------------------------------------------------------------------*/
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip-neighbor.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip-neighbor.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip-neighbor.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip-neighbor.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip-neighbor.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uip-neighbor.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uip-neighbor.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,106 @@
+/*
+ * Copyright (c) 2006, Swedish Institute of Computer Science.
@@ -60730,9 +60848,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uip-neighbor.h open-is
+void uip_neighbor_out(struct uip_stack *ustack);
+
+#endif /* __UIP-NEIGHBOR_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uipopt.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uipopt.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uipopt.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uipopt.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uipopt.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip/uipopt.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip/uipopt.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,537 @@
+/**
+ * \defgroup uipopt Configuration options for uIP
@@ -61271,9 +61389,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip/uipopt.h open-iscsi-2.
+/** @} */
+
+#endif /* __UIPOPT_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip-1.0-changelog.txt open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip-1.0-changelog.txt
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip-1.0-changelog.txt open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip-1.0-changelog.txt
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip-1.0-changelog.txt 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/uip-1.0-changelog.txt 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/uip-1.0-changelog.txt 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,98 @@
+* A new API: protosockets that are similar to BSD sockets but does not
+ require any underlying multithreading system.
@@ -61373,19 +61491,19 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/uip-1.0-changelog.txt open
+ o UDP: network byte order on lastport in uip_udp_new().
+
+ o IP: memset() bugs in IP fragment reassembly code fixed.
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/build_date.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/build_date.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/build_date.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/build_date.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/build_date.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/build_date.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/build_date.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1 @@
+char *build_date ="Thu May 5 12:17:42 PDT 2011";
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/build_date.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/build_date.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/build_date.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/build_date.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/build_date.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/build_date.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/build_date.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1 @@
+char *build_date;
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/clock-arch.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/clock-arch.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/clock-arch.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/clock-arch.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/clock-arch.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/clock-arch.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/clock-arch.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,55 @@
+/*
+ * Copyright (c) 2006, Swedish Institute of Computer Science.
@@ -61442,9 +61560,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/clock-arch.c open-isc
+}
+
+/*---------------------------------------------------------------------------*/
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/clock-arch.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/clock-arch.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/clock-arch.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/clock-arch.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/clock-arch.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/clock-arch.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/clock-arch.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,40 @@
+/*
+ * Copyright (c) 2006, Swedish Institute of Computer Science.
@@ -61486,10 +61604,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/clock-arch.h open-isc
+#define CLOCK_CONF_SECOND 1000
+
+#endif /* __CLOCK_ARCH_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/iscsid_ipc.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/iscsid_ipc.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/iscsid_ipc.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,823 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/iscsid_ipc.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,868 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -61603,8 +61721,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ LOG_INFO(PFX "%s: started NIC enable thread state: 0x%x",
+ nic->log_name, nic->state)
+
-+ /* Enable the NIC */
-+ nic_enable(nic);
++ /* Enable the NIC */
++ nic_enable(nic);
++
++ nic->enable_thread = INVALID_THREAD;
+
+ pthread_exit(NULL);
+}
@@ -61698,7 +61818,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+{
+ int rc;
+ nic_t *nic = NULL;
-+ nic_interface_t *nic_iface, *next_nic_iface;
++ nic_interface_t *nic_iface, *vlan_iface, *base_nic_iface;
+ char *transport_name;
+ size_t transport_name_size;
+ nic_lib_handle_t *handle;
@@ -61709,25 +61829,24 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ struct in_addr netmask;
+ int i, prefix_len = 64;
+ struct ip_addr_mask ipam;
++ struct iface_rec *rec;
++ void *res;
+
+ data = (iscsid_uip_broadcast_t *) arg;
+
++ rec = &data->u.iface_rec.rec;
+ LOG_INFO(PFX "Received request for '%s' to set IP address: '%s' "
-+ "VLAN: '%s'",
-+ data->u.iface_rec.rec.netdev,
-+ data->u.iface_rec.rec.ipaddress, data->u.iface_rec.rec.vlan);
-+
-+ vlan = atoi(data->u.iface_rec.rec.vlan);
-+ if ((valid_vlan(vlan) == 0) &&
-+ (strcmp(data->u.iface_rec.rec.vlan, "") != 0)) {
-+ LOG_ERR(PFX "Invalid VLAN tag: '%s'",
-+ data->u.iface_rec.rec.vlan)
-+ rc = -EIO;
++ "VLAN: '%d'", rec->netdev, rec->ipaddress, rec->vlan_id);
++
++ vlan = rec->vlan_id;
++ if (vlan && valid_vlan(vlan) == 0) {
++ LOG_ERR(PFX "Invalid VLAN tag: %d", rec->vlan_id);
++ rc = -EIO;
+ goto early_exit;
+ }
+
+ /* Detect for CIDR notation and strip off the netmask if present */
-+ rc = decode_cidr(data->u.iface_rec.rec.ipaddress, &ipam, &prefix_len);
++ rc = decode_cidr(rec->ipaddress, &ipam, &prefix_len);
+ if (rc && !ipam.ip_type) {
+ LOG_ERR(PFX "decode_cidr: rc=%d, ipam.ip_type=%d",
+ rc, ipam.ip_type)
@@ -61750,30 +61869,29 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+
+ if (i >= 10) {
+ LOG_WARN(PFX "Could not aquire nic_list_mutex lock");
-+
+ rc = -EIO;
+ goto early_exit;
+ }
+
+ /* Check if we can find the NIC device using the netdev
+ * name */
-+ rc = from_netdev_name_find_nic(data->u.iface_rec.rec.netdev, &nic);
++ rc = from_netdev_name_find_nic(rec->netdev, &nic);
+
+ if (rc != 0) {
+ LOG_WARN(PFX "Couldn't find NIC: %s, creating an instance",
-+ data->u.iface_rec.rec.netdev);
++ rec->netdev);
+
+ nic = nic_init();
+ if (nic == NULL) {
+ LOG_ERR(PFX "Couldn't allocate space for NIC %s",
-+ data->u.iface_rec.rec.netdev);
++ rec->netdev);
+
+ rc = -ENOMEM;
+ goto done;
+ }
+
+ strncpy(nic->eth_device_name,
-+ data->u.iface_rec.rec.netdev,
++ rec->netdev,
+ sizeof(nic->eth_device_name));
+ nic->config_device_name = nic->eth_device_name;
+ nic->log_name = nic->eth_device_name;
@@ -61787,7 +61905,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ nic_add(nic);
+ } else {
+ LOG_INFO(PFX " %s, using existing NIC",
-+ data->u.iface_rec.rec.netdev);
++ rec->netdev);
+ }
+
+ if (nic->flags & NIC_GOING_DOWN) {
@@ -61834,12 +61952,12 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ &transport_name_size);
+
+ if (strncmp(transport_name,
-+ data->u.iface_rec.rec.transport_name,
++ rec->transport_name,
+ transport_name_size) != 0) {
+ LOG_ERR(PFX "%s Transport name is not equal "
+ "expected: %s got: %s",
+ nic->log_name,
-+ data->u.iface_rec.rec.transport_name,
++ rec->transport_name,
+ transport_name);
+ }
+ } else {
@@ -61851,24 +61969,22 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ LOG_INFO(PFX "%s library set using transport_name %s",
+ nic->log_name, transport_name);
+
-+ /* Create the network interface if it doesn't exist */
-+ nic_iface = nic_find_nic_iface_protocol(nic, vlan, ipam.ip_type);
++ /* Create the base network interface if it doesn't exist */
++ nic_iface = nic_find_nic_iface_protocol(nic, 0, ipam.ip_type);
+ if (nic_iface == NULL) {
-+ LOG_INFO(PFX "%s couldn't find VLAN %d interface with "
++ LOG_INFO(PFX "%s couldn't find interface with "
+ "ip_type: 0x%x creating it",
-+ nic->log_name, vlan, ipam.ip_type);
++ nic->log_name, ipam.ip_type);
+
-+ /* Create the vlan interface */
++ /* Create the nic interface */
+ nic_iface = nic_iface_init();
+
+ if (nic_iface == NULL) {
-+ LOG_ERR(PFX "Couldn't allocate nic_iface for VLAN: %d",
-+ nic_iface, vlan);
++ LOG_ERR(PFX "Couldn't allocate nic_iface", nic_iface);
+ goto done;
+ }
+
+ nic_iface->protocol = ipam.ip_type;
-+ nic_iface->vlan_id = vlan;
+ nic_add_nic_iface(nic, nic_iface);
+
+ persist_all_nic_iface(nic);
@@ -61879,6 +61995,37 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ nic->log_name);
+ }
+
++ set_nic_iface(nic, nic_iface);
++
++ /* Find the vlan nic_interface */
++ if (vlan) {
++ vlan_iface = nic_find_vlan_iface_protocol(nic, nic_iface, vlan,
++ ipam.ip_type);
++ if (vlan_iface == NULL) {
++ LOG_INFO(PFX "%s couldn't find interface with VLAN = %d"
++ "ip_type: 0x%x creating it",
++ nic->log_name, vlan, ipam.ip_type);
++
++ /* Create the nic interface */
++ vlan_iface = nic_iface_init();
++
++ if (vlan_iface == NULL) {
++ LOG_ERR(PFX "Couldn't allocate nic_iface for "
++ "VLAN: %d", vlan_iface, vlan);
++ goto done;
++ }
++
++ vlan_iface->protocol = ipam.ip_type;
++ vlan_iface->vlan_id = vlan;
++ nic_add_vlan_iface(nic, nic_iface, vlan_iface);
++ } else {
++ LOG_INFO(PFX "%s: using existing vlan interface",
++ nic->log_name);
++ }
++ base_nic_iface = nic_iface;
++ nic_iface = vlan_iface;
++ }
++
+ /* Determine how to configure the IP address */
+ if (ipam.ip_type == AF_INET) {
+ if (memcmp(&ipam.addr4,
@@ -62004,39 +62151,56 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ }
+
+ /* Configuration changed, do VLAN WA */
-+ next_nic_iface = nic_iface->next;
-+ while (next_nic_iface) {
-+ if (next_nic_iface->vlan_id) {
-+ /* TODO: When VLAN support is placed in the iface file
-+ * revisit this code */
-+ next_nic_iface->ustack.ip_config =
++ vlan_iface = nic_iface->vlan_next;
++ while (vlan_iface) {
++ /* TODO: When VLAN support is placed in the iface file
++ * revisit this code */
++ if (vlan_iface->ustack.ip_config) {
++ vlan_iface->ustack.ip_config =
+ nic_iface->ustack.ip_config;
-+ memcpy(next_nic_iface->ustack.hostaddr,
++ memcpy(vlan_iface->ustack.hostaddr,
+ nic_iface->ustack.hostaddr,
+ sizeof(nic_iface->ustack.hostaddr));
-+ memcpy(next_nic_iface->ustack.netmask,
++ memcpy(vlan_iface->ustack.netmask,
+ nic_iface->ustack.netmask,
+ sizeof(nic_iface->ustack.netmask));
-+ memcpy(next_nic_iface->ustack.hostaddr6,
++ memcpy(vlan_iface->ustack.hostaddr6,
+ nic_iface->ustack.hostaddr6,
+ sizeof(nic_iface->ustack.hostaddr6));
++ memcpy(vlan_iface->ustack.netmask6,
++ nic_iface->ustack.netmask6,
++ sizeof(nic_iface->ustack.netmask6));
+ }
-+ next_nic_iface = next_nic_iface->next;
++ vlan_iface = vlan_iface->vlan_next;
+ }
+
+enable_nic:
+ if (nic->state & NIC_STOPPED) {
+ pthread_mutex_lock(&nic->nic_mutex);
++ if (nic->flags & NIC_ENABLED_PENDING) {
++ /* Still waiting */
++ pthread_mutex_unlock(&nic->nic_mutex);
++ rc = 0;
++ goto enable_out;
++ }
+ nic->flags |= NIC_ENABLED_PENDING;
+ pthread_mutex_unlock(&nic->nic_mutex);
+
+ /* This thread will be thrown away when completed */
++ if (nic->enable_thread != INVALID_THREAD) {
++ rc = pthread_join(nic->enable_thread, &res);
++ if (rc != 0) {
++ LOG_INFO(PFX "%s: failed joining enable NIC "
++ "thread\n", nic->log_name);
++ goto eagain;
++ }
++ }
+ rc = pthread_create(&nic->enable_thread, NULL,
+ enable_nic_thread, (void *)nic);
+ if (rc != 0)
+ LOG_WARN(PFX "%s: failed starting enable NIC thread\n",
+ nic->log_name);
-+
++eagain:
+ rc = -EAGAIN;
+ } else {
+ LOG_INFO(PFX "%s: NIC already enabled "
@@ -62044,14 +62208,13 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ nic->log_name, nic->flags, nic->state);
+ rc = 0;
+ }
-+
++enable_out:
+ LOG_INFO(PFX "ISCSID_UIP_IPC_GET_IFACE: command: %x "
+ "name: %s, netdev: %s ipaddr: %s vlan: %d transport_name:%s",
-+ data->header.command, data->u.iface_rec.rec.name,
-+ data->u.iface_rec.rec.netdev,
-+ (ipam.ip_type ==
-+ AF_INET) ? inet_ntoa(ipam.addr4) : ipv6_buf_str, vlan,
-+ data->u.iface_rec.rec.transport_name);
++ data->header.command, rec->name, rec->netdev,
++ (ipam.ip_type == AF_INET) ? inet_ntoa(ipam.addr4) :
++ ipv6_buf_str,
++ vlan, rec->transport_name);
+
+done:
+ pthread_mutex_unlock(&nic_list_mutex);
@@ -62082,7 +62245,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ }
+
+ /* This will be freed by parse_iface_thread() */
-+ data = (iscsid_uip_broadcast_t *) malloc(sizeof(*data));
++ data = (iscsid_uip_broadcast_t *) calloc(1, sizeof(*data));
+ if (data == NULL) {
+ LOG_ERR(PFX "Couldn't allocate memory for iface data");
+ return -ENOMEM;
@@ -62116,15 +62279,15 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+ switch (rc) {
+ case 0:
+ rsp.command = cmd;
-+ rsp.err = ISCISD_UIP_MGMT_IPC_DEVICE_UP;
++ rsp.err = ISCSID_UIP_MGMT_IPC_DEVICE_UP;
+ break;
+ case -EAGAIN:
+ rsp.command = cmd;
-+ rsp.err = ISCISD_UIP_MGMT_IPC_DEVICE_INITIALIZING;
++ rsp.err = ISCSID_UIP_MGMT_IPC_DEVICE_INITIALIZING;
+ break;
+ default:
+ rsp.command = cmd;
-+ rsp.err = ISCISD_UIP_MGMT_IPC_ERR;
++ rsp.err = ISCSID_UIP_MGMT_IPC_ERR;
+ }
+
+ break;
@@ -62313,9 +62476,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.c open-isc
+
+ LOG_INFO(PFX "iscsid listening thread has shutdown");
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/iscsid_ipc.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/iscsid_ipc.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/iscsid_ipc.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/iscsid_ipc.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -62368,10 +62531,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/iscsid_ipc.h open-isc
+void iscsid_cleanup();
+
+#endif /* __ISCSID_IPC_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/bnx2.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/bnx2.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/bnx2.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,1122 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/bnx2.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,1148 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -62757,6 +62920,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+}
+
+/**
++ * bnx2_free() - Used to free a bnx2 structure
++ */
++static void bnx2_free(nic_t *nic)
++{
++ if (nic->priv)
++ free(nic->priv);
++ nic->priv = NULL;
++}
++
++/**
+ * bnx2_alloc() - Used to allocate a bnx2 structure
+ */
+static bnx2_t *bnx2_alloc(nic_t * nic)
@@ -62770,6 +62943,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+ /* Clear out the bnx2 contents */
+ memset(bp, 0, sizeof(*bp));
+
++ bp->bar0_fd = INVALID_FD;
+ bp->flags = BNX2_UIO_TX_HAS_SENT;
+
+ bp->parent = nic;
@@ -62791,6 +62965,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+ __u32 val;
+ uint32_t tx_cid;
+ __u32 msix_vector = 0;
++ char sysfs_resc_path[80];
+
+ /* Sanity Check: validate the parameters */
+ if (nic == NULL) {
@@ -62835,10 +63010,20 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+ }
+ if (fstat(nic->fd, &uio_stat) < 0) {
+ LOG_ERR(PFX "%s: Could not fstat device", nic->log_name);
-+ return -ENODEV;
++ rc = -ENODEV;
++ goto error_alloc_rx_ring;
+ }
+ nic->uio_minor = minor(uio_stat.st_rdev);
+
++ cnic_get_sysfs_pci_resource_path(nic, 0, sysfs_resc_path, 80);
++ bp->bar0_fd = open(sysfs_resc_path, O_RDWR | O_SYNC);
++ if (bp->bar0_fd < 0) {
++ LOG_ERR(PFX "%s: Could not open %s", nic->log_name,
++ sysfs_resc_path);
++ rc = -ENODEV;
++ goto error_alloc_rx_ring;
++ }
++
+ /* TODO: hardcoded with the cnic driver */
+ bp->rx_ring_size = 3;
+ bp->rx_buffer_size = 0x400;
@@ -62872,7 +63057,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+ mlock(bp->rx_pkt_ring, sizeof(void *) * bp->rx_ring_size);
+
+ bp->reg = mmap(NULL, 0x12800, PROT_READ | PROT_WRITE, MAP_SHARED,
-+ nic->fd, (off_t) 0);
++ bp->bar0_fd, (off_t) 0);
+ if (bp->reg == MAP_FAILED) {
+ LOG_INFO(PFX "%s: Couldn't mmap registers: %s",
+ nic->log_name, strerror(errno));
@@ -63059,6 +63244,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+ bp->rx_ring = NULL;
+
+error_alloc_rx_ring:
++ bnx2_free(nic);
+
+ return errno;
+}
@@ -63132,6 +63318,11 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+ bp->reg = NULL;
+ }
+
++ if (bp->bar0_fd != INVALID_FD) {
++ close(bp->bar0_fd);
++ bp->bar0_fd = INVALID_FD;
++ }
++
+ if (nic->fd != INVALID_FD) {
+ rc = close(nic->fd);
+ if (rc != 0) {
@@ -63162,8 +63353,6 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+ */
+static int bnx2_close(nic_t * nic, NIC_SHUTDOWN_T graceful)
+{
-+ bnx2_t *bp = (bnx2_t *) nic->priv;
-+
+ /* Sanity Check: validate the parameters */
+ if (nic == NULL) {
+ LOG_ERR(PFX "bnx2_close(): nic == NULL");
@@ -63173,7 +63362,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+ LOG_INFO(PFX "Closing NIC device: %s", nic->log_name);
+
+ bnx2_uio_close_resources(nic, graceful);
-+ bp->flags &= ~BNX2_OPENED;
++ bnx2_free(nic);
+
+ return 0;
+}
@@ -63494,10 +63683,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.c open-iscs
+ .get_uio_name = bnx2_get_uio_name,
+ },
+};
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/bnx2.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/bnx2.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/bnx2.h 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,302 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/bnx2.h 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,303 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -63750,6 +63939,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.h open-iscs
+#define BNX2_UIO_TX_HAS_SENT 0x0002
+#define BNX2_OPENED 0x0004
+
++ int bar0_fd;
+ void *reg; /* Pointer to the mapped registers */
+
+ __u32 tx_bidx_io;
@@ -63800,10 +63990,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2.h open-iscs
+ ******************************************************************************/
+struct nic_ops *bnx2_get_ops();
+#endif /* __BNX2_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/bnx2x.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/bnx2x.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/bnx2x.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,1536 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/bnx2x.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,1554 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -63883,9 +64073,6 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+static const char cnic_uio_sysfs_name_tempate[] = "/sys/class/uio/uio%i/name";
+static const char bnx2x_uio_sysfs_name[] = "bnx2x_cnic";
+
-+static const char cnic_uio_sysfs_resc_tempate[] =
-+ "/sys/class/uio/uio%i/device/resource";
-+
+/*******************************************************************************
+ * String constants used to display human readable adapter name
+ ******************************************************************************/
@@ -64183,7 +64370,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+
+static inline int bnx2x_is_ver70(bnx2x_t *bp)
+{
-+ return (bp->version.major == 1 && bp->version.minor == 70);
++ return (bp->version.major == 1 && bp->version.minor >= 70);
+}
+
+static inline int bnx2x_is_ver60(bnx2x_t * bp)
@@ -64312,44 +64499,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+
+ LOG_INFO(PFX "%s: Verified is a cnic_uio device", nic->log_name);
+
-+ error:
++error:
+ return rc;
+}
+
-+static unsigned long cnic_get_bar2(nic_t * nic)
-+{
-+ char *raw = NULL, *raw_tmp;
-+ uint32_t raw_size = 0;
-+ char temp_path[sizeof(cnic_uio_sysfs_resc_tempate) + 8];
-+ int rc = 0, i, new_line;
-+ unsigned long bar = 0;
-+
-+ /* Build the path to determine uio name */
-+ snprintf(temp_path, sizeof(temp_path),
-+ cnic_uio_sysfs_resc_tempate, nic->uio_minor);
-+
-+ rc = capture_file(&raw, &raw_size, temp_path);
-+ if (rc != 0)
-+ return 0;
-+
-+ /* Skip 2 lines to get to BAR2 */
-+ raw_tmp = raw;
-+ i = 0;
-+ new_line = 0;
-+ while (i++ < raw_size && new_line < 2) {
-+ if (*raw_tmp == '\n')
-+ new_line++;
-+ raw_tmp++;
-+ }
-+
-+ if (new_line == 2)
-+ sscanf(raw_tmp, "%lx ", &bar);
-+
-+ free(raw);
-+
-+ return bar;
-+}
-+
+/*******************************************************************************
+ * bnx2x Utility Functions to get to the hardware consumer indexes
+ ******************************************************************************/
@@ -64426,7 +64579,17 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+}
+
+/**
-+ * bnx2x_alloc() - Used to allocate a CNIC structure
++ * bnx2x_free() - Used to free a bnx2x structure
++ */
++static void bnx2x_free(nic_t *nic)
++{
++ if (nic->priv)
++ free(nic->priv);
++ nic->priv = NULL;
++}
++
++/**
++ * bnx2x_alloc() - Used to allocate a bnx2x structure
+ */
+static bnx2x_t *bnx2x_alloc(nic_t * nic)
+{
@@ -64441,7 +64604,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+ /* Clear out the CNIC contents */
+ memset(bp, 0, sizeof(*bp));
+
-+ bp->mem_fd = INVALID_FD;
++ bp->bar0_fd = INVALID_FD;
++ bp->bar2_fd = INVALID_FD;
+
+ bp->parent = nic;
+ nic->priv = (void *)bp;
@@ -64463,9 +64627,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+ struct stat uio_stat;
+ int i, rc;
+ __u32 val;
-+ unsigned long bar2;
+ int count;
-+
++ char sysfs_resc_path[80];
+ uint32_t bus;
+ uint32_t slot;
+ uint32_t func;
@@ -64524,24 +64687,44 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+ }
+ if (fstat(nic->fd, &uio_stat) < 0) {
+ LOG_ERR(PFX "%s: Could not fstat device", nic->log_name);
-+ return -ENODEV;
++ rc = -ENODEV;
++ goto open_error;
+ }
+ nic->uio_minor = minor(uio_stat.st_rdev);
+
-+ bar2 = cnic_get_bar2(nic);
-+ if (bar2 == 0) {
-+ LOG_ERR(PFX "%s: Could not read BAR2", nic->log_name);
-+ return -ENODEV;
++ cnic_get_sysfs_pci_resource_path(nic, 0, sysfs_resc_path, 80);
++ bp->bar0_fd = open(sysfs_resc_path, O_RDWR | O_SYNC);
++ if (bp->bar0_fd < 0) {
++ LOG_ERR(PFX "%s: Could not open %s", nic->log_name,
++ sysfs_resc_path);
++ rc = -ENODEV;
++ goto open_error;
+ }
+
-+ bp->mem_fd = open("/dev/mem", O_RDWR | O_SYNC);
-+ if (bp->mem_fd < 0) {
-+ LOG_ERR(PFX "%s: Could not open /dev/mem", nic->log_name);
-+ return -ENODEV;
++ bp->reg = mmap(NULL, BNX2X_BAR_SIZE, PROT_READ | PROT_WRITE,
++ MAP_SHARED, bp->bar0_fd, (off_t) 0);
++
++ if (bp->reg == MAP_FAILED) {
++ LOG_INFO(PFX "%s: Couldn't mmap BAR registers: %s",
++ nic->log_name, strerror(errno));
++ bp->reg = NULL;
++ rc = errno;
++ goto open_error;
++ }
++
++ msync(bp->reg, BNX2X_BAR_SIZE, MS_SYNC);
++
++ cnic_get_sysfs_pci_resource_path(nic, 2, sysfs_resc_path, 80);
++ bp->bar2_fd = open(sysfs_resc_path, O_RDWR | O_SYNC);
++ if (bp->bar2_fd < 0) {
++ LOG_ERR(PFX "%s: Could not open %s", nic->log_name,
++ sysfs_resc_path);
++ rc = -ENODEV;
++ goto open_error;
+ }
+
+ bp->reg2 = mmap(NULL, BNX2X_BAR2_SIZE, PROT_READ | PROT_WRITE,
-+ MAP_SHARED, bp->mem_fd, (off_t) bar2);
++ MAP_SHARED, bp->bar2_fd, (off_t) 0);
+
+ if (bp->reg2 == MAP_FAILED) {
+ LOG_INFO(PFX "%s: Couldn't mmap BAR2 registers: %s",
@@ -64574,18 +64757,6 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+ goto open_error;
+ }
+
-+ bp->reg = mmap(NULL, BNX2X_BAR_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED,
-+ nic->fd, (off_t) 0);
-+ if (bp->reg == MAP_FAILED) {
-+ LOG_INFO(PFX "%s: Couldn't mmap registers: %s",
-+ nic->log_name, strerror(errno));
-+ bp->reg = NULL;
-+ rc = errno;
-+ goto open_error;
-+ }
-+
-+ msync(bp->reg, BNX2X_BAR_SIZE, MS_SYNC);
-+
+ if (bnx2x_is_ver60_plus(bp))
+ bp->status_blk_size = sizeof(struct host_sp_status_block);
+ else if (bnx2x_is_ver52(bp))
@@ -64749,6 +64920,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+
+ if (bnx2x_is_ver60_plus(bp) && CHIP_IS_E2_PLUS(bp)) {
+ __u32 mf_cfg_addr = 0;
++ __u32 mac_offset;
++ __u8 mac[6];
+
+ val = bnx2x_rd32(bp, (BNX2X_PATH(bp) ? MISC_REG_GENERIC_CR_1 :
+ MISC_REG_GENERIC_CR_0));
@@ -64769,9 +64942,6 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+ val = bnx2x_rd32(bp, bp->shmem_base + 0x354);
+ /* SI mode */
+ if ((val & 0x700) == 0x300) {
-+ __u32 mac_offset;
-+ __u8 mac[6];
-+
+ mac_offset = 0xe4 + (bp->func * 0x28) + 4;
+ val = bnx2x_rd32(bp, mf_cfg_addr + mac_offset);
+ mac[0] = (__u8) (val >> 8);
@@ -64794,6 +64964,34 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+ rc = -ENOTSUP;
+ goto open_error;
+ }
++ } else if ((val & 0x700) == 0) {
++ __u32 proto_offset = 0x24 + (bp->func * 0x18);
++ __u32 ovtag_offset = proto_offset + 0xc;
++
++ rc = -ENOTSUP;
++ val = bnx2x_rd32(bp, mf_cfg_addr + ovtag_offset);
++ val &= 0xffff;
++ /* SD mode, check for valid outer VLAN */
++ if (val == 0xffff)
++ goto open_error;
++
++ /* Check for iSCSI protocol */
++ val = bnx2x_rd32(bp, mf_cfg_addr + proto_offset);
++ if ((val & 6) != 6)
++ goto open_error;
++
++ mac_offset = proto_offset + 0x4;
++ val = bnx2x_rd32(bp, mf_cfg_addr + mac_offset);
++ mac[0] = (__u8) (val >> 8);
++ mac[1] = (__u8) val;
++ mac_offset += 4;
++ val = bnx2x_rd32(bp, mf_cfg_addr + mac_offset);
++ mac[2] = (__u8) (val >> 24);
++ mac[3] = (__u8) (val >> 16);
++ mac[4] = (__u8) (val >> 8);
++ mac[5] = (__u8) val;
++ memcpy(nic->mac_addr, mac, 6);
++
+ }
+ }
+
@@ -64842,11 +65040,17 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+ bp->rx_pkt_ring = NULL;
+ }
+
-+ if (bp->mem_fd != INVALID_FD) {
-+ close(bp->mem_fd);
-+ bp->mem_fd = INVALID_FD;
++ if (bp->bar2_fd != INVALID_FD) {
++ close(bp->bar2_fd);
++ bp->bar2_fd = INVALID_FD;
+ }
+
++ if (bp->bar0_fd != INVALID_FD) {
++ close(bp->bar0_fd);
++ bp->bar0_fd = INVALID_FD;
++ }
++ bnx2x_free(nic);
++
+ return rc;
+}
+
@@ -64914,9 +65118,14 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+ bp->reg2 = NULL;
+ }
+
-+ if (bp->mem_fd != INVALID_FD) {
-+ close(bp->mem_fd);
-+ bp->mem_fd = INVALID_FD;
++ if (bp->bar2_fd != INVALID_FD) {
++ close(bp->bar2_fd);
++ bp->bar2_fd = INVALID_FD;
++ }
++
++ if (bp->bar0_fd != INVALID_FD) {
++ close(bp->bar0_fd);
++ bp->bar0_fd = INVALID_FD;
+ }
+
+ if (nic->fd != INVALID_FD) {
@@ -64944,25 +65153,24 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+}
+
+/**
-+ * cnic_close() - Used to close the NIC device
++ * bnx2x_close() - Used to close the NIC device
+ * @param nic - NIC device to close
+ * @param graceful - whether to wait to close gracefully
+ * @return 0 if successful, <0 if there is an error
+ */
+static int bnx2x_close(nic_t * nic, NIC_SHUTDOWN_T graceful)
+{
-+ bnx2x_t *bp = (bnx2x_t *) nic->priv;
-+
+ /* Sanity Check: validate the parameters */
-+ if (nic == NULL || bp == NULL) {
-+ LOG_ERR(PFX "bnx2x_close(): nic == %p, bp == %p", nic, bp);
++ if (nic == NULL || nic->priv == NULL) {
++ LOG_ERR(PFX "bnx2x_close(): nic == %p, bp == %p", nic,
++ nic->priv);
+ return -EINVAL;
+ }
+
+ LOG_INFO(PFX "Closing NIC device: %s", nic->log_name);
+
+ bnx2x_uio_close_resources(nic, graceful);
-+ bp->flags &= ~BNX2X_OPENED;
++ bnx2x_free(nic);
+
+ return 0;
+}
@@ -65340,10 +65548,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.c open-isc
+ .get_uio_name = bnx2x_get_uio_name,
+ },
+};
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/bnx2x.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/bnx2x.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/bnx2x.h 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,645 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/bnx2x.h 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,646 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -65920,7 +66128,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.h open-isc
+ void *reg; /* Pointer to the BAR1 mapped registers */
+ void *reg2; /* Pointer to the BAR2 mapped registers */
+
-+ int mem_fd;
++ int bar0_fd;
++ int bar2_fd;
+
+ __u32 chip_id;
+ __u32 shmem_base;
@@ -65989,10 +66198,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/bnx2x.h open-isc
+
+struct nic_ops *bnx2x_get_ops();
+#endif /* __BNX2X_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/cnic.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/cnic.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/cnic.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,721 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/cnic.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,788 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -66320,7 +66529,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c open-iscs
+ struct iscsi_uevent *ev,
+ struct iscsi_path *path)
+{
-+ nic_interface_t *nic_iface;
++ nic_interface_t *nic_iface, *vlan_iface;
+ struct in_addr src_addr, dst_addr,
+ src_matching_addr, dst_matching_addr, netmask;
+ __u8 mac_addr[6];
@@ -66333,18 +66542,50 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c open-iscs
+ pthread_mutex_lock(&nic_list_mutex);
+
+ /* Find the proper interface via VLAN id */
-+ nic_iface = nic_find_nic_iface_protocol(nic, path->vlan_id, AF_INET);
++ nic_iface = nic_find_nic_iface_protocol(nic, 0, AF_INET);
+ if (nic_iface == NULL) {
-+ nic_iface = nic_find_nic_iface_protocol(nic, 0, AF_INET);
-+ if (nic_iface == NULL) {
-+ pthread_mutex_unlock(&nic_list_mutex);
-+ LOG_ERR(PFX "%s: Couldn't find net_iface vlan_id: %d",
-+ nic->log_name, path->vlan_id);
-+ return -EINVAL;
-+ }
++ pthread_mutex_unlock(&nic_list_mutex);
++ LOG_ERR(PFX "%s: Couldn't find net_iface vlan_id: %d",
++ nic->log_name, path->vlan_id);
++ return -EINVAL;
++ }
++ if (path->vlan_id) {
++ vlan_iface = nic_find_vlan_iface_protocol(nic, nic_iface,
++ path->vlan_id,
++ AF_INET);
++ if (vlan_iface == NULL) {
++ LOG_INFO(PFX "%s couldn't find interface with VLAN = %d"
++ "ip_type: 0x%x creating it",
++ nic->log_name, path->vlan_id, AF_INET);
++
++ /* Create the nic interface */
++ vlan_iface = nic_iface_init();
++
++ if (vlan_iface == NULL) {
++ LOG_ERR(PFX "Couldn't allocate nic_iface for "
++ "VLAN: %d", vlan_iface,
++ path->vlan_id);
++ return -EINVAL;
++ }
+
-+ nic_iface->vlan_id = path->vlan_id;
++ vlan_iface->protocol = nic_iface->protocol;
++ vlan_iface->vlan_id = path->vlan_id;
++ vlan_iface->ustack.ip_config =
++ nic_iface->ustack.ip_config;
++ memcpy(vlan_iface->ustack.hostaddr,
++ nic_iface->ustack.hostaddr,
++ sizeof(nic_iface->ustack.hostaddr));
++ memcpy(vlan_iface->ustack.netmask,
++ nic_iface->ustack.netmask,
++ sizeof(nic_iface->ustack.netmask));
++ nic_add_vlan_iface(nic, nic_iface, vlan_iface);
++ } else {
++ LOG_INFO(PFX "%s: using existing vlan interface",
++ nic->log_name);
++ }
++ nic_iface = vlan_iface;
+ }
++
+#define MAX_ARP_RETRY 4
+
+ memcpy(&dst_addr, &path->dst.v4_addr, sizeof(dst_addr));
@@ -66359,6 +66600,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c open-iscs
+ src_matching_addr.s_addr = src_addr.s_addr & netmask.s_addr;
+ dst_matching_addr.s_addr = dst_addr.s_addr & netmask.s_addr;
+
++ LOG_DEBUG(PFX "%s: src=%s", nic->log_name, inet_ntoa(src_addr));
++ LOG_DEBUG(PFX "%s: dst=%s", nic->log_name, inet_ntoa(dst_addr));
++ LOG_DEBUG(PFX "%s: nm=%s", nic->log_name, inet_ntoa(netmask));
+ if (src_matching_addr.s_addr != dst_matching_addr.s_addr) {
+ /* If there is an assigned gateway address then use it
+ * if the source address doesn't match */
@@ -66369,6 +66613,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c open-iscs
+ sizeof(dst_addr));
+ } else {
+ arp_retry = MAX_ARP_RETRY;
++ LOG_DEBUG(PFX "%s: no default", nic->log_name);
+ goto done;
+ }
+ }
@@ -66468,7 +66713,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c open-iscs
+ struct iscsi_uevent *ev,
+ struct iscsi_path *path)
+{
-+ nic_interface_t *nic_iface;
++ nic_interface_t *nic_iface, *vlan_iface;
+ __u8 mac_addr[6];
+ int rc, i;
+ uint16_t neighbor_retry;
@@ -66487,18 +66732,49 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c open-iscs
+ pthread_mutex_lock(&nic_list_mutex);
+
+ /* Find the proper interface via VLAN id */
-+ nic_iface = nic_find_nic_iface_protocol(nic, path->vlan_id, AF_INET6);
++ nic_iface = nic_find_nic_iface_protocol(nic, 0, AF_INET6);
+ if (nic_iface == NULL) {
-+ nic_iface = nic_find_nic_iface_protocol(nic, 0, AF_INET6);
-+ if (nic_iface == NULL) {
-+ pthread_mutex_unlock(&nic_list_mutex);
-+ LOG_ERR(PFX "%s: Couldn't find net_iface vlan_id: %d",
-+ nic->log_name, path->vlan_id);
-+ return -EINVAL;
++ pthread_mutex_unlock(&nic_list_mutex);
++ LOG_ERR(PFX "%s: Couldn't find net_iface vlan_id: %d",
++ nic->log_name, path->vlan_id);
++ return -EINVAL;
++ }
++ if (path->vlan_id) {
++ vlan_iface = nic_find_vlan_iface_protocol(nic, nic_iface,
++ path->vlan_id,
++ AF_INET6);
++ if (vlan_iface == NULL) {
++ LOG_INFO(PFX "%s couldn't find interface with VLAN = %d"
++ "ip_type: 0x%x creating it",
++ nic->log_name, path->vlan_id, AF_INET6);
++
++ /* Create the nic interface */
++ vlan_iface = nic_iface_init();
++
++ if (vlan_iface == NULL) {
++ LOG_ERR(PFX "Couldn't allocate nic_iface for "
++ "VLAN: %d", vlan_iface,
++ path->vlan_id);
++ return -EINVAL;
++ }
++ vlan_iface->protocol = nic_iface->protocol;
++ vlan_iface->vlan_id = path->vlan_id;
++ vlan_iface->ustack.ip_config =
++ nic_iface->ustack.ip_config;
++ memcpy(vlan_iface->ustack.hostaddr6,
++ nic_iface->ustack.hostaddr6,
++ sizeof(nic_iface->ustack.hostaddr6));
++ memcpy(vlan_iface->ustack.netmask6,
++ nic_iface->ustack.netmask6,
++ sizeof(nic_iface->ustack.netmask6));
++ nic_add_vlan_iface(nic, nic_iface, vlan_iface);
++ } else {
++ LOG_INFO(PFX "%s: using existing vlan interface",
++ nic->log_name);
+ }
-+
-+ nic_iface->vlan_id = path->vlan_id;
++ nic_iface = vlan_iface;
+ }
++
+ /* Depending on the IPv6 address of the target we will need to
+ * determine whether we use the assigned IPv6 address or the
+ * link local IPv6 address */
@@ -66714,9 +66990,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.c open-iscs
+ return -EIO;
+ }
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/cnic.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/cnic.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/cnic.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/cnic.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -66771,9 +67047,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/cnic.h open-iscs
+ struct iscsi_path *path);
+
+#endif /* __CNIC_NL_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/Makefile.am
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/Makefile.am
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/Makefile.am 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/Makefile.am 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/Makefile.am 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,12 @@
+INCLUDES = -I${top_srcdir}/src/uip \
+ -I${top_srcdir}/src/unix \
@@ -66787,9 +67063,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/Makefile.am open
+ cnic.c \
+ bnx2.c \
+ bnx2x.c
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/Makefile.in
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/Makefile.in
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/Makefile.in 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/libs/Makefile.in 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/libs/Makefile.in 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,449 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
@@ -67240,10 +67516,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/libs/Makefile.in open
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/logger.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/logger.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/logger.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,172 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/logger.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,181 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -67355,7 +67631,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.c open-iscsi-2
+ fflush(stdout);
+ }
+
-+ end:
++end:
+ va_end(ap2);
+ va_end(ap);
+ pthread_mutex_unlock(&main_log.lock);
@@ -67375,17 +67651,26 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.c open-iscsi-2
+
+ pthread_mutex_lock(&main_log.lock);
+
++ if (opt.debug != DEBUG_ON) {
++ rc = -EIO;
++ goto disable;
++ }
+ main_log.fp = fopen(filename, "a");
+ if (main_log.fp == NULL) {
+ printf("Could not create log file: %s <%s>\n",
+ filename, strerror(errno));
+ rc = -EIO;
+ }
-+ main_log.enabled = LOGGER_ENABLED;
++disable:
++ if (rc)
++ main_log.enabled = LOGGER_DISABLED;
++ else
++ main_log.enabled = LOGGER_ENABLED;
+
+ pthread_mutex_unlock(&main_log.lock);
+
-+ LOG_INFO("Initialize logger using log file: %s", filename);
++ if (!rc)
++ LOG_INFO("Initialize logger using log file: %s", filename);
+
+ return rc;
+}
@@ -67416,9 +67701,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.c open-iscsi-2
+
+ pthread_mutex_unlock(&main_log.lock);
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/logger.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/logger.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/logger.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/logger.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,128 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -67548,10 +67833,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/logger.h open-iscsi-2
+#define SHUTDOWN_LOGGER 0x02
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/main.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/main.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/main.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,362 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/main.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,402 @@
+/*
+ * Copyright (c) 2001, Adam Dunkels.
+ * All rights reserved.
@@ -67602,6 +67887,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0
+#include <sys/utsname.h>
+#include <net/ethernet.h>
+#include <arpa/inet.h>
++#include <sys/mman.h>
+
+#include "uip.h"
+#include "uip_arp.h"
@@ -67697,11 +67983,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0
+retry:
+ fini_logger(SHUTDOWN_LOGGER);
+ rc = init_logger(main_log.log_file);
-+ if (rc != 0) {
++ if (rc != 0)
+ printf("Could not initialize the logger in "
+ "signal!\n");
-+ goto retry;
-+ }
+ goto signal_wait;
+ default:
+ break;
@@ -67726,10 +68010,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0
+
+ printf("\nUsage: %s [OPTION]\n", APP_NAME);
+ printf("\
-+Broadcom uIP daemon.\n\
++iscsiuio daemon.\n\
+ -f, --foreground make the program run in the foreground\n\
+ -d, --debug debuglevel print debugging information\n\
-+ -p, --pid=pidfile use pid file (default %s ).\n\
++ -p, --pid=pidfile use pid file (default %s).\n\
+ -h, --help display this help and exit\n\
+ -v, --version display version and exit\n\
+", default_pid_filepath);
@@ -67752,6 +68036,38 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0
+ rc = chdir("/");
+}
+
++#define ISCSI_OOM_PATH_LEN 48
++
++int oom_adjust(void)
++{
++ int fd;
++ char path[ISCSI_OOM_PATH_LEN];
++ struct stat statb;
++
++ if (nice(-10) < 0)
++ LOG_DEBUG("Could not increase process priority: %s",
++ strerror(errno));
++
++ snprintf(path, ISCSI_OOM_PATH_LEN, "/proc/%d/oom_score_adj", getpid());
++ if (stat(path, &statb)) {
++ /* older kernel so use old oom_adj file */
++ snprintf(path, ISCSI_OOM_PATH_LEN, "/proc/%d/oom_adj",
++ getpid());
++ }
++ fd = open(path, O_WRONLY);
++ if (fd < 0)
++ return -1;
++ if (write(fd, "-16", 3) < 0) /* for 2.6.11 */
++ LOG_DEBUG("Could not set oom score to -16: %s",
++ strerror(errno));
++ if (write(fd, "-17", 3) < 0) /* for Andrea's patch */
++ LOG_DEBUG("Could not set oom score to -17: %s",
++ strerror(errno));
++ close(fd);
++ return 0;
++}
++
++
+/*******************************************************************************
+ * Main routine
+ ******************************************************************************/
@@ -67804,10 +68120,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0
+ if (main_log.enabled == LOGGER_ENABLED) {
+ /* initialize the logger */
+ rc = init_logger(main_log.log_file);
-+ if (rc != 0) {
-+ printf("Could not initialize the logger\n");
-+ goto error;
-+ }
++ if (rc != 0 && opt.debug == DEBUG_ON)
++ printf("WARN: Could not initialize the logger\n");
+ }
+
+ LOG_INFO("Started iSCSI uio stack: Ver " PACKAGE_VERSION);
@@ -67890,6 +68204,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0
+ sigaddset(&set, SIGINT);
+ sigaddset(&set, SIGQUIT);
+ sigaddset(&set, SIGTERM);
++ sigaddset(&set, SIGUSR1);
+ rc = pthread_sigmask(SIG_SETMASK, &set, NULL);
+
+ /* Spin off the signal handling thread */
@@ -67901,6 +68216,16 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0
+ /* Using sysfs to discover iSCSI hosts */
+ nic_discover_iscsi_hosts();
+
++ /* oom-killer will not kill us at the night... */
++ if (oom_adjust())
++ LOG_DEBUG("Can not adjust oom-killer's pardon");
++
++ /* we don't want our active sessions to be paged out... */
++ if (mlockall(MCL_CURRENT | MCL_FUTURE)) {
++ LOG_ERR("failed to mlockall, exiting...");
++ goto error;
++ }
++
+ /* Start the iscsid listener */
+ rc = iscsid_start();
+ if (rc != 0) {
@@ -67914,9 +68239,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/main.c open-iscsi-2.0
+ cleanup();
+ exit(EXIT_FAILURE);
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/Makefile.am
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/Makefile.am open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/Makefile.am
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/Makefile.am 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/Makefile.am 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/Makefile.am 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,38 @@
+SUBDIRS= libs
+
@@ -67956,9 +68281,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/Makefile.am open-iscs
+ ${top_srcdir}/src/unix/libs/lib_iscsiuio_hw_cnic.a
+
+iscsiuio_YFLAGS = -d
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/Makefile.in
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/Makefile.in open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/Makefile.in
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/Makefile.in 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/Makefile.in 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/Makefile.in 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,766 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
@@ -68726,10 +69051,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/Makefile.in open-iscs
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,1495 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,1653 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -69124,6 +69449,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ nic->fd = INVALID_FD;
+ nic->next = NULL;
+ nic->thread = INVALID_THREAD;
++ nic->enable_thread = INVALID_THREAD;
+ nic->flags |= NIC_UNITIALIZED | NIC_DISABLED;
+ nic->state |= NIC_STOPPED;
+ nic->free_packet_queue = NULL;
@@ -69172,7 +69498,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ nic_t *prev, *current;
+ struct stat file_stat;
+ void *res;
-+ nic_interface_t *nic_iface, *next_nic_iface;
++ nic_interface_t *nic_iface, *next_nic_iface, *vlan_iface;
+
+ pthread_mutex_lock(&nic->nic_mutex);
+
@@ -69184,7 +69510,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ nic->state = NIC_EXIT;
+ pthread_mutex_unlock(&nic->nic_mutex);
+
-+ if (nic->enable_thread) {
++ if (nic->enable_thread != INVALID_THREAD) {
+ LOG_ERR(PFX "%s: Canceling nic enable thread", nic->log_name);
+
+ rc = pthread_cancel(nic->enable_thread);
@@ -69198,6 +69524,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ if (rc != 0)
+ LOG_ERR(PFX "%s: Couldn't join to canceled enable nic "
+ "thread", nic->log_name);
++ nic->enable_thread = INVALID_THREAD;
+ }
+ if (nic->thread != INVALID_THREAD) {
+ LOG_ERR(PFX "%s: Canceling nic thread", nic->log_name);
@@ -69237,6 +69564,12 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ nic_iface */
+ nic_iface = nic->nic_iface;
+ while (nic_iface != NULL) {
++ vlan_iface = nic_iface->vlan_next;
++ while (vlan_iface != NULL) {
++ next_nic_iface = vlan_iface->vlan_next;
++ free(vlan_iface);
++ vlan_iface = next_nic_iface;
++ }
+ next_nic_iface = nic_iface->next;
+ free(nic_iface);
+ nic_iface = next_nic_iface;
@@ -69264,7 +69597,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+void nic_close(nic_t * nic, NIC_SHUTDOWN_T graceful, int clean)
+{
+ int rc;
-+ nic_interface_t *nic_iface;
++ nic_interface_t *nic_iface, *vlan_iface;
+ struct stat file_stat;
+
+ /* The NIC could be configured by the uIP config file
@@ -69291,8 +69624,14 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ nic_iface = nic->nic_iface;
+ while (nic_iface != NULL) {
+ if (!((nic_iface->flags & NIC_IFACE_PERSIST) ==
-+ NIC_IFACE_PERSIST))
++ NIC_IFACE_PERSIST)) {
+ uip_reset(&nic_iface->ustack);
++ vlan_iface = nic_iface->vlan_next;
++ while (vlan_iface != NULL) {
++ uip_reset(&vlan_iface->ustack);
++ vlan_iface = vlan_iface->vlan_next;
++ }
++ }
+ nic_iface = nic_iface->next;
+ }
+
@@ -69340,12 +69679,13 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+
+ memset(nic_iface, 0, sizeof(*nic_iface));
+ nic_iface->next = NULL;
++ nic_iface->vlan_next = NULL;
+
+ return nic_iface;
+}
+
+/**
-+ * nic_add_net_iface() - This function is used to add an interface to the
++ * nic_add_nic_iface() - This function is used to add an interface to the
+ * nic structure
+ * @param nic - struct nic device to add the interface to
+ * @param nic_iface - network interface used to add to the nic
@@ -69364,7 +69704,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+
+ /* Check to see if this interface already exists via 2
+ * conditions: 1) VLAN 2) protocol */
-+ while (current->next != NULL) {
++ while (current != NULL) {
+ if ((current->protocol == nic_iface->protocol) &&
+ (current->vlan_id == nic_iface->vlan_id)) {
+ LOG_WARN(PFX "%s: nic interface alread exists"
@@ -69373,7 +69713,6 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ current->protocol);
+ goto error;
+ }
-+
+ current = current->next;
+ }
+
@@ -69400,6 +69739,60 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ return 0;
+}
+
++/**
++ * nic_add_vlan_iface() - This function is used to add a vlan interface to the
++ * nic structure
++ * @param nic - struct nic device to add the interface to
++ * @param nic_iface - network interface to be added to
++ * @param vlan_iface - vlan interface used to add to the nic_iface
++ * @return 0 on success, <0 on failure
++ */
++int nic_add_vlan_iface(nic_t *nic, nic_interface_t *nic_iface,
++ nic_interface_t *vlan_iface)
++{
++ pthread_mutex_lock(&nic->nic_mutex);
++
++ /* Add the nic_interface */
++ if (nic_iface == NULL)
++ goto error;
++ else {
++ nic_interface_t *current = nic_iface->vlan_next;
++
++ /* Check to see if this interface already exists via 2
++ * conditions: 1) VLAN 2) protocol */
++ while (current != NULL) {
++ if ((current->protocol == vlan_iface->protocol) &&
++ (current->vlan_id == vlan_iface->vlan_id)) {
++ LOG_WARN(PFX "%s: vlan interface already exists"
++ "for VLAN: %d, protocol: %d",
++ nic->log_name, current->vlan_id,
++ current->protocol);
++ goto error;
++ }
++ current = current->vlan_next;
++ }
++
++ /* This interface doesn't exists, we can safely add
++ * this nic interface */
++ current = nic_iface;
++ while (current->vlan_next != NULL)
++ current = current->vlan_next;
++
++ current->vlan_next = vlan_iface;
++ }
++
++ /* Set nic_interface common fields */
++ vlan_iface->parent = nic;
++ nic->num_of_nic_iface++;
++
++ LOG_INFO(PFX "%s: Added vlan interface for VLAN: %d, protocol: %d",
++ nic->log_name, vlan_iface->vlan_id, vlan_iface->protocol);
++
++error:
++ pthread_mutex_unlock(&nic->nic_mutex);
++
++ return 0;
++}
+/******************************************************************************
+ * Routine to process interrupts from the NIC device
+ ******************************************************************************/
@@ -69676,6 +70069,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ uint16_t type = 0;
+ int af_type = 0;
+ struct uip_stack *ustack;
++ nic_interface_t *vlan_iface;
+
+ if ((pkt->vlan_tag == 0) ||
+ (NIC_VLAN_STRIP_ENABLED & nic->flags)) {
@@ -69702,8 +70096,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+
+ /* check if we have the given VLAN interface */
+ if (nic_iface == NULL) {
-+ nic_iface = nic_find_nic_iface_protocol(nic,
-+ pkt->vlan_tag,
++ nic_iface = nic_find_nic_iface_protocol(nic, 0,
+ af_type);
+ if (nic_iface == NULL) {
+ LOG_INFO(PFX "%s: Couldn't find interface for "
@@ -69725,11 +70118,58 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ }
+
+ nic_iface->protocol = af_type;
-+ nic_iface->vlan_id = pkt->vlan_tag;
++ nic_iface->vlan_id = 0;
+ nic_add_nic_iface(nic, nic_iface);
+
+ persist_all_nic_iface(nic);
+ }
++ if (pkt->vlan_tag) {
++ vlan_iface = nic_find_vlan_iface_protocol(nic,
++ nic_iface, pkt->vlan_tag,
++ af_type);
++ if (vlan_iface == NULL) {
++ LOG_INFO(PFX "%s couldn't find "
++ "interface with VLAN ="
++ " %d ip_type: 0x%x "
++ "creating it",
++ nic->log_name, pkt->vlan_tag,
++ af_type);
++
++ /* Create the nic interface */
++ vlan_iface = nic_iface_init();
++
++ if (vlan_iface == NULL) {
++ LOG_ERR(PFX "Couldn't allocate "
++ "nic_iface for VLAN: %d",
++ vlan_iface,
++ pkt->vlan_tag);
++ rc = 0;
++ goto done;
++ }
++ vlan_iface->protocol = af_type;
++ vlan_iface->vlan_id = pkt->vlan_tag;
++ nic_add_vlan_iface(nic, nic_iface,
++ vlan_iface);
++ /* TODO: When VLAN support is placed */
++ /* in the iface file revisit this */
++ /* code */
++ memcpy(vlan_iface->ustack.hostaddr,
++ nic_iface->ustack.hostaddr,
++ sizeof(nic_iface->ustack.hostaddr));
++ memcpy(vlan_iface->ustack.netmask,
++ nic_iface->ustack.netmask,
++ sizeof(nic_iface->ustack.netmask));
++ memcpy(vlan_iface->ustack.netmask6,
++ nic_iface->ustack.netmask6,
++ sizeof(nic_iface->ustack.netmask6));
++ memcpy(vlan_iface->ustack.hostaddr6,
++ nic_iface->ustack.hostaddr6,
++ sizeof(nic_iface->ustack.hostaddr6));
++
++ persist_all_nic_iface(nic);
++ }
++ nic_iface = vlan_iface;
++ }
+ }
+
+ pkt->nic_iface = nic_iface;
@@ -69827,10 +70267,19 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ struct timeval total_time;
+
+ /* 10s loop time to wait for DHCP */
-+ if (nic_iface->ustack.ip_config == IPV4_CONFIG_DHCP)
++ switch (nic_iface->ustack.ip_config) {
++ case IPV4_CONFIG_DHCP:
+ wait_time.tv_sec = 10;
-+ else
++ break;
++ case IPV6_CONFIG_DHCP:
+ wait_time.tv_sec = 15;
++ break;
++ case IPV6_CONFIG_STATIC:
++ wait_time.tv_sec = 4;
++ break;
++ default:
++ wait_time.tv_sec = 2;
++ }
+ wait_time.tv_usec = 0;
+
+ s = nic_iface->ustack.dhcpc;
@@ -69909,7 +70358,6 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ /* Signal the device to enable itself */
+ pthread_mutex_lock(&nic->nic_mutex);
+ pthread_cond_signal(&nic->nic_loop_started_cond);
-+ pthread_mutex_unlock(&nic->nic_mutex);
+
+ while ((event_loop_stop == 0) &&
+ !(nic->flags & NIC_EXIT_MAIN_LOOP) &&
@@ -69921,16 +70369,17 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ nic->log_name);
+
+ /* Wait for the device to be enabled */
-+ pthread_mutex_lock(&nic->nic_mutex);
++ /* nic_mutex is already locked */
+ pthread_cond_wait(&nic->enable_wait_cond,
+ &nic->nic_mutex);
-+ pthread_mutex_unlock(&nic->nic_mutex);
+
-+ if (nic->state == NIC_EXIT)
++ if (nic->state == NIC_EXIT) {
++ pthread_mutex_unlock(&nic->nic_mutex);
+ pthread_exit(NULL);
-+
++ }
+ LOG_DEBUG(PFX "%s: is now enabled", nic->log_name);
+ }
++ pthread_mutex_unlock(&nic->nic_mutex);
+
+ /* initialize the device to send/rec data */
+ rc = (*nic->ops->open) (nic);
@@ -69940,6 +70389,12 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+
+ if (rc == -ENOTSUP)
+ nic->flags &= NIC_EXIT_MAIN_LOOP;
++ else
++ nic->flags &= ~NIC_ENABLED;
++
++ /* Signal that the device enable is done */
++ pthread_cond_broadcast(&nic->enable_done_cond);
++ pthread_mutex_unlock(&nic->nic_mutex);
+
+ goto dev_close;
+ }
@@ -69954,7 +70409,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ } else {
+ LOG_ERR(PFX "%s: No packets allocated "
+ "instead of %d", nic->log_name, 5);
-+
++ /* Signal that the device enable is done */
++ pthread_cond_broadcast(&nic->enable_done_cond);
++ pthread_mutex_unlock(&nic->nic_mutex);
+ goto dev_close;
+ }
+ }
@@ -70020,10 +70477,19 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ &tmp, nic_iface->mac_addr);
+ if (dhcpc_init(nic, ustack,
+ nic_iface->mac_addr, ETH_ALEN)) {
-+ LOG_DEBUG(PFX "%s: DHCPv4 engine "
-+ "already initialized!",
-+ nic->log_name);
-+ goto skip;
++ if (ustack->dhcpc) {
++ LOG_DEBUG(PFX "%s: DHCPv4 "
++ "engine already "
++ "initialized!",
++ nic->log_name);
++ goto skip;
++ } else {
++ LOG_DEBUG(PFX "%s: DHCPv4 "
++ "engine failed "
++ "initialization!",
++ nic->log_name);
++ goto dev_close_free;
++ }
+ }
+ pthread_mutex_unlock(&nic->nic_mutex);
+ rc = process_dhcp_loop(nic, nic_iface,
@@ -70044,6 +70510,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+
+ pthread_mutex_unlock(&nic->nic_mutex);
+
++ if (nic->enable_thread ==
++ INVALID_THREAD)
++ goto dev_close_free;
++
+ rc = pthread_join(nic->enable_thread,
+ &res);
+ if (rc != 0)
@@ -70052,7 +70522,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ " thread",
+ nic->log_name);
+
-+ goto dev_close;
++ goto dev_close_free;
+ }
+
+ if (nic->flags & NIC_DISABLED) {
@@ -70139,15 +70609,17 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ nic->log_name,
+ nic_iface->vlan_id, nic_iface->protocol);
+
-+ nic_iface = nic_iface->next;
++ nic_iface = nic_iface->vlan_next;
+ }
+
+ if (nic->flags & NIC_DISABLED) {
+ LOG_WARN(PFX "%s: nic was disabled during nic loop, "
+ "closing flag 0x%x",
+ nic->log_name, nic->flags);
++ /* Signal that the device enable is done */
++ pthread_cond_broadcast(&nic->enable_done_cond);
+ pthread_mutex_unlock(&nic->nic_mutex);
-+ goto dev_close;
++ goto dev_close_free;
+ }
+
+ /* This is when we start the processing of packets */
@@ -70182,6 +70654,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+
+ LOG_INFO(PFX "%s: exited main processing loop", nic->log_name);
+
++dev_close_free:
++ free_free_queue(nic);
+dev_close:
+ pthread_mutex_lock(&nic->nic_mutex);
+
@@ -70190,20 +70664,27 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+
+ nic->flags &= ~NIC_GOING_DOWN;
+ } else {
-+
+ pthread_mutex_destroy(&nic->xmit_mutex);
+ pthread_mutex_init(&nic->xmit_mutex, NULL);
+
+ if (nic->flags & NIC_RESET_UIP) {
+ nic_interface_t *nic_iface = nic->nic_iface;
++ nic_interface_t *vlan_iface;
+ while (nic_iface != NULL) {
+ LOG_INFO(PFX "%s: resetting uIP stack",
+ nic->log_name);
+ uip_reset(&nic_iface->ustack);
-+
++ vlan_iface = nic_iface->vlan_next;
++ while (vlan_iface != NULL) {
++ LOG_INFO(PFX "%s: resetting "
++ "vlan uIP stack",
++ nic->log_name);
++ uip_reset(&vlan_iface->ustack);
++ vlan_iface =
++ vlan_iface->vlan_next;
++ }
+ nic_iface = nic_iface->next;
+ }
-+
+ nic->flags &= ~NIC_RESET_UIP;
+ }
+ }
@@ -70218,17 +70699,19 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.c open-iscsi-2.0-
+ /* Signal we are done closing CNIC/UIO device */
+ pthread_cond_broadcast(&nic->disable_wait_cond);
+ }
-+ pthread_mutex_unlock(&nic->nic_mutex);
+ }
++ pthread_mutex_unlock(&nic->nic_mutex);
+
+ LOG_INFO(PFX "%s: nic loop thread exited", nic->log_name);
+
++ nic->thread = INVALID_THREAD;
++
+ pthread_exit(NULL);
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic.h 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,352 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic.h 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,359 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -70361,6 +70844,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.h open-iscsi-2.0-
+ time_t start_time;
+
+ struct uip_stack ustack;
++ struct nic_interface *vlan_next;
+} nic_interface_t;
+
+/******************************************************************************
@@ -70533,11 +71017,13 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.h open-iscsi-2.0-
+int load_all_nic_libraries();
+
+nic_t *nic_init();
-+void nic_add(nic_t * nic);
-+int nic_remove(nic_t * nic);
++void nic_add(nic_t *nic);
++int nic_remove(nic_t *nic);
+
-+int nic_add_nic_iface(nic_t * nic, nic_interface_t * nic_iface);
-+int nic_process_intr(nic_t * nic, int discard_check);
++int nic_add_nic_iface(nic_t *nic, nic_interface_t *nic_iface);
++int nic_add_vlan_iface(nic_t *nic, nic_interface_t *nic_iface,
++ nic_interface_t *vlan_iface);
++int nic_process_intr(nic_t *nic, int discard_check);
+
+nic_interface_t *nic_iface_init();
+
@@ -70571,6 +71057,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.h open-iscsi-2.0-
+struct nic_interface *nic_find_nic_iface_protocol(nic_t * nic,
+ uint16_t vlan_id,
+ uint16_t protocol);
++struct nic_interface *nic_find_vlan_iface_protocol(nic_t *nic,
++ nic_interface_t *nic_iface,
++ uint16_t vlan_id,
++ uint16_t protocol);
+int find_nic_lib_using_pci_id(uint32_t vendor, uint32_t device,
+ uint32_t subvendor, uint32_t subdevice,
+ nic_lib_handle_t ** handle,
@@ -70581,10 +71071,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic.h open-iscsi-2.0-
+int nic_packet_capture(struct nic *, struct packet *pkt);
+
+#endif /* __NIC_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_id.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_id.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_id.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_id.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_id.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_id.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,369 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_id.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,364 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -70869,17 +71359,12 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_id.c open-iscsi-2
+ sscanf(tok2, "%x", func);
+ LOG_INFO(PFX "%s: is found at %02x:%02x.%02x", nic->log_name,
+ *bus, *slot, *func);
-+
-+ free(read_pci_bus_slot_func_str);
-+
+ rc = 0;
-+
-+ error:
-+ error_alloc_read_pci_bus:
++error:
++ free(read_pci_bus_slot_func_str);
++error_alloc_read_pci_bus:
+ free(path);
-+
-+ error_alloc_path:
-+
++error_alloc_path:
+ return rc;
+}
+
@@ -70954,9 +71439,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_id.c open-iscsi-2
+
+ return 0;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_id.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_id.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_id.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_id.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_id.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_id.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_id.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,46 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -71004,10 +71489,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_id.h open-iscsi-2
+ uint32_t * bus, uint32_t * slot, uint32_t * func);
+
+#endif /* __NIC_ID_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_nl.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_nl.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_nl.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,619 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_nl.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,627 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -71102,7 +71587,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.c open-iscsi-2
+
+#define NL_PROCESS_MAX_RING_SIZE 128
+#define NL_PROCESS_LAST_ENTRY NL_PROCESS_MAX_RING_SIZE - 1
-+#define NL_PROCESS_NEXT_ENTRY(x) ((x) & NL_PROCESS_MAX_RING_SIZE)
++#define NL_PROCESS_NEXT_ENTRY(x) ((x + 1) & NL_PROCESS_MAX_RING_SIZE)
+static int nl_process_head;
+static int nl_process_tail;
+static void *nl_process_ring[NL_PROCESS_MAX_RING_SIZE];
@@ -71339,7 +71824,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.c open-iscsi-2
+
+ if (ev->type == ISCSI_KEVENT_PATH_REQ) {
+ struct timespec sleep_rem;
-+ nic_interface_t *nic_iface;
++ nic_interface_t *nic_iface, *vlan_iface;
+ uint16_t ip_type;
+
+ if (path->ip_addr_len == 4)
@@ -71349,52 +71834,56 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.c open-iscsi-2
+ else
+ ip_type = 0;
+
-+ nic_iface = nic_find_nic_iface_protocol(nic, path->vlan_id,
-+ ip_type);
++ /* Find the parent nic_iface */
++ nic_iface = nic_find_nic_iface_protocol(nic, 0, ip_type);
+ if (nic_iface == NULL) {
-+ nic_interface_t *default_iface;
-+ default_iface = nic_find_nic_iface_protocol(nic,
-+ 0, ip_type);
-+ if (default_iface == NULL) {
-+ LOG_ERR(PFX "%s: Couldn't find default iface "
-+ "vlan: %d ip_type: %d "
-+ "ip_addr_len: %d to clone",
-+ nic->log_name, path->vlan_id, ip_type,
-+ path->ip_addr_len);
-+ goto error;
-+ }
++ LOG_ERR(PFX "%s: Couldn't find nic iface "
++ "vlan: %d ip_type: %d "
++ "ip_addr_len: %d to clone",
++ nic->log_name, path->vlan_id, ip_type,
++ path->ip_addr_len);
++ goto error;
++ }
++ if (path->vlan_id) {
++ vlan_iface = nic_find_vlan_iface_protocol(nic,
++ nic_iface, path->vlan_id, ip_type);
++ if (vlan_iface == NULL) {
++ /* Create a vlan_iface */
++ vlan_iface = nic_iface_init();
++ if (vlan_iface == NULL) {
++ LOG_ERR(PFX "%s: Couldn't allocate "
++ "space for vlan: %d ip_type: "
++ "%d ip_addr_len: %d",
++ nic->log_name, path->vlan_id,
++ ip_type, path->ip_addr_len);
++ goto error;
++ }
+
-+ nic_iface = nic_iface_init();
-+ if (nic_iface == NULL) {
-+ LOG_ERR(PFX "%s: Couldn't allocate space for "
-+ "vlan: %d ip_type: %d "
-+ "ip_addr_len: %d",
-+ nic->log_name, path->vlan_id, ip_type,
-+ path->ip_addr_len);
++ vlan_iface->protocol = ip_type;
++ vlan_iface->vlan_id = path->vlan_id;
++ nic_add_vlan_iface(nic, nic_iface, vlan_iface);
++
++ /* TODO: When VLAN support is placed in */
++ /* the iface file revisit this code */
++ vlan_iface->ustack.ip_config =
++ nic_iface->ustack.ip_config;
++ memcpy(vlan_iface->ustack.hostaddr,
++ nic_iface->ustack.hostaddr,
++ sizeof(nic_iface->ustack.hostaddr));
++ memcpy(vlan_iface->ustack.netmask,
++ nic_iface->ustack.netmask,
++ sizeof(nic_iface->ustack.netmask));
++ memcpy(vlan_iface->ustack.netmask6,
++ nic_iface->ustack.netmask6,
++ sizeof(nic_iface->ustack.netmask6));
++ memcpy(vlan_iface->ustack.hostaddr6,
++ nic_iface->ustack.hostaddr6,
++ sizeof(nic_iface->ustack.hostaddr6));
+
-+ goto error;
++ persist_all_nic_iface(nic);
++ nic_disable(nic, 0);
++ nic_iface = vlan_iface;
+ }
-+
-+ nic_iface->protocol = ip_type;
-+ nic_iface->vlan_id = path->vlan_id;
-+ nic_add_nic_iface(nic, nic_iface);
-+
-+ /* TODO: When VLAN support is placed in the iface file
-+ * revisit this code */
-+ nic_iface->ustack.ip_config =
-+ default_iface->ustack.ip_config;
-+ memcpy(nic_iface->ustack.hostaddr,
-+ default_iface->ustack.hostaddr,
-+ sizeof(nic_iface->ustack.hostaddr));
-+ memcpy(nic_iface->ustack.netmask,
-+ default_iface->ustack.netmask,
-+ sizeof(nic_iface->ustack.netmask));
-+ memcpy(nic_iface->ustack.hostaddr6,
-+ default_iface->ustack.hostaddr6,
-+ sizeof(nic_iface->ustack.hostaddr6));
-+
-+ persist_all_nic_iface(nic);
-+ nic_disable(nic, 0);
+ }
+
+ /* Force enable the NIC */
@@ -71598,9 +72087,13 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.c open-iscsi-2
+ LOG_INFO(PFX "Received if_down event");
+
+ pthread_mutex_lock(&nl_process_mutex);
-+ nl_process_if_down = 1;
++ /* Don't flush the nl ring if another if_down
++ is in progress */
++ if (!nl_process_if_down) {
++ nl_process_if_down = 1;
+
-+ flush_nl_process_ring();
++ flush_nl_process_ring();
++ }
+ pthread_mutex_unlock(&nl_process_mutex);
+ }
+
@@ -71627,9 +72120,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.c open-iscsi-2
+error:
+ return 0;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_nl.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_nl.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_nl.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_nl.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -71684,10 +72177,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_nl.h open-iscsi-2
+extern int nl_process_if_down;
+
+#endif /* __NIC_NL_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_utils.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_utils.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_utils.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,1547 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_utils.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,1657 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -71768,6 +72261,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+static const char iscsi_host_path_template[] = "/sys/class/iscsi_host/host%d";
+static const char iscsi_host_path_netdev_template[] =
+ "/sys/class/iscsi_host/host%d/netdev";
++static const char cnic_uio_sysfs_resc_template[] =
++ "/sys/class/uio/uio%i/device/resource%i";
+
+/**
+ * manually_trigger_uio_event() - If the uio file node doesn't exist then
@@ -71939,6 +72434,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+
+ if (nic_fill_name(nic) != 0) {
+ free(nic);
++ free(raw);
+ rc = -EIO;
+ continue;
+ }
@@ -72163,6 +72659,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+ char *search_paths[] = { "/sys/class/uio/uio%i/device/",
+ "/sys/class/uio/uio%i/device/net"
+ };
++ int path_to[] = { 5, 1 };
+ int (*search_filters[]) (const struct dirent *) = {
+ filter_net_name, filter_dot_out,};
+ char *(*extract_name[]) (struct dirent ** files) = {
@@ -72182,7 +72679,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+ /* Build the path to determine uio name */
+ rc = sprintf(path, search_paths[path_iterator], uio_minor);
+
-+ wait_for_file_node_timed(nic, path, 5);
++ wait_for_file_node_timed(nic, path, path_to[path_iterator]);
+
+ count = scandir(path, &files,
+ search_filters[path_iterator], alphasort);
@@ -72495,6 +72992,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+
+ nic->uio_minor = rc;
+
++ if (nic->flags & NIC_UIO_NAME_MALLOC)
++ free(nic->uio_device_name);
++
+ nic->uio_device_name =
+ malloc(sizeof(uio_udev_path_template) + 8);
+ if (nic->uio_device_name == NULL) {
@@ -72513,6 +73013,15 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+ return 0;
+}
+
++void cnic_get_sysfs_pci_resource_path(nic_t *nic, int resc_no,
++ char *sys_path, size_t size)
++{
++ /* Build the path to sysfs pci resource */
++ snprintf(sys_path, size,
++ cnic_uio_sysfs_resc_template, nic->uio_minor, resc_no);
++
++}
++
+void prepare_library(nic_t * nic)
+{
+ int rc;
@@ -72614,22 +73123,50 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+ rc = gettimeofday(&tp, NULL);
+ ts.tv_sec = tp.tv_sec;
+ ts.tv_nsec = tp.tv_usec * 1000;
-+ /* Changed the timeout to 10s to accommodate for DHCP
-+ timeout */
+ ts.tv_sec += 10;
+
-+ /* Wait for the device to be disabled */
++ /* Wait for the device to be enabled */
+ rc = pthread_cond_timedwait(&nic->enable_done_cond,
+ &nic->nic_mutex, &ts);
++#if 0
++ if (rc || !nic->flags & NIC_ENABLED) {
++ /* Give it one more shout */
++ pthread_cond_broadcast(&nic->enable_wait_cond);
++ rc = gettimeofday(&tp, NULL);
++ ts.tv_sec = tp.tv_sec;
++ ts.tv_nsec = tp.tv_usec * 1000;
++ ts.tv_sec += 5;
++ rc = pthread_cond_timedwait(&nic->enable_done_cond,
++ &nic->nic_mutex, &ts);
++ }
++#endif
+ nic->flags &= ~NIC_ENABLED_PENDING;
-+ pthread_mutex_unlock(&nic->nic_mutex);
+
+ if (rc == 0 && nic->flags & NIC_ENABLED) {
+ LOG_DEBUG(PFX "%s: device enabled", nic->log_name);
+ } else {
+ LOG_ERR(PFX "%s: waiting to finish nic_enable err:%s",
+ nic->log_name, strerror(rc));
++ /* Must clean up the ustack */
++ nic_interface_t *nic_iface = nic->nic_iface;
++ nic_interface_t *vlan_iface;
++ while (nic_iface != NULL) {
++ LOG_INFO(PFX "%s: resetting uIP stack",
++ nic->log_name);
++ uip_reset(&nic_iface->ustack);
++ vlan_iface = nic_iface->vlan_next;
++ while (vlan_iface != NULL) {
++ LOG_INFO(PFX "%s: resetting "
++ "vlan uIP stack",
++ nic->log_name);
++ uip_reset(&vlan_iface->ustack);
++ vlan_iface =
++ vlan_iface->vlan_next;
++ }
++ nic_iface = nic_iface->next;
++ }
+ }
++ pthread_mutex_unlock(&nic->nic_mutex);
+
+ return rc;
+ } else {
@@ -72668,7 +73205,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+ rc = gettimeofday(&tp, NULL);
+ ts.tv_sec = tp.tv_sec;
+ ts.tv_nsec = tp.tv_usec * 1000;
-+ ts.tv_sec += 5; /* TODO: hardcoded wait for 2 seconds */
++ ts.tv_sec += 5; /* TODO: hardcoded wait for 5 seconds */
+
+ /* Wait for the device to be disabled */
+ rc = pthread_cond_timedwait(&nic->disable_wait_cond,
@@ -72716,6 +73253,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+ nic = nic_list;
+ while (nic != NULL) {
+ nic_next = nic->next;
++ nic_close(nic, 1, FREE_ALL_STRINGS);
+ nic_remove(nic);
+ nic = nic_next;
+ }
@@ -72776,7 +73314,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+ */
+void nic_set_all_nic_iface_mac_to_parent(nic_t * nic)
+{
-+ nic_interface_t *current;
++ nic_interface_t *current, *vlan_current;
+
+ pthread_mutex_lock(&nic->nic_mutex);
+
@@ -72786,6 +73324,11 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+ * adapter */
+ memcpy(current->mac_addr, nic->mac_addr, 6);
+
++ vlan_current = current->vlan_next;
++ while (vlan_current != NULL) {
++ memcpy(vlan_current->mac_addr, nic->mac_addr, 6);
++ vlan_current = vlan_current->vlan_next;
++ }
+ current = current->next;
+ }
+
@@ -72975,20 +73518,80 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+
+void persist_all_nic_iface(nic_t * nic)
+{
-+ nic_interface_t *current;
++ nic_interface_t *current, *vlan_iface;
+
+ pthread_mutex_lock(&nic->nic_mutex);
+
+ current = nic->nic_iface;
+ while (current != NULL) {
+ current->flags |= NIC_IFACE_PERSIST;
-+
++ vlan_iface = current->vlan_next;
++ while (vlan_iface != NULL) {
++ vlan_iface->flags |= NIC_IFACE_PERSIST;
++ vlan_iface = vlan_iface->vlan_next;
++ }
+ current = current->next;
+ }
+
+ pthread_mutex_unlock(&nic->nic_mutex);
+}
+
++/**
++ * nic_find_vlan_iface_protocol() - This function is used to find an interface
++ * from the NIC
++ * @param nic_iface - Base NIC to look for the vlan interfaces
++ * @param vlan_id - VLAN id to look for
++ * @param protocol - either AF_INET or AF_INET6
++ * @return nic_iface - if found network interface with the given VLAN ID
++ * if not found a NULL is returned
++ */
++nic_interface_t *nic_find_vlan_iface_protocol(nic_t *nic,
++ nic_interface_t *nic_iface,
++ uint16_t vlan_id,
++ uint16_t protocol)
++{
++ nic_interface_t *current;
++
++ pthread_mutex_lock(&nic->nic_mutex);
++
++ current = nic_iface->vlan_next;
++ while (current != NULL) {
++ if ((current->vlan_id == vlan_id) &&
++ (current->protocol == protocol)) {
++ pthread_mutex_unlock(&nic->nic_mutex);
++ return current;
++ }
++ current = current->vlan_next;
++ }
++
++ pthread_mutex_unlock(&nic->nic_mutex);
++ return NULL;
++}
++
++void set_nic_iface(nic_t *nic, nic_interface_t *nic_iface)
++{
++ nic_interface_t *current, *prev;
++
++ pthread_mutex_lock(&nic->nic_mutex);
++
++ if (nic->nic_iface == nic_iface)
++ goto done;
++
++ prev = nic->nic_iface;
++ current = nic->nic_iface->next;
++ while (current != NULL) {
++ if (current == nic_iface) {
++ prev->next = current->next;
++ current->next = nic->nic_iface;
++ nic->nic_iface = current;
++ goto done;
++ }
++ prev = current;
++ current = current->next;
++ }
++done:
++ pthread_mutex_unlock(&nic->nic_mutex);
++}
+/*******************************************************************************
+ * Packet management utility functions
+ ******************************************************************************/
@@ -73235,10 +73838,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.c open-iscs
+
+ return rc;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_utils.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_utils.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_utils.h 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,96 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_utils.h 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,99 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -73309,12 +73912,15 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.h open-iscs
+ uint16_t ether_type);
+
+nic_interface_t *nic_find_nic_iface(nic_t * nic, uint16_t vlan_id);
++void set_nic_iface(nic_t *nic, nic_interface_t *nic_iface);
+
+void persist_all_nic_iface(nic_t * nic);
+
+int add_vlan_interfaces(nic_t * nic);
+
+int nic_verify_uio_sysfs_name(nic_t * nic);
++void cnic_get_sysfs_pci_resource_path(nic_t *nic, int resc_no,
++ char *sys_path, size_t size);
+void nic_close_all();
+void nic_remove_all();
+
@@ -73335,9 +73941,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_utils.h open-iscs
+int capture_file(char **raw, uint32_t * raw_size, const char *path);
+
+#endif /* __NIC_UTILS_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_vlan.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_vlan.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_vlan.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_vlan.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_vlan.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_vlan.c 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_vlan.c 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,339 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -73678,9 +74284,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_vlan.c open-iscsi
+
+ return 0;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_vlan.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_vlan.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_vlan.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_vlan.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_vlan.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/nic_vlan.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/nic_vlan.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,88 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -73770,9 +74376,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/nic_vlan.h open-iscsi
+
+int valid_vlan(short int vlan);
+#endif /* __NIC_VLAN_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/options.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/options.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/options.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/options.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/options.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/options.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/options.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,116 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
@@ -73854,7 +74460,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/options.h open-iscsi-
+#define ETHERTYPE_VLAN 0x8100 /* IEEE 802.1Q VLAN tagging */
+#endif /* ETHERTYPE_VLAN */
+
-+#define APP_NAME "uIP"
++#define APP_NAME "iscsiuio"
+/* BUILD_DATE is automatically generated from the Makefile */
+
+#define DEBUG_OFF 0x1
@@ -73890,10 +74496,10 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/options.h open-iscsi-
+#define barrier() __asm__ __volatile__("": : :"memory")
+
+#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/packet.c open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/packet.c
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/packet.c open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/packet.c
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/packet.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/packet.c 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,130 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/packet.c 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,146 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -73966,7 +74572,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/packet.c open-iscsi-2
+
+ return pkt;
+
-+ free_pkt:
++free_pkt:
+ free(pkt);
+
+ return NULL;
@@ -74019,15 +74625,31 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/packet.c open-iscsi-2
+
+ rc = num_of_packets;
+
-+ done:
++done:
+ pthread_mutex_unlock(&nic->free_packet_queue_mutex);
+
+ return i;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/packet.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/packet.h
++
++void free_free_queue(nic_t *nic)
++{
++ packet_t *pkt, *pkt_next;
++
++ pthread_mutex_lock(&nic->free_packet_queue_mutex);
++ pkt = nic->free_packet_queue;
++ while (pkt) {
++ pkt_next = pkt->next;
++ free_packet(pkt);
++ pkt = pkt_next;
++ }
++ nic->free_packet_queue = NULL;
++ pthread_mutex_unlock(&nic->free_packet_queue_mutex);
++}
++
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/packet.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/packet.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/packet.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/packet.h 2011-08-03 20:01:01.000000000 -0500
-@@ -0,0 +1,74 @@
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/packet.h 2012-03-05 23:26:42.000000000 -0600
+@@ -0,0 +1,75 @@
+/*
+ * Copyright (c) 2009-2011, Broadcom Corporation
+ *
@@ -74099,12 +74721,13 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/packet.h open-iscsi-2
+ * Packet Function Declarations
+ *****************************************************************************/
+int alloc_free_queue(struct nic *, size_t num_of_packets);
++void free_free_queue(struct nic *nic);
+void reset_packet(packet_t * pkt);
+
+#endif /* __PACKET_H__ */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/uip-conf.h open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/uip-conf.h
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/uip-conf.h open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/uip-conf.h
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/uip-conf.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/src/unix/uip-conf.h 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/src/unix/uip-conf.h 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1,161 @@
+/**
+ * \addtogroup uipopt
@@ -74267,8 +74890,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/src/unix/uip-conf.h open-iscsi
+
+/** @} */
+/** @} */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/stamp-h1 open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/stamp-h1
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/stamp-h1 open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/stamp-h1
--- open-iscsi-2.0-872-rc4-bnx2i/iscsiuio/stamp-h1 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/iscsiuio/stamp-h1 2011-08-03 20:01:01.000000000 -0500
++++ open-iscsi-2.0-872-rc4-bnx2i.uio/iscsiuio/stamp-h1 2012-03-05 23:26:42.000000000 -0600
@@ -0,0 +1 @@
+timestamp for config.h
diff --git a/iscsi-initiator-utils-uip-mgmt.patch b/iscsi-initiator-utils-uip-mgmt.patch
index 8f81b16..1a03a31 100644
--- a/iscsi-initiator-utils-uip-mgmt.patch
+++ b/iscsi-initiator-utils-uip-mgmt.patch
@@ -1,6 +1,6 @@
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/include/iscsi_err.h open-iscsi-2.0-872-rc4-bnx2i.build/include/iscsi_err.h
---- open-iscsi-2.0-872-rc4-bnx2i.base/include/iscsi_err.h 2011-08-14 16:49:44.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/include/iscsi_err.h 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_err.h open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_err.h
+--- open-iscsi-2.0-872-rc4-bnx2i/include/iscsi_err.h 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/include/iscsi_err.h 2012-03-05 23:36:29.000000000 -0600
@@ -58,6 +58,8 @@ enum {
ISCSI_ERR_ISNS_QUERY = 25,
/* iSNS registration/deregistration failed */
@@ -10,21 +10,21 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/include/iscsi_err.h open-iscsi-2.0
/* Always last. Indicates end of error code space */
ISCSI_MAX_ERR_VAL,
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/Makefile open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/Makefile
---- open-iscsi-2.0-872-rc4-bnx2i.base/libiscsi/Makefile 2011-08-14 16:55:23.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/libiscsi/Makefile 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/libiscsi/Makefile open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/Makefile
+--- open-iscsi-2.0-872-rc4-bnx2i/libiscsi/Makefile 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/libiscsi/Makefile 2012-03-05 23:37:25.000000000 -0600
@@ -13,7 +13,7 @@ TESTS += tests/test_set_auth tests/test_
COMMON_SRCS = sysdeps.o
# sources shared between iscsid, iscsiadm and iscsistart
--ISCSI_LIB_SRCS = netlink.o transport.o cxgbi.o be2iscsi.o iscsi_timer.o initiator_common.o iscsi_err.o session_info.o iscsi_util.o dcb_app.o io.o auth.o discovery.o login.o log.o md5.o sha1.o iface.o idbm.o sysfs.o iscsi_sysfs.o iscsi_net_util.o iscsid_req.o
-+ISCSI_LIB_SRCS = netlink.o uip_mgmt_ipc.o transport.o cxgbi.o be2iscsi.o iscsi_timer.o initiator_common.o iscsi_err.o session_info.o iscsi_util.o dcb_app.o io.o auth.o discovery.o login.o log.o md5.o sha1.o iface.o idbm.o sysfs.o iscsi_sysfs.o iscsi_net_util.o iscsid_req.o
+-ISCSI_LIB_SRCS = netlink.o transport.o iser.o cxgbi.o be2iscsi.o iscsi_timer.o initiator_common.o iscsi_err.o session_info.o iscsi_util.o dcb_app.o io.o auth.o discovery.o login.o log.o md5.o sha1.o iface.o idbm.o sysfs.o iscsi_sysfs.o iscsi_net_util.o iscsid_req.o
++ISCSI_LIB_SRCS = netlink.o uip_mgmt_ipc.o transport.o iser.o cxgbi.o be2iscsi.o iscsi_timer.o initiator_common.o iscsi_err.o session_info.o iscsi_util.o dcb_app.o io.o auth.o discovery.o login.o log.o md5.o sha1.o iface.o idbm.o sysfs.o iscsi_sysfs.o iscsi_net_util.o iscsid_req.o
FW_PARAM_SRCS = fw_entry.o prom_lex.o prom_parse.tab.o fwparam_ppc.o fwparam_sysfs.o
# sources shared with the userspace utils, note we build these separately
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.c open-iscsi-2.0-872-rc4-bnx2i.build/usr/initiator.c
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.c 2011-08-14 16:49:44.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/initiator.c 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.c 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator.c 2012-03-05 23:36:29.000000000 -0600
@@ -45,6 +45,7 @@
#include "iscsi_sysfs.h"
#include "iscsi_settings.h"
@@ -32,7 +32,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.c open-iscsi-2.0-872
+#include "host.h"
#include "sysdeps.h"
#include "iscsi_err.h"
-
+ #include "kern_err_table.h"
@@ -557,6 +558,48 @@ static int iscsi_conn_connect(struct isc
return 0;
}
@@ -94,7 +94,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.c open-iscsi-2.0-872
if (iscsi_conn_connect(conn, qtask)) {
delay = ISCSI_CONN_ERR_REOPEN_DELAY;
goto queue_reopen;
-@@ -1659,6 +1707,53 @@ failed_login:
+@@ -1667,6 +1715,53 @@ failed_login:
}
@@ -148,7 +148,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.c open-iscsi-2.0-872
static int iscsi_sched_ev_context(struct iscsi_ev_context *ev_context,
struct iscsi_conn *conn, unsigned long tmo,
int event)
-@@ -1700,6 +1795,11 @@ static int iscsi_sched_ev_context(struct
+@@ -1708,6 +1803,11 @@ static int iscsi_sched_ev_context(struct
ev_context);
actor_schedule(&ev_context->actor);
break;
@@ -160,7 +160,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.c open-iscsi-2.0-872
case EV_CONN_LOGOUT_TIMER:
actor_timer(&ev_context->actor, tmo * 1000,
iscsi_logout_timedout, ev_context);
-@@ -1833,7 +1933,17 @@ session_login_task(node_rec_t *rec, queu
+@@ -1841,7 +1941,17 @@ session_login_task(node_rec_t *rec, queu
conn = &session->conn[0];
qtask->conn = conn;
@@ -179,7 +179,7 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.c open-iscsi-2.0-872
__session_destroy(session);
return ISCSI_ERR_LOGIN;
}
-@@ -1990,6 +2100,7 @@ iscsi_host_send_targets(queue_task_t *qt
+@@ -1998,6 +2108,7 @@ iscsi_host_send_targets(queue_task_t *qt
struct sockaddr_storage *ss)
{
struct iscsi_transport *t;
@@ -187,9 +187,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.c open-iscsi-2.0-872
t = iscsi_sysfs_get_transport_by_hba(host_no);
if (!t) {
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator_common.c open-iscsi-2.0-872-rc4-bnx2i.build/usr/initiator_common.c
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator_common.c 2011-08-14 16:49:44.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/initiator_common.c 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator_common.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator_common.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/initiator_common.c 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator_common.c 2012-03-05 23:36:29.000000000 -0600
@@ -561,6 +561,36 @@ TODO handle this
return 0;
}
@@ -238,9 +238,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator_common.c open-iscsi-
rc = host_set_param(t, session->hostno,
ISCSI_HOST_PARAM_IPADDRESS,
iface->ipaddress, ISCSI_STRING);
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.h open-iscsi-2.0-872-rc4-bnx2i.build/usr/initiator.h
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.h 2011-08-14 16:49:44.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/initiator.h 2011-08-14 16:58:14.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/initiator.h 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/initiator.h 2012-03-05 23:36:29.000000000 -0600
@@ -83,6 +83,7 @@ typedef enum iscsi_event_e {
EV_CONN_LOGOUT_TIMER,
EV_CONN_STOP,
@@ -258,9 +258,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/initiator.h open-iscsi-2.0-872
+ struct iface_rec *iface);
#endif /* INITIATOR_H */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsid_req.c open-iscsi-2.0-872-rc4-bnx2i.build/usr/iscsid_req.c
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsid_req.c 2011-08-14 16:49:44.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/iscsid_req.c 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid_req.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.c 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid_req.c 2012-03-05 23:36:29.000000000 -0600
@@ -22,6 +22,7 @@
#include <stdlib.h>
#include <string.h>
@@ -391,9 +391,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsid_req.c open-iscsi-2.0-87
+ close(fd);
+ return err;
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsid_req.h open-iscsi-2.0-872-rc4-bnx2i.build/usr/iscsid_req.h
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsid_req.h 2011-08-14 16:49:44.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/iscsid_req.h 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid_req.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsid_req.h 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsid_req.h 2012-03-05 23:36:29.000000000 -0600
@@ -33,4 +33,6 @@ extern int iscsid_req_by_rec(int cmd, st
extern int iscsid_req_by_sid_async(int cmd, int sid, int *fd);
extern int iscsid_req_by_sid(int cmd, int sid);
@@ -401,9 +401,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsid_req.h open-iscsi-2.0-87
+extern int uip_broadcast(void *buf, size_t buf_len);
+
#endif
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsi_err.c open-iscsi-2.0-872-rc4-bnx2i.build/usr/iscsi_err.c
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsi_err.c 2011-08-14 16:49:44.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/iscsi_err.c 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_err.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_err.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/iscsi_err.c 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/iscsi_err.c 2012-03-05 23:36:29.000000000 -0600
@@ -49,6 +49,7 @@ static char *iscsi_err_msgs[] = {
/* 24 */ "iSCSI login failed due to authorization failure",
/* 25 */ "iSNS query failed",
@@ -412,22 +412,22 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/iscsi_err.c open-iscsi-2.0-872
};
char *iscsi_err_to_str(int err)
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/Makefile open-iscsi-2.0-872-rc4-bnx2i.build/usr/Makefile
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/Makefile 2011-08-14 16:55:23.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/Makefile 2011-08-14 16:58:57.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/Makefile open-iscsi-2.0-872-rc4-bnx2i.work/usr/Makefile
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/Makefile 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/Makefile 2012-03-05 23:38:00.000000000 -0600
@@ -42,7 +42,8 @@ SYSDEPS_SRCS = $(wildcard ../utils/sysde
ISCSI_LIB_SRCS = iscsi_util.o io.o auth.o iscsi_timer.o login.o log.o md5.o \
sha1.o iface.o idbm.o sysfs.o host.o session_info.o iscsi_sysfs.o \
- iscsi_net_util.o iscsid_req.o transport.o cxgbi.o be2iscsi.o \
+ iscsi_net_util.o iscsid_req.o transport.o iser.o cxgbi.o be2iscsi.o \
- initiator_common.o iscsi_err.o $(IPC_OBJ) $(SYSDEPS_SRCS) $(DCB_OBJ)
+ initiator_common.o iscsi_err.o uip_mgmt_ipc.o \
+ $(IPC_OBJ) $(SYSDEPS_SRCS) $(DCB_OBJ)
# core initiator files
- INITIATOR_SRCS = initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o
+ INITIATOR_SRCS = initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o kern_err_table.o
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/transport.c open-iscsi-2.0-872-rc4-bnx2i.build/usr/transport.c
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/transport.c 2011-08-14 16:49:44.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/transport.c 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/transport.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/transport.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/transport.c 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/transport.c 2012-03-05 23:36:29.000000000 -0600
@@ -25,6 +25,7 @@
#include "log.h"
#include "iscsi_util.h"
@@ -435,8 +435,8 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/transport.c open-iscsi-2.0-872
+#include "uip_mgmt_ipc.h"
#include "cxgbi.h"
#include "be2iscsi.h"
-
-@@ -67,6 +68,7 @@ struct iscsi_transport_template bnx2i =
+ #include "iser.h"
+@@ -69,6 +70,7 @@ struct iscsi_transport_template bnx2i =
.ep_connect = ktransport_ep_connect,
.ep_poll = ktransport_ep_poll,
.ep_disconnect = ktransport_ep_disconnect,
@@ -444,9 +444,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/transport.c open-iscsi-2.0-872
};
struct iscsi_transport_template be2iscsi = {
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/transport.h open-iscsi-2.0-872-rc4-bnx2i.build/usr/transport.h
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/transport.h 2011-08-14 16:49:34.000000000 -0500
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/transport.h 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/transport.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/transport.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/transport.h 2012-03-05 23:36:21.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/transport.h 2012-03-05 23:36:29.000000000 -0600
@@ -35,6 +35,9 @@ struct iscsi_transport_template {
int (*ep_poll) (struct iscsi_conn *conn, int timeout_ms);
void (*ep_disconnect) (struct iscsi_conn *conn);
@@ -457,9 +457,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/transport.h open-iscsi-2.0-872
};
/* represents data path provider */
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/uip_mgmt_ipc.c open-iscsi-2.0-872-rc4-bnx2i.build/usr/uip_mgmt_ipc.c
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/uip_mgmt_ipc.c 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/uip_mgmt_ipc.c 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/uip_mgmt_ipc.c open-iscsi-2.0-872-rc4-bnx2i.work/usr/uip_mgmt_ipc.c
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/uip_mgmt_ipc.c 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/uip_mgmt_ipc.c 2012-03-05 23:36:29.000000000 -0600
@@ -0,0 +1,41 @@
+/*
+ * uIP iSCSI Daemon/Admin Management IPC
@@ -502,9 +502,9 @@ diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/uip_mgmt_ipc.c open-iscsi-2.0-
+ sizeof(iscsid_uip_broadcast_header_t) +
+ sizeof(*iface));
+}
-diff -Naurp open-iscsi-2.0-872-rc4-bnx2i.base/usr/uip_mgmt_ipc.h open-iscsi-2.0-872-rc4-bnx2i.build/usr/uip_mgmt_ipc.h
---- open-iscsi-2.0-872-rc4-bnx2i.base/usr/uip_mgmt_ipc.h 1969-12-31 18:00:00.000000000 -0600
-+++ open-iscsi-2.0-872-rc4-bnx2i.build/usr/uip_mgmt_ipc.h 2011-08-14 16:56:54.000000000 -0500
+diff -Naurp open-iscsi-2.0-872-rc4-bnx2i/usr/uip_mgmt_ipc.h open-iscsi-2.0-872-rc4-bnx2i.work/usr/uip_mgmt_ipc.h
+--- open-iscsi-2.0-872-rc4-bnx2i/usr/uip_mgmt_ipc.h 1969-12-31 18:00:00.000000000 -0600
++++ open-iscsi-2.0-872-rc4-bnx2i.work/usr/uip_mgmt_ipc.h 2012-03-05 23:36:29.000000000 -0600
@@ -0,0 +1,73 @@
+/*
+ * uIP iSCSI Daemon/Admin Management IPC
diff --git a/iscsi-initiator-utils.spec b/iscsi-initiator-utils.spec
index 6dfe341..523c79c 100644
--- a/iscsi-initiator-utils.spec
+++ b/iscsi-initiator-utils.spec
@@ -3,15 +3,16 @@
Summary: iSCSI daemon and utility programs
Name: iscsi-initiator-utils
Version: 6.2.0.872
-Release: 35%{?dist}
+Release: 36%{?dist}
Source0: http://people.redhat.com/mchristi/iscsi/rhel6.0/source/open-iscsi-2.0-872-rc4-bnx2i.tar.gz
Source1: iscsid.init
Source2: iscsidevs.init
Source3: 04-iscsi
-# sync brcm to 0.7.0.12
-Patch0: iscsi-initiator-utils-sync-uio-0.7.0.8.patch
-# sync iscsi tools to upstream commit e8c5b1d34ee5ce0a755ff54518829156dfa5fabe
+# sync brcm to 0.7.2.1
+Patch0: iscsi-initiator-utils-sync-uio-0.7.2.1.patch
+# sync iscsi tools to upstream commit 2e342633db5ac211947ffad1d8da718f6f065d3e
+# (iscsi tools: update iscsi_if.h for host event)
Patch1: iscsi-initiator-utils-sync-iscsi.patch
# Add Red Hat specific info to docs.
Patch2: iscsi-initiator-utils-update-initscripts-and-docs.patch
@@ -27,40 +28,17 @@ Patch6: iscsi-initiator-utils-uip-mgmt.patch
Patch7: iscsi-initiator-utils-dont-use-static.patch
# Remove the OFFLOAD_BOOT_SUPPORTED #ifdef.
Patch8: iscsi-initiator-utils-remove-the-offload-boot-supported-ifdef.patch
-# brcm uio: handle the different iface_rec structures in iscsid and brcm.
-Patch9: iscsi-initiator-utils-uio-handle-different-iface_rec.patch
-# Document missing brcm arguments
-Patch10: iscsi-initiator-utils-brcm-man.patch
-# setup default ifaces for all ifaces in kernel
-Patch11: iscsi-initiator-utils-fix-default-bindings.patch
-# fix iscsiadm return value/msg when login fails
-Patch12: iscsi-initiator-utils-fix-iscsiadm-return.patch
-# don't use openssl-devel
-Patch13: iscsi-initiator-utils-dont-use-openssl.patch
-# sync uio to 0.7.0.14
-Patch14: iscsi-initiator-utils-sync-uio-0.7.0.14.patch
-# fix nl msglen
-Patch15: iscsi-initiator-utils-fix-nlmsglen.patch
-# fixes for offload iface support
-Patch16: iscsi-initiator-utils-ofl-iface-fixes.patch
# fix ipv6 ibft/firmware boot
-Patch17: iscsi-initiator-utils-fix-ipv6-boot.patch
+Patch9: iscsi-initiator-utils-fix-ipv6-boot.patch
# netconfig libiscsi support
-Patch18: iscsi-initiator-utils-Add-Netconfig-support-through-libiscsi.patch
+Patch10: iscsi-initiator-utils-Add-Netconfig-support-through-libiscsi.patch
# libiscsi offload support
-Patch19: iscsi-initiator-utils-libiscsi-to-support-offload.patch
-# sync iscsiuio to 0.7.0.14g
-Patch20: iscsi-initiator-utils-sync-uio-0.7.0.14g.patch
-# return on exists
-Patch21: iscsi-initiator-utils-return-on-exists.patch
-# don't sync kernel sessions.
-Patch22: iscsi-initiator-utils-dont-sync-kern-sess.patch
-# allow iscsistart to take in any setting
-Patch23: iscsi-initiator-utils-iscsistart-param.patch
-# fix -i mode use
-Patch24: iscsi-initiator-utils-fix-readme-imode.patch
+Patch11: iscsi-initiator-utils-libiscsi-to-support-offload.patch
+# sync to upstream commit f9f627fbf0fc96545931ae65aa2b6214841bfd4e to
+# add iscsiadm ping and host chap support and fix default iface handling
+Patch12: iscsi-initiator-utils-ping-and-chap.patch
# add rhel version info to iscsi tools
-Patch25: iscsi-initiator-utils-add-rh-ver.patch
+Patch13: iscsi-initiator-utils-add-rh-ver.patch
Group: System Environment/Daemons
License: GPLv2+
@@ -88,7 +66,7 @@ developing applications that use %{name}.
%prep
%setup -q -n open-iscsi-2.0-872-rc4-bnx2i
-%patch0 -p1 -b .sync-uio-0.7.0.8
+%patch0 -p1 -b .sync-uio-0.7.2.1
%patch1 -p1 -b .sync-iscsi
%patch2 -p1 -b .update-initscripts-and-docs
%patch3 -p1 -b .use-var-for-config
@@ -97,23 +75,11 @@ developing applications that use %{name}.
%patch6 -p1 -b .uip-mgmt
%patch7 -p1 -b .dont-use-static
%patch8 -p1 -b .remove-the-offload-boot-supported-ifdef
-%patch9 -p1 -b .uio-handle-different-iface_rec
-%patch10 -p1 -b .brcm-man
-%patch11 -p1 -b .fix-default-bindings
-%patch12 -p1 -b .fix-iscsiadm-return
-%patch13 -p1 -b .dont-use-openssl
-%patch14 -p1 -b .sync-uio-0.7.0.14
-%patch15 -p1 -b .fix-nlmsglen
-%patch16 -p1 -b .ofl-iface-fixes
-%patch17 -p1 -b .fix-ipv6-boot
-%patch18 -p1 -b .Add-Netconfig-support-through-libiscsi
-%patch19 -p1 -b .libiscsi-to-support-offload
-%patch20 -p1 -b .sync-uio-0.7.0.14g
-%patch21 -p1 -b .return-on-exists
-%patch22 -p1 -b .dont-sync-kern-sess
-%patch23 -p1 -b .iscsistart-param
-%patch24 -p1 -b .fix-readme-imode
-%patch25 -p1 -b .add-rh-ver
+%patch9 -p1 -b .fix-ipv6-boot
+%patch10 -p1 -b .Add-Netconfig-support-through-libiscsi
+%patch11 -p1 -b .libiscsi-to-support-offload
+%patch12 -p1 -b .ping-and-chap
+%patch13 -p1 -b .add-rh-ver
%build
cd utils/open-isns
@@ -239,6 +205,11 @@ fi
%{_includedir}/libiscsi.h
%changelog
+* Mon Mar 5 2012 Mike Christie <mcrhsit at redhat.com> 6.2.0.872.36
+- 740054 sync iscsiuio to 0.7.2.1
+- 790609 Add ping and host chap support to iscsiadm
+- 636013 scalability testing.
+
* Sun Feb 26 2012 Mike Christie <mcrhsit at redhat.com> 6.2.0.872.35
- 738192 Allow iscsistart to take any parameter.
- 739049 Fix -i use in README.
More information about the scm-commits
mailing list