Troubleshooting Network Adapters and Protocols

This section contains information about troubleshooting problems related to network protocols. For general information about troubleshooting the network installation, including how to use net diag, see Chapter 14, "Introduction to Networking Configuration." For information about troubleshooting procedures and tools provided with Windows 98, see Chapter 27, "General Troubleshooting."

Correcting Problems with Network Adapters

This section describes specific problems you might encounter using network adapters with Windows 98.

For information about specific network adapters, see the Windows 98 Adapter Card Configuration Help File on the Windows 98 Resource Kit compact disc.

For general troubleshooting steps, see the "Troubleshooting Basic Networking Configuration" section in Chapter 14, "Introduction to Networking Configuration."

Plug and Play card does not function with 16-bit network drivers.

If you are running Plug and Play with a 16-bit, real-mode driver, your Plug and Play network adapter might not function properly. If this happens, disable Plug and Play support for that network adapter.

To disable Plug and Play support for a network adapter

1. Run the software setup utility that comes with your Plug and Play card.
2. Set the card to non-Plug and Play Mode.
3. In Control Panel, double-click System, and then click the Device Manager tab.
4. Expand the Network adapters tree, and then select your network card.
5. Click Remove.
6. In Control Panel, double-click Add New Hardware.
7. Manually reinstall the network adapter.

   Note

   For some network adapters, you will also need to install a non-Plug and Play driver.

If you later need to re-enable Plug and Play support, follow these steps:

To re-enable Plug and Play support for a network adapter

1. In Control Panel, double-click System, and then click the Device Manager tab.
2. Remove the network adapter.
3. Run the software setup utility that comes with your Plug and Play card.
4. Set the card to Plug and Play Mode.
5. Reboot the computer. Windows 98 automatically detects the network adapter.

Correcting Problems with TCP/IP

This section describes TCP/IP utilities that you can use to diagnose TCP/IP connectivity problems. Next, it discusses general troubleshooting methods to solve TCP/IP connectivity problems. Finally, it lists common problems you might experience.

Using Diagnostic Utilities to Troubleshoot

Use the TCP/IP diagnostic utilities included with Microsoft TCP/IP to diagnose connectivity problems. The following list describes which MS-DOS utility helps to identify various problems. For a more detailed description of these utilities, see "TCP/IP Utilities" earlier in this chapter.

Table 15.23 Using TCP/IP diagnostic utilities

For more information about these utilities, see "TCP/IP Utilities" earlier in this chapter.

You can also use the graphical IP Configuration utility winipcfg to display, update, or release TCP/IP configuration values, including DHCP values.

Winipcfg can also show you whether or not your computer is using automatic private IP addressing for its IP address. For more information about automatic private IP addressing, see "Configuring IP Addresses Using Automatic Private IP Addressing" earlier in this chapter.

To use winipcfg

1. Click Start, click Run, and then type:

   winipcfg

2. The resulting screen identifies your IP address and the IP address of your default gateway.
3. Click More info.
4. The resulting screen tells you your IP address, subnet mask, and default gateway for each of your network interfaces. It also shows your DNS and WINS settings.

To test TCP/IP using ping

• Check the loopback address by typing ping 127.0.0.1 and pressing ENTER at the command prompt. The computer should respond immediately. To determine whether you configured IP properly, use ping with the IP address of your computer, your default gateway, and a remote host. (If you are using DHCP, use winipcfg to find the IP address.)

If you cannot use ping successfully at any point, verify the following:

• The computer was restarted after TCP/IP was installed and configured.
• The local computer’s IP address is valid and appears correctly in the TCP/IP Properties dialog box.
• The IP address of the default gateway and remote host are correct.
• IP routing is enabled on the router, and the link between routers is operational.
• The local computer’s registry includes an entry for lmhosts=c:\directory that correctly indicates the location of LMHosts.

If you can ping other computers running Windows 98 on a different subnetwork but cannot connect using Windows Explorer, net use \\server\share, or net view \\server\share, verify the following:

• The host is functioning.
• The correct host computer name was used.
• Using tracert, make sure that a router path exists between your computer and the target computer.
• LMHosts contains correct entries, so the computer name can be resolved.
• The computer is configured to use WINS, the WINS server addresses are correct, and WINS servers are functioning.

You can use winipcfg to verify your TCP/IP configuration settings. For information about using winipcfg, see "Using Diagnostic Utilities to Troubleshoot," earlier in this chapter.

Troubleshooting TCP/IP Gateway Problems

If a host computer on one subnet has problems communicating to computers on another subnet when using TCP/IP, the following information can help you determine whether the problem is with the gateway. For these troubleshooting steps, it does not matter whether the gateway that provides routing capabilities is a hardware router or a Windows NT or UNIX server configured to act as a router.

First, to troubleshoot gateway problems, you need a network map, plus the IP addresses and subnet masks for the host computer with problems, the near side of the hardware or software router that acts as the gateway, the remote side of the gateway, and the destination computer (node). For example, Figure 15.6 shows two subnets connected by a router.

Figure 15.6 Two subnets connected by a router

The following example of troubleshooting steps uses the IP addresses from this illustration.

To troubleshoot possible gateway (router) problems

1. Use ping to access the host computer that is having problems communicating outside the subnet. For example:

   ping 172.22.4.66
   

   If this works, this host is probably healthy at the IP level.

   If this does not work, use the usual methods to check the IP configuration and network connections on this host.

2. If the problem is not solved, use ping to access the near side of the router (that is, the default gateway). For example:

   ping 172.22.3.1
   

   If this works, this side of the router is healthy.

   If this does not work, use the usual methods to check the actual IP configuration and network connection for the near side of the router. Adjust the gateway settings on the problem host computer, if required.

   Notice, however, that if you can use ping to get a response from this address, it does not necessarily mean that this is actually a router.

3. If the problem is not solved, use ping to access the far side of the router. For example:

   ping 172.22.4.25
   

   If this works, the router is working.

   If this does not work, have another user use the same ping command from the destination node (172.22.4.66 in the example).

   If this works, the router is not working correctly.

4. If the problem is not solved, use ping to access the remote host. For example:

   ping 172.22.4.66
   

   If this works and all problems in the previous steps have been resolved, TCP/IP should be working fine.

   If this does not work, check the IP configuration and network connections on the destination computer. Typically, at this point the problem is that the remote computer has not route configured back to the original host computer. That is, the remote computer’s routers or routing table does not contain the information necessary to send packets back to the original host computer.

When troubleshooting router connections, note the following:

• Do not use the host name when you are testing the router; instead, use the IP address. This will avoid any problems related to the Hosts or LMHosts files, DNS server, WINS server, or any other methods of name resolution.
• In most cases, the subnet mask should be the same for all hosts on the same side of the router.
• There could be two routers at separate sites performing the same job as described above; if this is the case, treat this situation the same as above, keeping in mind that each router could have a near and far side, depending on the configuration.
• If multiple routers exist between the source and destination, use tracert to see an ordered list of routers used. Tracert can also help you determine how many hops there are between the source and destination, and how much time it takes a packet to travel from the source to the destination.

Tip for using SNMP for routing

The TCP/IP utilities use the public interface provided by inetmib1.dll in both Windows NT and Windows 98. This API can be used with Simple Network Management Protocol (SNMP) for actions such as setting and getting routing information programmatically on Windows 98 computers. For information about the management information base (MIB) object types provided for Microsoft networking, see the Microsoft Windows NT Server Resource Kit (for Microsoft Windows NT Server version 4.0).

Notice, however, that you cannot use a Windows 98 computer to run the SNMPUTIL tool provided with the Windows NT Resource Kit utilities.

Troubleshooting Other TCP/IP Problems

This section describes how to troubleshoot other problems with TCP/IP.

Windows 98 does not retain primary WINS server IP address.

If the setting for your primary WINS server IP address is not retained when you reboot, check that a secondary WINS server IP address is also configured. If not, add a secondary WINS server IP address.

Windows 98 does not send DHCP request packet.

If the DHCP key in the registry contains eight MAC address entries, Windows 98 cannot create a new entry for the current session and will not send a DHCP request packet. If this happens, use the Registry Editor to remove all keys except for the Dhcpinfo00 key from the following registry entry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP

Then restart the computer.

Windows 98 detects an IP address conflict.

If your Windows 98 computer uses static IP addressing (described in the section "Manually Configuring IP Addresses" earlier in this chapter) and you receive a message that Windows 98 has detected an IP address conflict, another computer on the network is using the same IP address and you must change the IP address.

To change your IP address

1. In Control Panel, double-click Network.
2. Click your TCP/IP protocol.
3. Click the Properties button.
4. Click the IP Address tab.
5. Configure the protocol to use a different IP address that is not already in use on the network.

Cannot log on to Windows NT domain.

If you cannot log on to a Windows NT domain, check that your computer uses NetBIOS name services. Windows 98 needs NetBIOS name services to log on to a Windows NT domain.

IP address connects but host names do not.

Verify that the Hosts file and DNS settings have been configured for the computer by checking settings on the DNS Configuration tab.

• If you are using a Hosts file, verify that the DNS host name of the remote computer is identical—especially in terms of spelling and capitalization—to the name in the file and the application using it.
• If you are using DNS, verify that the IP addresses of the DNS servers are correct and in proper order. Use ping with the remote computer, and type both the host name and IP address to determine if the host name is resolved properly.

Use the netstat -a command to show the status of all activity on TCP and UDP ports on the local computer. A good TCP connection is usually established with 0 bytes in the send and receive queues. If data is blocked in either queue or if the state is irregular, there might be a problem with the connection. If not, you are probably experiencing network or application delays.

Connect times are long after adding to LMHosts.

You might experience long connect times with a large LMHosts file if there is an entry at the end of the file. If so, mark the entry in LMHosts as a preloaded entry by following the mapping with the #PRE tag, or place the mapping higher in the LMHosts file. Then use the nbtstat -R command to update the local name cache immediately. The LMHosts file is parsed sequentially to locate entries without the #PRE keyword. You should place frequently used entries near the top of the file, and place the #PRE entries near the bottom.

You see a message stating computer is unable to connect to a server.

This message appears if name resolution fails for a particular computer name. If the computer is on the local subnetwork, confirm that the target server name is spelled correctly and that the target server is running TCP/IP. If the computer is not on the local subnetwork, be sure that its name and IP address mapping are available in the LMHosts file or the WINS database. If all TCP/IP elements appear to be installed properly, use ping with the remote computer to be sure that its TCP/IP software is working.

Use the nbtstat -n command to determine what name (or names) the server registered on the network. The nbtstat command can also display the cached entries for remote computers from either #PRE entries in LMHosts or recently resolved names. If the remote computers are using the same name for the server, and the other computers are on a remote subnetwork, be sure that they have the computer’s mapping in their LMHosts files.

Correcting Problems with NetBEUI and IPX/SPX

This section describes problems that might occur with the NetBEUI and IPX protocols.

You cannot connect using NetBEUI

• Use net diag to test for NetBIOS connectivity over the LANA that NetBEUI is using. If it fails, check the transceiver type, cabling, and adapter.
• Check the NetBEUI protocol bindings.
• Verify that routing is not involved.

A NetBIOS application fails to start

This might be because the application is hard-coded to use the protocol on LANA 0 (such as Lotus Notes). You can force a particular protocol to always occupy LANA 0 by selecting it as the default protocol, as described in "Setting LAN Adapter Numbers" earlier in this chapter.

You cannot connect using the IPX/SPX-compatible protocol

Verify that both computers trying to connect are using the same frame type and that other settings are correct for this protocol.

• Verify the following in the Advanced tab of the IPX/SPX-compatible Protocol Properties dialog box, as described in "Configuring the IPX/SPX-compatible Protocol" earlier in this chapter:
  • The correct frame type is set. The recommended setting is Auto, but this frame type only checks SAP broadcast traffic on the network and might be selecting an incorrect frame type in a mixed frame-type environment.
  • Source Routing is enabled and a cache size is set if needed.
  • The option named Force Even Length Packets is set properly. NetWare servers with older NetWare Ethernet drivers or older IPX routers may require even-sized packets. If required, change this setting to make sure the computer transmits only even-length IPX frames.
• On the IPX routers, check the setting for Type 20 Packets (NetBIOS packets). When using NetBIOS over IPX, the IPX packet type is set to 14h (decimal 20). Manufacturers of routers might consider all NetBIOS traffic as being nonroutable LAN traffic even when carried over the routable IPX protocol, and so, by default, will not pass Type 20 NetBIOS IPX packets. To use NetBIOS over IPX connectivity, Type 20 packet passing must be enabled on the router.
• Use net diag to test for IPX connectivity over the related LANA number used by NetBIOS over IPX.
• Use System Monitor to view statistics for the IPX/SPX-compatible protocol. Then retry network operation and check the activity. If there is none, remove and reinstall the protocol, and then retry and retest the operation.

Correcting Connection Problems with Microsoft 32-bit DLC

This section describes common problems you might encounter while using the 32-bit DLC protocol.

Windows 98 reports a Dlchlp error message.

This error message appears if you have removed or renamed your Autoexec.bat file, or removed the reference to Dlchlp.exe from your Autoexec.bat file. To correct this error, add the Dlchlp.exe entry to your Autoexec.bat file.

Setting 32-bit DLC as the default protocol does not change the LANA number for NetBIOS protocols.

The 32-bit DLC protocol does not use a LANA number, so there is no reason to set DLC as the default protocol.

The 32-bit DLC protocol does not bind to the Dial-Up adapter.

Currently, the Microsoft 32-bit DLC protocol cannot bind to the Dial-Up adapter. When the Dial-Up adapter is installed and you then install the 32-bit DLC protocol, the 32-bit DLC protocol appears to be bound to the Dial-Up adapter. However, after you restart your computer, Windows 98 removes the binding. This is by design.

You cannot use Extra SAPs and Extra Stations settings.

Manual configuration of Extra SAPs and Extra Stations is no longer necessary with the Microsoft 32-bit DLC protocol.

After removing an adapter driver, programs cannot connect to the host.

When your computer is configured with multiple network adapters, removing an adapter driver may prevent the DLC program from connecting properly to the host. The connection fails when the removed network adapter driver is the adapter for which the DLC program is configured. To prevent this problem, if the DLC program is configured for the primary adapter, make sure the CCB Adapter Num is set to 0. If the DLC program is configured for the alternate (or secondary) adapter, make sure the CCB Adapter Num is set to 1. The 32-bit DLC protocol allows CCB2 adapter numbers 0 through F.

You cannot connect to the host over Ethernet after adding the 32-bit DLC protocol.

The most common issues you will face when using the DLC protocol on Ethernet are problems with bit swapping and Ethernet DIX. Check to see whether the host uses frame type 802.3 or Ethernet DIX 2.0, and whether address swapping is required on your network. For more information about configuring the 32-bit DLC protocol, see "Configuring the 32-bit DLC Protocol" earlier in this chapter.

After you have installed the 32-bit DLC protocol on a token-ring network adapter, Windows 98 stops responding.

Sometimes a token-ring network adapter has an RcvBufsize setting that is too small for the size of the frame being sent across the wire. If this happens, restart Windows 98 in Safe Mode, and increase the RcvBufSize setting for the network adapter driver. For more information about the appropriate settings for your network adapter, see the documentation for your network adapter. For information on getting to Safe Mode, see Chapter 27, "General Troubleshooting."

Correcting Connection Problems with Microsoft 16-bit DLC

If you encounter problems using the real-mode Microsoft DLC protocol, check the following items:

• When adding the Microsoft DLC protocol, make sure that there is only one net start entry in Autoexec.bat. Setup adds an entry for Microsoft DLC, even if an entry already exists. Also, make sure that Autoexec.bat is configured properly, as described in "Installing and Configuring Real-Mode Microsoft DLC" earlier in this chapter.
• Do not make direct entries or changes in Protocol.ini for Microsoft DLC. Instead, make all changes in the Advanced properties for Microsoft DLC by using the Network option in Control Panel. If you make changes directly in Protocol.ini, the next time you change any values by using the Network option in Control Panel, all settings in Protocol.ini for Microsoft DLC will be overwritten.
• Some terminal emulation applications use TSRs to communicate with the Microsoft DLC protocol. If your emulation application uses a TSR that runs from Autoexec.bat, make sure that the entry for the TSR still exists (usually, the TSR entry occurs after the msdlc and net start lines). Windows 98 Setup removes or comments out many TSRs.
• The option named Set This Protocol To Be The Default Protocol in the Advanced properties for Microsoft DLC does not provide any functionality. This option should not be checked, because Microsoft DLC does not use LANA settings.
• Real-mode Microsoft DLC is an NDIS 2 protocol, so the network adapter must have an NDIS 2-compatible network adapter driver for use with Windows 98. Windows 98 includes many compatible drivers, but some Windows 98 drivers for certain PCI and PC Cards do not have a corresponding NDIS 2 driver to allow loading real-mode Microsoft DLC.

Additional Resources