]> git.ipfire.org Git - thirdparty/ipxe.git/commit
[iscsi] Fail immediately if target rejects any of our parameters
authorMichael Brown <mcb30@ipxe.org>
Mon, 5 Dec 2011 20:28:45 +0000 (20:28 +0000)
committerMichael Brown <mcb30@ipxe.org>
Mon, 5 Dec 2011 20:39:07 +0000 (20:39 +0000)
commitbd718b211020fb6932035a2fbab4c3e82d623a74
tree620a8eb02cc4ccd7318fdd2b2b35d4e76e4cec01
parentc46acda67200bf01c27d1d039f1abc9b0e71b2b7
[iscsi] Fail immediately if target rejects any of our parameters

Some iSCSI targets (observed with stgt) can be configured to reject
connections that do not use header or data digests, and will respond
with "HeaderDigest=Reject" and/or "DataDigest=Reject", while still
allowing the connection to proceed to the full feature phase.

According to a strict reading of RFC3720, we are perfectly safe to
ignore these "Reject" messages: upon such a rejection "the negotiated
key is left at its current value (or default if no value was set)".
Since the default value for both HeaderDigest and DataDigest is
"None", then the only viable conclusion to be drawn is that the value
resulting from "Reject" is still "None".

Unfortunately, stgt doesn't seem to agree with this interpretation of
events, causing us to eventually report an unhelpful "connection timed
out" message to the user when we don't get any response to our first
PDU in full feature phase.

Fix by detecting any rejected parameters and immediately reporting an
error, which at least gives the user some insight as to what the real
problem may be.

Reported-by: Michal Suchanek <hramrach@centrum.cz>
Tested-by: Michal Suchanek <hramrach@centrum.cz>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
src/net/tcp/iscsi.c