LAN Manager vs. Windows 7

I recently spent some time trying to access disks shared by a Windows 7 machine from various versions of OS/2 (running in VMs, although that’s not really relevant). The OS/2 clients ranged from OS/2 1.3 with LAN Manager 2.1 (1991 vintage) to MCP2 (released in 2001/2002), in all cases configured to use only NetBIOS over TCP/IP transports.

This endeavor was far more difficult than it should have been. One part of the problem is that the default Windows 7 configuration is inimical to all older Microsoft/IBM network clients, including DOS, Windows 9x, and old versions of Windows NT. That is more or less obvious and relatively well documented.

With the necessary changes on the Windows 7 side in place, OS/2 clients can connect to Windows 7 shares and browse disks. However, attempts to access files more often than not result in SYS0240: The network connection is disconnected.

The behavior is quite confusing though. Some programs may be executed, text files can be displayed with the TYPE command, but a COPY to a local disk (i.e. from a disk shared by Windows 7 to a local disk on an OS/2 client) almost always fails with SYS0240. That is, all files but those smaller than about 4KB fail to copy.

That is certainly not the expected behavior. A packet trace revealed that access to a small file is handled as a single SMB request (albeit split into several TCP packets). For larger files, the first 4KB are read successfully, but then OS/2 issues a so-called multiplexed read (“Read MPX” in Wireshark). Rather than failing such request on the SMB level, Windows 7 resets the TCP connection. That is, unsurprisingly, translated into a SYS0240 error.

It is questionable whether this is a bug in Windows which aborts the TCP connection rather than returning a SMB error, or if OS/2 should not even attempt multiplexed reads. However, that is largely an academic question; the real question is whether anything can be done about it.

As it turns out, the answer is “yes”. The OS/2 Workstation (in LAN Manager terminology) or Requester (in IBM parlance) can be easily adjusted to avoid issuing multiplexed reads and write requests. The key is the wrkheuristics parameter in the [workstation] section of the appropriate .INI file. For Microsoft LAN Manager, that is \LANMAN\LANMAN.INI, for IBM LAN Requester it’s \IBMLAN\IBMLAN.INI, usually on the C: drive. The files have essentially identical format.

On newer versions of OS/2, the wrkheuristics parameter is already present and populated with the default values. On LAN Manager, it might not exist and must be created first. In any case, “bits” 14 and 15 must be changed from 0 and 1. That will disable the use of multiplexed reads and writes, respectively. This is documented at least as far back as the Microsoft LAN Manager Administrator’s Reference, Version 2.0 from 1990 (document number SY10468-0590).

The default setting of wrkheuristics looks as follows:

;                         1         2         3         4
;               01234567890123456789012345678901234567890
wrkheuristics = 11111111213111111110010111200112210000000

That must be changed to the following:

wrkheuristics = 11111111213111001110010111200112210000000

That is, the digits in position 14 and 15 must be changed to zero.

After changing the INI file, the workstation/requester must be restarted (rebooting OS/2 is not necessary). Once the change is active, OS/2 can read from and write to Windows 7 shares successfully. Whew!

Disabling multiplexed reads and writes has been previously documented as desirable when connecting to newer Samba servers. However, for accessing Samba shares, it is only a performance optimization. For accessing Windows 7 shares, it is absolutely essential.

It does not appear that disabling multiplexed reads/writes has any adverse effect when using NetBIOS over TCP/IP as multiplexing is actually not relevant for connection-oriented transports such as TCP.

For reference, the default administrator account on old LAN Manager setups is ADMIN/password. On IBM LAN Requester it is often USERID/password. Note that the user name is not case sensitive while the password is.

This entry was posted in Networking, OS/2, Windows. Bookmark the permalink.

7 Responses to LAN Manager vs. Windows 7

  1. Vasily Levchenko says:

    Interesting, that “Implementing CIFS” doesn’t describe multiplexing reads/writes, but “X/Open CAE Specification Protocols for X/Open PC Interworking: SMB, Version 2”, rather clearly describes this operations in 12.7/8. Wonder why Windows 7 declines these operations in such strange manner. Could it be an issue caused by NAT or you see the same behavior with bridged network attachment?

  2. michaln says:

    It’s not NAT; the same error occurs with bridged networking. With NAT it sometimes takes quite a while for the operation to time out and the guest report the error, but NAT just adds the delay rather than causing the issue.

    From what little I’ve seen, SMB multiplexing is clearly quite an old feature. It was apparently intended for environments such as multiple modem lines where a single request SMB could be split/parallelized on the lower transport layer. It can reportedly be used over IPX as well, but not over TCP/IP.

  3. wow id’ all just about given up on that endeavor, and I usually rely on an NT 4.0 machine with netbios, FPNW, and any other gateway stuff (I had the mac stuff somewhere…)

    There was some unnecessarily bad blood from MS going from OS/2 to NT, and they just basically pushed a lot of us in IT to push from OS/2 to NT 3.51, convert the HPFS disks, and up to NT 4.0 and beyond…

    but I guess that was it, networking with 95 & NT 4.0 was such a snap compared to trying to stagger stuff with OS/2, Netware & DOS… but it was a big deal to get something to talk to everything!

  4. michaln says:

    I did give up… but then got back to it. Setting up a SMB share on OS X was way, way easier than doing that on Windows 7 (sad, really). But OS/2 could talk to neither, and I happened to solve the incompatibility with Win7 first. It’s also fun that the same fix applies to Microsoft’s own LAN Manager from the pre-NT days.

    Microsoft was in an interesting situation WRT networking and OS/2 in the mid-1990s. It was of course in their best interest to make it as incompatible as they could, but tricky because the code which IBM was using all came from Microsoft and the core was the same as in Microsoft’s own networking products 🙂

  5. Renee F. Senger says:

    As additional information, Windows 7 (and all other versions of Windows based in Windows NT lanman code), by default, do not permit OS/2 clients to browse available resources on Microsoft Networks due to a LAN Manager parameter called lmannounce. This parameter defines the response to LAN Manager 2.x browser broadcasts. The solution is manually modify the Lmannounce entry in the winndows registry. The \HKEY_LOCAL_MACHINES\System\CurrentControlSet\Services\LanmanServer\Parameters have to be changed from the default of 0 to 1.

    RF Senger

  6. Michal Necasek says:

    I’m fairly sure there is some policy setting that controls this and it’s not actually needed to manually edit the registry… but yeah, the default Windows 7 networking settings suck.

    That’s why I switched to a Linux-based NAS for my home networking needs. Far less hassle when using SMB than when using Windows… kind of sad really.

  7. Yuhong Bao says:

    One reason they set the default settings the way they did in newer versions of Windows is because of security. For example, NTLMv1 (and MS-CHAPv2) encrypt the password hash with 56-bit DES, which has been considered insecure for years and now can attack it.

Leave a Reply

Your email address will not be published. Required fields are marked *