summaryrefslogtreecommitdiffstats
path: root/src/interface/smbios
diff options
context:
space:
mode:
authorMichael Brown2011-12-05 21:28:45 +0100
committerMichael Brown2011-12-05 21:39:07 +0100
commitbd718b211020fb6932035a2fbab4c3e82d623a74 (patch)
tree620a8eb02cc4ccd7318fdd2b2b35d4e76e4cec01 /src/interface/smbios
parent[build] Include UNDI PCI driver within all-drivers build (diff)
downloadipxe-bd718b211020fb6932035a2fbab4c3e82d623a74.tar.gz
ipxe-bd718b211020fb6932035a2fbab4c3e82d623a74.tar.xz
ipxe-bd718b211020fb6932035a2fbab4c3e82d623a74.zip
[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>
Diffstat (limited to 'src/interface/smbios')
0 files changed, 0 insertions, 0 deletions