It seems that there is yet another variation on the SESSION SETUP ANDX RESPONSE. Windows 95 and 98 systems, when acting as servers, do not return any data in the SMB_DATA block.

It's empty:

SMB (Server Message Block Protocol)
    SMB Header
    Session Setup AndX Response (0x73)
        Word Count (WCT): 3
        AndXCommand: Tree Connect AndX (0x75)
        Reserved: 00
        AndXOffset: 41
        Action: 0x0000
        Byte Count (BCC): 0
    Tree Connect AndX Response (0x75)
        Word Count (WCT): 2
        AndXCommand: No further commands (0xff)
        Reserved: 00
        AndXOffset: 174
        Byte Count (BCC): 4
        Service: IPC

At first I thought that this was due to the fact that the W9x boxes were configured to offer Share Level authentication. To test this I set up a W98 system as a member of an NT Domain (using a Windows NT4 PDC). The W98 system was then able to offer User Level Authentication via the pass-through authentication mechanism (which is as good as it gets for W9x).

The end result was that the SMB_DATA block was still empty.

So:

• If the server is a W95, W98, or (possibly) W/ME then the SMB_DATA block will be empty (ByteCount will be zero). This appears to be a quirk of that family of OSes.

• Other Windows systems running the "NT LM 0.12" dialect (eg. Windows NT, 2000, etc.) should return an SMB_DATA block in the following format:

      typedef struct
        {
        ushort ByteCount;
        struct
          {
          uchar NativeOS[];
          uchar NativeLanMan[];
          uchar PrimaryDomain[];
          } Bytes;
        } smb_SessSetupAndx_Resp_Data;

  Windows NT4 and Windows 2000 were tested. Samba also returns the above structure.

• If Extended Security has been negotiated, the SecurityBlob[] will also be included:

      typedef struct
        {
        ushort ByteCount;
        struct
          {
          uchar SecurityBlob[];
          uchar NativeOS[];
          uchar NativeLanMan[];
          uchar PrimaryDomain[];
          } Bytes;
        } smb_SessSetupAndx_Resp_Data;

Section 4.1.2 of the SNIA doc covers the SESSION SETUP ANDX exchange, but it doesn't mention this exception.

Also, the SNIA doc lists the NativeOS, NativeLanMan, and PrimaryDomain fields as being part of the response in dialects prior to NT LM 0.12. In a test against Windows for Workgroup 3.11, however, those fields were not present so WfWG 3.11 exhibits the same behavior as W9x.

Fun, eh?