This information has been tested and created for use on the Gateworks Single Board Computers (SBCs), specifically the Ventana family that utilizes the Freescale i.MX6 processors.

Gateworks SBCs can be viewed at the following link:

For information on various wireless technologies see the following pages:

802.11 WiFi

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.

Common Wireless Radio Hardware

Gateworks re-sells some of the more popular radios in our on-line store and has tested several others:

Some additional radio vendors:

Doodlelabs Prism-FES (Front End Subsystems)

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.

Part Numbering Scheme

Before we break this down further, the following terminology used by Doodlelabs is required:

Grade Breakdown:

  • Military Grade - This is their Industrial grade option. This grade has extended temp of -40C - +85C. This grade also has antenna port protection, and is built to a higher standard than their other radio's.
  • Enterprise - This is their Indoor Commercial grade option. This grade has a temperature range of 0C - +60C and has no antenna port protection.
  • Outdoors - This is their Outdoor Commercial grade option. This grade has a temperature range of -40C - +40C and has antenna port protection.

The model number NM-770-2F is broken down into three sections: NM, 770, 2F

  • NM - The 'N' refers to this being an 80211N radio. If this were 'ACM', for example, that would mean the radio is a 80211AC radio. The last character of the first section refers to the grade the radio is. In this case, the 'M' stands for Military, or rugged, grade.
  • 770 - This number refers to the middle frequency of the frequency range that the card supports. In this case, the card supports 746~798, the midpoint center frequency resulting in 770. If there is no number, and instead has either 'DB' or 'TB', that only means "Dual-Band" and "Tri-Band", respectively. When DB is specified, that refers to both the 2.4GHz and 5.8GHz range. TB refers to DB, but also includes the 4.9GHz frequency range.
  • 2F - The number '2' refers to the number of chains the radio has. In this case, there are two chains on this radio. A '3' would indicate three chains. The 'F' alludes to the fact that each chain get's frequency shifted through the frequency shifting module. This means that you're always going to have a FES module per chain.

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.

Licensed vs Unlicensed

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'.

Frequency Shifting/Power Level Mappings

Coming Soon.


Gateworks BSP Support

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

If you are looking for additional support please contact support@…

OpenWrt Wireless Configuration

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 Wireless Configuration

Yocto uses the standard Linux utilities, init scripts, and conf files.

For more info on configuring Wireless for Yocto see:

Android Wireless Configuration

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:

Wireless Configuration (Standard Linux)

There are several tools and applications that are used by Linux to configure wireless devices:

  • iw
  • hostapd
  • wpa_supplicant

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, similar to how the ip command is replacing ifconfig etc.

The full documentation is here but some common commands we find useful are:

  • list devices:
    iw dev ;# 'iw dev wlan0 info' for each dev
    iw phy ;# 'iw phy phy0 info' for each dev
  • list device info:
    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
  • antenna info:
    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
  • TX power info:
    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)
  • channel:
    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-]
  • 4-addr header parsing (WDS):
    iw dev wlan0 set 4addr <on|off>
  • interface mode:
    iw dev wlan0 set type <managed|ibss|monitor|mesh|wds>
  • rate masks (when fixed mask set you won't see T,p,P change in rc_stats but will see the stats change)
    iw dev set bitrates ;# clear masks
    iw dev wlan0 set bitrates ht-mcs-5 19 ;# set MCS-19
  • interface creation:
    iw phy phy0 interface add <name> type <type>
    iw phy phy0 interface add mon0 type monitor
    iw dev <name> del ;# delete interface


  • most commands allow specification of a network device (ie wlan0) or a phy (ie phy0)
  • most iw set commands will show current settings if a value isn't specified
  • iw wlan0 ... is short for iw dev wlan0 and iw phy0 is short for iw phy phy0, though it is not recommended



The hostapd application is the userspace application that configures and manages wireless drivers in Access Point (AP) mode.



The wpa_supplicant application is the userspace application that configures and manages wireless drivers in Station (STA) mode.


Linux Kernel Drivers

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.

Atheros AR5xxx 802.11abg cards (ath5k)

There are two driver options for the Atheros AR5xxx based 802.11abg cards:

  1. madwifi driver - development of this driver has ceased but it still has been known to outperform the fully opensource ath5k replacement and has some additional features that are not (and will not be) in ath5k
  2. ath5k - mac80211 driver - driver should be stable, but does not get much attention anymore as most users have moved on to 802.11n or 802.11ac devices

Theoretical max throughput rate of 802.11abg is 54mbps. Typical performance is around 30mbps (TCP)

Atheros AR9xxx 802.11abgn cards (ath9k)

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:

  • widening the channel bandwidth (up to 40MHz)
  • Multiple Input(rx) Multiple Output(tx) streams (MIMO) up to 4
  • 64-QAM modulation

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

Atheros AR10xx 802.11ac cards (ath10k)

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:

  • widening the channel bandwidth (up to 160MHz)
  • increased MIMO spatial streams (up to 8 vs 4 in 802.11n)
  • multi-user MIMO (aka MU-MIMO)
  • high-density modulation (up to 256-QAM vs 64-QAM for 802.11n)

Current popular hardware available supports up to 3x3 MIMO and up to 80MHz channel bandwidths using VHT80 which can theoretically yield 1.3gbps of throughput. Actual results will vary based on CPU and bus bottlenecks, driver performance, and RF characteristics.


The ath10k driver makes use of binary firmware (closed-source) that offload hardware configurations to the card itself. The ath10k driver then acts like a full MAC driver and causes interrupts to be generated on the host that allow the processor to then process those irq requests. However, in the history of this driver, there are quite a few firmware out in the wild. The 'official' location of these drivers is located here. Note that each chipset has it's own binary blobs.

However, a large issue pops up. When QCA first made firmware available for use, they offered two different ones:

  • 10.1.467.2-1
    • Focuses as AP in which DFS works. STA mode works, but not well tested. No AdHoc or P2P support
    • Works in wireless bridge with upstream ath10k patches. These patches are in our 14.08 Branch (as well as trunk) of OpenWrt
  • 999.999.0.636
    • Supports both AP and STA, AdHoc, and P2P. Has issues with DFS and cannot be configured an an AP in a wireless bridge
    • Has less than half the performance than the 10.1.467.2-1 firmware. This was a primary reason for not choosing this firmware as our default shipped firmware
    • Monitor mode is not supported (crashes the firmware)
    • TX Power is not honored

While the above is still true, QCA has opted to only update the "AP" firmware (10.1.467.xx-xx). This means that anyone looking to get adhoc will either have to use the 999.999.0.636 firmware or be referred to a third party firmware.

To see what's current in ath10k, see here for more info

Verifying / Checking Firmware Version

On our Yocto BSPs, we create a symlink to the firmware. This allows easy viewing of which firmware will be used:

root@ventana:~# ls -la /lib/firmware/ath10k/QCA988X/hw2.0/
drwxr-xr-x    2 root     root           392 Mar 29 02:20 .
drwxr-xr-x    3 root     root           224 Mar 29 02:20 ..
-rw-r--r--    1 root     root          2116 Mar 29 00:50 board.bin
lrwxrwxrwx    1 root     root            29 Mar 29 02:20 firmware-5.bin -> firmware-5.bin_10.
-rw-r--r--    1 root     root        247196 Mar 29 00:50 firmware-5.bin_10.

To see that this was actually used, if an ath10k radio (with QCA988X chipset) is connected to a system:

root@ventana:~# dmesg | grep "firmware ver" | grep ath10k
[    7.822425] ath10k_pci 0000:07:00.0: firmware ver api 5 features no-p2p,raw-mode,mfp crc32 fee9a3e8

Multiple Firmware instructions

To use one firmware vs. another, you simply need to rename, or relink it. Steps are details below:

cd /lib/firmware/ath10k/QCA988X/hw2.0/
ln -sf firmware-2-ct-full-community-beta.bin firmware-2.bin
# Reboot board

You can use this method to link any firmware, so long as it's called firmware-2.bin or newer (e.g. firmware-5.bin). Note that firmware numbering matters, with firmware-5.bin being the highest priority.


Candelatech got their hands on the source code for the ath0k firmware and have been actively developing it. One of their latest enhancements to their firmware was to add adhoc support in conjunction with infrastructure.

For more details see here

Wireless Testing

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

  • Infrastructure mode means the following:
    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
  • Wireless Bridging means the following:
    (S)                     (C)
    PC-A<--->AP<- ->STA<--->PC-B
  • AdHoc means the following:
    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:

wireless test setup image

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.


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 or iperf3. 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.

Performance Tuning

There are many characteristics that factor into performance (throughput):

  • Radio factors:
    • use wider channel bandwidths for the highest bandwidth
      • For example, HT40 for 802.11n or VHT80/VHT160 for 802.11ac instead of HT20/VHT20
    • RF characteristics
      • For example: look at the driver's rate control statistics to ensure you are achieving the expected modulation rate. Modulation rates are dynamic and achieving the best one will result in the highest bandwidth
  • CPU factors:
    • CPU performance bottleneck (which can be verified by watching output of 'top' while doing performance tests) can vary greatly based on SMP configuration, IRQ configuration, kernel netfilter modules, userspace services, and CPU cache configuration

Additional References:

Performance Comparison (Measured Data Rates)

Below are our results with the following firmware modifications:

  • Firewall was turned off
802.11AC (ath10k|iwlwifi)
Radio Chipset Platform OS Used Infrastructure Results2 Wireless Bridge Results3
3x3 ACE-DB-3 QCA9880 GW5400 (Ventana) OpenWrt (14.08 BSP) NA NA 270 325
(miniPCIe) OpenWrt (16.02 BSP) 404 418 492 5181
Yocto 1.6 (backports 20140808) 243 394 297 315
Yocto 1.8 (backports 20150129) 290 402 312 392
Yocto 1.8.2 (backports 20160122) 4201 4211 340 338
GW2388-4 + GW16059 (Laguna)
(Not mechanically compatible)
3x3 WLE900VX QCA9880 GW5400 (Ventana) OpenWrt (14.08 BSP) 302 236 294 294
(miniPCIe) OpenWrt (16.02 BSP) 360 380 5001 511
Yocto 1.6 (backports 20140808) 289 301 274 367
Yocto 1.8 (backports 20150129) 290 410 310 412
Yocto 1.8.2 (backports 20160122) 374 420 344 398
GW2388-4 + GW16059 (Laguna) OpenWrt (14.08 BSP) 206 188 100 166
OpenWrt (16.02 BSP) 105 109 202 211

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

802.11N (ath9k)
Radio Chipset Platform OS Used Infrastructure Results2 Wireless Bridge Results AdHoc Results3
3x3 WLE350NX AR9590 GW2388-4 + GW16059 (Laguna) OpenWrt (13.06 BSP) NA NA 153 178 NA NA
(miniPCIe) OpenWrt (14.08 BSP) 101 130 95 111 23 29
OpenWrt (16.02 BSP) 75 100 171 186 61 87
GW5400 (Ventana) OpenWrt (14.08 BSP) 195 209 228 250 23 29
OpenWrt (16.02 BSP) 204 280 2731 293 248 273
Yocto 1.8 (backports 20150129) 251 3011 251 296 159 238
Yocto 1.8.2 (backports 20160122) 2531 292 253 3011 2501 2881
3x3 DNMA-H5 AR9160-BC1B GW2388-4 (Laguna) OpenWrt (13.06 BSP) NA NA 108 156 NA NA
(miniPCI) OpenWrt (14.08 BSP) 88 130 96 120 22 27
OpenWrt (16.02 BSP) 74 98 133 143 45 84
GW5400 + GW16082 (Ventana) OpenWrt (14.08 BSP) 67 70 69 76 22 27
OpenWrt (16.02 BSP) 95 98 107 113 36 55
2x2 SR71-15 AR9220 GW2388-4 (Laguna) OpenWrt (13.06 BSP) NA NA 110 111 NA NA
(miniPCI) OpenWrt (14.08 BSP) 82 117 90 101 22 27
OpenWrt (16.02 BSP) 66 91 123 137 43 81
GW5400 + GW16082 (Ventana) OpenWrt (14.08 BSP) 70 72 69 90 23 28
OpenWrt (16.02 BSP) 78 85 82 86 77 82
1x1 DHXA-2254 AR9485 GW2388-4 + GW16059 (Laguna) OpenWrt (14.08 BSP) 48 60 49 63 22 29
(miniPCIe) OpenWrt (16.02 BSP) 47 62 51 64 44 57
GW5400 (Ventana) OpenWrt (14.08 BSP) 50 60 51 62 22 28
OpenWrt (16.02 BSP) 50 60 52 62 105 119
Yocto 1.8 (backports 20150129) 53 68 54 68 90 105

1. Best performing in this category (802.11n)
2. Infrastructure tested by generating packets on PC-A and sourcing them on the STA. See the wireless testing section for more details
3. AdHoc testing is based on NODE to NODE
4. In AP mode, this can only deliver at HT20 rates (MCS-7)

802.11ABG (ath5k|madwifi)
Radio Platform OS Used Infrastructure Results2 Wireless Bridge Results AdHoc Results
CM9 GW2388-4 (Laguna) OpenWrt (12.10BSP) + madwifi NA NA 10.4 11.5 NA NA
OpenWrt (12.10BSP) + ath5k NA NA 30.11 32.41 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

WiFi Terminology and Concepts


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).


Regulatory Domain

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.


  • OpenWrt uses this option
  • If you enable CONFIG_CFG80211_INTERNAL_REGDB and fail to overwrite the default net/wireless/db.txt a default domain will be used which sets the 'no IR' flag on all channels (meaning you can not transmit)


Automatic Channel Selection (ACS)

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.


  • a modern hostapd (2013-11-21) must be used and built with CONFIG_ACS
  • specify channel=0 or channel=acs_survey in hostapd.conf


Dynamic Frequency Selection (DFS)

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.


  • a modern hostapd (2013-11-21) must be used
  • not supporting DFS limits the channels that can be used:
    • In the US (FCC regulatory domain) there are 4 channels in the 5.8GHz band that do not require DFS and 4 that do

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.


Antenna Selection

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 values are a bitmask (ie 1 for antenna1, 2 for antenna2, 4 for antenna 3, 3 for antenna 1&2, 6 for antenna 2&3 etc)
  • typically the interface needs to be in a down state (ifconfig wlan0 down) in order to set the antenna selection bitmasks
  • not all drivers support this

Guard band Interval (GI)

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.


  • The rate control algorithm may decide between short GI and long GI based on statistics and alternate this over time

Channel Width

Channel Width refers to the bandwidth per channel and varies per 802.11 mode:

  • 802.11b - defines 20MHz channel width (this allows for 3 non-overlapping channels out of the 11 channels defined in the 2.4GHz band)
  • 802.11n - added the capability of 40MHz channels referred to as 'HT' or High Throughput channels. When using 40MHz HT channels you must specify HT40- to use the current channel specified frequency and the 20MHz below it, and HT40+ to use the current channel specified frequency and the 20MHz above it
  • 802.11ac - added the capability of 80MHz and 160MHz channels referred to as 'VHT' or Very High Throughput channels

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.

Modulation Rates

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.

Various drivers will list their current or last MCS rate via debug sysfs after some packets have been transmitted/received. Please see below where such information can be found:

  • ath9k
    > cat /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/<STATION MAC ADDR>/rc_stats
  • ath10k
    > cat /sys/kernel/debug/ieee80211/phy0/ath10k/fw_stats | grep -A20 "ath10k PEER stats"
                 ath10k PEER stats (2)
                  Peer MAC address 04:f0:21:0d:4b:02
                         Peer RSSI 0
                      Peer TX rate 0
                      Peer RX rate 0
                  Peer MAC address 04:f0:21:0d:4a:f4
                         Peer RSSI 43
                      Peer TX rate 433300
                      Peer RX rate 433300

Modulation Schemes:

  • 802.11b - allowed for 1M, 2M, 5.5M, 11M CCK modulation rates
  • 802.11g - added additional OFDM modulation schemes to allow for 6M, 9M, 12M, 18M, 24M, 36M, 48M, and 54M modulation rates
  • 802.11n - added additional modulation schemes to allow several more rates and introduced the concept of a Modulation and Coding Scheme (MCS) index to describe them
  • 802.11ac - added 2 additional MCS indexes for new 256-QAM modulation schemes


  • you can use the iw dev wlan0 set bitrates command to set bitmasks to indicate which modulation rates to allow
  • there is not a standard mac80211 way to determine what modulation rate is being used, or what the rate control algorithm is doing
  • some devices/drivers use the mac80211 rate control algorithms (there are 2 to choose from at compile time) and others use algorithms baked into device firmware
  • Modulation Table Online

Adhoc mode (IBSS)

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.

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 phy phy0 interface add wlan0 type ibss # create an interface on phy0 called wlan0 configured for adhoc mode
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 dev wlan0 set type ibss # change an existing wlan0 device to ibss mode (if must be down)
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

Frame Aggregation

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.


Quality of Service

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.


Wired Equivalent Privacy (WEP)

Wired Equivalent Privacy (WEP) is a security algorithm for IEEE 802.11 wireless networks. Introduced as part of the original 802.11 standard ratified in September 1999, its intention was to provide data confidentiality comparable to that of a traditional wired network. WEP, recognizable by the key of 10 or 26 hexadecimal digits, was at one time widely in use and was often the first security choice presented to users by router configuration tools.

In 2003 the Wi-Fi Alliance announced that WEP had been superseded by Wi-Fi Protected Access (WPA). In 2004, with the ratification of the full 802.11i standard (i.e. WPA2), the IEEE declared that both WEP-40 and WEP-104 have been deprecated.


Wi-Fi Protected Access (WPA)

Wi-Fi Protected Access (WPA) was introduced by the Wi-Fi Alliance in 2003 as an intermediate solution to WEP insecurities and implements a subset of a draft of 802.11i.


Wi-Fi Protected Access II (WPA2)

802.11i-2004 is Wi-Fi Protected Access II (WPA2) which supersedes the previous security spec Wired Equivalent Privacy (WEP) which has vulnerabilities. It also superscedes Wi-Fi Protected Access (WPA) which was introduced by the Wi-Fi Alliance as an intermediate solution to WEP insecurities and implements a subset of a draft of 802.11i (2003).

Consider WPA a draft form of 802.11i and WPA2 a final form of 802.11i with additions over WPA.

802.11i (WPA2) enhances IEEE 802.11-1999 by providing a Robust Security Network (RSN) with two new protocols:

  • the 4-way handshake
  • group key handshake
Last modified 13 months ago Last modified on 05/26/16 11:56:06

Attachments (1)

Download all attachments as: .zip