full-featured WLAN USB adaptor-Collection of common programming errors

In the meantime, I bought and tested some devices. My choice was highly inspired by the list suggested by @Renat. Here, I compile my findings.

AVM Fritz

The small variant of the AVM Fritz Wlan Stick N supports only 2.4 GHz, while the large one has multiband support with 2.4 and 5 GHz. Both rely on the carl9170 driver module. Used as clients, they are both a catastrophe. They crash regularly. The kernel restarts them in less then a second, but a reconnect is necessary and time-consuming. Real-time connections are impossible, let alone things like SSH. Also, the problem seems to cumulate. The longer I used the sticks, the more frequent they did crash, resulting in a stick that worked some minutes at maximum. Tweaking the module parameters, nohwcrypt and noht to reduce load on the device hardware caused only temporary amendment.

Testing the multiband one in AP mode, however, it worked flawless. Video streaming and sftp file transfer worked with the full 300 MBit/s.

TP-Link

With TP-Link, I again had the choice between the TL-WDN3200 dual-band variant and the 2.4 GHz only TL-WN821N. The first needs an out-of-tree driver to be compiled, so I skipped to the single-band model immediately. The TL-WN821N uses the ath9k_htc module included in the linux kernel. even has a slightly higher transfer speed and connection quality than the Fritz models, tested across two floors and some walls. It also crashes much less than these, only a few times a day. But when it does, it compensates for its performance by freezing large parts of the networking subsystem. Every syscall that tries to access a network device (including the loopback, which many IPC-Solutions rely on) stalls and wont return until the device is unplugged or the kernel module is removed. I donated it to some windows user where it does its work as client ever since.

Buffalo

Lastly, I tried out the Buffalo WLI-UC-G300HP. Although it is labelled with 300 MBit/s, too, it performs a little slower than the aforementioned ones. The connection quality is still good throughout some walls and floors, especially when utilizing its little adjustable antenna, which can also be flapped away completely when space is tight. I am using it for some months now and am very satisfied.

Its only flaw is that no driver automatically feels responsible for this device. In fact, it can be used with the well-tested rt2800usb module. There are two possibilities to teach this to the kernel.

At Runtime

Issue as root

modprobe rt2800usb
echo 0411 01a8 > /sys/bus/usb/drivers/rt2800usb/new_id

The first line inserts the module. The second one tells the device and product id to the driver. These numbers can be found via lsusb, but should be the ones given for the WLI-UC-G300HP. Then, the driver takes command of the module. This could be made persistent with an udev rule. I, for my part, choose another method by

Compiling a Kernel

When you build your kernel yourself anyway, you can simply apply the following patch.

diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 098613e..2ded919 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -953,6 +953,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
        { USB_DEVICE(0x0411, 0x016f) },
        { USB_DEVICE(0x0411, 0x01a2) },
        { USB_DEVICE(0x0411, 0x01ee) },
+       { USB_DEVICE(0x0411, 0x01a8) },
        /* Corega */
        { USB_DEVICE(0x07aa, 0x002f) },
        { USB_DEVICE(0x07aa, 0x003c) },

It adds the ids to the internal database of the module so that it will be intrinsically motivated to manage the device.