IPX Subnet Clients Unable to Connect to Windows NT

• Microsoft Windows NT Workstation version 3.5
• Microsoft Windows NT Server version 3.5
• Microsoft Windows for Workgroups version 3.11

SYMPTOMS

When IPX clients from a subnet attempt to connect to a server, the following error message appears:

   DOS error 53 - name not found

CAUSE

This problem occurs if the connection request originates from a client whose IPX four byte network number contains 06 in the second byte. The server responds with a name recognized to a FindName Query from any other network excluding the range mentioned above.

When the NBIPX portion of the code receives the frame, it checks certain frame properties. If the second byte in the NBIPX header is 06, it assumes it is a session data frame. As a result, NameRecognize is not processed.

The following is a sample FindName frame that does not get a response:

NOTE: TransmissionControl is set to 1 (indicating 1 hop). Second byte in the NBIPX header contains 00 06. The network number in the IPX header (x6112) is not the same in the NBIPX portion. This is a modified FindName frame that was transmitted on the wire using Network Monitor.

USER1STA *BROADCAST NBIPX Find Name USER101        <00>

    IPX: Checksum = 65535 (0xFFFF)
    IPX: IDP Length = 80 (0x50)
    IPX: Transport control = 1 (0x1)
    IPX: Packet type = WAN Broadcast
    IPX: Destination Address Summary 0.FFFFFFFFFFFF.455
        IPX: IPX Address = 00000000.FFFFFFFFFFFF
        IPX: Destination Net Number = 0 (0x0)
        IPX: Destination Socket Number = NetBIOS
    IPX: Source Address Summary 6112.08002B314A12.455
        IPX: IPX Address = 00006112.08002B314A12
        IPX: Source Net Number = 24850 (0x6112)
        IPX: Source Socket Number = NetBIOS
    IPX: Data: Number of data bytes remaining = 50 (0x0032)
NBIPX: Find Name USER101        <00>
    NBIPX: Routing Info
        NBIPX: Routing information = 393216 (0x60000)
        NBIPX: Routing information = 0 (0x0)
        NBIPX: Routing information = 0 (0x0)
        NBIPX: Routing information = 0 (0x0)
        NBIPX: Routing information = 0 (0x0)
        NBIPX: Routing information = 0 (0x0)
        NBIPX: Routing information = 0 (0x0)
        NBIPX: Routing information = 0 (0x0)
    NBIPX: Name type flag
        NBIPX: 0....... = Unique Name
        NBIPX: .0...... = Name not used
        NBIPX: .....0.. = Name not Registered
        NBIPX: ......0. = Name not Duplicated
        NBIPX: .......0 = Name not Deregistered
    NBIPX: Data stream type 2 = Find Name
    NBIPX: Name = USER101        <00>
    NBIPX: Data: Number of data bytes remaining = 1 (0x0001)
00000:  FF FF FF FF FF FF 08 00 2B 31 4A 12 00 54 E0 E0   ........+1J..T..
00010:  03 FF FF 00 50 01 14 00 00 00 00 FF FF FF FF FF   ....P...........
00020:  FF 04 55 00 00 61 12 08 00 2B 31 4A 12 04 55 00   ..U..a...+1J..U.
00030:  06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00040:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00050:  01 4D 4F 48 41 4B 30 31 20 20 20 20 20 20 20 20   .USER101
00060:  00 00                                             ..

WORKAROUND

To work around this problem, use an IPX network number that does not have 06 as the second byte in the network number.

STATUS

Microsoft has confirmed this to be a problem in Windows NT version 3.5. This problem has been corrected in the latest U.S. Service Pack for Windows NT version 3.5. For information on obtaining the Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces):

   S E R V P A C K