Troubleshooting Client Connectivity Errors

• Given a network troubleshooting scenario involving a client connectivity problem (e.g. incorrect protocol/client, software/authentication configuration, or insufficient rights/permissions), identify the cause of the problem.

Any network administrator is likely to tell you that client connectivity errors are one of the most common sources of network-related problems. Client connectivity errors range from plain old user error to more complex protocol and cabling issues as well as administrative mistakes. With so many possibilities, it is no wonder that client connectivity persists as one of the biggest network troubleshooting hotspots. The following sections explore the common sources of client connectivity problems and provide scenarios that network administrators might encounter.

Protocol Errors

The client system has to have a protocol assigned or bound to its NIC in order to access resources. You can use specialized tools to verify that a protocol is being used by the system; for example, on Windows NT/2000/XP systems you use the ipconfig command, on older Windows client systems you use the winipcfg command, and on Linux systems you use the ifconfig command.

Protocol-Specific Issues

You need to consider a number of factors related to network protocols when you troubleshoot a network. The following list describes some of the protocol-specific issues you should be aware of when dealing with client protocol configurations:

• Transmission Control Protocol/Internet Protocol (TCP/IP)— For a system to operate on a TCP/IP-based network, it must have at the very least a unique IP address, the correct subnet mask for the network to which it is connected, and (for cross-network connectivity) a default gateway entry. In addition, Domain Name Service (DNS) server addresses may be required.

• Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX)— Each system on an IPX/SPX network must have a unique address, although the addresses are generated and assigned automatically. Care must be taken to ensure that the correct frame type is being used, although systems are usually able to autodetect the frame type that is in use.

• Network BIOS Extended User Interface (NetBEUI)— Each system on a network that uses NetBEUI must have a unique name to identify the computer on the network. For name resolution between network segments, a network needs either a Windows Internet Naming System (WINS) server or manual name resolution through an LMHOSTS file.

• AppleTalk— Each system on an AppleTalk network must have a unique address.

On networks that use TCP/IP, DHCP is often used to automatically assign protocol information to clients. When DHCP is not used, protocol information has to be entered manually, and many errors can arise—most commonly duplicate IP addresses.

When protocol settings are correctly configured, protocol problems are infrequent. Unless settings are manually changed, very little can go wrong.

Authentication

Before users can log on to the system, their identities must be verified. By far the most common type of authentication used is the standard username and password combination. When a user account is created, it is good practice for the administrator to set a password. The user should change that password immediately so that the administrator no longer knows it.

Users should be forced to change their logon passwords periodically, although that often creates the problem of users forgetting their passwords. Mechanisms should therefore be in place that allow users to get new passwords quickly.

Most user password problems can be traced to users entering an incorrect password or entering the correct password incorrectly. All common operating systems offer the capability for the administrator to change a user's password, but none offer the capability to determine the user's existing password. Therefore, if a user does forget his or her password, a new one has to be created and issued.

Little can be done about users incorrectly typing passwords, except that you can encourage users to be careful. Note that Linux and Windows NT/2000 and some NetWare platforms used case-sensitive passwords. Therefore, if a user is having trouble logging on, he or she should ensure that the Caps Lock key is on or off as appropriate.

Permissions Errors

Access to programs and data across the network is controlled by permissions. Permissions are responsible for protecting the data on the network and ensuring that only those who should have access to it do.

The first rule of permissions troubleshooting is to remember that permissions do not change themselves. If a user cannot access a file, the first question to the user should always be, “Could you ever access the file?” If the user says “Yes, but now I can't access the file,” you should check server change logs or documentation to see if any changes have been made in the permissions structure.

If no changes have been made, you should verify that the user is in fact allowed access to that file or directory. In large environments, trying to keep track of who should have access to what can be a tricky business—one that is best left to defined policies and documentation.

The following are some other items you should consider when troubleshooting permissions problems:

• On some operating systems, rights and permissions can be inherited from parent directories or other directories that are higher in the directory structure. A change in the permissions assignments at one level may have an effect on a lower level in the directory tree.

• File permissions can be gained from objects other than the user's account. Depending on the operating system being used, rights can also be gained from group membership, other network objects, or security equivalence. When you are troubleshooting a permissions problem, be sure that you understand where rights are supposed to originate.

• File attributes can override file permissions, and they can prevent actions from being performed on certain files. To the uninitiated, this might seem like a file permissions problem, but in fact it is correct operation. For example, on a NetWare file system, the Rename Inhibit permission prevents changes to the name of a file, even if the user has the Supervisory File System permission.

• You need to determine that there is actually a problem. Users sometimes decide to clean up by deleting files they think are no longer used. Permissions may have been set that prevent users from doing this, and rightly so, but the user might identify this as a permissions problem and report it as such. To a lesser extent, the same situation can occur if a user tries to manipulate a file while it is in use by another application or user.

IN THE FIELD APPLICATION PROBLEMS AND FILE PERMISSIONS A malfunctioning application can sometimes be traced back to a file permissions problem. Many types of applications write temporary files, which they then need to delete when a certain operation is completed or the application is closed. File permissions and attributes can prevent this process, and in some cases, the result is that the application misbehaves or stops working completely. If you have an application problem you can't nail down, make sure that it is not related to file permissions or attribute problems.

Troubleshooting permissions problems can be both challenging and enjoyable. As with many other IT troubleshooting scenarios, you can solve most permissions problems effectively if you fully understand what you are troubleshooting and the factors that affect the situation.

Physical Connectivity Errors

Although many of the problems associated with client connectivity can be traced to software-based problems such as configuration, authentication, and permissions issues, physical connectivity is often the root of the problem.

When you are troubleshooting physical connectivity errors, the first place to look is at the network cables. Although it is rare, cables can become loose or disconnected from NICs or from the ports on a hub or switch. Oftentimes, this is the result of other cables being plugged in or unplugged, or of activity on the connections around the one that is having the problem. Other cable considerations include exceeded maximum lengths, cable breaks, and improperly terminated or made cables, although these are only a consideration in exceptional cases.

Physical connectivity errors also involve the devices used to establish the physical client/server connectivity. This can include hubs, switches, MSAUs, NICs, routers, and connectivity hardware. As discussed earlier in this chapter, these devices normally have LEDs that indicate the state of the network and the respective links with devices. Although it is possible to have a problem with a single port on one of the aforementioned devices, it is more likely that the entire unit will malfunction. Thankfully, networking devices are very resilient devices that normally provide many years of reliable service, with few or no problems.

Troubleshooting physical connectivity errors often requires some trial and error. For example, you might switch a cable to a different port in a hub to test whether the port is at fault or replace a cable or NIC with one that is known to be working to see if it fixes the problem. If you are fortunate enough to have them, you can use instruments and devices that are aimed at reducing the hit-or-miss approach to the troubleshooting process, but they are costly devices and they actually often come a distant second to the trial-and-error method.