Finding the right WIFI dongle (And patching its kernel driver and firmware)
This post is a follow-up on https://befinitiv.wordpress.com/2015/01/25/true-unidirectional-wifi-broadcasting-of-video-data-for-fpv/ . Here I describe my findings on several WIFI dongles that I have tested.
In the last post I presented my raw sender and raw receiver software. This post focuses on the right hardware to use with that software.
Therefore, I tested the following WIFI adapters:
My tests focused on tx power and injection rate. I also briefly looked into the receiver sensivity.
Looking into the TX power was an interesting journey. The first thing I did was to google how others change their TX power. I guess most of you know about the wardriving kids changing their regulatory domain to BO for being able to execute “iwconfig wlan0 txpower 30” to get 30dbm. I tried that same command for lowering my tx output power and noticed no difference at all when looking at the receive strength (RSSI) on a second card. That is quite weird. There should be a noticeable difference between 1dbm and 20dbm. I started looking into the device drivers and noticed that the iwconfig command never reaches the power set function of the cards (this was true for all of the tested cards). I haven’t traced down the position where the call gets lost but I was quite stunned. Should all the 1000 “change your regdomain” websites be wrong about this? As an additional check I hardcoded different tx power values in the drivers. This did change the RSSI! To be honest, I only tested the vanilla drivers. I didn’t check if Kali uses modified drivers. But I found no hints on this.
Let’s look in detail at the extraordinary claims of the ALFA cards (1W, 2W, …). For example the AWUS036NHR (sold as 2W) only contains a 1W amplifier. I increased the tx power in the kernel driver to 200mw and tested the card in a shielded cage (perfect use case for a micro-wave oven 🙂 ). I saw already lots of package drops. I suspect that the power distribution of the card is too bad to supply this amount of power. One indication is that the supply voltage of the tx amplifier dropped from 5V to 4V during the transmission of a packet. I wouldn’t be surprised if this caused the drops. Using a tx power of 1W nearly all packages got dropped. Just a few made in through the air. I noticed the same behaviour on the AWUS036H – although not as bad as on the NHR.
The TP-LINK TL-WN722N supports only 100mW output power on the paper. My tests showed that this claim is more or less true. The card shows reliable transmission at 100mW and the RSSI suggested that the output power is in that order of magnitude (compared to the AWUS cards RSSI). Nice!
I did not bother to hack the Dlink cards driver since this card does not have an external antenna connector.
I was surprised to see how the injection rates differ from card to card. I was thinking that the packets are injected at maximum rate (obeying free channel). But this is not at all the case. I did not trace the cause of low injection rates because I’m not motivated to optimize a driver stack in that respect. Following is a list of injection rates of the tested cards. I injected packets with 1024 bytes payload and measured the rate. On the left you see the air data rate, on the right you see the net data throughput. Net means 100% user data.
len: 1024 bytes REALTEK RTL8187 --------------- 54 mbit/s OFDM: 480p/s ~ 3.9mbit/s REALTEK RTL8192 --------------- 54 mbits/s OFDM: 80p/s ~ 0.6mbit/s RALINK RT2573 ------------- 54 mbit/s OFDM: 2500p/s ~ 20.5mbit/s ATHEROS AR9172 -------------- 11 mbit/s CCK: 830p/s ~ 6.8mbit/s 24 mbit/s OFDM: 1750p/s ~ 14.3mbit/s 54 mbit/s OFDM: 2700p/s ~ 22mbit/s 6.5 mbits/s MCS0: 630p/s ~ 5.1mbit/s 13 mbit/s MCS1: 1100p/s ~ 9mbit/s 26 mbit/s MCS3: 1800p/s ~ 14.7mbit/s 52 mbit/s MCS5: 2700p/s ~ 22.1mbit/s
Again, the ALFA cards are pretty much crap. Luckily, the TP-LINK card showed excellent results. Depending on your data rate and packet loss reliability requirements (the retransmission flag of the tx program) you can use these numbers to find the right modulation scheme. Assume you have a video stream with 6mbit/s (enough for h264 HD) you can fit that easily into the MCS3 modulation, even with one retransmission.
The RX sensitivity of the TP-LINK was the best of all the tested cards. I have no numbers available since all the other cards are already disqualified by their injection rate. I measured it by sending packets at a known rate and looked at the reception rate. Again, the ALFA cards were the worst. The public opinion on these cards is really the opposite of my findings… quite interesting.
The winner of my tests is very clear: TP-LINK TK-WN722N
It has excellent injection rates and also an acceptable tx power level. But it is not only good for transmission: It supports to deliver frames with wrong FCS to user space. These frames are for example the ones where only a single bit is flipped. Normal cards just drop these frames and there is no way to see them from user space. It is quite obvious that a few flipped bits have lesser effect on a video stream than the loss of a whole packet (8*1024 = 8192 bits). This is exactly what I described in the last post: That the link should behave as much as possible as an analogous link. The feature of this card can be enabled by this command:
sudo iw dev wlan1 set monitor fcsfail
Another advantage of this card is that its firmware is open: https://github.com/qca/open-ath9k-htc-firmware.git
Lastly, this card is really cheap: 10€. I’m quite happy that I’ve found it.
As said before, to change the tx power of the card a change of the driver is necessary. I patched the driver of the TL-WN722N in the raspberry kernel. This patch should set the power to a constant 20dbm (although I haven’t checked the unit of the tx-power value. This is still TODO). Use the following commands to apply it:
cd /tmp hg clone https://bitbucket.org/befi/wifibroadcast/ git clone https://github.com/raspberrypi/linux.git cd linux git checkout fe4a83540ec73dfc298f16f027277355470ea9a0 git branch wifi_txpower git checkout wifi_txpower git apply ../wifibroadcast/patches/AR9271/kernel/fixed_channel_power_of_ath9k_to_20dbm.patch
From here on you can just compile the necessary modules the usual way (Refer to http://www.raspberrypi.org/documentation/linux/kernel/building.md ). When the compilation is finished you need to copy the following modules to the corresponding folders under /lib/modules/`uname -r`/kernel on the raspi:
drivers/net/wireless/ath/ath9k/ath9k.ko drivers/net/wireless/ath/ath9k/ath9k_hw.ko drivers/net/wireless/ath/ath9k/ath9k_htc.ko drivers/net/wireless/ath/ath9k/ath9k_common.ko
Changing the tx rate was a bit more complicated. It seems as if the firmware of the card just takes rate suggestions from the kernel driver. But the actual rate is decided by the firmware. Therefore, I needed to patch that as well. You find a pre-compiled firmware that uses MCS3 (26mbit/s) as an injection rate under patches/AR9271/firmware/htc_9271.fw. Copy this file to /lib/firmware and re-insert the card to use the modified firmware. If you want to compile the firmware with a different injection rate you can take look at the patch that I supplied. The easiest way is to replace the first line in the list with a copy of the wanted injection rate. Instructions for compiling the firmware are given in the firmware repo: https://github.com/qca/open-ath9k-htc-firmware.git
The TL-WN722N is my choice for the receiving side. I’m still hesitating to buy a second one for the transmitter. Maybe I should give ALFA a second chance with the AWUS036NHA (https://wikidevi.com/wiki/ALFA_Network_AWUS036NHA ) which uses the same chip-set as the TP-Link. The advantage would be that it adds a 1W power amplifier to the output. However, if it is as bad as the other ALFA cards, I would have thrown away 25€… If you want me to test that card, feel free to donate 🙂