Examining Wifi Signal Quality

If one looks at the Wifi signal quality reported by a variety of Linux laptops one will see a range of different results even though the machines are the same distance from an access point.

So why is this? Well, some of it has to do with the physical hardware - antennae, diversity, and the wifi silicon too. The other factor to consider is the Wifi driver, which may or may not calculate the signal quality as one would expect.

Bill Moss has written an excellent article describing the method used to calculate the ipw2200 wireless signal quality. It's based on a least squares fit on four data points from calibrations on the Windows XP driver. His article compares the traditional linear model based on the raw hardware provided Received Signal Strength Indicator (RSSI) values to the quadratic model used by the ipw2200 driver. It's an interesting read.

The problem is that the RSSI scale is vendor specific and maximum values vary (e.g. Ciscso uses 101, Atheros 60). RSSI is not associated with any power scale such as mW - it is an arbitrary scale which the hardware provides to a device driver. One should not assume that the values are precise or even very accurate either. There is more detail about this in this posting by Afsaneh Sattari. Hopefully you see the problem.

Looking at drivers in more detail, one finds the calculation varies from driver to driver:

For example Ath9K, Ath5K, Hostap, iwmc3200, rtl8187 and wl12xx drivers (to name but a few) use a linear mapping from the RSSI to calculate the signal quality. iwlwifi uses a least squares fit, rt2x00 uses a scaled down RSSI with a larger mix of TX/RX success and failure weightings. And libertas uses RSSI with a mix of TX success and failure weightings.

So next time you compare your Wifi signal quality on your laptop with somebody else bear in mind there are many factors to make up this meaningless indicator of quality metric!

GCC inline assembler explained

There are times when the Linux Kernel uses inline assembler to either use specific instruction sequences for optimal code efficiency or to use processor features that are not accessible in C (e.g. memory barriers, I/O instructions, manipulating processor state, etc..).

GCC provides a mechanism to enable one to place inlined assembler into C source but to the beginner the syntax can be a little impenetrable. A useful little primer and guide to GCC inline assembler can be found at http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html

The primer is a little old, but nevertheless it is still valid and very useful.

Kernel Oops page fault error codes

The x86 Linux kernel Oops messages provide normally just enough information to help a kernel developer corner and fix critical bugs. The start of a typical Oops message may look like the following:

kernel BUG at kernel/signal.c:1599!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pc = 84427f6a
*pde = 00000000
Oops: 0001 [#1]

The 4 digit value after the "Oops:" message dumps out the page fault error code in hexadecimal which in turn can help one deduce what caused the oops. The page fault error code is encoded as follows:

bit 0 - 0 = no page found, 1 = protection fault
bit 1 - 0 = read access, 1 = write access
bit 2 - 0 = kernel-mode access, 1 = user mode access
bit 3 - 0 = n/a, 1 = use of reserved bit detected
bit 4 - 0 = n/a, 1 = fault was an instruction fetch

So, in the above example, the Oops error code was 0x0001 which means it was a page protection fault, read access in kernel mode.

A lot of Oops error codes are 0x0000, which means a page was not found by a read access in kernel mode.

For more information, consult arch/x86/mm/fault.c

200 Mbps Powerline Ethernet Plugs

This week I bought a pair of 200 Mbps powerline ethernet plugs from Faculty-X to add some extra home network connectivity. Up until now I've been happy with the speed of my 80211g Wifi network, but I really wanted to get a faster connection between two parts of my house and I didn't want to run any Ethernet cabling through my walls.

I purchased some budget powerline plugs which did state on the box they worked for Windows, Mac and Linux, but on receiving them found that one needed to run a Windows based configuration tool to configure a password protected private LAN connection between the two plugs. However, by default, one can just plug these devices into the electrical wall sockets and they work, but the network is public.

So I gritted my teeth and tried to run the configuration software from Wine, but I could not connect to the plugs. Then I tried from a virtual Windows Vista inside KVM and also failed to connect and configure the devices. Finally, I installed Vista on a sacrificial laptop, ran the configuration software and configured the two plugs to run as a private network. Amusingly I was able to scan and find some other powerline plugs with very week signals, so somebody else down my street is using similar kit.

The private network is protected using 128 bit AES encryption on the link, plus I only connect to machines using ssh, so hopefully it reduces the snooping risk.

My gripe is that a box should not be labelled "compatible with Windows, Mac and Linux" when in fact the configuration software in Windows based. This is totally misleading and disingenuous. To have to run a OS-centric app to get the full functionality of networking kit is very lame.

The pragmatic side of my personality chose to go the path of least resistance and configure the powerline plugs using Windows (with much gnashing of teeth). The hacker side of my personality wanted to capture the packet activity between the the configuration application and the powerline plug to help me write a open source configuration tool. When I get a spare 10 minutes I will write to the manufacturer and see if they will open up the configuration protocol...

As for speed - well, I'm fairly pleased. With the two devices plugged into a 4 way power socket I was able to get about 150Mbs+ and between two floors in my house across two ring mains (with fairly old wiring) I was able to get about 100Mbs which isn't bad considering all the noisy kit such as fridges that cause interference.

My upstairs network has been mainly wifi based - even my server runs off a Ralink wifi card. I mainly ssh into my server, so network performance has not really been an issue. However, as of this weekend, my server is now connected to the network via one of these powerline plugs I can now send a Wake-on-LAN (WoL) packet to the server to switch it on remotely. I just installed the wakeonlan package and then run the wakeonlan command specifying the MAC address of the server's Ethernet card - easy!

The next few months will see how reliable these devices are. The technical blurb with the plugs states that they only use 6W - when I get a spare half hour I will measure the power consumption of an idle and busy network to get an idea of the true yearly running cost.