| Version 94 (modified by , 2 years ago) ( diff ) |
|---|
This information has been tested and created for use on the Gateworks Single Board Computers (SBCs).
Gateworks SBCs can be viewed at the following link: http://www.gateworks.com
For information on various wireless technologies see the following pages:
Gateworks has had extensive experience with wireless radio's. This list includes miniPCI and miniPCIe, specifically with the Atheros wireless chipsets which happen to be one of the most common chipset's used under Linux in the industrial world.
Out of box, our BSP's include the latest wireless drivers available. This allows our customers to get the latest and greatest support right away.
Gateworks re-sells some of the more popular radios in our on-line store and has tested several others. Please see the sections below for more information.
The following radios have been tested on Gateworks SBCs:a
/lib/firmware/ath10k/QCA9984/hw1.0/board-2.bin
Find all Laird Sterling (LWB5+) on-board wireless information on this dedicated wiki page: expansion/on-board-wireless
WiFi6 & WiFi6E & 802.11ax is the latest, fastest generation of WiFi radios. These are bleeding edge and often require the latest software (kernel 5.15 or newer), firmware, and latest hardware.
WiFi6E is the 'extension' of WiFi6. Wi-Fi 6E supports 6-GHz. WiFi6 is backwards compatible with other previous WiFi versions, but WiFi6E is not.
Because the below radios are bleeding edge, the Linux kernel may still be working to add full support.
WiFi 6 / 802.11ax Radios Gateworks has seen on the market:
WiFi 6E:
Note that MiniPCIe and M.2 sockets have 'W_DISABLE#' pins that are intended to disable all RF transmission on a wireless device.
Typically these signals are either driven high by default or pulled up with a pull-up resistor on-card and thus only need to be manipulated if you want to disable RF.
See gpio/w_disable# for more details
Gateworks supports multiple Board Support Packages. The following table shows details on WiFi support for each:
| BSP | Product Families | Drivers | Modes |
|---|---|---|---|
| OpenWrt | All | ath5k/ath9k/ath10k | AP / client |
| Yocto | Ventana | ath5k/ath9k/ath10k | AP / client |
| Android | Ventana | ath5k/ath9k | AP / client |
| ubuntu | Ventana, Newport | ath9k/ath10k | AP / client |
If you are looking for additional support please contact support@…
OpenWrt uses the standard Linux wireless utilities but configured and launched through its own configuration system.
For more info on configuring Wireless for OpenWrt see:
Yocto uses the standard Linux utilities, init scripts, and conf files.
For more info on configuring Wireless for Yocto see:
Android uses the standard Linux utilities but wraps them around a Network Daemon that performs configuration and management.
For more info on configuring Wireless for Android see:
Ubuntu uses the standard Linux utilities, init scripts, and conf files.
For more info on configuring Wireless for Ubuntu see:
There are several tools and applications that are used by Linux to configure wireless devices:
For more info on configuring Wireless for Yocto see:
The 'iw' tool is the modern tool (which replaces the older set of WIRELESS_EXTENSION tools such as iwconfig, iwpriv, iwlist, etc) for configuration of wireless drivers.
The full documentation is here but some common commands we find useful are:
iw dev ;# 'iw dev wlan0 info' for each dev iw phy ;# 'iw phy phy0 info' for each dev
iw dev wlan0 info ;# basic info: ifname, mode, mac (same as iw wlan0 info) iw phy phy0 info ;# detailed info: antennas, supported modes, bands, freqs (same as iw phy0 info) iw dev wlan0 link # info about link
iw phy phy0 | grep Antenna ;# get Antenna bitmasks iw phy phy0 set antenna_gain <gainindbm> iw phy phy0 set antenna <bitmap> | all <txbitmap> <rxbitmap> ;# set allowed antennas
iw dev wlan0 set txpower <auto|fixed|limit> [<txpowermbm>] iw phy phy0 set txpower <auto|fixed|limit> [<txpowermbm>] iw phy phy0 set distance <distance meters> ;# set appropriate coverage class (0-114750) iw phy phy0 set coverage <coverage class> ;# set coverage class (1 for every 3us of air prop time 0-255)
iw phy phy0 channels #show available channels iw dev wlan0 set channel <channel> [HT20|HT40+|HT40-] ;# or iw phy iw dev wlan0 set freq <freq> [HT20|HT40+|HT40-] ;# or iw phy iw dev wlan0 set freq <control freq> [20|40|80|80+80|160] [<center freq>] [<center freq2>] iw phy phy0 set freq <freq> [HT20|HT40+|HT40-]
iw dev wlan0 set 4addr <on|off>
iw dev wlan0 set type <managed|ibss|monitor|mesh|wds>
iw dev set bitrates ;# clear masks iw dev wlan0 set bitrates ht-mcs-5 19 ;# set MCS-19
iw phy phy0 interface add <name> type <type> iw phy phy0 interface add mon0 type monitor iw dev <name> del ;# delete interface
# May increase wireless performance depending on radio iw dev wlan0 set power_save off
Notes:
References:
The hostapd application is the userspace application that configures and manages wireless drivers in Access Point (AP) mode.
References:
By default the Yocto BSP is configured to enable a Wireless Access Point.
The 'hostap-daemon' package provides the hostapd application which configures the radio for AP mode using configuration from /etc/hostapd.conf.
You will need to configure /etc/hostapd.conf to specify important details such as:
The default /etc/hostapd.conf file contains detailed documentation and you can find more info here. However, because every wireless cards' capabilities are vastly different from one another, Gateworks has written a script to help ascertain a proper hostapd.conf file. Though not 100% of the functionality mentioned in the hostapd documentation is supported, it does help the user create a hostapd.conf file specific to their wireless card.
This bash script, named hostapd-conf, is included in our latest Yocto 1.8/Master branches. To read over the script, please click here.
Usage is as follows:
root@ventana:~# ./hostapd-conf hostapd-conf [OPTIONS] <iface> <ssid> <channel> [<htmode>] [<passphrase>] Options: --help - This help --br-name <name> - Name of bridge --wds <0|1> - Enable WDS --version - Print this version: v1.0 Example: Print channel information for wlan0 and exit: hostapd-conf wlan0 State wlan0 SSID is 'myssid', on channel 6 with WPA2 passphrase "nowayinside": hostapd-conf wlan0 myssid 6 nowayinside State wlan0 is in named bridge br0, enable WDS, SSID 'myssid', channel 6, in HT20(802.11n), with WPA2 passphrase "nowayinside": hostapd-conf --br-name=br0 --wds=1 wlan0 myssid 6 HT20 nowayinside
Below are some usage cases for this script. In these examples, a WLE900VX radio was used. Note, any information that isn't apparent in the below script may be found via the iw phy phy<n> info command.
To view all channels/frequencies and HT modes that can emit radiation on a specified interface, indicate just the interface:
root@ventana:~# ./hostapd-conf wlan0 ERROR: SSID is empty Available Channel Information on phy0 ===================================== Band 1: Channel Freq Allowed HT Modes 0 0000 HT20 HT40 HT40+ HT40- 1 2412 HT20 HT40 HT40+ 2 2417 HT20 HT40 HT40+ 3 2422 HT20 HT40 HT40+ 4 2427 HT20 HT40 HT40+ 5 2432 HT20 HT40 HT40+ HT40- 6 2437 HT20 HT40 HT40+ HT40- 7 2442 HT20 HT40 HT40+ HT40- 8 2447 HT20 HT40 HT40+ HT40- 9 2452 HT20 HT40 HT40+ HT40- 10 2457 HT20 HT40 HT40- 11 2462 HT20 HT40 HT40- Band 2: Channel Freq Allowed HT Modes 0 0000 HT20 HT40 HT40+ HT40- VHT20 VHT40 VHT80 36 5180 HT20 HT40 HT40+ VHT20 VHT40 VHT80 40 5200 HT20 HT40 HT40- VHT20 VHT40 VHT80 44 5220 HT20 HT40 HT40+ VHT20 VHT40 VHT80 48 5240 HT20 HT40 HT40- VHT20 VHT40 VHT80 149 5745 HT20 HT40 HT40+ VHT20 VHT40 VHT80 153 5765 HT20 HT40 HT40- VHT20 VHT40 VHT80 157 5785 HT20 HT40 HT40+ VHT20 VHT40 VHT80 161 5805 HT20 HT40 HT40- VHT20 VHT40 VHT80 165 5825 HT20 HT40 HT40+ VHT20 VHT40 VHT80
2.4GHz 802.11g
To create a hostapd.conf file in the 2.4GHz range, using 802.11g technology:
root@ventana:~# ./hostapd-conf wlan0 test-ssid 6 Settings: IFACE: wlan0 PHY: phy0 SSID: test-ssid CHANNEL: 6 FREQ: 2437 BANDS: 1 2 HWMODE: g Written to hostapd-phy0.conf root@ventana:~# cat hostapd-phy0.conf # For more options, please visit the following: # http://linuxwireless.org/en/users/Documentation/hostapd/ driver=nl80211 logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 # a=5GHz, g=2.4GHz hw_mode=g # channel=0 turns on ACS survey channel=6 # Please take the following into consideration: # Country code (ISO/IEC 3166-1). Used to set regulatory domain. # Set as needed to indicate country in which device is operating. # This can limit available channels and transmit power. #country_code=US # Enable IEEE 802.11d. This advertises the country_code and the set of allowed # channels and transmit power levels based on the regulatory limits. The # country_code setting must be configured with the correct country for # IEEE 802.11d functions. # (default: 0 = disabled) #ieee80211d=1 # Enable IEEE 802.11h. This enables radar detection and DFS support if # available. DFS support is required on outdoor 5 GHz channels in most countries # of the world. This can be used only with ieee80211d=1. # (default: 0 = disabled) #ieee80211h=1 interface=wlan0 ctrl_interface=/var/run/hostapd ctrl_interface_group=0 disassoc_low_ack=1 preamble=1 wmm_enabled=1 macaddr_acl=0 auth_algs=1 ignore_broadcast_ssid=0 ssid=test-ssid ieee80211n=0 ieee80211ac=0
5.8GHz 802.11ac
To create a hostapd.conf file in the 5GHz range, using 802.11ac technology, plus WPA2 encryption:
root@ventana:~# ./hostapd-conf wlan0 test-ssid 157 VHT80 nowayinside Settings: IFACE: wlan0 PHY: phy0 SSID: test-ssid CHANNEL: 157 FREQ: 5785 BANDS: 1 2 HWMODE: a HTMODE: VHT80 PASSPHRASE: nowayinside Written to hostapd-phy0.conf root@ventana:~# cat hostapd-phy0.conf # For more options, please visit the following: # http://linuxwireless.org/en/users/Documentation/hostapd/ driver=nl80211 logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 # a=5GHz, g=2.4GHz hw_mode=a # channel=0 turns on ACS survey channel=157 # Please take the following into consideration: # Country code (ISO/IEC 3166-1). Used to set regulatory domain. # Set as needed to indicate country in which device is operating. # This can limit available channels and transmit power. #country_code=US # Enable IEEE 802.11d. This advertises the country_code and the set of allowed # channels and transmit power levels based on the regulatory limits. The # country_code setting must be configured with the correct country for # IEEE 802.11d functions. # (default: 0 = disabled) #ieee80211d=1 # Enable IEEE 802.11h. This enables radar detection and DFS support if # available. DFS support is required on outdoor 5 GHz channels in most countries # of the world. This can be used only with ieee80211d=1. # (default: 0 = disabled) #ieee80211h=1 interface=wlan0 ctrl_interface=/var/run/hostapd ctrl_interface_group=0 disassoc_low_ack=1 preamble=1 wmm_enabled=1 macaddr_acl=0 auth_algs=1 ignore_broadcast_ssid=0 # Put a 3 here if you want both WPA/WPA2 wpa=2 wpa_passphrase=nowayinside wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP ssid=test-ssid ieee80211n=1 ht_capab=[HT40+][LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40] ieee80211ac=1 vht_oper_chwidth=1 vht_oper_centr_freq_seg0_idx=155 vht_capab=[RXLDPC][SHORT-GI-80][TX-STBC-2BY1][RX-ANTENNA-PATTERN][TX-ANTENNA-PATTERN][RX-STBC1][MAX-MPDU-11454][MAX-A-MPDU-LEN-EXP7]
After the hostapd-<phy>.conf file has been created and any edits have been made (if any), you may either:
hostapd-phy.conf file over /etc/hostapd.conf and restart hostapd, noting that /etc/network/interfaces isn't configuring the wlan interface automatically (e.g. make sure no auto wlan0 exists in /etc/network/interfaces)
mv /etc/hostapd.conf /etc/hostapd.conf.bak # Backup original hostapd.conf file
cp hostapd-phy0.conf /etc/hostapd.conf
/etc/init.d/hostapd restart
root@ventana:~# /etc/init.d/hostapd stop root@ventana:~# hostapd -B hostapd-phy0.conf Configuration file: hostapd-phy0.conf [ 1825.468968] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready wlan0: interface state UNINITIALIZED->HT_SCAN [ 1825.636135] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
At this point your wlan0 interface should be up and authenticating with WiFi clients and the next step is to configure IP networking (below).
A routed Access Point is used when you want the wireless network to have its own DHCP server and network. In this case traffic is routed across the WAN (Wide Area Network) interface (ie eth0) and WLAN (Wireless Local Area Network) interface (ie wlan0). This is the typical configuration for a wireless access point.
For this you need:
Configuration:
apt-get update apt-get install dnsmasq -y
systemctl stop systemd-resolved systemctl mask systemd-resolved
rm /etc/resolv.conf echo nameserver 8.8.8.8 | tee /etc/resolv.conf
cat << EOF > /etc/network/interfaces # WAN interface auto eth0 iface eth0 inet dhcp # WLAN interface auto wlan0 iface wlan0 inet static address 10.0.0.1 netmask 255.255.255.0 # NAT configuration via iptables post-up iptables-restore < /etc/iptables.ipv4.nat EOF
cat << EOF > /etc/dnsmasq.conf interface=wlan0 dhcp-range=10.0.0.10,10.0.0.200,2h EOF
systemctl restart dnsmasq
# enable forwarding on bootup echo net.ipv4.ip_forward=1 >> /etc/sysctl.conf # Configure NAT via iptables and then save its config to the restore script iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT iptables-save > /etc/iptables.ipv4.nat chmod +x /etc/iptables.ipv4.nat
/etc/init.d/networking restart echo 1 > /proc/sys/net/ipv4/ip_forward
hostapd hostapd-phy1.conf &
A bridged Access Point is used to provide an a Wireless Access Point on a LAN that already has a DHCP server and creates a bridge between the LAN interface and the WIFI interface such that wireless client DHCP requests will be bridged to the LAN and answered from there.
For this you need:
# create a bride and add interfaces to it brctl addbr br0 brctl addif br0 eth0 brctl addif br0 wlan0 # bring it up ifconfig br0 up # use DHCP to assign IP info udhcpc -i br0
echo 1 > /proc/sys/net/ipv4/ip_forward
echo net.ipv4.ip_forward=1 >> /etc/sysctl.conf
Note that if your intention is to also create a wireless client bridge where a wireless client connection is bridging its wireless to a local Ethernet network you will need to enable WDS/4-addr header parsing on both the Access Point and the Client. To do this on the Access Point, add the following to /etc/hostapd.conf:
wds_sta=1
Alternatively, if using the hostapd-conf script, an option exists to enable this feature via --wds=1.
If encountering bad TCP performance with MIMO cards (typically ath10k):
If encountering issues:
hostapd-conf was written for and takes advantage of the bash shell, make sure you aren't running it with another shell program (ie Ubuntu's default "dash" shell)
iw dev wlan0 scan for a Linux client, or use a wireless scanner such as 'Wifi Analyzer' on an Android device)
wlan0: associated in the kernel messages
route -n on Linux) and make sure you have a proper gateway
The wpa-supplicant application is the userspace application that configures and manages wireless drivers in Station (STA) mode.
References:
You generate a wpa_supplicant.conf file using a tool called wpa_passphrase:
~# wpa_passphrase MYSSID MYWPAPASSCODE network={ ssid="MYSSID" #psk="MYWPAPASSCODE" psk=82207641ae13124ee6dc8fd2642605ac52a17405263b0b3203ee5cdb826d700d }
The following steps below can be used to connect to a WPA access point. You will likely need to alter this depending on your OS and distribution.
For the following example we will use an SSID of 'MYSSID' and a WPA passcode of 'MYWPAPASSCODE' (replace with values your AP is configured with):
root@ventana:~# wpa_passphrase MYSSID MYWPAPASSCODE > /etc/wpa_supplicant.conf
To start wpa_supplicant manually:
killall wpa_supplicant # make sure its not already running
wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf -B
To obtain DHCP network configuratnoi:
dhclient wlan0
Monitor all traffic on a wireless channel.
Check that your wireless interface supports monitor mode.
iw list |grep monitor
Check current mode.
iw dev
Configure radio (for example wlan0).
ip link set wlan0 down iw wlan0 set monitor control ip link set wlan0 up
Optional
Scan traffic using tshark (terminal wireshark).
apt-get install tshark
tshark -i wlan0
To read more about mesh see our dedicated mesh page.
There are various linux kernel drivers such as madwifi, ath5k, ath9k, ath10k, iwlwifi, to name a few. The below few sections will talk at length about several of them.
As of 2018
There are two driver options for the Atheros AR5xxx based 802.11abg cards:
Theoretical max throughput rate of 802.11abg is 54mbps. Typical performance is around 30mbps (TCP)
The linux-wireless 'ath9k' driver supports the Atheros AR9xxx based 802.11n cads.
The 802.11n standard released in 2009 introduces some additions on top of the 802.11a standard:
Current popular hardware available supports up to 3x3 MIMO and up to 40MHz channel bandwidths using HT40+/HT40- which can 'theoretically yield' 300mbps of throughput. Actual results will vary based on CPU and bus bottlenecks, driver performance, and RF characteristics.
We regularly obtain throughputs around 150mbps.
See ath9k for more info
The linux-wireless 'ath10k' driver supports the Atheros AR10xx based 802.11ac cards.
The 802.11ac standard which was developed from 2011 through 2013 and approved in Jan 2014, introduces some additions on top of the 802.11n standards:
Current popular hardware available supports up to 4x4 MU-MIMO and up to 160MHz channel bandwidths using VHT160 which can theoretically yield >2.0gbps of throughput. Some cards also support VHT80+80 which functions similarly to VHT160 but is composed to two 80MHz channels that do not need to be contiguous, which can help with band selection. Actual results will vary based on CPU and bus bottlenecks, driver performance, and RF characteristics.
ath10k notes:
To check which version of ath10k firmware is being used on the Single board computer, use the dmesg and grep command:
root@OpenWrt:/# dmesg | grep ath10k [ 10.934967] ath10k: qca988x hw2.0 (0x4100016c, 0x043202ff) fw 10.1.467.2-1 root@OpenWrt:/#
To select between default and custom firmware you must rename or re-link it using the existing filenames in the driver directory. The driver will not use your custom firmware unless it has a name it's familiar with. This can vary depending on the chipset firmware you are intending to use as well as the BSP
Some examples:
$ cd /lib/firmware/ath10k/QCA988X/hw2.0/ $ ln -sf firmware-2-ct-full-community-beta.bin firmware-2.bin $ # Reboot board
# Download Candelatech's firmware.bin and board.bin files wget http://www.candelatech.com/downloads/ath10k-9984-10-4/board-2-ct.bin wget http://www.candelatech.com/downloads/ath10k-9984-10-4/firmware-5-ct-full-community.bin # Back up old files cp /lib/firmware/ath10k/QCA9984/hw1.0/board-2.bin /lib/firmware/ath10k/QCA9984/hw1.0/board-2.bin_old cp /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin_old # Drop in Candelatech files mv board-2-ct.bin /lib/firmware/ath10k/QCA9984/hw1.0/board-2.bin mv firmware-5-ct-full-community.bin /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin
That's it! You can use this method to link any firmware, so long as it's called firmware-2.bin (and if using the latest ath10k drivers, firmware-3.bin).
Candelatech licenses the source code for the ath0k firmware from QCA and has been actively developing it to provide enhancements and bugfixes that are not necessarily limitted to QCA's stock firmware priorities. One such enhancement is that they add IBSS/adhoc support.
Candelatech also has a web page for custom firmware files that may be required for certain radio's such as the WLE1216V5-20 wave 2 radio.
You may need this firmware if the ath10k driver and QCAXXXX firmware combination does not properly probe your device and create an interface. This would appear in your system log as:
root@xenial-newport:~# dmesg | grep ath10k [ 2.362523] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA9984/hw1.0/board-pci-168c:003e:11ad:0804.bin failed with error -2 [ 2.362527] ath10k_pci 0000:02:00.0: failed to load spec board file, falling back to generic: -2 [ 2.362536] ath10k_pci 0000:02:00.0: Direct firmware load for ath10k/QCA9984/hw1.0/board.bin failed with error -2 [ 2.362538] ath10k_pci 0000:02:00.0: failed to fetch generic board data: -2 [ 2.362540] ath10k_pci 0000:02:00.0: failed to fetch board file: -2 [ 2.362541] ath10k_pci 0000:02:00.0: could not fetch firmware files (-2) [ 2.362543] ath10k_pci 0000:02:00.0: could not probe fw (-2)
If this is the case, you can use CT's firmware as follows:
# Download Candelatech's firmware.bin and board.bin files wget http://www.candelatech.com/downloads/ath10k-9984-10-4/board-2-ct.bin wget http://www.candelatech.com/downloads/ath10k-9984-10-4/firmware-5-ct-full-community.bin # Back up old files cp /lib/firmware/ath10k/QCA9984/hw1.0/board-2.bin /lib/firmware/ath10k/QCA9984/hw1.0/board-2.bin_old cp /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin_old # Drop in Candelatech files mv board-2-ct.bin /lib/firmware/ath10k/QCA9984/hw1.0/board-2.bin mv firmware-5-ct-full-community.bin /lib/firmware/ath10k/QCA9984/hw1.0/firmware-5.bin
QCA9984 chipset. You may need to change your wget and /usr/lib/firmware/... targets accordingly.
Finally, to see what's current in ath10k, see here for more info
Ath11k is a Linux driver for Qualcomm 802.11AX devices. 802.11ax is often called WiFi6.
Examples of Athh11k Radios:
Support was first added upstream in kernel version 5.6, though it's recommended to use a kernel 5.15 or newer. Gateworks has successfully tested on a Venice board using 5.15 kernel. Testing with a Ventana board on a 5.10 kernel was unsuccessful.
To enable support for this device in the kernel menuconfig enable the option for "CRYPTO_MICHAEL_MIC" then "ATH11K", instructions on kernel.org suggest this option should be enabled as a module, not static to the kernel.
Currently the firmware for Ath11k cards is not included in our prebuilt images. To add it:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
cd cd /lib/firmware/ath11k/ scp -r <hostname>@<ipaddress_of_workstation>:/<path_to_ath11k_firmware>/linux-firmware/ath11k/* . sync reboot
More CMA memory may need to be allocated.
In dmesg check for messages regarding inadequate CMA:
[ 7.533137] cma: cma_alloc: reserved: alloc failed, req-size: 512 pages, ret: -12 [ 7.541360] cma: cma_alloc: reserved: alloc failed, req-size: 512 pages, ret: -12
To remedy:
#in U-boot setenv bootargs ${bootargs} cma=128M saveenv
Speed testing was bottlenecked by the router being used. WLE3000H2 maxed out its throughput.
#iperf3 using 2 WLE3000H2's across Netgear Wifi6 AX1800 dual band WAP: root@focal-venice:~# iperf3 -c 192.168.1.5 Connecting to host 192.168.1.5, port 5201 [ 5] local 192.168.1.127 port 58128 connected to 192.168.1.5 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 51.3 MBytes 430 Mbits/sec 0 2.11 MBytes [ 5] 1.00-2.00 sec 52.5 MBytes 440 Mbits/sec 0 2.76 MBytes [ 5] 2.00-3.00 sec 53.8 MBytes 451 Mbits/sec 0 3.08 MBytes [ 5] 3.00-4.00 sec 51.2 MBytes 430 Mbits/sec 0 3.08 MBytes [ 5] 4.00-5.00 sec 56.2 MBytes 472 Mbits/sec 0 3.08 MBytes [ 5] 5.00-6.00 sec 52.5 MBytes 440 Mbits/sec 0 3.08 MBytes [ 5] 6.00-7.00 sec 55.0 MBytes 461 Mbits/sec 0 3.08 MBytes [ 5] 7.00-8.00 sec 55.0 MBytes 462 Mbits/sec 0 3.08 MBytes [ 5] 8.00-9.00 sec 52.5 MBytes 440 Mbits/sec 0 3.08 MBytes [ 5] 9.00-10.00 sec 53.8 MBytes 451 Mbits/sec 0 3.08 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 534 MBytes 448 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 531 MBytes 445 Mbits/sec receiver
References:
https://wireless.wiki.kernel.org/en/users/drivers/ath11k
https://wireless.wiki.kernel.org/en/users/drivers/ath11k/installation
Gateworks has recently validated Alfa AWPCIE-AX200U a cost effective (half size) mPCI-e form factor card. The AX200U supports WI-FI6 (IEEE 802.11AX) in 2.4 and 5ghz modes and has integrated BT5, it is also backward compatible with IEEE 802.11a/b/g/n/ac. This card uses both a PCI-e 1x lane and USB 2.0 for BT. The AX200 chipset this card is based on was developed by Intel. Intel reports a thermal rating from 0C to 80C. Please see the Intel ARK page for more details.
Linux support is provided by the iwlwifi driver, which is included in the mainline kernel source. The compatibility with Gateworks prebuilt Ubuntu images is plug and play. A limitation of this driver is AP's can only be hosted at 2.4GHZ. This driver does provide support for station (client) at 5ghz or 2.4ghz, P2P, Monitor, and IBSS. The chipset is also capable of packet injection which makes it an excellent option for use with the Aircrack-ng suite and Kali Linux which is available from Offensive Security for the Ventana and Newport platforms.
Special Notes
root@focal-venice:~# diff /usr/bin/hostapd-conf hostapd-conf 275c275 < | grep "Capabilities: " | cut -d" " -f2) --- > | grep "Capabilities: 0x" | cut -d" " -f2)
The AX200 requires a firmware file that may or may not be on the board you are using:
Download the firmware here and place the iwlwifi-cc-a0-46.ucode in the /lib/firmware/ folder on the running system.
The AX200U is one of the fastest low cost wi-fi cards we have validated to date, below are the results of real world type iperf3 tests using a WI-FI6 capable Netgear (WAX204) wireless router.
Accepted connection from 192.168.1.3, port 46278 [ 5] local 192.168.1.2 port 5201 connected to 192.168.1.3 port 46280 [ ID] Interval Transfer Bandwidth [ 5] 0.00-1.00 sec 52.6 MBytes 441 Mbits/sec [ 5] 1.00-2.00 sec 87.4 MBytes 733 Mbits/sec [ 5] 2.00-3.00 sec 89.7 MBytes 752 Mbits/sec [ 5] 3.00-4.00 sec 94.7 MBytes 795 Mbits/sec [ 5] 4.00-5.00 sec 92.6 MBytes 777 Mbits/sec [ 5] 5.00-6.00 sec 87.1 MBytes 731 Mbits/sec [ 5] 6.00-7.00 sec 86.0 MBytes 722 Mbits/sec [ 5] 7.00-8.00 sec 65.9 MBytes 552 Mbits/sec [ 5] 8.00-9.00 sec 79.4 MBytes 666 Mbits/sec [ 5] 9.00-10.00 sec 88.5 MBytes 742 Mbits/sec [ 5] 10.00-10.01 sec 954 KBytes 763 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 5] 0.00-10.01 sec 826 MBytes 692 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 825 MBytes 691 Mbits/sec receiver
First, some testing vocabulary:
Symbol Legend Key Meaning AP Access Point STA Station <---> Ethernet Connection <- -> Wireless Connection (S) iperf server (1) (C) iperf client (2) X Doesn't Work NA Didn't Test
1. TCP server run with: iperf -s -w3M; UDP server run with: iperf -su
2. TCP client run with: iperf -c $IP -i1 -t25 -w3M; UDP client run with: iperf -u -c $IP -i1 -t25 -b999M
1. Testing between AP and STA (S) (C) AP<- ->STA 2. Testing between WAN and STA (Our standard infrastructure mode test) (S) (C) PC-A<--->AP<- ->STA
(S) (C) PC-A<--->AP<- ->STA<--->PC-B
1. No Bridge (S) (C) NODE1<- ->NODE2 (Our standard !AdHoc test) 2. With Bridge (Requires special software) (S) (C) PC-A<--->NODE1<- ->NODE2<--->PC-B
Below is an example setup of how we test and with what hardware:
1. 60dB Attenuators on each chain
2. Directional Coupler (Krytar 1850 shown)
3. Power Sensor (Agilent 8481A shown)
4. Power Meter (HP E4418A shown)
The image above shows our testing setup. In general, to test TX Power, we use a Power Meter + Power Sensor + Directional Coupler. Further, when people talk about performance, they typically are talking about throughput from AP<- ->STA. When we talk about performance, we spell out specifically which network topology we are testing, who is generating/sending packets, and who is receiving. This should make it very clear where performance numbers came from and how you can compare against them.
Troubleshooting:
We define performance as the rate at which data can travel at. This essentially means looking at throughput numbers via performance tools such as iperf. One of the ways we stress test our product is by running it through conditions that our customers might use. Since we also support a wide variety of wireless cards, we test a whole lot. The below sections will talk about how to tune a product to get the best performance and talk about the numbers we've gotten for each card we've tested.
There are many characteristics that factor into performance (throughput):
Additional References:
Below are our results with the following firmware modifications:
This table contains some throughput numbers (in Mbits/s) seen during testing.
| Radio | Chipset | Platform | OS Used | Infrastructure Results2 | Wireless Bridge Results3 | AdHoc Results4 | |||
|---|---|---|---|---|---|---|---|---|---|
| TCP | UDP | TCP | UDP | TCP | UDP | ||||
| 3x3 ACE-DB-3 | QCA9880 | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 271 | 380 | 4 | 9 |
| Yocto 1.6 (backports 20140808) | NA | NA | NA | NA | NA | NA | |||
| 3x3 WLE900VX | QCA9880 | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 228 | 495 | NA | NA |
| Yocto 1.6 (backports 20140808) | NA | NA | NA | NA | NA | NA | |||
| GW6300 (Newport) | Ubuntu (16.02 Xenial) | NA | NA | 330 | 677 | NA | NA | ||
| 3x3 DAXA-O1 | QCA9880 | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 240 | 463 | 131 | NA |
| Yocto 1.6 (backports 20140808) | NA | NA | NA | NA | NA | NA | |||
| 4x4 WLE1216V5-20 | QCA9984 | GW6300 (Newport) | Ubuntu (16.02 Xenial) | NA | NA | 8001 | 7181 | NA | NA |
1. Best performing in this category
2. Infrastructure tested by generating packets on PC-A and sourcing them on the STA. See the wireless testing section for more details
3. Wireless bridging works only with the 10.1.467.2-1 firmware with upstream patches
4. AdHoc works only with the 999.999.0.636 firmware and since there isn't wireless bridging, this number is based on NODE to NODE
| Radio | Platform | OS Used | Infrastructure Results3 | Wireless Bridge Results | AdHoc Results4 | |||
|---|---|---|---|---|---|---|---|---|
| TCP | UDP | TCP | UDP | TCP | UDP | |||
| 1x1 GTM671WFSd | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 50 | 65 | NA | NA |
| 2x2 SR71-15 | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 92 | 112 | NA | NA |
| 2x2 WLM200N5-26 | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 88 | 106 | NA | NA |
| 2x2 SR71e | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 1902 | 2452 | NA | NA |
| 3x3 HNMA-H5 | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 111 | 119 | NA | NA |
| 3x3 WLE300NX | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 240 | 3671 | NA | NA |
| 3x3 WLE350N5-25 | GW5400 (Ventana) | OpenWrt (14.08 BSP) | NA | NA | 2431 | 355 | NA | NA |
1. Best performing in this category (802.11n)
2. Best performing in this sub-category (802.11n, number of chains, form-factor)
3. Infrastructure tested by generating packets on PC-A and sourcing them on the STA. See the wireless testing section for more details
4. AdHoc testing is based on NODE to NODE
1,6,and 11 do not overlap.
In the US: 36, 40, 44, 48, 149, 153, 157 and 161.
Note: Usable non-overlapping channels exist between 48 and 149. 52, 56, 60, 64, 100, 104, 108, 112, 116, 132, and 136 to be specific. These channels are regulated and will not work if other devices are already transmitting in this range
Starting in Linux 2.6.7 (and back-ported to 2.4.27), Linux includes alternative congestion control algorithms beside the traditional 'reno' algorithm. 2.6.13 added support for plug-able congestion control algorithms set using sysctl variable net.ipv4.tcp_congestion_control which is set to bic/cubic or reno by default depending on kernel versions.
The Internet has predominantly used loss-based congestion control (largely Reno or CUBIC) since the 1980s, relying on packet loss as the signal to slow down. While this worked well for many years, loss-based congestion control is unfortunately out-dated in today's networks. On today's Internet, loss-based congestion control causes the infamous bufferbloat problem, often causing seconds of needless queuing delay, since it fills the bloated buffers in many last-mile links. On today's high-speed long-haul links using commodity switches with shallow buffers, loss-based congestion control has abysmal throughput because it over-reacts to losses caused by transient traffic bursts.
TCP congestion control algorithms can be configured in the Kenrel under 'Networking support (NET) -> Networking options -> TCP/IP networking (INET) -> TCP: advanced congestion control (TCP_CONG_ADVANCED). The default is typically CONFIG_TCP_CONG_CUBIC which builds in CUBIC (default) and Reno. A more modern algorithm called BBR was introduced more recently.
You can select between multiple TCP congestion control algorithms via userspace sysctl:
cat /proc/sys/net/ipv4/tcp_available_congestion_control # see available algos sysctl net.ipv4.tcp_congestion_control=reno # select Reno
References:
TCP Small Queues (TSQ) performs local flow control, limiting the amount of data in the queues on the sending host. Like TSO autosizing, TSQ has its own balancing act, keeping the queues small to reduce latency and head-of-line blocking (HoLB), while keeping the queues just large enough to ensure the queues on the sending host.
The kernel TSQ logic allows up to 1ms of bytes to be queued into qdisc and driver queues. However, Wifi aggregation (multiple streams) needs a bigger budget to allow bigger rates to be discovered by various TCP Congestion Control algos.
A patch has made it into the 4.15 kernel that allows wifi drivers to adjust this value as needed but drivers need to be updated to add this functionality.
Gateworks has a patch in the Newport kernel that allows userspace to change the default 1ms buffering time manually with sysctl. Increasing the buffering to something between 1ms and 9ms shows significant throughput increases for MIMO cards. For example:
sysctl net.ipv4.tcp_tsq_limit_output_interval=5 # use 5ms of buffering in TSQ logic
References:
mac80211 refers to the Linux kernel 802.11 MAC layer software stack written for !SoftMAC radios. For many years all radio drivers utilize this layer and those drivers are referred to as 'mac80211 drivers'. An exception to this would be the popular 'madwifi' driver used for Atheros AR5XXX based 802.11abg radios (the mac80211 driver alternative to madwifi is the ath5k driver).
References:
Different regulatory domain's exist around the world that are regulated by various bodies - examples include the FCC for North Ameriaca, and ETSI for many European countries. Modern Linux mac80211 based drivers use the crda (Central Regulatory Domain Agent) userspace agent for regulatory domain rule database and checking. It is comprised of a database of regulatory domain rules.
Alternatively mac80211 can be configured at compile-time with CONFIG_CFG80211_INTERNAL_REGDB to use an internal regdb based on net/wireless/db.txt which can be easier to udpate if need be for your application (providing you are making changes that are legal in the regulatory domain you will be operating in). One example of where this would be useful is if you are licensed to operate in the US Public Safety band, which crda has no support for.
Notes:
The iw list command will print out frequencies that are supported or may be blocked due to current domain, see example below showing the no IR statement:
Frequencies: * 5955 MHz [1] (20.0 dBm) (no IR)
Current regulatory domain can be seen with the command and set to US with example below:
root@jammy-venice:~# iw reg get global country 00: DFS-UNSET (755 - 928 @ 2), (N/A, 20), (N/A), PASSIVE-SCAN (2402 - 2472 @ 40), (N/A, 20), (N/A) (2457 - 2482 @ 20), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (2474 - 2494 @ 20), (N/A, 20), (N/A), NO-OFDM, PASSIVE-SCAN (5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW, PASSIVE-SCAN (5490 - 5730 @ 160), (N/A, 20), (0 ms), DFS, PASSIVE-SCAN (5735 - 5835 @ 80), (N/A, 20), (N/A), PASSIVE-SCAN (57240 - 63720 @ 2160), (N/A, 0), (N/A) phy#0 (self-managed) country 00: DFS-UNSET (2402 - 2472 @ 40), (N/A, 20), (N/A) (2457 - 2482 @ 20), (N/A, 20), (N/A), PASSIVE-SCAN (5170 - 5330 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5490 - 5730 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5735 - 5895 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5945 - 7125 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN root@jammy-venice:~# iw reg set US root@jammy-venice:~# iw reg get global country US: DFS-FCC (902 - 904 @ 2), (N/A, 30), (N/A) (904 - 920 @ 16), (N/A, 30), (N/A) (920 - 928 @ 8), (N/A, 30), (N/A) (2400 - 2472 @ 40), (N/A, 30), (N/A) (5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW (5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW (5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS (5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW (5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN (5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN (57240 - 71000 @ 2160), (N/A, 40), (N/A) phy#0 (self-managed) country 00: DFS-UNSET (2402 - 2472 @ 40), (N/A, 20), (N/A) (2457 - 2482 @ 20), (N/A, 20), (N/A), PASSIVE-SCAN (5170 - 5330 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5490 - 5730 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5735 - 5895 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN (5945 - 7125 @ 160), (N/A, 20), (N/A), AUTO-BW, PASSIVE-SCAN root@jammy-venice:~#
References:
The Automatic Channel Selection (ACS) feature is useful if you want the operating channel to be selected based on usage in your area. A specification exists on how this is done.
Notes:
References:
Dynamic Frequency Selection (DFS) is a specification required by certain regulatory domains on specific channels in order to eliminate conflicts with weather and government/military radar equipment. For this reason it is sometimes know as 'radar detection' (which is likely a better description of it). This is often required for channels on the 5.8GHz band and there are specific rules for how and if a radio can transmit on these channels.
Because DFS is complex many small office and home office AP's as well as some enterprise AP's don't allow operation at all on DFS channels in the 5GHz band and many client devices are not certified for DFS operation.
Notes:
The ath9k as well as ath10k (and possibly others) fully support ETSI DFS and FCC DFS requirements according to reports on the linux-wireless maillist and various radio certifications.
References:
MIMO (Multiple-In Multiple-Out) radios (802.11n and 802.11ac) have multiple transmit and multiple receive antennas (also known as 'chains'). On some devices/drivers you can configure which are used for tx as well as rx using the 'set antenna' command:
iw phy0 info | grep Antenna # show available Antennas iw phy0 set antenna 1 2 # set tx for antenna1, rx for antenna 2 iw phy0 set antenna 1 3 # set tx for antenna1, rx for antenna 2 and 3
The guard band interval describes how long you wait in between packets before transmission. For 802.11 OFDM this is 800ns hjwever 802.11n (also supported in 802.11ac) introduced a 400ns option to increase data-rates. This new 400ns GI is referred to as a 'short' GI and the original 800ns is referred to as a 'long' GI.
Notes:
Channel Width refers to the bandwidth per channel and varies per 802.11 mode:
Some drivers also support 'half' channel bandwidth (10MHz) and/or 'quarter' channel bandwidth (5Mhz) which is useful if you don't need the bandwidth provided by standard (20MHz) channels or HT/VHT channels and instead want more channel separation.
Note that as you increase the channel width, you increase channel overlap and decrease separation.
Various 802.11 specifications allow for varying modulation schemes which trade off error resilience, throughput, and effective distance. Each transmission can vary the modulation scheme and A 'rate control algorithm' has the ability to change this dynamically for each node being transmitted to based on different statistics.
Modulation Schemes:
Notes:
Though not part of the 802.11 spec (was part of the 802.11 draft), a popular mode is referred to as 'adhoc' mode or 'IBSS' mode. In this mode there is no authentication/de-authentication and no concept of an Access Point. Instead a 'network' is defined by the 'BSSID' used by the nodes. Network discovery is performed by listening to beacons and beacon transmission is shared by nodes in a BSSID (each node has a beacon timer with a random backoff interval which is reset when a beacon matching the nodes network is received which tends to share the beacon transmission load). A scheme was defined so that nodes would join a network if a beacon is received matching the nodes network configuration and BSSID's would 'merge' depending on timestamps however this is not implemented consistently and can cause issues such as merge storms across various drivers/chipsets. Because of this often adhoc networks will define a BSSID instead.
Because adhoc mode is not in the 802.11 spec and is not as popular as infrastructure mode (AP/STA) it isn't always as stable as infrastructure mode.
While not required, Adhoc networking is often used as the underlying connection mode for layer2 (MAC layer) and layer3 (IP layer) MESH networks such as olsrd.
Check that IBSS is available to use:
iw phy0 info
When using adhoc mode, you do not need hostapd or wpa_supplicant and the iw tool can be used to join/leave adhoc network:
iw dev wlan0 set type ibss # change an existing wlan0 device to ibss mode (if must be down) iw dev wlan0 ibss join myssid 5180 # join the 'myssid' network, on 5180MHz (20MHz) and rely on IBSS discovery and merging iw dev wlan0 ibss leave # leave the adhoc network
Some other useful commands for adhoc nodes:
iw phy phy0 interface add wlan1 type ibss # create an interface on phy0 called wlan1 configured for adhoc mode iw dev wlan0 ibss join myssid 5180 0a:0b:0c:0d:0e:0f # join the 'myssid' network, on 5180MHz (20MHz) with fixed bssid iw dev wlan0 ibss join myssid 5180 HT40- 0a:0b:0c:0d:0e:0f # join the 'myssid' network, on 5180MHz (40MHz using 5180 and the ch below) with fixed bssid
Creating an interface that already exists will cause an error:
root@OpenWrt:/# ls /sys/class/net/ bond0 can0 gretap0 lo bonding_masters eth0 ifb0 usb0 br-lan gre0 ifb1 wlan0 root@OpenWrt:/# iw phy phy0 interface add wlan0 type ibss command failed: Too many open files in system (-23) root@OpenWrt:/#
As data rates increase the overhead of management and headers starts to create bandwidth bottlenecks. The 802.11n specification introduced the concept of Frame Aggregation to combat this. Two types of aggregation was introduced: A-MPDU and A-MSDU.
This does not need to be enabled and should be used automatically by the driver if the card has the capability.
References:
The 802.11e specification added various aspects to 802.11 to create the concept of multiple data queues with different priorities in order to create a quality of service.
References:
The following terminology used by Doodlelabs is required:
Grade Breakdown:
The model number NM-770-2F is broken down into three sections: NM, 770, 2F
So in conclusion, the NM-770-2F system includes a 80211N radio with two chains, each getting frequency shifted by a FES module to the 770MHz range.
In the US, the difference between Licensed and Unlicensed comes down to how the FCC regulates the frequency spectrum. In general, Doodlelabs refers to 'unlicensed' radio's the 2.4GHz and 5GHz range frequencies. All other frequencies fall under being 'licensed'.
Coming Soon.
Doodlelabs creates frequency shifting modules to allow frequencies between 700MHz - 6.5GHz, while using standard linux drivers. These systems are comprised of one ath9k/ath10k radio with a FES module on each chain. The below picture will help visualize this:
In this system, a radio has two separate FES modules per chain. From the factory, Doodlelabs calibrates each chain on a specific radio to a particular FES module. This means that a radio with 2 chains is specifically paired with two FES modules. You can find which FES modules are paired with what radio by comparing serial numbers (Hint: all components in the system have the same serial). It's very highly recommended by Doodlelabs that nothing is mixed and matched.
Radio's configured to be used in a Prism-FES all have EEPROM values programmed in to only allow a maximum of 10dBm output (per chain). Anything higher will damage the frequency translator. For this reason, Prism-FES's that are using ath10k are recommended to stay away from using the STA firmware (999.999.0.636) as we found that this firmware does not honor the EEPROM settings and configures the radio to output much higher than 10dBm.
FES Power Discussion
For example, the GW6100 can support approximately 8W of power to the Mini-PCIe slot (at 3.3V).
The Doodle Labs radio requires around 2W for the radio portion which should work fine in the Mini-PCIe site.
For the FES amplifier you will need and additional 16W of power which would be over the limit of what we can provide from the slot.
Doodle Labs does however have an optional DC/DC converter (6-38V input) which can be used to power the FES directly from your VIN supply. See the following link for picture of the DC/DC: https://doodlelabs.com/products/industrial-wifi-transceivers/datasheet-nm-5500-2f/
By using the optional DC/DC you can also mount the FES away from the board to optimize your thermal solution. The FES is pretty small and generates a lot of heat so I would suggest mounting it directly to your enclosure for maximum heat transfer and then you can cable from the radio to the FES.
If the Doodle Labs DC/DC doesn't fit your design needs there are lots of other vendors that make DC/DC modules that you could use for the FES power. As an example see the following link: https://www.cui.com/product/resource/pyb20-u.pdf
Sometimes a USB WIFI device is the only option available. Gateworks seldom validates these radios, from our limited testing "AmazonBasics Wi-Fi 11N USB Adapter - 300 Mbps, Black" is an excellent inexpensive choice. This radio's drivers are already built in the kernel providing a turn key wireless interface.
https://www.amazon.com/AmazonBasics-Wi-Fi-11N-USB-Adapter/dp/B071Y6Y83W/
GW17032 WLE900VX Radio
ax200U
Download all attachments as: .zip
Powered by Trac 1.6
By Edgewall Software
.
Visit the Trac open source project at
http://trac.edgewall.org/
