Network Troubleshooting

Occasionally, you find yourself without a working network. This article is designed to guide you through the basic steps to work out what is wrong. Hopefully, from there you will be able to find out how to resolve your problem.

Note

This guide was written based on an Ubuntu setup, using commands that are installed by default. It should apply to any system that has iproute and mtr installed. The article also assumes you are only dealing with a wired connection. It will mostly apply to a wireless network, but there may be additional steps you need to investigate.

Hardware

The first thing to do is check that your network card has been detected.

Run “ip link”

mojo-jojo david% ip link
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:a0:c9:92:9c:c0 brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop 
    link/sit 0.0.0.0 brd 0.0.0.0

You should see eth0. If this is the case, then your network card was detected correctly.

Lets make sure we have a cable plugged in correctly by checking the link status using mii-tool.

mojo-jojo david% sudo mii-tool 
eth0: negotiated 100baseTx-FD flow-control, link ok

If you see “link ok” then you have a working ethernet connection. If you don’t you should check your network cable is plugged in securely and that it is wired correctly and your switch is working correctly.

IP networking

The next thing to do is to check that you have got an IP address for that network device. You can do that by running “ip addr show dev eth0”

2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:a0:c9:92:9c:c0 brd ff:ff:ff:ff:ff:ff
    inet 10.187.182.233/27 brd 10.187.182.255 scope global eth0
    inet6 2002:8b0:ed:2:2a0:c9ff:fe92:9cc0/64 scope global dynamic 
       valid_lft 2591991sec preferred_lft 604791sec
    inet6 fe80::2a0:c9ff:fe92:9cc0/64 scope link 
       valid_lft forever preferred_lft forever

The line you’re interested in here is the line that starts inet. If you don’t or it starts 169.254 then you don’t have an ip address assigned.

You can either get this dynamically via something called DHCP, or you can configure it statically. We’ll try dhcp first by running “sudo dhclient eth0”

mojo-jojo david% sudo dhclient eth0
Password:
Internet Systems Consortium DHCP Client V3.0.4
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:a0:c9:92:9c:c0
Sending on   LPF/eth0/00:a0:c9:92:9c:c0
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 10.187.182.226
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 10.187.182.226
bound to 10.187.182.233 -- renewal in 38436 seconds.

If you keep seeing DHCPDISCOVER lines over and over, then it means your router is not providing addresses via DHCP, although I find this quite unlikely.

If you repeat the “ip addr show eth0” line again you should see that you now have a new “inet” line.

Lets see if our networking is working. Let’s ping the machine that gave us an IP address. If you take the IP address from the DHCPOFFER line and try to ping it using “ping <ipaddress>”. Press Ctrl-C to stop it.

mojo-jojo david% ping 10.187.182.226
PING 10.187.182.226 (10.187.182.226) 56(84) bytes of data.
64 bytes from 10.187.182.226: icmp_seq=1 ttl=64 time=0.364 ms
64 bytes from 10.187.182.226: icmp_seq=2 ttl=64 time=0.274 ms
64 bytes from 10.187.182.226: icmp_seq=3 ttl=64 time=0.286 ms

--- 10.187.182.226 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 0.274/0.308/0.364/0.039 ms

If you get lines like this, then you have working IP networking.

So we’ve been given an IP address from somewhere. Let’s see if they have given us a default route. We can do this by running “ip route”

mojo-jojo david% ip route
10.187.182.224/27 dev eth0  proto kernel  scope link  src 10.187.182.233 
default via 10.187.182.225 dev eth0

From this we can see that our default route is to 10.187.182.225 using eth0 network device. Lets try pinging that:

mojo-jojo david% ping 10.187.182.225
PING 10.187.182.225 (10.187.182.225) 56(84) bytes of data.
64 bytes from 10.187.182.225: icmp_seq=1 ttl=64 time=0.317 ms
64 bytes from 10.187.182.225: icmp_seq=2 ttl=64 time=0.291 ms
64 bytes from 10.187.182.225: icmp_seq=3 ttl=64 time=0.224 ms

--- 81.187.182.226 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.224/0.277/0.317/0.041 ms

So we know we can at least reach the router.

Routing

Now, lets see if we can get any further than this. Lets try pinging Ubuntu’s webserver.

mojo-jojo david% ping 82.211.81.166
PING 82.211.81.166 (82.211.81.166) 56(84) bytes of data.
64 bytes from 82.211.81.166: icmp_seq=1 ttl=52 time=30.5 ms
64 bytes from 82.211.81.166: icmp_seq=2 ttl=52 time=30.8 ms
64 bytes from 82.211.81.166: icmp_seq=3 ttl=52 time=30.2 ms

--- 82.211.81.166 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 30.232/30.532/30.836/0.318 ms

If this works, then we have working networking and can move on to checking DNS.

If this doesn’t work, we need to find out where the problem lies using mtr (I’d normally suggest traceroute here, but it doesn’t look like it’s a part of the standard Ubuntu install). We will trace the route to ubuntu’s webserver again.

mojo-jojo david% mtr -r -c 1  82.211.81.166
HOST: mojo-jojo                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. brian.catnip.org.uk           0.0%     1    0.4   0.4   0.4   0.4   0.0
  2. 10.187.182.201                0.0%     1    1.1   1.1   1.1   1.1   0.0
  3. careless.aaisp.net.uk         0.0%     1   30.2  30.2  30.2  30.2   0.0
  4. needless.aaisp.net.uk         0.0%     1   28.7  28.7  28.7  28.7   0.0
  5. ge-2-0-216.ipcolo2.London1.L  0.0%     1   30.2  30.2  30.2  30.2   0.0
  6. ae-0-55.bbr1.London1.Level3.  0.0%     1   30.2  30.2  30.2  30.2   0.0
  7. as-0-0.bbr2.London2.Level3.n  0.0%     1   30.3  30.3  30.3  30.3   0.0
  8. ge-3-0-0-55.gar1.London2.Lev  0.0%     1   30.2  30.2  30.2  30.2   0.0
  9. 195.50.91.146                 0.0%     1   30.4  30.4  30.4  30.4   0.0
 10. vlan102.core-l-1.lon2.mnet.n  0.0%     1   29.6  29.6  29.6  29.6   0.0
 11. 85.133.32.130                 0.0%     1   31.7  31.7  31.7  31.7   0.0
 12. 82.211.81.76                  0.0%     1   30.0  30.0  30.0  30.0   0.0
 13. signey.ubuntu.com             0.0%     1   29.9  29.9  29.9  29.9   0.0

This shows us every router between us and the remote machine. The first line will show your ADSL router. The line after that will be the remote end of your ADSL line. If your adsl is not connected you won’t be able to reach the second hop. Anything beyond this is nothing you can control, but considering it works in Windows it’s unlikely that this is the case.

There is another possibility why you can’t reach the second hop and that is that the default route isn’t correct, but this address should have been given to you via DHCP like your IP address.

If this is all working, we can check DNS.

DNS

Try looking up a host by name using the host command:

mojo-jojo david% host www.ubuntu.com
www.ubuntu.com has address 82.211.81.166

If this works, then your networking should be working fine. If not, then we need to check /etc/resolv.conf. It should look something like:

mojo-jojo david% cat /etc/resolv.conf 
nameserver 10.187.182.226
nameserver 10.187.182.229

Here we list DNS name servers. You should edit this file to use the name servers that you were given by your ISP.