Linux Network Troubleshooting

Linux network troubleshooting should be performed using recommendation for network troubleshooting listed in TCP/IP Network Troubleshooting and tools listed Network Troubleshooting Tools. Due to Byzantium nature of Linux network stack the first thing to do is to perform baseline comparison to see that the machine's baseline is different from the "known good" configuration. In Suse you use supportconfig or Siga for this purpose. In older vertions of RHEL  (4.5 to 5.0) you can use Sysreport. For later you can use Siga or one of the Perl Baseliners.

Here are some additional cases from  Les Bell and Associates Pty Ltd (Page last updated: 03/Jan/2005). Information is outdated as it related to 2.4 kernel and networking stack but some parts of its are still useful

 Networking Not Configured During Installation

This usually means that the installer program was not able to probe and identify your network card. Generally, this is because the network card is too old (many modern installers don't expect to see old-fashioned 10Base-2 coax network cards like the 3Com Etherlink II, for example) or is too new, so that there is no support for it in the kernel supplied as part of your distribution. It can also mean that the card needs to be manually configured - this often happens with ISA bus NE-2000 cards, EtherExpress Pro's and the like.

First - if you know the type of card, take a look at /lib/modules/kernelver/kernel/drivers/net and see if you can identify the required driver. The 3Com Etherlink II, for example, uses the 3c503.o module, so I can attempt to load it with the command

modprobe 3c503

As usual, no messages indicates success. If you see something like:

[root@sleipnir net]# modprobe 3c503
/lib/modules/2.4.20-31.9/kernel/drivers/net/3c503.o: init_module: No such device or address
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters.

then either it is the wrong driver module, or you need to pass some parameters for the driver. One of our machines here, for example, has an Intel EtherExpress Pro, and its driver module has to be loaded with the command line:

[root@baldur root]# modprobe eepro irq=5 io=0x300

This specifies the IRQ line and I/O port address the card is using.

If you're completely stuck and desparate, one trick that might help is to try to load all network card drivers in turn and see what sticks, with the command:

[root@baldur root]# modprobe -t net \*

Expect to see lots of error messages fly by as drivers load and fail to initialize the right hardware. However, after it has done, do an lsmod command, and see if any network card driver module has "stuck".

If your network card is new or otherwise not supported by the kernel, then you'll have to obtain a driver from the manufacturer's web site. I recently worked with some machines that used an on-board Intel EtherExpress Gigabit Ethernet chipset, for example. We had to use Red Hat 9 on the machines, but the Anaconda installer simply skipped network configuration as it didn't "recognise" the interface. Although RH 9 has an e1000.o module, it obviously wasn't the right one for this interface, so I had to visit the Intel web site and download the driver source code, compile it and install it manually. The good news is that Intel supports easy building of an RPM package, and once that has been done and copied to floppy, it's a snap to install on the other machines.

Once you've identified (and installed) the correct driver module, you can make it permanent by loading it from with /etc/modules.conf (2.4 kernels) or /etc/modprobe.conf (2.6 kernels). For example, the syntax to load the eepro.o module with the parameters above looks like this:

alias eth0 eepro
options eepro irq=5 io=0x300

You should now be able to set up an IP address on the interface as described in the following sections.

Incorrect Address, Broadcast Address, Subnet Mask

Problems with an interface showing the wrong IP address, broadcast address or subnet mask are usually down to an incorrect entry in the configuration files. You can fix the problem by reconfiguring an interface on the fly with the ifconfig command. For example, to set an interface to the address 192.168.0.1:

ifconfig eth0 192.168.0.1

will do the trick. This assumes that your network is Class-C sized (/24), which it probably is, and so it sets the subnet mask to 255.255.255.0, the network address to 192.168.0.0 and the broadcast address to 192.168.0.255. However, you can over-ride these settings; for example, I use four /24 subnets - in other words, a /22 - so I could configure the interface like this:

ifconfig eth0 192.168.0.1 netmask 255.255.252.0

However, this is only temporary - it will remain in effect until the machine is shut down or the interface is reconfigured. In order to configure the interface on power-up, the system runs startup scripts which will read the configuration from a file somewhere. On systems that use System V-style init scripts, this is often a file in /etc/sysconfig/network-scripts, e.g. /etc/sysconfig/network-scripts/ifcfg-eth0. Here's an example from one of my systems:

[root@sleipnir root]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.168.11
NETMASK=255.255.255.0
GATEWAY=192.168.168.252

You can see that this sets the IP address and subnet mask (the braodcast and network addresses are implicitly derived from these). It also sets the default route on this interface. If you are running Slackware, you will need to edit /etc/rc.d/rc.inet1 in order to set the interface parameters.

Configuration by DHCP

If your network interface is configured by a DHCP server, then the configuration script above will not specify the IP address, etc. instead, it will say something like this:

ONBOOT=yes
TYPE=Ethernet
DHCP_HOSTNAME=sleipnir.cullen.lesbell.com.au
DEVICE=eth0
HWADDR=00:0c:6e:0a:3d:26
BOOTPROTO=dhcp
USERCTL=no
PEERDNS=yes

With BOOTPROTO set to dhcp, the startup scripts will run a DHCP client program to retrieve the interface configuration from the DHCP server. There are several different DHCP clients that have been used over the years and by different distributions. If your interface has not come up correctly, you can attempt to obtain a DHCP lease with the following command:

[root@sleipnir root]# dhclient eth0
Internet Software Consortium DHCP Client V3.0pl1
Copyright 1995-2001 Internet Software Consortium.
All rights reserved.
For info, please visit http://www.isc.org/products/DHCP

Listening on LPF/eth0/00:0c:6e:0a:3d:26
Sending on   LPF/eth0/00:0c:6e:0a:3d:26
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.168.1
bound to 192.168.168.76 -- renewal in 4215 seconds.

If the dhclient command is not found, then you should try "pump -i eth0" and "dhcpcd eth0". If one of these commands work, and you get an IP address, then you should set about making the DHCP configuration permanent, using your distribution's configuration tools or by directly editing the network startup scripts.

Network Reachability (arp, ping)

Once you've got an IP address on an interface, the next step is to test whether you can reach remote systems. I always start by pinging the system's local interface, then the local router and then some distant systems. For example:

[root@sleipnir root]# ifconfig|grep inet
         inet addr:192.168.168.11  Bcast:192.168.168.255  Mask:255.255.255.0
         inet addr:127.0.0.1  Mask:255.0.0.0
[root@sleipnir root]# # Ping the local interface first
[root@sleipnir root]# ping -c 2 192.168.168.11
PING 192.168.168.11 (192.168.168.11) 56(84) bytes of data.
64 bytes from 192.168.168.11: icmp_seq=1 ttl=64 time=0.041 ms
64 bytes from 192.168.168.11: icmp_seq=2 ttl=64 time=0.042 ms

--- 192.168.168.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.041/0.041/0.042/0.006 ms
[root@sleipnir root]# # Now ping the upstream router
[root@sleipnir root]# ping -c 2 192.168.168.252
PING 192.168.168.252 (192.168.168.252) 56(84) bytes of data.
64 bytes from 192.168.168.252: icmp_seq=1 ttl=64 time=0.368 ms
64 bytes from 192.168.168.252: icmp_seq=2 ttl=64 time=0.282 ms

--- 192.168.168.252 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.282/0.325/0.368/0.043 ms
[root@sleipnir root]# # Finally, ping a remote host
[root@sleipnir root]# ping -c 2 203.35.202.153
PING 203.35.202.153 (203.35.202.153) 56(84) bytes of data.

--- 203.35.202.153 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

The ping command on UNIX systems defaults to sending a packet every second until you press Ctrl+C to interrupt it. Using the "-c 2" option makes it send two packets and then stop. In this example, you can see that the attempt to ping a remote system has failed, with 100% packet loss. What's going on here?

Don't assume too much from the ping command. It only indicates that a destination host is up and running, and that it is reachable. It's possible that the machine's OS might have crashed, but still be responding to interrupts, or that the particular daemon or network service that you want to use has crashed or is unable to respond. It might also happen that the wrong host replies - I've seen that happen when someone accidentally sets a machine to the wrong IP address. And of course, the lack of a reply doesn't necessarily indicate a problem, ether. In the example above, the destination machine has firewall rules and will not respond to ICMP echo requests (pings) for security reasons, even though it's up and running. Make sure that you try a few external hosts, ideally ones that you know will respond to ICMP echo requests.

If you do not get back a reply from the local interface, something is really very wrong - the steps listed above using the ifconfig command should have given you a working local interface and you should go back and double-check them.

If you do not get back a reply from the upstream router, try some other machines on the local network. If you still do not get a response, then use the arp command to see whether your machine was able to work out their Ethernet (MAC) addresses

Here's what happens when you've got a machine disconnected or down:

[root@sleipnir root]# ping baldur
PING baldur.cullen.lesbell.com.au (192.168.168.10) 56(84) bytes of data.

--- baldur.cullen.lesbell.com.au ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1012ms

[root@sleipnir root]# arp -a
baldur.cullen.lesbell.com.au (192.168.168.10) at <incomplete> on eth0
FREYA.cullen.lesbell.com.au (192.168.168.70) at 00:10:A4:82:99:C1 [ether] on eth0
dvalin.cullen.lesbell.com.au (192.168.168.252) at 00:10:B5:39:E4:18 [ether] on eth0
fulbert.cullen.lesbell.com.au (192.168.168.1) at 00:40:F4:3C:85:6A [ether] on eth0

When I gave the "ping baldur" command, my machine looked up baldur's IP address correctly (more on that shortly) and, since both machines are on the same network, it referred to its ARP cache to get the corresponding Ethernet address. It then sent out the ICMP echo request datagrams, but got no replies (in this case because the machine had been unplugged while we did some work on the nearby cabling). It also purged the Ethernet address out of its cache, as shown by the arp -a command.

If baldur's Ethernet address hadn't been in the ARP cache in the first place, we would have seen this:

[root@sleipnir root]# ping -c 2 baldur
PING baldur.cullen.lesbell.com.au (192.168.168.10) 56(84) bytes of data.
From sleipnir.cullen.lesbell.com.au (192.168.168.11) icmp_seq=1 Destination Host Unreachable
From sleipnir.cullen.lesbell.com.au (192.168.168.11) icmp_seq=2 Destination Host Unreachable

--- baldur.cullen.lesbell.com.au ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1013ms
, pipe 2
[root@sleipnir root]# arp -a
baldur.cullen.lesbell.com.au (192.168.168.10) at <incomplete> on eth0
FREYA.cullen.lesbell.com.au (192.168.168.70) at 00:10:A4:82:99:C1 [ether] on eth0
dvalin.cullen.lesbell.com.au (192.168.168.252) at 00:10:B5:39:E4:18 [ether] on eth0
fulbert.cullen.lesbell.com.au (192.168.168.1) at 00:40:F4:3C:85:6A [ether] on eth0

The "Destination Host Unreachable" messages are a clue that this machine could not even send the ICMP datagrams in the first place.

Routing (route add, route, netstat, traceroute)

If you can ping machines on the local network but cannot get to all or some destinations on remote networks, then the problem could be in the routing table of your machine or an upstream router. You can add and remove routes with the route add and route delete commands, and display them with route:

[root@dvalin root]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
artemis.rr.lesb *               255.255.255.255 UH    0      0        0 ppp0
203.97.202.152  *               255.255.255.248 U     0      0        0 eth1
192.168.170.0   *               255.255.255.0   U     0      0        0 wlan0
192.168.168.0   *               255.255.255.0   U     0      0        0 eth0
127.0.0.0       *               255.0.0.0       U     0      0        0 lo
default         midgard.lesbell 0.0.0.0         UG    0      0        0 eth1

This is a more complex routing table than the average - it's for a firewall machine that has two Ethernet interfaces (eth0 and eth1), Wi-Fi interface (wlan0) and a PPP connection to a dial-up host (ppp0). Here you can see the route to artemis (the dial-in host) has the H flag set, indicating this is a host route (i.e. a route to a single host rather than a network, as the netmask value of 255.255.255.255 confirms). There's an entry for the DMZ network on eth1 (that's 203.97.202.152/29), an entry for 192.168.170.0/24, which is the wireless network and one for 192.168.168.0, the private Ethernet LAN. You can also see the entry for the loopback interface, lo, and finally the default entry, which passes datagrams for all other destinations to the external router, midgard. This entry has the G flag turned on, indicating it routes via a gateway - naturally, since that's what midgard is.

You can diagnose routing problems by using the traceroute command. This will show the routers through which your datagrams will pass on the way to the destination. However, as for ping, don't assume too much - it's possible that routers along the path may be configured not to respond to traceroute. For example:

[root@sleipnir root]# traceroute www.pcuser.com.au
traceroute to www.pcuser.com.au (203.18.241.23), 30 hops max, 38 byte packets
1  dvalin (192.168.168.252)  0.705 ms  0.289 ms  0.391 ms
2  midgard.lesbell.com.au (203.97.202.158)  1.829 ms  1.553 ms  1.673 ms
3  Loopback1.ken10.Sydney.telstra.net (165.228.2.1)  18.125 ms  17.887 ms  19.615 ms
4  GigabitEthernet2-1.ken17.Sydney.telstra.net (203.50.20.27)  20.833 ms  20.587 ms  19.583 ms
5  austra426.lnk.telstra.net (139.130.238.198)  21.840 ms  21.336 ms  20.195 ms
6  * * *
7  * * *

[root@sleipnir root]#

Each line shows the next router along the path to the destination, along with the round-trip-times for three queries and responses. You can see the firewall and upstream router in my office, then a router at Telstra's Kent Street exchange, then the gigabit Ethernet backbone there, then a link to austra426 - and then everything goes quiet. The three asterisks indicate a timeout, and after a couple of these, I pressed Ctrl+C to stop traceroute. This doesn't mean that I can't get to the PC User website - just that a firewall along the way is not responding to the UDP datagrams sent by traceroute. In any case, I can see that the link from my office into Telstra's network is working OK.

When tracerouting to distant hosts, you can often see the round-trip-time jump as you cross the trans-Pacific link. For example:

[root@sleipnir root]# traceroute www.ibm.com
traceroute: Warning: www.ibm.com has multiple addresses; using 129.42.21.99
traceroute to www.ibm.com (129.42.21.99), 30 hops max, 38 byte packets
1  dvalin (192.168.168.252)  0.739 ms  0.364 ms  0.265 ms
2  midgard.lesbell.com.au (203.35.202.158)  1.890 ms  1.315 ms  1.292 ms
3  Loopback1.ken10.Sydney.telstra.net (165.228.2.1)  17.909 ms  19.071 ms  19.581 ms
4  10GigabitEthernet15-0.ken-core4.Sydney.telstra.net (203.50.20.1)  31.446 ms  208.883 ms  171.406 ms
5  10GigabitEthernet3-0.pad-core4.Sydney.telstra.net (203.50.6.86)  20.327 ms  20.912 ms  18.271 ms
6  GigabitEthernet2-2.syd-core01.Sydney.net.reach.com (203.50.13.38)  20.309 ms  20.360 ms  19.721 ms
7  i-12-2.wil-core01.net.reach.com (202.84.144.25)  169.611 ms  170.647 ms  168.839 ms
8  202.84.251.166 (202.84.251.166)  191.602 ms  188.565 ms  177.935 ms
9  so-1-0.core2.LosAngeles1.Level3.net (64.152.193.65)  201.521 ms  200.113 ms  202.050 ms
10  so-4-1-0.bbr2.LosAngeles1.Level3.net (4.68.113.173)  201.732 ms  201.403 ms  201.674 ms
11  so-3-0-0.mp1.Denver1.Level3.net (64.159.1.113)  228.770 ms  227.226 ms  229.076 ms
12  so-6-0.hsa1.Denver1.Level3.net (4.68.112.154)  228.021 ms  228.383 ms  237.262 ms
13  unknown.Level3.net (209.245.20.10)  226.879 ms  228.772 ms  230.193 ms

[root@sleipnir root]#

Notice how the RTT jumps from around 20 ms to 170 ms as it crosses the Pacific. By the way, there are fancy graphical traceroute programs - for example, xtraceroute - that draw a world map to show where your packets are going, but they're really not much help for troubleshooting.

DNS Configuration (host, dig)

A common problem that afflicts users on dial-up connections, and sometimes those with DHCP-allocated IP addresses on broadband, is an inability to resolve names into IP addresses. Symptoms include popup error messages from your browser, such as "hostname could not be found. Please check the name and try again" or command-line error messages like "Temporary failure in name resolution".

Your machine will turn names into IP addresses by asking a Domain Name Server, and the IP addresses of one or more DNS's will be set up in the file /etc/resolv.conf. It should look something like this:

search cullen.lesbell.com.au lesbell.com.au
nameserver 192.168.168.1
nameserver 192.168.168.252

In this example, there are two domain name servers listed, but you can have between one and three (by default) entries. If you are seeing errrors in resolving hostnames, first check that this file exists, and then try pinging the DNS's listed.

If the file does not exist, you can manually create it, using the IP addresses of your own DNS's or the DNS's provided by your ISP. However, if your system is configured by DHCP - e.g. you are using a consumer-grade ADSL or cable modem connection - or is configured by a dial-up PPP connection, then the file is normally created or overwritten when the connection is set up. If this is not happening, you will need to check the documentation for your DHCP client program or PPP configuration to try to determine what the problem is. In general, for DHCP you should check your ifcfg-eth0 file for the presence of a "PEERDNS=yes" statement, while for a PPP connection, check /etc/ppp/options for a "usepeerdns" statement.

You can check whether your system is able to connect to a DNS and resolve a hostname into an IP address with the host command:

[les@sleipnir les]$ host fulbert
fulbert.cullen.lesbell.com.au has address 192.168.168.1

If you need to get down to low-level debugging of DNS lookups, then you really should learn the nuances of the dig command. This will let you query any name server for all kinds of information the DNS service can provide:

[les@sleipnir les]$ dig www.pcuser.com.au @dvalin.lesbell.com.au

; <<>> DiG 9.2.1 <<>> www.pcuser.com.au @dvalin.lesbell.com.au
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17821
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; QUESTION SECTION:
;www.pcuser.com.au.             IN      A

;; ANSWER SECTION:
www.pcuser.com.au.      36417   IN      A       203.18.241.23

;; AUTHORITY SECTION:
pcuser.com.au.          36417   IN      NS      ns1.telstra.net.
pcuser.com.au.          36417   IN      NS      acphofdns01.acp.com.au.
pcuser.com.au.          36417   IN      NS      acphofdns02.acp.com.au.

;; ADDITIONAL SECTION:
ns1.telstra.net.        104627  IN      A       139.130.4.5

;; Query time: 3 msec
;; SERVER: 203.35.202.157#53(dvalin.lesbell.com.au)
;; WHEN: Wed Nov 10 14:17:27 2004
;; MSG SIZE  rcvd: 152

As you can see, dig will provide a lot of data, including details of the query it sent, the answer it received and how it got the information. Another common use of dig is for turning IP addresses into host names by doing a reverse lookup:

[les@sleipnir les]$ dig -x 203.18.241.23

; <<>> DiG 9.2.1 <<>> -x 203.18.241.23
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41638
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; QUESTION SECTION:
;23.241.18.203.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
23.241.18.203.in-addr.arpa. 86400 IN    PTR     techw02.acp.com.au.

;; AUTHORITY SECTION:
241.18.203.in-addr.arpa. 86400  IN      NS      ns1.telstra.net.
241.18.203.in-addr.arpa. 86400  IN      NS      acphofdns01.acp.com.au.
241.18.203.in-addr.arpa. 86400  IN      NS      acphofdns02.acp.com.au.

;; ADDITIONAL SECTION:
ns1.telstra.net.        104486  IN      A       139.130.4.5

;; Query time: 2087 msec
;; SERVER: 192.168.168.1#53(192.168.168.1)
;; WHEN: Wed Nov 10 14:19:48 2004
;; MSG SIZE  rcvd: 173

Common Errors

Firewall in the way

Quite often, everything is configured fine at your end, but between you and the system you are trying to connect to, there is a firewall. If it's not your firewall, there's not a lot you can do about that - although Linux boasts an interesting armoury of tools for getting past firewalls, their use is beyond the scope of this article. If you're trying to connect to your own server, check that you have added a firewall rule to allow access to the appropriate protocol and port number - you can use the iptables -L command to dump your firewall rules or edit your firewall configuration file.

Daemon not listening

If you can ping a machine, but canot connect to a specific service, and you've eliminated firewall rules as a problem, then check that the daemon you are trying to connect to is in fact running. Use the ps aux command to list running processes, and/or use the netstat -pat and netstat -pau commands to list processes that are listening on TCP and UDP sockets, respectively. If you don't see the daemon you need, then start it, with a command like service httpd start or apachectl start, depending on your Linux distribution.

Remember, packets have to flow both ways!

When setting up routing tables in more complex internetworks, a common failing is to think about how datagrams get routed away from where you are sitting - but don't forget that replies have to be routed back again! This may require your host or subnet to be added to the routing table of "upstream" routers and firewalls.

Conclusions

Linux network configuration offers lots of options, but most distributions provide grapical configuration tools to keep things relatively simple. When things don't work out, especially for more complex configurations like servers, routers and firewalls, there's a huge selection of diagnostic tools that you can use to sort the problem out.

Hint Sidebar

Most Linux network-related commands will try to display hostnames rather than IP addresses, and they do this by doing a reverse DNS lookup. However, if you're using these commands because you've got some network problem, there's a good chance that your DNS is unreachable, and this will make the commands run very slowly as they try to do the reverse lookups and time out. However, these commands mostly accept the -n (Numeric) option, which will display addresses and dispense with the reverse DNS lookup so that things run a lot faster. See the difference:

[root@sleipnir root]# ping -nc2 192.168.168.1
PING 192.168.168.1 (192.168.168.1) 56(84) bytes of data.
64 bytes from 192.168.168.1: icmp_seq=1 ttl=64 time=0.127 ms
64 bytes from 192.168.168.1: icmp_seq=2 ttl=64 time=0.285 ms

--- 192.168.168.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.127/0.206/0.285/0.079 ms

References and Further Reading

ARP Address Resolution Protocol - converts IP addresses into MAC addresses by broadcasting a request: "Who has 192.168.168.11?" and seeing who replies, then remembering their MAC addresses for future use.

ICMP The Internet Control Message Protocol. Routers and hosts generate messages in this protocol when they have problems. ICMP datagrams can indicate network congestion, destination unreachable for a variety of reasons, routing table errors and other problems. Perhaps the best known ICMP datagrams are the "echo request" and "echo reply" packets which are sent and received by the ping command.

IP Address A 32-bit address used by the Internet Protocol. This allows communication between networks, since the IP address can be broken down into a network part, subnetwork part and the final host address - in much the same way as a phone number (in the US at least) consists of an area code, and exchange within that area, and then the line that connects to the final phone.

MAC Address Also known as a hardware address or Ethernet address, is the 48-bit address used by Ethernet cards to talk directly over a local area network. Other LAN protocols such as Token Ring and 802.11 wireless LANs also use 48-bit addresses in the same way. You cannot communicate with a network card on a different network using this address, which is why IP addresses are required.

TCP Transmission Control Protocol - a connection-oriented protocol used by services that require reliable transfer ot variable length data, such as email, ftp and the web.

UDP User Datagram Protocol - a connectionless protocol used by some low-level system services like DNS, as well as multimedia applications like Real Audio

Page last updated: 03/Jan/2005 Back to Home Copyright © 1987-2007 Les Bell and Associates Pty Ltd. All rights reserved. [email protected]

NEWS CONTENTS

• 200209 : Troubleshooting Tips ( Troubleshooting Tips, )

Old News ;-)

Troubleshooting Tips

The purpose of this page is to give you some ideas to cope with a variety of problems that will occur when using Unix. To use Unix effectively, you need to not just know the syntax and features of the operating system, but you must develop an attitude of coping with problems and understanding a bit of the worldview that might help you use Unix better. Some of this advice may seem odd or humorous, but it all has the point of conveying some kinds of coping mechanisms that go beyond just knowing the syntax of the commands.

1. Remain calm.
   Panic will cloud your ability to think through the problem and to come up with solutions. Slow down and calm down. Many times I see that problems arise when students try to type too quickly. Become familiar with your keyboard and how it works; type slowly if you have to. Remember that in Unix, you must type things exactly.
2. Know when to quit.
   As you type a Unix command at the shell prompt, you will type the wrong symbol. You might try the backspace or delete keys. These may or may not work--the way the backspace and delete keys are mapped to their functions are not always done correctly. This is particularly true when using telnet. If you get some funny characters or strange characters, cancel the command line. Do this by holding down the control key (usually at the lower left-hand corner of a keyboard) and the C key at the same time. That cancels the command. If you don't do this, you may create some strange file or have some strange effect. (Strange characters = possible strange effects.) Be particularly vigilant when you are creating a file name.
3. Seek clarity.
   If your terminal acts "funny" or your vi editor session is "strange," try this:

   $ set term=vt100
   $ clear

   The first command tells your telnet client that it is an old standard type of terminal (vt100); this often clears up strange control characters or if the computer output is not scrolling up on the screen. Then used with the clear command, you get added refreshment--this clears the screen of previous commands and output. This can then help you focus on a new task or way of approaching a problem.

4. Don't flirt with deadlines.
   In the real world, real deadlines mean either money lost or money gained. In the real world, if you miss a deadline, you may lose your company money and lose your job. If you meet a deadline, you may help your company succeed. If you start your work close to the deadline, you may run into trouble that you might not be able to resolve in time.
   
5. Understand that Unix was written for humans and by humans and thus is a language, full of ambiguity, inconsistencies, history, and culture.
   Computers don't need an operating system--you do. Electronic computers just care about high and low voltages. Operating systems like Unix were written by humans for humans to make use of the resources of the computer. Humans are full of all kinds of interesting ideas and these are reflected in the Unix operating system and its flavors. Not all the sequences of commands and options are entirely consistent. There are inconsistencies in syntax from command to command. There are cultural artifacts throughout the operating system that came out of the "geek" culture that gave rise to it-- who else would come up with the "finger" command?
   
6. Understand that Unix and computers are a mystery to be lived, not a problem to be solved.
   There will be errors, mistakes, funny things happen. You could spend the rest of your life analyzing exactly what gave rise to a particular error--or you could:
   • Take a deep breath and try it again
   • Log off and log back in
   • Try a different computer
   • Get a night's sleep and try tomorrow (but not if your deadline is tonight)

   The combination of hardware, networks, operating systems, and software gives rise to a high level of complexity. When problems arise, I have found it is best to try some troubleshooting techniques, then try something else, rather than trying to figure out exactly what went wrong (however, I do read error messages and look for any clues on the screen). Due to the nature of Unix systems, by the time you have found out what went wrong, the system (its hardware or software) will have been changed or "upgraded" (introducing new problems). This is particularly true, I have found, in academic computing systems.
   

7. Speak in a soothing, kind voice to the computer.
   This is more for you than for the computer. If you get frustrated and type haphazardly at the keyboard, you are not going to get work done. If you don't read the screen and any error messages, you are going to keep repeating the same mistakes over and over. Thanking the computer for what it does helps you focus on the give-and-take interaction you have with the computer. The soothing voice calms you down also.
   
8. Realize that there are many paths to getting things done.
   There are usually many ways to accomplish a task. Don't get too dogmatic about finding the one and only one way to do it, nor get too over-involved in figuring out every way to do something. Most Unix users develop a particular set of habits for using the commands that match their way of thinking. Don't be too concerned if you see others use a different style of Unix interaction--however, you might learn some new things from them. Don't be too insistent on continually pointing out, "you could also do that by..." (particularly if you are standing over their shoulder). You could spend many weeks pointing out alternative ways to do a task. Find a way that works and matches your thinking and then get your work done.
   
9. Make use of your environment.
   Think like a castaway on a desert isle who has only what is at his or her disposal to survive. If you are on an Internet-connected computer, you have access to range of online help resources, some of which are available right from the command line (although don't think too hard about the "man" pages--I don't think there are many humans alive who understand these fully). If you are on a computer which has a window system (such as Microsoft Windows or X Window System), bring up several windows at the same time:
   • A window that shows a Unix command prompt where you can type in commands (this would be the telnet client; in an X Window System environment, it would be an xterm)
   • A Web browser showing task information about what you are supposed to (this would be the assignment description)
   • Another Web browser that shows reference information
   • Perhaps another Web browser that shows more or alternate reference information

   Keep all of these windows up while working until you get your task done. Don't be afraid to bring up another Web browser, and keep the Web browser showing task information or reference information up. I've seen many students go through the trouble of bringing up a Web browser, following links to the assignment description, looking up a requirement for the assignment, then closing that Web browser, only to have to repeat the entire process when they need to look at the assignment description or reference information again. Don't be afraid to have as many windows open at the same time showing different information to get your work done.
   

10. Unix gets work done.
    You may think that a command-line operating system like Unix is somehow outdated. After all, a telnet session opened to a Unix shell is pretty plain visually. Its gotta be outdated, right? I have found that this is not the case. When you need to accomplish a large amount of precise work, there is nothing like pipes, filters, shell programming, and computer programs, to accomplish tasks. These can be implemented very efficiently

Recommended Links

LPI exam 202 prep, Topic 214 Network troubleshooting

• TUTORIAL FOR LPI EXAM 202 part 7 -- Topic 214 Network Troubleshooting --

Simple_Network_Troubleshooting

Google books

• Linux Troubleshooting Bible - by Christopher Negus, Chris Negus, Thomas Weeks - 626 pages
• Network Troubleshooting Tools - by Joseph D Sloan - 366 pages
• Linux Troubleshooting for System ... - by James Kirkland, David Carmichael, ... - 601 pages

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019