On Thu, 2014-02-13 at 19:32 +0530, Sumit Rai wrote: > On 02/12/2014 12:23 AM, Nicholas A. Bellinger wrote: > > On Tue, 2014-02-11 at 19:10 +0530, Sumit Rai wrote: > >> Hi, > >> > >> I am sending login PDU with CSG=Security Negotiation, T=0, NSG=2. > >> Note: We deliberately setting NSG to invalid value of 2. > >> > >> Now, the Target is failing the login with 'Initiator Error > >> (miscellaneous error)'. > >> > >> It's my understanding that since T bit is 0, NSG is reserved and invalid > >> NSG should not cause login to fail. > >> > >> As per RFC "The next stage value is only valid when the T bit is 1; > >> otherwise, it is reserved." > >> > >> "10.12.3. CSG and NSG > >> > >> Through these fields, Current Stage (CSG) and Next Stage (NSG), the > >> Login negotiation requests and responses are associated with a > >> specific stage in the session (SecurityNegotiation, > >> LoginOperationalNegotiation, FullFeaturePhase) and may indicate the > >> next stage to which they want to move (see Chapter 5). The next > >> stage value is only valid when the T bit is 1; otherwise, it is > >> reserved. > >> > >> The stage codes are: > >> > >> - 0 - SecurityNegotiation > >> - 1 - LoginOperationalNegotiation > >> - 3 - FullFeaturePhase > >> > >> All other codes are reserved." > >> > >> Is this an expected behavior? > >> > > > > Yes. My original interpretation was that valid values for stage codes > > are ignored when the transmit bit is not set. However, values such as > > NSG=2 (eg: an illegal value) are always considered a protocol error, > > regardless of transmit bit. > > > > --nab > > > > > > RFC states > "Any compliant sender MUST set all bits not defined and all reserved > fields to zero unless specified otherwise. Any compliant receiver > MUST ignore any bit not defined and all reserved fields unless > specified otherwise. Receipt of reserved code values in defined > fields MUST be reported as a protocol error." > > It's my understanding that sending reserved code values (e.g. 2 in NSG > Field since all codes other than 0,1, 3 are reserved) in defined field > is considered an protocol error. But, according to RFC NSG is reserved > field when T=0 so target must ignore it. > > Is my understanding correct? > Again, my interpretation of 'ignoring the NSG bit' means that no login state transition is performed (by the target) after the login response is sent, and not that related protocol error / sanity checks for the NSG bit field are skipped. --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
