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 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. 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. 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 */ -- 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
