Hi Nicholas,
Quoting "Nicholas A. Bellinger" <nab@xxxxxxxxxxxxxxx>:
On Wed, 2013-11-13 at 17:07 +0530, Sumeet Gandhare wrote:
Hi,
I am attempting to transmit a login request with invalid key from
initiator to target. This is done as part of ISCSI Protocol Conformance
testing.
TargetAlias="My LIO Target"
TargetportalGroupTag=1
TargetAddress="10.0.0.15:3260"
Since these keys are invalid, I am expecting the target to send reject
or reject with disconnect.
Not sure that I agree with that assumption. Care to provide a pointer
in the spec where it describes this as a requirement..?
The 'dmesg' output i have provided shows that the target treats this as
"protocol error'.
Apparently not, the 'protocol error' message is just printk() output.
However, the target is sending out key/value pair with "NotUnderstood"
string. Are we looking at an error with LIO?
According to section 5.2 Text Mode Negotiation:
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.
Or this is how LIO behaves.Please comment.
Care to explain why the NotUnderstood 'MUST' above does not apply
here..?
Thanks a lot for the quick response and pointing out Section 5.2 for
Text Mode Negotiations. What you say does make sense.
I was however confused because I was reading it in conjunction with
Section 6.3 in RFC 5048 on iSCSI Corrections and Clarifications where it
says -
All keys defined in [RFC3720 <http://tools.ietf.org/html/rfc3720> ]
MUST be supported by all compliant implementations; a NotUnderstood
answer on any of the
[RFC3720 <http://tools.ietf.org/html/rfc3720> ] keys therefore MUST be
considered a protocol error and
handled accordingly.
http://tools.ietf.org/html/rfc5048#section-6.3
That seemed to suggest to me that it is expected of any iSCSI
implementation to understand the keys defined in RFC3720 and hence
should not respond with NotUnderstood and if it does then it would be
considered a protocol error.
What do think should be the behavior in light of section 6.3 in RFC 5048 ?
Regards,
Sumeet
--nab
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
