10

Let's say I have a problem with my wireless connection. What commands should I run to share their output with a tech-savvy friend or an online support community?

For example:

  • How can I tell if my wireless card is recognised?
  • How can I get information on which wireless networks are within range?
  • How can I tell if I am connected to a wireless, but not the Internet?

I'm asking this question because I'm seeing many questions about problems with wireless connections, without many details, like this one. It would be useful if I could point to this question so that the asker can improve their question with more information. I'm hoping for a comprehensive answer with all the details, or with links to other generic questions for brevity.

2
  • 2
    Great question! We are seeing a lot of "my wifi does not work" type questions. Consolidating the fundamentals in one question will be great. Thanks.
    – user68186
    Jan 4, 2013 at 14:54
  • 2
    I think I have done some work on this in My WiFi adapter is not working at all. Where to start troubleshooting? very recently. It only covers your first and imo most important example sub-question. See the Identifying the exact hardware part in particular. See also chat discussion starting here.
    – gertvdijk
    Jan 4, 2013 at 17:11

2 Answers 2

5

To check if the card is recognized, run:

sudo lshw -C network

or

lspci -nnk | grep -iA2 net

The second command is useful, as it shows the vendor and product IDs [8086:4222]:

~$ lspci -nnk | grep -iA2 net
06:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4222] (rev 02)
    Subsystem: Hewlett-Packard Company PRO/Wireless 3945ABG [Golan] Network Connection [103c:135c]
    Kernel driver in use: iwl3945
    Kernel modules: iwl3945

Example - card recognized, brand and model are correctly identified, correct driver is in use (driver=iwl3945), and wireless connection is established (ip=192.168.2.81):

sudo lshw -C network
[sudo] password for hp: 
  *-network               
       description: Wireless interface
       product: PRO/Wireless 3945ABG [Golan] Network Connection
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:06:00.0
       logical name: wlan0
       version: 02
       serial: 00:13:02:c8:d2:75
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwl3945 driverversion=3.2.0-35-generic firmware=15.32.2.9 ip=192.168.2.81 latency=0 link=yes multicast=yes wireless=IEEE 802.11abg
       resources: irq:45 memory:80000000-80000fff

To make sure you are connected to a wireless, but not an ethernet network, first identify the wireless interface (usually wlan0, eth1 or eth2) by looking at the output of sudo lshw -C network. Then, look for an IP address to tell which interface is connected.

1
3

The ability to experiment rapidly is the best approach for a quick diagnosis.

Two diagnostic tools I find invaluable to pinpoint the root cause in cases where the WiFi works, but is unreliable, e.g. intermittently losing the connection, sessions hanging, web-pages freezing are iwlist and mtr.

Here's how to use iwlist and mtr effectively:

1) Is the low-level wireless reception/transmission healthy?

watch sudo iwlist wlan0 scan

This gives a treasure trove of information about the strongest wireless signals detected by your card. I find the Channel, Frequency, ESSID, Quality, and Signal level, the most useful.

If you have no signal, or your ESSID isn't recognized, you need to focus on the low-level (hardware/drivers): Is the router on? Are antennas oriented optimally? Is device too far away from the router? Do you have the right driver for your wifi card? (for that you may want to check the system logs)

Assuming the ESSID is known and the quality is good (say about 30%-100% of the maximum) you may move to the second, higher level, stage:

2) Once a WiFi connection is established, is the connection stable?

Since TCP/IP supports error-detection with retransmits, and congestion control, WiFi disconnects/reconnects are usually a result of a large number of errors to the point where TCP gives-up. Rather than waiting for a full disconnect, which may happen only once in several minutes, I run mtr in a separate window and continuously watch the Loss% (packet percent loss) and Avg (average round-trip time in milliseconds) columns:

mtr <hostname>

While looking at this screen, I can immediately see not just whether there's some ongoing transmission/reception problem, but also which link along the way is the most problematic/slow one, in case there's more than one hop between me and the target <hostname>.

(If you don't have mtr installed, you may install it using: sudo apt-get install mtr)

I find these two tools particularly valuable because they provide a continuous state of the WiFi connection. I can quickly change configuration and immediately see the effect of my change on the network. Some examples of experiments you may do while looking at the above described screens are:

  • Edit /etc/network/interfaces and then ifdown wlan0 && ifup wlan0
  • Reload drivers: modprobe <name_of_device_driver>...
  • Restart the network: service networking restart
  • Reorient the WiFi card antenna
  • Change the wireless iterface MTU: e.g. ifconfig wlan0 mtu 1472
  • Disable the card power-saving ability
  • Adjust your access point transmission power, preferred channel number, bandwidth, ... in the router UI.
  • If you use a repeater (aka range-extender), turn it off, wait, turn it on again

As there are so many knobs you can turn and experiment with, the most critical thing, is to be able to see the immediate effect of any change on the continuously updating screens. If it makes no difference (most cases, in my experience), just note it down, and revert to the previous state. But if you suddenly see the Loss% rates jump up in mtr, or the signal strength sharply drop (or conversely, jump way up) in iwlist, you know you've found a smoking gun (or the fix).

Again, the #1 take-away from all of this is: Rapid experimentation is the key to be able to quickly diagnose WiFi issues

0

Not the answer you're looking for? Browse other questions tagged .