On Fri, 2017-03-31 at 00:09 -0700, Nicholas A. Bellinger wrote: > On Thu, 2017-03-30 at 22:35 -0700, Arun Easi wrote: <SNIP> > > > > > > The result is that since the QLogic MSFT initiator doesn't propose them, > > > LIO proposes them itself, and then immediately transitions to full > > > feature phase. However, the QLogic MSFT side still attempts to respond > > > to DefaultTime2Retain and DefaultTime2Wait, even though > > > ISCSI_FLAG_LOGIN_NEXT_STAGE3 and ISCSI_FLAG_LOGIN_TRANSIT have been set > > > in the last login response by LIO. > > > > > > AFAIK, this is the only initiator I've seen that doesn't propose > > > DefaultTime2Retain + DefaultTime2Wait, also doesn't honor the target's > > > request to transition to full feature phase, but then still attempts to > > > respond to the keys. > > > > Interestingly, I was suggesting the same as a workaround to our Windows > > driver team earlier Today. > > > > :-) > > > > > > > So really this is a grey area. The original hack to support GlobalSAN > > > is definitely not RFC, but at the same time Qlogic MSFT should really be > > > sending DefaultTime2Retain + DefaultTime2Wait, and should be honoring > > > LIO's ISCSI_FLAG_LOGIN_NEXT_STAGE3 and ISCSI_FLAG_LOGIN_TRANSIT to > > > transition to full feature phase. > > > > IMHO, not proposing the keys (and taking defaults, instead) is better, and > > more RFC compliant, than not waiting for a response to the proposed keys. > > This would not be so bad because most initiators proposes main keys in the > > initial request itself anyway. > > > > This is what RFC has to say about the response to proposals: > > > > Responses are REQUIRED in all other cases, and the value chosen and > > sent by the acceptor becomes the outcome of the negotiation. > > > > The exception was given only to boolean keys; given that these keys are > > not boolean keys, initiators are required by the RFC to respond. > > > > ..and this about using defaults: > > > > All negotiations are explicit (i.e., the result MUST only be based on > > newly exchanged or declared values). There are no implicit > > proposals. If a proposal is not made, then a reply cannot be > > expected. Conservative design also requires that default values > > should not be relied upon when use of some other value has serious > > consequences. > > > > Just my 2c. > > > > In retrospect, I agree not proposing the keys and using RFC defaults > instead is a better approach than the original hack. It would involve a > larger change to existing code to work though.. > > In the case DefaultTime2Retain and DefaultTime2Wait having either sides > use (potentially) different values is harmless, considering they don't > have anything to do with I/O. > > However, the original GlobalSAN initiator also didn't propose nor > respond to FirstBurstLength or MaxBurstLength.. > > So taking the approach to just use defaults and don't propose anything > for the non I/O related keys would be OK, but for the I/O related keys > that may not be as safe an assumption. > > That said, looking around it appears at least some version of GlobalSAN > are now proposing the keys the hack in question originally addressed: > > https://forums.freebsd.org/threads/51006/ > > Albeit, the log output is from discovery but I think it's a good sign > the RFC breakage may finally be addressed. > > If that is the case, I'd much proper to drop this old hack all-together. > > So I'll go steal a MacOSX laptop from someone tomorrow and give it a > shot with a modern GlobalSAN version. > Ok, I've been able to confirm with GlobalSAN iSCSI v5.3.0.541 that it does correctly propose the four keys in question, and makes the original hack in iscsi_check_proposer_for_optional_reply() that is causing problems here, now unnecessary. Sending out a patch for this shortly. Martin + Arun + QLogic folks, please verify on your end. -- 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
