NDCTL.EXE must be started from STARTUP.CMD (or later) with Samba plugin 3.x

[Lewis Rosenthal]

This is either a bug to be addressed or a proposed change to the installer (and at least a readme item).

Loading NDCTL.EXE detached from CONFIG.SYS will fail with Samba plugin 3.x. This may be due to memory constraints. Moving NDCTL.EXE to STARTUP.CMD works around the issue and allows the control program to load normally, including all configured plugins.

Option 1 is to figure out a way to correct this to allow the control program to start from CONFIG.SYS.

Option 2 is to change the installer to move the command to STARTUP.CMD (or the Startup folder) when the new plugin is installed.

[Silvan Scherrer]

this can't be a general problem, as I have NDCTL always started from config.sys. And all my shares are attached.

[Lewis Rosenthal]

With builds since late May, attempting to load NDCTL.EXE from the RUN= line in CONFIG.SYS yield either a failure of the Samba plugin to load or failure of the desktop to init. Current testing is with:

7-04-15 17:23 5,512,638 124 ndpsmb.dll

This one blocks the WPS from starting (blinking black cursor), though the log indicates that the plugin is loaded:

[   local] internal plugin has been initialized.
[  ndpftp] (level 2) plugin has been loaded.
[  ndpsmb] (level 2) plugin has been loaded.
[ ndpntfs] (level 2) plugin has been loaded.
[  ndpdav] (level 2) plugin has been loaded.
[  ndpfat] (level 2) plugin has been loaded.
[  ndpiso] (level 2) plugin has been loaded.
Initialization completed. The control program is running.

Note that I have confirmed this with all plugins disabled except for ndpsmb. I believe that Paul has also had to make the the same change to the load order to boot normally.

I see this on bare metal and in a VM, each with a different mix of apps loading. In both cases, moving NDCTL.EXE to STARTUP.CMD has addressed the issue.

[Silvan Scherrer]

ah with client 3.x. I'm out of this, as I'm not supporting it. I thought you refer to 2.3.

[Paul Smedley]

I would prefer option 1 - but not sure why there is an issue :/ I wonder if Vitali would have any thoughts?

[Lewis Rosenthal]

debug log when loading NDCTL.EXE from CONFIG.SYS

[Lewis Rosenthal]

POPUPLOG.OS2 abstract showing crash in SDDGRADD.DLL when loading NDCTL.EXE from CONFIG.SYS

[Lewis Rosenthal]

I have to test this on the VM and another system. The attached snippet from POPUPLOG.OS2 is from my T43 running SNAP. As I see this on other systems without SNAP, I can't believe that this is a SNAP incompatibility (alone).

[Lewis Rosenthal]

ndpsmb-samba_4.2.3-heimdal-20150716b.zip was not lxlite'd. Even with NDCTL.EXE loaing from STARTUP.CMD, I get a stall with a partial desktop, and the following in POPUPLOG.OS2:

07-16-2015  07:18:04  SYS3171  PID 0025  TID 0001  Slot 004b
C:\OS2\PMSHELL.EXE
c0000005
1fcd709a
P1=00000002  P2=0003ffbc  P3=XXXXXXXX  P4=XXXXXXXX
EAX=00000001  EBX=800000c6  ECX=0000000c  EDX=00000000
ESI=800000c6  EDI=020e02bd
DS=0053  DSACC=f0f3  DSLIM=ffffffff
ES=0053  ESACC=f0f3  ESLIM=ffffffff
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1fcd709a  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0003ffc0  SSACC=f0f3  SSLIM=ffffffff
EBP=00040058  FLG=00010246

PMMERGE.DLL 0004:0010709a

After lxlite, the desktop loads successfully. The debug log snippet says:

Samba client 3.0.x build beta-date based on 4.2.3
This build is maintained by netlabs
2015/07/16 07:17:52.1: 9 1: Working with 64 bit fileio NDFS
2015/07/16 07:17:53.39: 9 1: NdpIOCTL init thread
2015/07/16 07:17:53.39: 9 1: NdpMountResource in
2015/07/16 07:17:54.13: 0 1: The initial smb.conf is missing, defaults are used!
2015/07/16 07:17:54.23: 9 1: dircache_create: 10 seconds, 32 entries
2015/07/16 07:17:54.23: 9 1: dircache_create: 0x606da0, rc = 0
2015/07/16 07:17:54.24: 9 1: NdpMountResource rc=0
2015/07/16 07:17:56.60: 9 1: NdpMountResource in
2015/07/16 07:17:56.60: 9 1: dircache_create: 10 seconds, 32 entries
2015/07/16 07:17:56.60: 9 1: dircache_create: 0x61fee0, rc = 0
2015/07/16 07:17:56.60: 9 1: NdpMountResource rc=0
2015/07/16 07:18:02.50: 9 2: NdpIOCTL init thread
2015/07/16 07:18:02.50: 9 2: NdpRsrcQueryFSAllocate 0285fdd0
2015/07/16 07:18:02.50: 9 2: checkMountResource in tid#2
2015/07/16 07:18:02.50: 1 2: Connecting to \\Lewis:*********@workgroup:galileo\d
ata. Master WORKGROUP:1
2015/07/16 07:18:02.50: 1 2: NTLMv1 Support enabled
2015/07/16 07:18:02.74: 4 2: Connection to galileo failed (Error NT_STATUS_HOST_
UNREACHABLE)
2015/07/16 07:18:02.74: 9 2: NdpCreateConnection failed rc=3
2015/07/16 07:18:02.74: 9 2: NdpRsrcQueryInfo in
2015/07/16 07:18:02.74: 9 2: NdpRsrcQueryInfo 0
2015/07/16 07:18:02.74: 9 2: NdpRsrcQueryFSAllocate 0285fdd0
2015/07/16 07:18:02.74: 9 2: checkMountResource in tid#2
2015/07/16 07:18:02.74: 1 2: Connecting to \\lewis:*********@workgroup:dp45sg\Te
st. Master WORKGROUP:1
2015/07/16 07:18:02.75: 4 2: Connection to dp45sg failed (Error NT_STATUS_HOST_U
NREACHABLE)
2015/07/16 07:18:02.75: 9 2: NdpCreateConnection failed rc=3
2015/07/16 07:18:02.75: 9 2: NdpRsrcQueryInfo in
2015/07/16 07:18:02.75: 9 2: NdpRsrcQueryInfo 0

(References to samba shares which are not present are correct; system was booted off the LAN, and Wi-Fi had not yet been started.)

[abwillis]

I am not experiencing any issues with having ndctl.exe launch from config.sys here.

[Lewis Rosenthal]

Andy, what video driver are you using? I'm away for a few days, so my testing in the VM or on another box will have to wait.

[Lewis Rosenthal]

We have traced this to some extent. It appears to be dependent upon a number of factors impacting available network connectivity. Thus, some LAN/NIC/protocol/startup combinations may init the network faster or more slowly than others. If the TCP connection is not fully up and available, the plugin will fail to load. As expected, many factors are involved in this timing.

The approach we are taking with one Arca Noae client is to start NDCTL.EXE from TCPEXIT.CMD, because even STARTUP.CMD appears to be too soon (Warp 4 FP15).

The current NetDrive installer will respect the presence of NDCTL.EXE in STARTUP.CMD and not blindly add it to CONFIG.SYS. Further logic would be required to know when it should be added to STARTUP.CMD or TCPEXIT.CMD. (Ultimately, some kind of "wait until" retry logic could be explored, where we attempt loading in CONFIG.SYS and then retry every X seconds until we are finally successful. This would resolve the issue for all mixes of plugins.)

Meanwhile, resolving this here as not fixable, accepting that this may not be something which can be directly addressed in the plugin code.