bd718b2110
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> |
||
|---|---|---|
| .. | ||
| ftp.c | ||
| http.c | ||
| https.c | ||
| iscsi.c | ||