I have a project about building public hotspots using Raspberry Pi and wanted to share my experience with you.
The problem I am facing now is the low number of stations that can connect to the wireless network. Unfortunately, this limitation is not documented anywhere and as I wasn't aware of it, I assumed if AP mode works for an adapter it should support at least 40-50 clients. Well, I was wrong...
I've tried 3 different types of USB wifi sticks so far but unfortunately, none of them proved to be suitable for my use-case. Here is my experience with each, hopefully it will be useful to some of you:
- TP-LINK TL-WN722N: provides a stable, strong signal and good coverage but the htc_9271 firmware it uses does not allow more than 7 stations to associate. Raising this limit within the driver code does not work as the firmware still prevents the 8th station to associate. Counting this limitation out, this adapter is probably the best choice for building an access point. It comes with a detachable 4 dBi antenna included which makes the coverage pretty nice, I could connect to the network with my smartphone from about 40 meters in a rather overloaded environment (downtown), with multiple walls between the devices. This adapter comes with an AR9271 SoC and therefore can be used with the ath9k_htc driver (included by default in recent kernel images). At last, but not at least, it is pretty cheap for its good quality and the long (3 years) warranty term the manufacturer provides.
- TP-LINK TL-WN8200ND: this one has 2 detachable antennas, supports MIMO with 300 Mbps max. throughput and high-power operation. Its features would make it a very good choice to use as an AP but this adapter seems to be totally unusable currently. It comes with a Realtek 8192CU chipset which can be used with two drivers: "rtl8192cu" which is a pretty problematic, rather unstable driver compared to the vendor-provided "8192cu" driver, therefore recent kernel builds include the latter one by default. Unfortunately, none of these drivers are capable of handling master mode properly on Linux. Using rtl8192cu, no beacons are sent in master mode which makes it impossible to use this device as an AP. As far as I know, the reason is that the required driver functions are simply not implemented in the driver code currently. As of now, AP mode works only with a custom version of hostapd published by Realtek and the corresponding 8192cu driver but there are some issues with TX power/rate controlling and/or antenna handling and therefore clients can connect from ridiculously low distances only (about 5-6 cm) which makes this adapter totally useless to serve as an AP on Linux. The max. number of clients should be 32 according to the driver sources, although I'm unable to make any tests to confirm this.
- Noname Realtek RTL8188CUS: a small, nano-sized USB adapter with an RTL8188CUS chipset. It's cheap, comes with a 3 dBi external antenna and works fine as an AP using the driver and hostapd provided by Realtek. According to a test I made, it can easily handle 12 simultaneous clients (might support more but I couldn't find more wifi devices for the testing). It doesn't provide as good coverage as the AR9271 based adapter but it is totally adequate for simple use-cases. It uses the same driver as the RTL8192CU chipset and therefore it should also support 32 clients in AP mode by default.
Update1: taking a quick look at the source code of the rt2800usb driver, it seems there is no hard-coded limit on the number of stations so I assume that the available memory is the only boundary. I'm about to make some tests as soon as I get the new adapters and publish the results.
Update2: looking into the source more thoroughly, I found some precious information:
In rt2800.h it says:
"MAC_WCID_BASE: 8-bytes (use only 6 bytes) * 256 entry" - this basically means the adapter can store 256 client MAC addresses in its memory if I understand correctly. That looks great but after going a bit deeper I found this:
rt2800lib.c, line 1353:
"Since parts of the pairwise key table might be shared with the beacon frame buffers 6 & 7 we should only write into the first 222 entries."
After the comment, there's an iteration going from 33 up to 222 which should mean the adapter can handle 189 stations in total.
Running through the sources of the 8192cu driver, I could find some interesting limits:
include/sta_info.h, line 29:
#define NUM_STA 32
#define NUM_ACL 16
This should mean that the driver supports 32 stations and 16 ACL entries in the MAC allow/deny table. Also, as no firmware is required for these chips, I assume the station table is stored in the system RAM which means it's likely this limit can be pushed upwards by modifying the source.