On Thu, 2013-11-14 at 21:06 +0530, sumeet.gandhare@xxxxxxxxxxxxxx wrote: > 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 ? > Here is the language from RFC5048, Section 6.3 that reinforces the how the current implementation works: NotUnderstood has the reserved meaning that the sending side did not understand the proposed key semantics. Eg: The initiator sending Target[Alias,PortalGroupTag,Address] declarative keys to the target and getting a NotUnderstood response is correct, because the initiator implementation 'did not understand the proposed key semantics' which dictate these three specific keys are only to be proposed by the target. Also, wrt to the language mentioned above: All keys defined in [RFC3720] MUST be supported by all compliant implementations; a NotUnderstood answer on any of the [RFC3720] keys therefore MUST be considered a protocol error and handled accordingly This means that once the proposer gets the NotUnderstood answer it MUST be considered a protocol error (because it sent a key it is not allowed to be proposing), and *not* the accepting side generating the protocol error. If the accepting side was to generate the protocol error and fail the login attempt, then the NotUnderstood response would never actually be returned to the proposer! And to drill down on the RFC3720 5.2 Text Mode Negotiation language again: Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. The key part being 'not understood by the acceptor', and not 'not defined within this RFC'. So based on these points, a target sending NotUnderstood responses to an initiator proposing keys (only the target should be declaring) makes sense in order to signal the initiator does not understand the proposed key schematics. --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
