Hey Arun! Long time no see. Hope that you are well. On Thu, 2017-03-30 at 22:35 -0700, Arun Easi wrote: > Hi Nic, > > On Thu, 30 Mar 2017, 10:02pm, Nicholas A. Bellinger wrote: > > > Hi Martin & Co, > > > > On Thu, 2017-03-23 at 15:44 +0100, Martin Svec wrote: > > > Hello Himanshu, > > > > > > Dne 22.3.2017 v 2:19 Madhani, Himanshu napsal(a): > > > > Hello Nic, Martin, <SNIP> > > > > After reviewing the packet capture, it's clear what's going on.. > > > > So the initiator is not proposing DefaultTime2Retain and > > DefaultTime2Wait, so the target proposes them itself and then > > transitions to full feature phase operation by setting > > ISCSI_FLAG_LOGIN_NEXT_STAGE3 and ISCSI_FLAG_LOGIN_TRANSIT. > > > > The problem is, a hack was made to allow the GlobalSAN iSCSI initiator > > for MacOSX (which didn't follow RFC) to work waaay back in 2009, to > > allow the response of these two keys (along with two other keys) to be > > optional. > > > > https://groups.google.com/forum/#!topic/linux-iscsi-target-dev/7mtXSSwGR98 > > Thanks for the background, I was under the impression that this was just a > plain bug in TCM target. > > > > > 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. -- 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
