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> > > > > > Here’s response i got from our windows driver team > > > > > > —— > > > There is a known issue with iscsi login in tcm/lio side and we have a driver workaround for > > > handling this target issue. > > > > > > Please try with registry key ‘wkflg=1’. See attached snapshot > > > > > > Thanks, > > > - Himanshu > > > > > I tried the workaround in "qeois" key and also in "bxois" key which seem to be the right service > > in our case, but with no luck. Then, I downgraded iSCSI Adapter driver to the version recommended > > by Dell and upgraded back to the latest version found by Windows Driver Update (ver. 7.14.1.1). > > None of it fixed the issue. Do the OEM-branded BCM57840S drivers support this workaround? > > > > Used registry keys: > > > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\bxois\Parameters\Device] > > "DriverParameter"="wkflg=1" > > > > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\qeois\Parameters\Device] > > "DriverParameter"="wkflg=1" > > > > 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. Regards, -Arun > > That said, here is a patch to disable the GlobalSAN hack that should get > you up and running. > > Preferably, I'd like to drop the old GlobalSAN hack to avoid this > situation all together, but I don't know if it still suffers from the > same bug or not. > > Give this a shot, and let's see if we can find someone with a recent > version of GlobalSAN to determine if it suffers from the same breakage. > > diff --git a/drivers/target/iscsi/iscsi_target_parameters.c b/drivers/target/iscsi/iscsi_target_param > index e65bf78..ecde825 100644 > --- a/drivers/target/iscsi/iscsi_target_parameters.c > +++ b/drivers/target/iscsi/iscsi_target_parameters.c > @@ -793,10 +793,12 @@ static void iscsi_check_proposer_for_optional_reply(struct iscsi_param *param) > SET_PSTATE_REPLY_OPTIONAL(param); > if (!strcmp(param->name, FIRSTBURSTLENGTH)) > SET_PSTATE_REPLY_OPTIONAL(param); > +#if 0 > if (!strcmp(param->name, DEFAULTTIME2WAIT)) > SET_PSTATE_REPLY_OPTIONAL(param); > if (!strcmp(param->name, DEFAULTTIME2RETAIN)) > SET_PSTATE_REPLY_OPTIONAL(param); > +#endif > /* > * Required for gPXE iSCSI boot client > */ >
