Top 6 basic Network problems with troubleshooting steps

Network issues are already irritating and frustrating to handle, but they can spell out disaster when they happen on a business network. While your IT department should be able to fix most network issues, you can save a lot of time by handling the issues yourself. This article will guide you to fix the Top 6 basic Network problems with troubleshooting steps.

Problem 1: Connection closed by the remote host

A user has established a connection to a remote host, and the connection closes before the user logs out.

Cause:

This type of network problem usually occurs because the remote host performed a shutdown and severed the connection or the user process for the associated daemon was terminated.

Solution:

Use the ping command to determine whether the host is running. Determine whether the remote host is down by contacting the host network administrator. If the host is not down, use telnet to re-establish the connection.

Problem 2: Connection refused

Users cannot connect to a remote host. The remote host is up, and the interface is up, but a connection cannot be established. Several possible causes and solutions for the problem follow.

Possible Cause A:

The wrong port number for the program is listed in the /etc/services file on the local or the remote host.

Solution:

Check the protocol’s port number in the network services file (/etc/services) on the localhost. It must agree with the port number shown in the default network services file Network services, Internet-style # telnet   25/tcp The telnet daemon should have port number 23 instead of 25; therefore, the /etc/services file that is in error must be edited accordingly. The /etc/services data file should always keep the standard protocol port numbers. When the client program is started (that is, a user initiates a command), it opens /etc/services, obtains a port number, and looks for a daemon program that is listening on that remote host port.

Problem 3: Connection timed out

The local host is trying to connect to the remote host but is not making an active connection. The telnet program sent a packet to a specific address, but no hosts are responding. The telnet client program times out if a connection is not made within a certain time limit (usually between 30 and 75 seconds).

Example:

Assume that the user from the local TCP/IP host issued the following command:

Possible Cause A:

The remote host or network is down. Solution: If you suspect that the remote host or network is down, contact the network administrator for the host and request the host status.

Possible Cause B:

An incorrect Internet address is specified for the remote host. Solution: A conflict in the Internet address can arise from the following situations:

• A user entered an incorrect Internet address on the command line. The user should retry the command, using the official host name or alias (to avoid re-entering an incorrect Internet address).
• A network administrator changed the Internet address of the remote host without informing the other hosts on the network. The address associated with the host is different from that in the local /etc/hosts table. The network administrator for the host should verify that the address is correct.
• The local host table contains varying entries for the remote host. Only the first entry is used, regardless of which one is correct. Therefore, if multiple entries for a remote host appear in your /etc/hosts file, ensure that the first one is correct and delete the others.

Problem 4: Login incorrect

A user is attempting to issue the rlogin command and receives the error message Login incorrect.

Cause:

The error message is returned from the remote host because the user entered an invalid user name or password for the host. When an invalid user name is specified, or an autologin is impossible because /etc/hosts.equiv or $HOME/.rhosts is not set up to allow an autologin, the user receives a prompt for a login and password.

Solution:

• Set up the /etc/hosts.equiv or $HOME/.rhosts file correctly so that the user is not prompted for a password.
• Users must know their valid accounts and passwords on the remote hosts.

Problem 5: The. netrc file not correct mode

A user attempts to use ftp with autologin to a remote host. The user’s $HOME/.netrc file is set up properly with machine, username, and password entries, but the error message is returned, and ftp aborts.

Cause:

The file has read permissions set for someone other than the owner. Because of the sensitivity of information in $HOME/.netrc, the $HOME/.netrc file should be accessible only to the owner.

Example:

The following permissions are incorrect:

Solution: Change the access mode of the .netrc file to 600, as follows:

The following dialog verifies that the mode was changed:

Problem 6: Network is unreachable

The user attempts to connect to a host outside the local area network (LAN) and cannot establish the connection. Both hosts are known to be up.

Cause:

• The local network hardware interface is down. If the remote interface is down, the error message Connection refused is returned.
• The local network hardware interface is up, but the Internet address associated with it is incorrect. The interface is on a network that is different from the one for which it was intended.
• The route was deleted for the local interface.
• A route was not set up for the destination host.
• An incorrect route was set up for the destination host.

Solution:

1. If users cannot perform a telnet operation back to themselves (using the local host name rather than loopback), the problem is in the interface.

Example:

User peter on crayhost issues the following command:

Enter the netstat command with the -i option to determine whether the local interface board is up, as follows:

The asterisk following qfa0 indicates that the interface is down. Use the ifconfig command to initialize the interface, as follows:

The following output from netstat -i verifies that the interface is up: