Uniform AG1311 Contactless Smart Card Reader Module User Manual

Uniform Industrial Corp. Contactless Smart Card Reader Module Users Manual

Users Manual

Download:
Mirror Download [FCC.gov]
Document ID	2120934
Application ID	13OufLaryRpvaxbvAZgpPw==
Document Description	Users Manual
Short Term Confidential	No
Permanent Confidential	No
Supercede	No
Document Type	User Manual
Display Format	Adobe Acrobat PDF - pdf
Filesize	103.41kB (1292589 bits)
Date Submitted	2013-11-17 00:00:00
Date Available	2013-11-18 00:00:00
Creation Date	2013-10-22 10:31:08
Producing Software	Adobe Acrobat 10.1.7
Document Lastmod	2013-10-22 10:31:08
Document Title	Users Manual
Document Creator	PScript5.dll Version 5.2.2
Document Author:	slee

ŇŏĵıĳłġŉŢųťŸŢųŦġŔűŦŤį
őųŦűŢųŦť
łűűųŰŷŦť
œŦŷŪŴŪŰů
Description
ĹıĳįĲĲůġŸŪŧŪġŔźŴŵŦŮġŎŰťŶŭŦ
System
CPU
Flash
DRAM
RTC
Ethernet
RF
łŵũŦųŰŴġłœĺĴĴĲġĩłœĲĴĲĲĪ
ĹġŎŃ
ĴĳġŎŃ
ŏŰ
ĲıİĲııġŎţűŴġŇŢŴŵġņŵũŦųůŦŵġīĳġĩŰűŵŪŰůŢŭġŵŰġŐůŦġœŋĮĵĶĪ
ĲŕĲœĭġĹıĳįĲĲůĭġũŪĮűŰŸŦųġĩĶııġŮŸĪ(2.4GHz Band)
Switch port
Power Input
DC jack
I/O & Peripherial
JTAG
RS-232 (console)
USB
USB extension
Wifi antenna
LEDs
Reset Button
Environmental
PCB dimension
Housing
Operating temperature
Humidity
ĶŗĭġŮŪůŪŅńġŋŢŤŬ
ŏİł
ŤŰůŴŰŭŦġűŰųŵġŸŪŵũġĵĮűŪůġűŪůġũŦŢťġŤŰůůŦŤŵŰų
ŐůŦġűŰųŵĭġŖŔŃġĳįıġũŰŴŵ
ķĮűŪůġŦŹŵŦůťŦťġŧųŰŮġŖŔŃġűŰųŵ
ŷŪŢġŔŎłġœŇġŤŰůůŦŤŵŰųġŧŰųġŦŹŵŦųůŢŭġŢůŵŦůůŢ
ķġōņŅŴ
ŚŦŴĭġŔŰŧŵŸŢųŦġœŦŴŦŵ
ĶĸŮŮġīġĸıġŮŮ
ŕŅŃ
ıƱńġſĶıƱń
ĺıĦġůŰůĮŤŰůťŦůŴŪŷŦ
ŌŦůůźġńũŦů
ŔűŦůŤŦųġńũŦů
ŷŦųġĲįĲ
ĴįĲĲįĳıĲĴ
GPIO definition
ňőŊŐġı
ňőŊŐġĲĴ
ňőŊŐġĲĸ
őŰŸŦų
ňőŊŐġĳĸ
ňőŊŐġĳķ
ňőŊŐġĳı
ňőŊŐġĳĴ
ňőŊŐġĲĳ
ōņŅġĲ
ōņŅġĳ
ōņŅġĴ
ōņŅġĵ
ōņŅġĶ
ōņŅġķ
ŊƳńġŅŢŵŢ
ŊƳńġńŭŰŤŬ
œŦŴŦŵġţŶŵŵŰůġĩŴŰŧŵŸŢųŦġœŦŴŦŵĪ
Revision record
ųŦŷįĲįĲŎ
PRELIMINARY
Revision History
Revision
Date
Description
0.5
November
2008
Original Release
0.6
November
2008
Updated to include Web interface and configuration methods.
0.7
Jan 2010
Updated for UMAC baseline
PRELIMINARY
Table of Contents
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.4
1.4.1
1.4.2
1.5
1.6
2.1
2.2
2.3
2.3.1
2.3.1.1
2.3.1.2
2.3.1.3
2.3.1.4
2.3.2
2.3.2.1
2.3.2.2
2.3.2.3
2.3.3
2.3.3.1
2.3.3.2
2.4
2.4.1
2.4.2
2.4.2.1
2.4.2.2
2.4.2.3
2.4.2.4
2.4.2.5
2.4.2.6
2.4.2.6.1
2.4.3
2.5
2.5.1
Introduction................................................................................................................................................ 6
Top Level architecture ........................................................................................................................ 6
Fusion Overview ................................................................................................................................. 6
Lower MAC ........................................................................................................................................ 7
HAL .................................................................................................................................................... 7
ATH .................................................................................................................................................... 7
Rate Control ........................................................................................................................................ 7
Packet Logging ................................................................................................................................... 8
DFS ..................................................................................................................................................... 8
Upper MAC ........................................................................................................................................ 8
802.11 Layer ....................................................................................................................................... 8
Shim Layer.......................................................................................................................................... 8
WLAN Driver Interface and OS Abstraction Layer ........................................................................... 9
WBUF Abstraction ............................................................................................................................. 9
User Interface ........................................................................................................................................... 10
Configuration File ............................................................................................................................. 10
Environmental Variables................................................................................................................... 10
Shell Scripts ...................................................................................................................................... 19
Initialization Scripts .......................................................................................................................... 26
rcS ..................................................................................................................................................... 27
rc.network ......................................................................................................................................... 27
rc.bridge ............................................................................................................................................ 27
rc.wlan............................................................................................................................................... 27
Driver Operation Scripts ................................................................................................................... 27
makeVAP.......................................................................................................................................... 28
activateVAP ...................................................................................................................................... 29
killVAP ............................................................................................................................................. 29
Compatibility Scripts ........................................................................................................................ 29
apup................................................................................................................................................... 29
apdown.............................................................................................................................................. 29
Wireless Tools .................................................................................................................................. 30
iwconfig ............................................................................................................................................ 30
iwpriv ................................................................................................................................................ 32
Radio Layer....................................................................................................................................... 33
Protocol Layer................................................................................................................................... 41
WMM related.................................................................................................................................... 42
Security Related ................................................................................................................................ 44
802.11n related.................................................................................................................................. 48
Regulatory commands....................................................................................................................... 52
General commands .................................................................................................................... 54
Changing parameters using iwconfig and iwpriv.............................................................................. 63
wlanconfig utility .............................................................................................................................. 63
Creating a VAP ................................................................................................................................. 63
PRELIMINARY
Listing VAP Parameters.................................................................................................................... 63
2.5.2
2.5.2.1
Station (sta) ....................................................................................................................................... 64
2.5.2.2
AP List (ap)....................................................................................................................................... 65
2.5.2.3
Channel (chan) .................................................................................................................................. 65
2.5.2.4
Capabilities (caps)............................................................................................................................. 66
2.5.2.5
WMM Configuration (wme) ............................................................................................................. 66
2.5.3
Deleting a VAP ................................................................................................................................. 66
AP Configuration Guide .......................................................................................................................... 67
3.1
AP Modes of Operation .................................................................................................................... 67
3.1.1
Network Configuration ..................................................................................................................... 67
3.1.1.1
Bridged Mode ................................................................................................................................... 67
3.1.1.2
Static IP address Mode...................................................................................................................... 67
3.1.1.3
DHCP Client ..................................................................................................................................... 67
3.1.1.4
DHCP Server .................................................................................................................................... 67
3.1.2
Radio Configuration.......................................................................................................................... 68
3.1.3
Operating Mode ................................................................................................................................ 68
3.2
Security ............................................................................................................................................. 69
3.2.1
WEP Configuration........................................................................................................................... 69
3.2.2
WPA.................................................................................................................................................. 69
3.2.2.1
Enabling WPA Preauthorization (AP only) ...................................................................................... 69
3.2.2.2
WPA PSK ......................................................................................................................................... 70
3.2.2.3
WPA Enterprise ................................................................................................................................ 70
3.2.3
WSC Configuration........................................................................................................................... 70
3.2.3.1
Including WSC in the build............................................................................................................... 70
3.2.3.2
Activating WSC support on the AP .................................................................................................. 70
3.3
VLAN Configuration ........................................................................................................................ 71
3.3.1
Bridge configuration in mBSSID and VLAN mode ......................................................................... 72
3.4
Multiple BSS..................................................................................................................................... 72
3.4.1
Multiple Open APs............................................................................................................................ 72
3.4.2
Multiple AP’s with different security modes .................................................................................... 73
3.4.3
Changing Parameters in mBSSID Modes ......................................................................................... 73
3.5
Wi-Fi Distribution System (WDS).................................................................................................... 73
3.5.1
AP With Single WDS Repeater ........................................................................................................ 73
3.5.1.1
Limitations ........................................................................................................................................ 73
3.5.1.2
Setup Instructions.............................................................................................................................. 74
3.5.2
AP with Multiple Repeaters .............................................................................................................. 74
3.5.2.1
Limitations ........................................................................................................................................ 75
3.5.2.2
Setup Instructions.............................................................................................................................. 75
3.5.3
WDS Bridge with single span ........................................................................................................... 75
3.5.3.1
Limitations ........................................................................................................................................ 75
3.5.3.2
Setup Instructions.............................................................................................................................. 76
3.5.4
WDS Bridge with multiple span ....................................................................................................... 76
3.5.4.1
Limitations ........................................................................................................................................ 76
3.5.4.2
Setup Instructions.............................................................................................................................. 77
3.6
Dual Concurrent Operations ............................................................................................................. 77
Appendix A Country Code Definition.......................................................................................................................... 78
PRELIMINARY
Introduction
This manual provides information on the design and use of the Atheros AP system. This system consists of the OS kernel,
utility functions, and the Atheros AP Driver.
1.1
Top Level architecture
This driver is based on the Atheros Universal Driver Architecture. This architecture abstracts the WLAN driver into
various common sections that can be used for a variety of operating systems. OS specific components are well isolated,
and the Atheros Driver Framework (ADF) provides abstractions of OS services such that the common code does not
have to have ANY OS specific coding. The data packet abstraction, called WBUF, allows the driver to handle different
OS specific frame formats in a common way. This abstraction has been used with both SKB and MBUF frame
architectures successfully, and also works with Windows frame architectures.
The software design is moved to a further modularized architecture that allows for better isolation of data items and
object oriented design. . Global variables are eliminated, and all layer functions are contained within a call structure.
1.2
Fusion Overview
The main driver for the Fusion architecture was the use of a common code base to support multiple operating systems.
This allows for more efficient development processes, as well as the synergy of getting bug fixes for all major platforms
at the same time.
The Fusion architecture consists of 4 major components. The first is the WLAN driver interface, which is the operating
system unique interface adaptor that translates OS specific calls to Fusion “generic” calls. The second is the Upper
MAC layer, which contains the bulk of the 802.11 protocol processing for both station and AP applications. In earlier
versions of Fusion, this layer was implemented specifically for each operating system. In later versions, a common
version of the Upper MAC is used to provide the protocol processing layer.
The third component is the Lower MAC, which contains the ATH and HAL layers. This layer is much more hardware
centric, and is designed to support the needs of the Atheros chipset architecture. The fourth component is the OS
Abstraction layer. This is a set of macros that is used to redefine “generic’ OS primitives into specific system calls that
perform the required function. Functions such as register read/write, translation of OS packets into WBUF abstractions,
and tasking control are all included in this section. A block diagram of the components and their relationship are shown
in Figure 1.
˪˴̅́˼́˺ʳ
15.21 "Changes or modifications are not expressly approved by the manufacturer could void the user's authority to operate
the equipment."
The following sentence has to be displayed on the outside of device in which the transmitter module is installed "Contains
FCC ID: TFJAG1311 "
This device uses, generates and radiated radio frequency energy. The radio frequency energy produced by this device is
well below the maximum exposure allows by Federal Communications Commission(FCC).
PRELIMINARY
WLAN Driver Interface
OS Abstraction Layer
IEEE 802.11 Protocol Stack
STA/AP SME
Scanning/Roaming
MLME
Config
Mgmt Frm
PM
Base Objects (channel, ic, node, VAP)
LMAC Interface
Atheros Device Object (ath dev)
ATH DEV
Rate Control
Packet Logging
DFS
Hardware Abstraction Layer
AR5212
AR5416
Figure 1 Fusion Top Level Block Diagram
1.3
Lower MAC
The Lower MAC portion consists of two main components: The Hardware Abstraction Layer (HAL), and the
Atheros Device Object (ATH). The HAL contains all chip-specific settings and procedures that are performed
to initialize and operate the device. The ATH layer is responsible for managing the data flow into the input
queues of the hardware, as well as managing lower layer protocols, such as Block ACK processing.
1.3.1 HAL
HAL provides low-level primitives to program Atheros chipsets. HAL abstraction will allow runtime support of
multiple chipset families and defines a common body of functions between chipsets with chipset differences
being handled in specific components. Only low-level driver components can interface directly with HAL.
1.3.2 ATH
ATH_DEV module implements the low level MAC functionalities including:
Unified transmit and receive path for both legacy and 11n chipsets.
Advanced 11n MAC features: aggregation, RIFS, MIMO power save, etc.
802.11 network power save and device power state (D0-D3) management.
Beacon generation and TSF management.
Wake-On-Wireless support.
Key cache management.
RfKill, Customized LED and GPIO algorithms
ATH_DEV can be accessed through Atheros device object interface (section 1.2) by protocol shim layer.
1.3.3 Rate Control
The rate control algorithm attempts to transmit unicast packets at the optimum data rate. If there are changes in
the propagation channel, the rate control algorithm will automatically step up or down to a data rate that allows
reliable transmission at the fastest possible rate. The rate control can only be accessed by ath_dev, and should
not by protocol stacks.
PRELIMINARY
1.3.4 Packet Logging
Packet logging provides a low level mechanism to capture driver activities. It can log activities like transmit,
receive, rate find and update, aggregation, ANI, and etc. Different operating system shall have its own tool to
enable packet log and retrieve the log buffer.
1.3.5 DFS
the DFS or Dynamic
Frequency
y Selection algorithm,
, which enables wireless devices
This module implements
g in the 5GHz band to detect the presence
a systems.
is detected, the wireless
operating
of radar
If a radar system
device must avoid interfering with it and mustt automatically switch to another frequency.
1.4
Upper MAC
The Upper MAC is the portion of the MAC that performs most of the 802.11 protocol processing, and
provides the interface to the OS networking stack. In the Fusion implementation, the Upper MAC consists of
the 802.11 layer, and the so-called “shim” layer.
1.4.1 802.11 Layer
Most wireless LAN device driver today consists of two major components: a protocol stack and a low-level
driver. Usually the protocol stack contains IEEE802.11 state machine, scanning/roaming, IE processing, and
other device independent support needed by an 802.11 device. Although the functionalities of a protocol stack
are largely platform independent, the actual implementation is often platform specific.
Many protocol stacks are available. The protocol stacks with the most support in the Fusion driver are the
net80211 derivatives. They have been ported to NetBSD, Linux, Darwin, and Windows Vista. Another popular
stack is Devicescape’s 802.11 stack in Linux kernel. Microsoft also has a separate stack for SoftAP on Vista.
1.4.2 Shim Layer
The Shim layer is provided in order to minimize changes to upper layers that have been implemented for nonfusion architectures. Since the HAL/ATH layers try to encapsulate internal data and only provide interfaces
through the operations interface, the upper layer no longer have direct access to variables within the lower
layers. The Shim layer is provided to expose various state and configuration variables to the upper layers in
order to minimize changes to the upper layers.
The Shim layer uses the standard interfaces to the ATH/HAL layers to obtain state information. Since
everything is written in the “C” language, this is enforced more through coding convention than through
language restrictions. Because of the protocol stack is largely device independent, while a low level driver is
protocol independent, a protocol shim layer is required to connect different components of the wireless LAN
driver. Most importantly, it has the following operations:
Register with IEEE802.11 protocol stack.
Register with operating system’s network stack.
Manage low level driver object (ath_dev, see section 1.4).
Forward packets between protocol stack and low level driver.
Translate control request and event indication between protocol stack and low
level driver.
Figure 2 illustrates the operations of protocol shim layer.
PRELIMINARY
net80211
Packets
net80211 Requests
net80211 APIs
IF_ATH
Packets
ath_dev APIs
ath_dev Indications
ATH_DEV
Figure 2 UMAC Shim Layer
1.5
WLAN Driver Interface and OS Abstraction Layer
Each operating system has its own networking and wireless driver interface, such as NDIS 6.0 with Revised Native WiFi
in Windows Vista. The WLAN driver interface allows the driver to register with kernel, and defines data path and
configuration path from/to network stack, such as OID for Windows Vista, iwconfig/iwpriv tools for Linux, and etc.
OS abstraction layer is a set of kernel services used by wireless LAN driver. A separate implementation is required for
each platform. By having a consistent API across all platforms, driver developers can focus on the core wireless LAN
logic. Currently supported operating systems are: NetBSD, Linux and Windows Vista.
1.6
WBUF Abstraction
A wbuf (wireless buffer) is a platform independent object to represent a network buffer. In WLAN world, it also
represents an MSDU passed down by the protocol stack. The low level driver components treat wbuf as an opaque object
defined by type wbuf_t, and access it only through a well defined interface. The wbuf APIs can be found in
include/wbuf.h. Each platform should implement the same set of APIs in their OS abstraction layer. Usually the
wbuf is associated with or mapped to native network buffer structures.
PRELIMINARY
User Interface
The user interface on the Linux AP baseline provides a rich set of capabilities via command line tools, and also provides a
simplified web interface that can be used for quick AP configuration. The user interface is based on shell scripts and a
configuration utility that will store configuration information in flash. The web interface also uses this utility to store
information through boot cycles.
2.1
Factory Default File
The file /etc/ath/apcfg contains the “factory default” information for the AP. This is the data that is used to configure
the device in the absence of other configuration information. If the configuration information is erased, this data will
repopulate the configuration information files. The default values included in this file can be changed if the user so
desires.
2.2
Configuration Tool
The purpose of the cgiMain utility is to provide a small program size mechanism for managing environmental
configuration information in as efficient manner as possible. Major consideration has been applied to small footprint
environments, where JFFS2 filesystem space is at a premium. Further, if no configuration information needs to be
changed in the JFFS2 filesystem, the cramfs can be used to further reduce the flash footprint of the overall system.
2.2.1 Design
The main design intent was to provide a busybox like environment that can be used as a CGI program for getting
environmental information, and further providing output formatting that will make the web pages easily configurable,
but dynamic. This was done in lieu of other larger implementations, such as PHP or Python, simply for the smaller size
requirement, and the customization required to use flash resources effectively.
The main engine will receive an input file and “translate” it, changing specially tagged parameters into their equivalent
values. For example, let’s say that we have an environmental variable called AP_SSID, whose value is AP24. Further,
let’s say we have a configuration file that has a line in the file of the form
ssid=.
We can put a tagged reference to the environmental variable in the configuration file, and then “translate” it to a scratch
file:
Original file:
Translated file:
ssid=~~AP_SSID~
ssid=AP24
The translated file can be written to /tmp (ram disk), thus not requiring any more flash space to support the translation.
A typical command line to implement this would be
# cgiMain –t2 /etc/ath/PSK.ap_bss > /tmp/vap2sec.bss
Where /etc/ath/PSK.ap_bss is the file containing the tags, and /tmp/vap0sec.bss is the file containing the translated
version with tags replaced with values.
10
PRELIMINARY
2.2.1.1
Variable Names
All tags work with the names of environmental variables. These are passed either through the CGI interface when doing
HTML pages, and/or read from the stored environmental data. There are two types of variable names used by the
program:
Fixed Names:
The standard name with no additions, like AP_SSID
Indexed Names:
When variables are indexed by instance, they will typically have an extension, such as
AP_SSID_2. The indexed names are expressed as AP_SSID#, where the # is replaced by the
index as specified in the –t (translate) option
All variable names fall within these two categories. Indexed names can be used in any tag value
2.2.1.2
File Tags
The used tag types are designed to support two main efforts. First, they will allow an HTML page to be created with
tagged information that will be translated through the CGI interface. Secondly, in a command line format, it can be used
to manage the values stored in the flash/cache areas, allowing the user to have either temporary or permanent parameter
storage. Table 1 defines the available tags.
Table 1 Available File Tags
Tag
Usage
Example
~~VAR_NAME~
~~VAR_NAME#~
Direct replacement of the environmental
variable with its value. Variable must
exist to produce a value. If the value does
not exist, the tag is erased and no
characters are substituted.
~~AP_SSID~
~~AP_SSID#~
~~VAR_NAME:default~
~~VAR_NAME#:default~
Direct Replacement with Default. If the
variable exists, then its value is inserted.
If it does not exist, then the “default”
string will be substituted.
~~AP_STARTMODE:dual~
~~AP_CHMODE#:11NAHT20~
~`exec str`~
Execute the program or script enclosed in
` ` markers. The output of these programs
will be processed to be displayable in
HTML format (non breaking spaces will
be added, and tabs translated). Note that
any stderr output is not caught, and
should be piped to /dev/null if to be used
in a web page.
~`athstats 2>/dev/null`~
~cVAR_NAME:VAL~
~cVAR_NAME#:VAL
Used for checkboxes in HTML files
~sVAR_NAME:VAL~
~sVAR_NAME:VAL~
~?VAR_NAME:VAL`exec str`~
~?VAR_NAME#:VAL`exec str`~
11
PRELIMINARY
2.2.1.3
Flash Usage
This program seeks to eliminate extra usage of flash resources by using an existing sector for storing date (the calibration
sector). Note that the board and radio calibration data only take up the first 32 KB of flash storage, leaving the second
32 KB available. The permanent storage area for parameter data is put into this area without using a filesystem – the
data is simply written to flash as a linear string of data. Parameters are stored in the “NAME=VALUE” format. The
first 4 bytes of the data are flagged with a know value (0xfaf30020) as a synchronization value to verify the data is valid
(as opposed to an “erased” flash). The data is assumed terminated if a value of 0x0 is found (note that all data is stored
as ASCII, and can be read/edited in flash using u-boot).
A limit of 32 characters for variable names, and 64 characters for values are imposed. Adding the “=” and the
terminators, each value has a maximum of 98 characters used. This means that a total number of (32768-4)/98 = 334
parameters can be stored in this area. Since many parameter names and values are much shorter, an estimate of 450-500
parameters is not unreasonable. Note that parameters will only take up the space required, not the full 32/64 byte area.
The following is an example “dump” of the parameter data in flash:
ar7100> md 0xbf668000
bf668000: faf30020 49504144
bf668010: 36382e31 2e320a49
bf668020: 352e3235 352e3235
bf668030: 503d3139 322e3136
bf668040: 4e4d4153 4b3d3235
bf668050: 352e300a 41505f53
bf668060: 5f486f6c 64656e0a
bf668070: 323d4150 35305f48
bf668080: 5f504153 53504852
bf668090: 65310a41 505f5041
bf6680a0: 5f323d66 726f7a65
bf6680b0: 3d686572 650a0000
2.2.1.4
44523d31
504d4153
352e300a
382e322e
352e3235
5349443d
41505f53
6f6c6465
4153453d
53535048
0a5a4849
0000fbb7
39322e31
4b3d3235
57414e49
310a5741
352e3235
41503234
5349445f
6e0a4150
6672617a
52415345
46454e47
ffc1f6f7
... IPADDR=192.1
68.1.2.IPMASK=25
5.255.255.0.WANI
P=192.168.2.1.WA
NMASK=255.255.25
5.0.AP_SSID=AP24
_Holden.AP_SSID_
2=AP50_Holden.AP
_PASSPHRASE=fraz
e1.AP_PASSPHRASE
_2=froze.ZHIFENG
=here...........
Cache File
For temporary changes, a cache file is located in /tmp/.apcfg. This file contains the same type of information that is in
the flash, but is not permanent. This is used to perform updates to parameters during a run, but it is not desired to
commit these changes to flash. Note that a specific commit operation is required to update the flash area.
2.2.2 Tool Usage
The intended use for this is for both a web server interface, and for script access to permanent variables. Having a single
program to perform this function will save on flash space.
2.2.2.1
Web Server Usage
HTML files that define web pages usually contain static content, unless they have embedded java code. In order to get
dynamic content (without using something like PHP or java) something is required to modify the pages such that they
display the dynamic data as required. This is accomplished by linking the page name to the cgiMain program.
A web server will execute programs/scripts as part of the Computer Gateway Interface (CGI). This allows a program to
be run to generate the web page content as required. This interface is exploited for this function. The Busybox httpd
daemon will execute as a CGI program any page that is located in the /usr/www/cgi-bin directory. In order to have
separate pages that reference the same program, the same method that Busybox uses is used here. Page names are soft
linked to /usr/www/cgi-bin/cgiMain. The cgiMain program uses the argv[0] (the name of the program) to determine
which html page to process to produce the web content. This works in the exact same way as the file translation mode of
the cgiMain program, changing tagged values into their value strings, or in special cases indicating which parameters
have been “set” to specific values.
12
PRELIMINARY
An example of a tagged HTML page:

Basic AP Configuration

Bridged
Routed

DHCP

Local IP settings
Local IP Addr

Local Netmask

Gateway IP

WAN IP settings
WAN IP Addr

Local Netmask

Primary DNS

Secondary DNS

Note the embedded tags for the text boxes and the check boxes. This produces the web page:
13
PRELIMINARY
2.2.2.2
Command Line Usage
The cgiMain program also has command line switches available for use in scripts. This provides convenient access to
stored parameter data, and data updated via web pages. In fact, a web page can start a script as part of a CGI interface,
where the script executes command line versions of cgiMain within the script to perform various functions.
Note that the cache file takes precedence over the flash contents when executing scripts. This is to allow changes to be
made and executed on a temporary basis, and only kept if the desired configuration operates satisfactorily. If you want
to discard cache change, they either ALL have to be discarded, or specific parameters removed. See adding, deleting,
committing, and invalidating cache.
In order to avoid putting /usr/www/cgi-bin into the execution path, a soft link from /bin/cfg to
/usr/www/cgi-bin/cgiMain can be made. All following examples assume the system is configured in this manner. The
basic command line format is as follows:
#cfg [option] [option parameter]
2.2.2.2.1
Adding/modifying a variable in the cache file
To add a variable/value pair to the cache, use the following form:
#cfg –a VAR=VALUE
The variable name must not include spaces, and if the value includes spaces they must be “escaped” (\) or the
value enclosed in quotes (“val”).
2.2.2.2.2
Deleting (removing) a value from the cache file
To delete a variable/value pair from the cache, use the following form:
#cfg –r VAR
The variable name must not include spaces. If the variable does not exist, no error is generated, but no action is
preformed on the cache file. If you remove a variable from the cache file, but do not commit the cache, it will remain in
the permanent flash storage and will be defined upon next bootup.
2.2.2.2.3
Committing the cache file to flash
To commit the contents of the cache file to flash, use the following form:
#cfg –c
This copies the entire contents of the cache file to flash. These values will be preserved through boot and power cycles.
2.2.2.2.4
Invalidating the cache file
In order to invalidate the cache file (re-read it from flash), use the following form:
#cfg –i
This re-reads the contents of the flash and overwrites the cache file with the flash values. This effectively eliminates any
changes made to the cache file without saving them to flash. Use with caution.
2.2.2.2.5
Translating a file
In order to translate a tagged file into a file with values inserted, use the following form:
#cfg –t
This performs the translation as defined above. Note that the output is put to stdout, so it must be redirected to the
desired destination. The index argument on the option indicates the index value to use for variables with the “#” tag. An
example of usage:
#cfg –t2 /etc/wpa2/open_bss.ap > /tmp/sec2.cfg
This will translate the file /etc/wpa2/openbss.ap, inserting tags and using the value of “_2” as the substation for “#” tags,
and output the file to /tmp/sec2.cfg. The original file is not affected.
14
PRELIMINARY
2.2.2.2.6
Exporting variables
In order to use the variables in scripts, they need to be exported. The form for doing this is:
#cfg –e
This will output all variables in the form “export VAR=VALUE” for all variables in the cache. To use this in a script
file, you can put the following line in the script:
`cfg –e`
and all variable/value pairs will be in the environment for use.
2.2.2.2.7
Resetting to factory defaults
Resetting to factory defaults is a two step process. First, all current variables must be deleted. This is done by using the
–x option as in the following form:
#cfg -x
This deletes everything in cache and in flash. To reset the default values, execute the apcfg script to re-populate the
defaults. Note that this will be done by the apup script automatically:
#/etc/ath/apcfg
2.3
Environmental Variables
All configuration information is stored in the form of environmental variables that can be displayed by the “cfg –e”
command. Error! Reference source not found. outlines the various environmental variables, their default values (if
applicable), and their effects.
Table 2 AP Environmental Variable
Variable
Default
ATH_countrycode
Description
Identifies the specific regulatory table to use for the country of
interest. Used for testing regulatory compliance.
AP_IPADDR
192.168.1.2
AP_NETMASK
255.255.255.0
WAN_MODE
bridged
The IP address of the LAN interface; typically assigned to the bridge
interface, because the LAN is always included in the br0 bridge
interface with the ath interfaces.
Provides the netmask for the LAN/bridge interface; defines the
number of IP address that can be addressed on the local LAN
interface.
Indicates the mode for the WAN.
bridged
WAN_IPADDR
192.168.2.1
WAN_NETMASK
255.255.255.0
Indicates that the WAN interface is included on br0
static
Indicates that the WAN interface is to be given the IP
address specified by WAN_IPADDR
dhcp
Indicates that the WAN interface should get its IP
address from the network it is connected to
IP address for the WAN
Netmask
PRIDNS
Primary DNS server IP address
SECDNS
Secondary DNS server IP address
WLAN_ON_BOOT
Indicates that the WLAN should be activated as part of the rcS script
on bootup. Only valid with the default parameters specified in the
apcfg file. This will be more useful with future enhancements.
15
PRELIMINARY
AP_STARTMODE
standard
Mode for apup execution.
standard
Creates a single AP
rootap
Creates a single WDS mode AP
client
Creates a single WDS station instance.
repeater
multi
multivlan
dual
Creates a WDS repeater containing an AP and client
Creates a multiple VAP configuration
Puts each VAP on a desired VLAN interface
On platforms capable of dual concurrent operations set
VAP0 to 2.4 GHz on radio 0, and VAP1 to 5.0 GHz
band on radio 1
AP_RADIO_ID#
For dual concurrent devices, the radio ID (0 for the “lower” slot, and
1 for the “upper” slot) must be identified for each VAP. When dual
concurrent mode (as opposed to multi mode) is selected, the radio
ID of the first VAP (ath0) is set to 0 and the second VAP (ath1) is
set to 1. In the following entries the radio parameters with the _2
suffix refer to settings for Radio 1 (the “second” radio).
AP_MODE#
ap
For each VAP, the “mode” of the AP is required. The mode is used
to initialize the VAP. The following are the available modes:
AP_PRIMARY_CH
AP_PRIMARH_CH_2
40
AP_CHMODE
AP_CHMODE_2
11NGHT20
11NAHT40PLUS
ROOTAP_MAC
AP_VLAN#
ap
Infrastructure access point
sta
Simple station VAP (not normally used alone)
ap-wds
WDS (4 address frame) format interface that WDS
stations can connect to. See ROOTAP_MAC.
sta-wds
Client WDS interface that connects to an Infrastructure
WDS interface, creating a WDS bridge between the
two devices. Also see ROOTAP_MAC.
Indicates the specific
channel to set the AP to. Setting
g to a value of
“11ng”
g will cause the AP to scan for a free 11g
g ((2.4 GHz)) channel.
A value of “11na” will cause the AP to scan for a free 11a (5
( GHz)
channel,, and a value of “11ng”
g will scan for a free 11gg (2.4
( GHz))
channel. Note that the selected channel should match the extension
or MINUS) mode appropriate for the selected
channel (PLUS
channel/regulatory mode.
Specifies the channel operating mode. See Table 7 Channel
Operating Modes
and section 3.1.3 for details.
This is used for clients, and will set the preferred MAC address for
the repeater client to associate to. In WDS mode, this is provided to
the client device, and is the MAC address of the WDS VAP on the
root AP device.
For each VAP that is associated to a VLAN, this parameter
identifies the VLAN ID for the VAP.
16
PRELIMINARY
AP_BRNAME
When assigning a VLAN to a VAP, a bridge instance is created for
the VLAN. This identifies the “name” of the bridge.
TXQUEUELEN
1000
SHORTGI
SHORTGI_2
Enables the short gating interval.
AMPDUENABLE
AMPDUENABLE_2
Enables AMPDU aggregation; applies to all VAPs attached to the
radio.
AMPDUFRAMES
AMPDUFRAMES_2
32
Maximum number of frames to include in the aggregated frame.
Applies to all VAPs attached to the radio.
AMPDULIMIT
AMPDULIMIT_2
50000
Number of bytes for the maximum size of the AMPDU packet.
AMPDUMIN
AMPDUMIN_2
32768
Minimum number of bytes to include in an AMPDU frame.
CWMMODE
CWMMODE_2
RATECTL
auto
Provides the number of transmit descriptors to be allocated for the
ath object. These are shared for all VAPs
Setting for channel width management.
HT20 only
HT20/40
HT40 only
Specifies if rate control is to be controlled automatically through the
rate control module.
auto
manual
Automatic rate control
Manually set the rates and retry limits
MANRATE
0x8c8c8c8c
This 32 bit hex number encodes the 4 rate table entries that are tried
on the link. This if manual rate control is enabled.
MANRETRIES
0x04040404
Number of retries on each rate interval to attempt before changing.
Only applicable if manual rate control
RX_CHAINMASK
RX_CHAINMASK_2
5 for 3 chain device
3 for 2 chain device
Selects the chain mask to apply to the Receive path. The lowest 3
bits indicate the three antenna chains. This is for a “by 2”
configuration. This setting will override the setting in the EEPROM
of the device.
TX_CHAINMASK
TX_CHAINMASK_2
5 for 3 chain device
3 for 2 chain device
Selects the chain mask to apply to the Transmit path. The lowest 3
bits indicate the transmit chains to include. This is for a “2 by”
configuration. . This setting will override the setting in the
EEPROM of the device.
AP_SSID#
Atheros_Xspan_2G
Atheros_Xspan_5G
For the single VAP configurations, or the repeater case, only
AP_SSID is used. Default setting is as indicated.
For multiple VAP configurations, specifies the SSID for each VAP
instance (AP_SSID is VAP 1). If any of the variables are not
defined, the associated VAP will not be created. The AP_SSID_x
variables should be defined in order. If AP_SSID_2 is not defined,
AP_SSID_3 should not be defined. For example, if you are creating
3 VAPs, do not define AP_SSID_4. If you are only creating two
VAPs, do not define AP_SSID_3 and AP_SSID_4.
AP_SECMODE#
NONE
Selects the security mode for the indicated VAP. One of “WEP”,
“WPA”, “WSC”, or “NONE”
17
PRELIMINARY
AP_SECFILE#
Indicates which security configuration file to use for the VAP. See
section 2.1for a description of the configuration files.
AP_VLAN#
Used to configure VLAN tags for SSIDs AP_SSID, AP_SSID_2,
AP_SSID_3 and AP_SSID_4 respectively. To configure VLANs.
AP_STARTMODE should be set to multivlan. No default values
are assumed for these configuration items.
WEPKEY_1
WEPKEY_2
WEPKEY_3
WEPKEY_4
These are the 4 WEP keys that are defined in the first 4 slots. Note
that they are the same for ALL VAPs. The length of the key
indicates the strength of the cipher (10 hex digits or 4 characters for
64 bit, 26 hex digits or 13 characters for 128 bit). To indicate ASCII
entry, prepend “s:” to the string
AP_PRIKEY
Primary WEP key to use.
AP_WPA#
WPA mode. This indicates if WPA-1 or WPA-2 (or both) are to be
used in WPA operations.
AP_CYPHER#
Which pairwise ciphers to use for WPA operations. CCMP is AES
encryption where TKIP is WEP. Specifying both indicates auto
selection based on the client.
PSK_KEY#
A 9 to 64 bit value used for the PSK generation. This is an ASCII
value.
PSK_KEY_HEX#
A 9 to 64 bit value used for the PSK generation. This is an ASCII
value.
AP_AUTH_SVR#
IP address of the Radius server used for EAP authentication
methods.
AP_AUTH_PORT#
AP_AUTH_SECRET#
WSC_PIN
WSC_NAME
Port number on the Radius server used for EAP authentication login
Password for logging onto the EAP server for authentication.
In WSC mode, the PIN number used by the client to authenticate
with the WSC server.
Simple network name for the AP in WSC mode.
18
PRELIMINARY
2.4
Web Interface
The Atheros AP reference design includes a simplified web interface that can be used to configure the AP in various
modes. These pages provide both configuration and status information. All pages are processed using the cgiMain
program described in section 2.2. Each of these pages contains related information that can be used to configure the AP.
Note that default values are automatically provided to the web interface. These defaults are encoded in the
/etc/ath/apcfg file, and can be modified as required for a particular implementation
Each web page has the buttons:
Update
This button accepts the changes on the current page. If the current page is switched, the
updates are NOT saved, so click update if you want to save what you changed on the page.
Reboot
This button will reboot the AP. This performs a quick reboot, without closing any open files.
Use with care.
Commit
This button commits the parameters in the parameter cache (/tmp/.apcfg) to the flash area.
This saves the parameters through reboot cycles.
Start
This starts the AP using the /etc/ath/apup script. This script reads configuration information
from flash/cache, and applies the parameters using the sub-scripts described in the following
sections.
Stop
This brings the AP driver and hostapd software down using the /etc/ath/apdown script. This
performs a graceful shutdown of the AP.
In addition, the main network page includes a “factory reset” button that reapplies the parameters encoded in the
/etc/ath/apcfg file.
19
PRELIMINARY
2.4.1 Network Page
The network page is the default initial page, and provides for general network settings. The network page is shown in
Figure 3.
Figure 3 Network Configuration Page
The parameters on this page allow the user to set specific environmental variables with a “point and click” interface:
Table 3 Network Configuration: Page Parameters
Parameter
Env Var
Description
Bridge Mode
WAN_MODE
Selects the bridge mode. Bridged means that the WLAN, WAN, and LAN interfaces are all
bridged together, and use the Local IP Addr as the IP address of the device. DHCP means
that the WAN IP address will be set via DHCP. Static means that the WAN interface will use
the IP address and mask specified under WAN IP Settings
Startup Mode
AP_STARTMODE
Sets the startup mode that the scripts use to initialize the AP. The modes are described in the
parameter description for AP_STARTMODE
LocalIP addr
AP_IPADDR
This is the IP address used for bridged mode, or it’s the IP address on the LAN interface in
DHCP mode
Local Netmask
AP_NETMASK
Network mask for the LAN network.
Gateway IP
IPGW
IP address for the network gateway for Bridged mode, or the gateway on the WAN link for
DHCP mode.
WAN IP Addr
WAN_IPADDR
IP address for the WAN interface when static mode is used
WAN Netmask
WAN_NETMASK
Netmask of the WAN interface when static mode is used
Primary DNS
PRIDNS
Primary DNS server on the WAN interface
Secondary DNS
SECDNS
Secondary DNS server on the WAN interface
20
PRELIMINARY
2.4.2 Radio Configuration Page
This page includes the radio parameters for each radio on the AP. This example is for a dual concurrent AP, a single
radio AP would only show a single column. Note that indexed variables here are per Radio as opposed to per VAP.
Figure 4 Radio Configuration Page
Table 4 Radio Configuration: Page Parameters
Parameter
Env Var
Description
Channel
AP_PRIMARY_CH
AP_PRIMARY_CH_2
Indicates the channel selected for the AP. Invalid channels will cause the AP to fail on
startup.
Mode
AP_CHMODE
AP_CHMODE_2
Specifies the channel operating mode. See Table 7
Gating Index
SHORT_GI
SHORT_GI_2
Enables half period Gating Index. Disable forces full period gating index.
Aggregation
AMPDUENABLE
AMPDUENABLE_2
Enables/Disables aggregation for the radio
Agg Frames
AMPDUFRAMES
AMPDUFRAMES_2
Maximum number of frames to include in an aggregate.
Agg Size
AMPDULIMIT
AMPDULIMIT_2
Maximum size (in bytes) of an aggregate
Agg Min Size:
AMPDUMIN
AMPDUMIN_2
Minimum number of bytes to send as an aggregate
Channel Width
CWMMODE
CWMMODE_2
Channel Width Mode (PHY mode). 0 sets to static 20 MHz mode, 1 sets to dynamic 20/40
MHz mode, and 2 sets to static 40 MHz mode.
Tx Chainmask
TX_CHAINMASK
TX_CHAINMASK_2
Transmit chainmask. Selections vary between devices
Rx Chainmask
RX_CHAINMASK
RX_CHAINMASK_2
Receive chainmask. The number of receive chains to use (not necessarily antennas).
Selections vary between devices.
Channel Operating Modes
and section 3.1.3 for details
21
PRELIMINARY
2.4.3 Virtual AP (VAP) Configuration Page
For each VAP (1-4) its individual parameters can be configured through this page. Note that there are selections for
VAP 1-4 on the left panel. These parameters specify things like the ESSID string, which radio to use (for dual
concurrent platforms), VLAN information, initialization mode, and Security Modes.
In this document the various sections of the page are shown in two sections, because a readable screen shot of the entire
page was not possible. The web interface presents all parameters as a single page.
Figure 5 VAP Configuration Page (1 of 2)
Table 5 VAP Configuration: Page Parameters
Parameter
Env Var
Description
ESSID String
AP_SSID#
SSID String for the Virtual interface. For Client mode VAPs, this is the ESSID of the BSS to
join to. For AP’s, this is the SSID advertised in the beacon.
Radio
AP_RADIO_ID#
ID of the radio that this VAP is assigned to. Virtual interface to physical interface mapping.
VLAN ID
AP_VLAN#
If this VAP is to be included in a VLAN group, the VLAN ID number of the group
VLAN Bridge
AP_BRNAME
Name of the bridge that is used by this VLAN. Ethernet instances will be added to the bridge
for the VLAN
VAP Mode
AP_MODE#
Indicates the operating mode for the VAP. See table 1 for details
Root AP MAC
Address
ROOTAP_MAC#
Identifies the MAC address of the WDS root when creating a VAP for WDS Client mode.
22
PRELIMINARY
Figure 6 VAP Configuration Page (2 of 2)
23
PRELIMINARY
Table 6 VAP Configuration: Page Parameters
Parameter
Env Var
Description
Security Modes
AP_SECMODE#
Vertical set of radio buttons that select the security mode
Security Submodes
AP_SECFILE
Open
No Security
WEP
WEP Security (only 1 instance per radio allowed)
WPA
WPA (and WDS) security modes
For WPA Security Mode, the following sub modes are defined:
Personal Shared Key
User creates a passphrase for authentication. No outside server
required.
Enterprise/Radius
Security using 802.1x security modes requiring an authentication
server.
WiFi Protected Setup Security using new WPS standards. AP can be configured from
client.
WEP Mode
AP_WEP_MODE
Indicates the mode to operate the WEP security in: Open, Shared, or Auto (detect)
WEP Keys
WEPKEY_1
WEPKEY_2
WEPKEY_3
WEPKEY_4
WEP keys expressed as either 10, 26, or 52 digit Hex numbers, or after the s: marker, as 5,
13, or 26 character strings.
Primary Key
AP_PRIMARY_KEY
Indicates the key to use as the primary transmit key.
WPA Mode
AP_WPA#
Indicates the WPA modes to support: 802.1x (WEP),WPA (WPA-1), WPA2, or Auto
(detect either).
WPA Cypher
AP_CYPHER
Key policy, either TKIP or CCMP (AES). Auto indicates detect either
WPA Rekey Int
AP_WPA_GROUP_REKEY#
Interval for group rekey
WPA Master Rekey
AP_WPA_GMK_REKEY#
Master rekey interval
WEP Rekey Interval
AP_WEP_REKEY#
When WEP is used with 802.1x mode (not advised), this provides the rekey interval
PSK KEY
PSK_KEY
PSK value (8-64 characters) to use as a passphrase. String
RSN Preauth
AP_RSN_ENA_PREAUTH#
Enable RSN preauthorization between APs (for roaming)
RSN Interface
AP_WPA_PREAUTH_IF#
Interface to use for preauthorization (e.g. eth0)
EAP Reauth Period
AP_EAP_REAUTH_PER
When using a RADIUS server, the interval to reauthenticate with the server
Auth Server
AP_AUTH_SERVER#
IP address of the RADIUS server
Auth Port
AP_AUTH_PORT#
Port number that the RADIUS server is serving on.
Secret
AP_AUTH_SECRET#
Authentication password for communicating with the RADIUS server
AP PIN
WSC_PIN
PIN number for static PIN method of WPS setup
Device Name
WSC_NAME
Name of the device as advertised in PnP messages
Enrollee’s PIN
AP_ENROLLEE
PIN of the Enrollee when using the remote PIN method
StartPINMethod
Button that starts the remote PIN method for enrolling
Soft Push Button
Button that emulates the WPS pushbutton on the board.
24
PRELIMINARY
2.4.4 Status Page
This page shows the output of the command “iwconfig” with no parameters
Figure 7 AP Status Page
2.4.5 Channel Page
This page shows the output of the “wlanconfig athx list channel” command. See section 2.5.3 for details.
Figure 8 Channel Page
25
PRELIMINARY
2.4.6 Statistics
This shows the output of the “athstats” program.
Figure 9 Statistics Page
2.5
Command Line Interface
The command line interface consists of setting environmental variables using the configuration tool, and the following
scripts. The recommended approach is to set environmental variables and use the “apup” or “apdown” scripts to ensure
everything is configured correctly.
2.5.1 Shell Scripts
Several shell scripts are provided as examples, or as fully useable implementations. These scripts can be called from
other programs or CGI scripts to implement functionality in the user’s interface.
2.5.1.1
Initialization Scripts
Standard Linux operation requires an initialization script that is run upon bootup. This script, rcS, is kept in the standard
location /etc/rc.d/. All system function initialization scripts, such as network or other services are typically kept in this
directory. Therefore, four scripts have been defined; rcS, rc.bridge, rc.network, and rc.wlan. The rc.* scripts are
intended to be generic and not board specific. These scripts bring up the networking systems in a standard way on all
boards. The rcS script is specific for each board type, depending on its hardware configuration. Any unique modules or
other initialization is performed in this script, keeping the board unique items separate from the general purpose items.
The scripts are described in the following sections.
26
PRELIMINARY
2.5.1.1.1
rcS
Format:
# /etc/rc.d/rcS
This script is the bootup script. It will install any board specific modules, initialize the networking system and bridge,
and optionally bring up the WLAN with the default configuration. It calls the rc.network, rc.bridge, and optionally the
apup script. This script is never executed in any context other than initialization.
2.5.1.1.2
rc.network
Format:
/etc/rc.d/rc.network
This script initializes the main network interfaces on the device. This script requires that the WAN_MODE
environmental variable be set. The WAN_MODE variable controls whether the WAN interface is bridged to the LAN
interface, or if it operates on its own. If set to “static”, the WAN IP is set to the value defined in WAN_IPADDR. If set
to “DHCP”, the WAN address will run the UDHCPC client to obtain its IP address from the network. Finally, if set to
“bridged”, then the WAN is bridged with the LAN and WLAN interfaces.
2.5.1.1.3
rc.bridge
Format
# /etc/rc.d/rc.bridge
The rc.bridge script will setup the bridging function on the device. It is assumed that the LAN interface is always
bridged with the WLAN interfaces, so this interface is always included in the bridge. If the WAN_MODE is set to
“bridged”, then the WAN will also be included in the bridge.
The LAN_DHCP variable indicates whether the DHCP server should be started on the bridge. If set to “y”, then the
UDHCPD daemon is started. The configuration file for the DHCP server is located at /etc/udhcpd.conf.
2.5.1.1.4
rc.wlan
Format:
# /etc/rc.d/rc.wlan up|down
The WLAN modules are initialized or removed using this script. The argument “up” or “down” indicate whether to
install or remove the WLAN driver modules from the system. This script is called by the makeVAP script when it
determines that the ath_pci module is not loaded, and is called by the killVAP script when all VAPs are removed. It is
also called, indirectly, when the reboot command is issued (the inittab will cause the killVAP all command to be
executed on shutdown).
This script does not actually create any VAPs. It simply loads the modules and gets the system ready for VAP creation.
There are no environmental variables that currently are used to configure this script.
2.5.1.2
Driver Operation Scripts
To operate the driver (for example, to create interfaces), three main scripts are provided. These scripts perform the
creation of VAP objects, activation of VAP objects, and destruction of VAP objects. The creation and activation stages
for VAP objects were separated due to the need to create ALL VAP objects before activating ANY VAP objects. This is
required because multiple VAPs will still share the same HAL and ATH driver object. All RF parameters applied to the
VAPS will apply to the single ATH object, so they only need to be set in a single VAP.
27
PRELIMINARY
2.5.1.2.1
makeVAP
Format:
/etc/ath/makieVAP VAP_type SSID IFStr Beacon_Int
VAP_type
SSID
IFstr
Beacon Int
ap
Standard access point
ap-wds
WDS root access point
sta
Standard Client Mode
sta-wds WDS mode client station
ESSID string for the access point
Interface configuration string of the form
interface:RF:PriCh:ModeStr
Beacon interval, in milliseconds
This script will create and configure a VAP for the indicated mode VAP_type can be set to AP or station.
Adding the –wds suffix to the VAP type indicates that the VAP is operating in WDS mode. This script
requires that the SSID be specified on the command line – the default is not used. The interface string (IFstr)
was added to support configuration of multiple physical interfaces on the same system. This string has the
form Iface:RF:PriCH:MODE, where Iface is the interface number (0 for WiFi0, 1 for WiFi1), RF indicates
that the RF parameters are to be sent to the VAP to configure the base ATH device, PriCH is the Primary
channel for the operation of the interface, and MODE is the mode name defined in the following table. RF
configuration should only be done on one VAP for a particular interface, since RF parameters apply to any
and all VAPs that are associated with the physical WiFi device. Finally, for multiple BSS configurations the
Beacon Interval can be specified to spread out beacon transmits.
Table 7 Channel Operating Modes
Name
Description
11A
Standard Legacy OFDM rates in 5 GHz band
11B
Standard Legacy DSSS rates in 2.4 GHz band
11G
Standard Legacy rates in 2.4 GHz band
11NAHT20
11n rates limited to HT20 MCS rates in 5 GHz band
11NGHT20
11n rates limited to HT20 MCS rates in 2.4 GHz band
11NAHT40PLUS
11n rates up to HT40 MCS rates, using upper extension channel, 5 GHz band
11NAHT40MINUS
11n rates up to HT40 MCS rates, using lower extension channel, 5 GHz band
11NGHT40PLUS
SԘ
11n rates up to HT40 MCS rates, using upper extension channel, 2.4 GHz band
ķ
11NGHT40MINUS
11n rates up to HT40 MCS rates, using lower extension channel, 2.4 GHz band
An example setup for a dual concurrent configuration would have two makeVAP calls:
# makeVAP ap AP24G 0:RF:8:11NGHT20
# makeVAP ap AP50G 1:RF:52:11NAHT40PLUS
# makeVAP ap AP50Gsec 1:::
This example does the following:
Creates an AP VAP with ESSID of AP24G on interface 0, configures the RF
to channel 8 in static HT20 mode
Creates an AP VAP on interface1, configures the RF to channel 52 with
extension channel on the high end.
Creates a second AP VAP with ESSID of AP50Gsec on interface 1, and
does not configure the RF. This will be on channel 52, since the previous
VAP configured the RF parameters for the physical interface.
The makeVAP script DOES NOT bring the VAP up, or set the security mode. The reason for splitting the
script into a make and activate section is that all VAPs must be created before activating any of them, since
they all share the same ATH device. This constraint is written into the apup script.
Ԙ
For 2.4 GHz, HT40 mode must not be set up in an out-of-the-box configuration to meet Wi-Fi certification requirements.
HT40 mode can be user-configurable.
28
PRELIMINARY
2.5.1.2.2
activateVAP
/etc/ath/activateVAP VAP_id BRG_id SECmode SECparam
VAP_id
The specific VAP, as in ath0, ath1, etc.
BRG_id
The bridge to add the VAP to, as in br0. Specifying “-“ will
keep the VAP from being added to any bridge.
SECmode
Security mode. One of WPA, WEP, WSC, or NONE.
blank for the default mode of NONE
SECparam
Parameter for the security mode. Typically the file containing
the parameters for the selected security mode.
This can be left
This script activates the VAP by calling “ifconfig vap_id up”, and properly configures the selected security
mode. If the VAP is a station mode VAP, the station scan module will be loaded and activated. All VAPs
must be created prior to calling activateVAP on any VAP. Once this script is executed, VAP
configuration is subject to the restrictions as specified in section 0. For details on security modes and
configuration files, see section 3.2.
2.5.1.2.3
killVAP
/etc/ath/killVAP VAP_id
VAP_id
The specific VAP to remove, or “all” to remove all
This script will deconfigure and remove the specified VAP. Optionally, if “all” is specified as the VAP_id, all
VAPs are removed, and all driver modules are unloaded. This is how the apdown script is now implemented.
This script will remove the indicated VAP(s), and remove the associated instances of hostapd,
wpa_supplicant, or wsc. This script does not rely on any environmental variables.
2.5.1.3
Compatibility Scripts
Two scripts have been kept from earlier system operations, apup and apdown. These were kept to allow for backward
compatibility with existing test automation systems existing at Atheros, and possible at customer locations. The
internals have changed significantly, however. Each script should be used with the concept of 1) setting all required
environmental variables, and 2) executing the script.
2.5.1.3.1
apup
Format:
/etc/ath/apup
This is the main script for bringing up various AP configurations that is compatible with the previous methods
for configuring the AP. This script is now completely parameterized, AND SHOULD NOT BE MODIFIED.
Again, the concept of setting environmental variables, then executing this script, is the designed mode of
operation.
The main environmental variable that affects the operation of this script is AP_STARTMODE. This can be
set to standard, repeater, rootap, client, multi or multivlan. The default value is “standard”, which is a single
standard AP instance. See the configuration descriptions in section 3 for the various uses of the
AP_STARTMODE variable.
2.5.1.3.2
apdown
Format:
/etc/ath/apdown
This script is simply a remapping of “killVAP all”. This will remove all VAPs, and unload all driver
modules.
29
PRELIMINARY
2.5.2 Wireless Tools
The Wireless Tools interface is the primary interface used in Linux for configuring and operating the WLAN interface.
The tools themselves are open source, and require specific support through the ioctl interface for the driver. The Atheros
WLAN driver supports these tools “out of the box” without modification. Any version of Wireless tools after version 28
can be used with the Atheros WLAN driver system.
The Wireless Tools use device names to determine which device to configure. In the Atheros driver, there are two
device types that are created when the AP is brought up. The Radio layer, also known as the ATH/HAL layer, is
instantiated as a “wifiN” device, where N is the specific instance starting with zero. The first radio instance, for
example, would be called wifi0. The protocol, or 802.11 layer, will be instantiated as an “athN” device. These devices
are also known as Virtual Access Points, or VAPs. There can be multiple VAPs associated with a single radio, but only
one radio associated with any particular VAP (one to many relationship), as described in the top level architecture. Each
layer controls specific aspects of the operation of the system, so there are specific commands that apply to each
The two main programs of the Wireless tools suite are iwconfig and iwpriv. These commands are used to get or change
specific configuration or operating parameters of the system. Many commands will only be effective before the AP
interface is in the “up” state, so these commands must be performed prior to issuing the “ifconfig up” command to the
interface. The following sections define the valid parameters and commands for each command. Note that the Radio
layer does not support the iwconfig command – this is used exclusively in the protocol layer. Also note that any ifconfig
commands used on the access point must be applied to the protocol layer (ath) device – they have no effect on the Radio
layer.
2.5.2.1
iwconfig
The iwconfig commands are a fixed set of commands that are used to set up and operate the WLAN interface. They are
used in much the same way as ifconfig commands, but are specific to 802.11 device operations. As such, they will
interface to the particular VAP interface. Note that the Radio Layer does not support iwconfig.
ap
#iwconfig athN ap MAC
Selects the specific AP for a client to associate with; used only for WDS client modes in the AP environment.
The only valid argument is the MAC address of the desired AP. The help text will also indicate “off” and
“auto” as choices, but these have no effect other than to disable the selection of a specific MAC address. This is
disabled by default.
#iwconfig ath0 00:03:7f:01:23:45
essid
#iwconfig athN essid “Name of Network”
Sets the name of the BSS as it is provided in the beacon message. While there is no official definition of
“ESSID” in the 802.11 specification, this is the commonly used term for BSS network name in the Linux
environment. The network name can be up to 32 characters in length, and can contain spaces. When running in
AP mode, this is the name of the network as advertised in the beacon message. In STA mode, this is the
network name that the STA will associate with. The name can be quoted (“”) or not, but must be quoted when
including spaces. The ESSID is blank by default. The provided scripts will set the ESSID to
Atheros_Xspan_2G for the first interface, and Atheros_Xspan_5G for the second interface in a dual
concurrent configuration.
#iwconfig ath0 essid AP50_Test
frag
#iwconfig athN frag level
This sets the fragmentation threshold, which is the maximum fragment size. Note that this is not valid for 11n
aggregation operations. The argument level indicates the maximum fragment size, or setting to off disables
fragmentation. Fragmentation is off by default.
#iwconfig ath0 frag 512
30
PRELIMINARY
channel
#iwconfig athN args
Selects the channel for operations. In AP mode, this is the channel that the AP will operate in. For STA
operations, the station will associate to the appropriate AP based on the MAC address setting and the ESSID, so
channel is not important in that mode.
The channel argument will only take channel number. See the freq command for setting the specific frequency.
If an invalid channel is selected, this command will return with an error status. The VAP for this interface
should be destroyed at this point, as it will not be properly configured with a channel. There is no default value.
The provided scripts will bring up the first interface on channel 6 by default, and the second on channel 40 by
default (for dual concurrent operations).
#iwconfig ath0 channel 11
freq
#iwconfig athN freq frequency
Similar to the channel command, this will select the frequency of operation. Note that the frequency value must
be a valid frequency supported by the regulatory requirements table for the device. This command will take
both channel numbers and frequency values. For frequency values, the suffix K, M, or G can be appended to
the value to specify KHz, MHz, or GHz. The values of 2.412G, 2412M, and 2412000000K are all the same
value.
This command will also return an error if the indicated frequency is invalid for the device. The VAP for this
interface should be destroyed at this point, as it will not be properly configured with an operating frequency.
There is no default frequency value.
#iwconfig ath0 freq 5.2G
#iwconfig ath0 freq 40
rate
#iwconfig athN rate rateval|auto
Selects a fixed rate for transmit, or enables the internal rate control logic. When rateval is provided, it specifies
the bit rate desired. Using the M or k suffix can be used to indicate the rate, such as 36M. Specifying auto
instead of a fixed rate will enable the rate control logic internal to the driver. This is the default configuration.
Setting 11n fixed rates is a bit more complicated, and is accomplished using the iwpriv commands
Set11NRates and Set11NRetries. Selecting MCS rates cannot be accomplished through this command.
#iwconfig ath0 rate 54M
retry
Software retry is not supported
rts
#iwconfig athN rts pkt_size
Sets the minimum packet size for which RTS/CTS protection is used. This setting is used to reduce the amount
of arbitration that occurs with short packet transmission, improving throughput. The value of pkt_size is set to
the minimum packet size for which to use the RTS/CTS handshake. Setting pkt_size to a value of 0 disables
RTS/CTS handshake entirely. The use of RTS/CTS in 11n is governed by rate tables and other settings, so this
command may not have the desired effect when using 11n rates.
#iwconfig ath0 rts 64
sens
Receiver sensitivity control is not supported in this driver
31
PRELIMINARY
txpower
#iwconfig athN txpower power_setting
This command will set the transmit power for all packets on the device. This power is limited by the regulatory
limits encoded into the driver, and selected by setting the country code (see iwpriv command setCountry). The
value of power_setting is provided in units of dBm. Setting the power_setting value to off will enable the
internal power control logic for setting power level. Default Tx power levels are dependant on the information
in the selected regulatory table.
#iwconfig ath0 txpower 30
enc
key
#iwconfig athN key [index] key_value
The commands enc and key are synonyms for the same command to set and manage WEP keys. The hardware
will support up to four WEP keys per radio module. The optional index value indicates which key is being
set/activated. The index value can be from 1 to 4.
The key_value parameter can be specified in either hex mode or as an ASCII string. Key values can be
specified for either WEP 64 (40) bit mode, requiring 5 bytes, or WEP 128 (108) bit mode, requiring 13 bytes.
In hexadecimal mode this comes out to 10 or 26 hex digits, respectively. Hex digits are separated in groups of 4
by hyphens. When specifying ASCII keys, the keys will require 5 or 13 characters, respectively. All ASCII
key strings are preceded by the s: indicator.
To turn WEP off, use the off command without index. WEP is automatically turned on when a key is specified.
Specifying a key index without a key value will select that key as the active key.
#iwconfig ath0 key [2] DEAD_BEEF_EA
#iwconfig ath0 key [1] s:AnASCIIkeyVal
#iwconfig ath0 key off
2.5.2.2
iwpriv
The following section defines all of the iwpriv commands available for each layer. Note that there are some duplicate
commands between the layers. It is recommended to use the radio layer commands over the protocol layer command
(wifiN commands over athN commands) when duplication exists.
32
PRELIMINARY
2.5.2.3
Radio Layer
The radio layer commands are provided to configure the radio layer for ALL VAPs attached to the radio.
Common parameters for the radio include the frequency (channel), the channel width mode (HT 20/40), and
other parameters that apply to radio operations. Note that ALL VAPS attached to the specific radio are
affected by the configurations made to the radio layer.
6MBAck
#iwpriv wifiN 6MBAck 1|0
This command will enable (1) or disable (0) the use of the 6 MB/s (OFDM) data rate for ACK frames. If
disabled, ACK frames will be sent at the CCK rate. The default value is 0. The command has a corresponding
get command to return the current value.
#iwpriv wifi0 6MBAck 1
#iwpriv wifi0 Get6MBAck
wifi0
Get6MBAck:1
AddSWBbo
SWBcnRespT
DMABcnRespT
#iwpriv wifiN SWBcnRespT Response Time
#iwpriv wifiN DMABcnRespT Response Time
#iwpriv wifiN AddSWBb0 Response Time
These settings are used to adjust the calculation of the ready time for the QoS queues. This is used to adjust the
performance of the QoS queues for optimal timing. The parameter Software Beacon Response Time represents
the time, in microseconds, required to process beacons in software. The DMA Beacon Response Time is the
time required to transfer the beacon message from Memory into the MAC queue. Finally, the Additional
Software Beacon Backoff is a “fudge factor” used for final adjustment of the ready time offset.
These parameters are used for experimental adjustment of queue performance. In the AP application they are
not relevant, so they should not be modified. Their default value is zero. Each parameter has a corresponding
get command.
#iwpriv wifi0 SWBcnRespT 1
#iwpriv wifi0 DMABcnRespT 2
#iwpriv wifi0 AddSWBbo 10
#iwpriv wifi0 GetSWBcnRespT
wifi0
GetSWBcnRespT:1
#iwpriv wifi0 GetDMABcnRespT
wifi0
GetDMABcnRespT:2
#iwpriv wifi0 GetAddSWBbo
wifi0
GetAddSWBbo:10
33
PRELIMINARY
AggrProt
AggrProtDur
AggrProtMax
#iwpriv wifiN AggrProt 1|0
#iwpriv wifiN AggrProtDur duration
#iwpriv wifiN AggrProtMax size
These are used to enable RTS/CTS protection on aggregate frames, and control the size of the frames receiving
RTS/CTS protection. These are typically used as a test commands to set a specific condition in the driver. The
AggrProt command is used to enable (1) or disable (0) this function. Default is disabled. The AggrProtDur
setting indicates the amount of time to add to the duration of the CTS period to allow for additional packet
bursts before a new RTS/CTS is required. Default is 8192 microseconds. The AggrProtMax command is used
to indicate the largest aggregate size to receive RTS/CTS protection. The default is 8192 bytes. These
commands have associated get commands.
#iwpriv
#iwpriv
#iwpriv
#iwpriv
wifi0
#iwpriv
wifi0
#iwpriv
wifi0
wifi0 AggrProt 1
wifi0 AggrProtDuration 8192
wifi0 AggrProtMax 8192
wifi0 getAggrProt
getAggrProt:1
wifi0 getAggrProtDur
getAggrProtDur:8192
wifi0 getAggrProtMax
getAggrProtMax:8192
AMPDU
#iwpriv wifiN AMPDU 1|0
This is used to enable/disable transmit AMPDU aggregation for the entire interface. Receiving of aggregate
frames will still be performed, but no aggregate frames will be transmitted if this is disabled. This has a
corresponding get command, and the default value is 1 (enabled).
#iwpriv wifi0 AMPDU 1
#iwpriv wifi0 getAMPDU
wifi0
getAMPDU:1
AMPDUFrames
#iwpriv wifiN AMPDUFrames numFrames
This command will set the maximum number of subframes to place into an AMPDU aggregate frame. Frames
are added to an aggregate until either a) the transmit duration is exceeded, b) the number of subframes is
exceeded, c) the maximum number of bytes is exceeded, or d) the corresponding queue is empty. The subframe
that causes the excess conditions will not be included in the aggregate frame, but will be queued up to be
transmitted with the next aggregate frame.
The default value is 32. This command has a corresponding get command.
#iwpriv wifi0 AMPDUFrames 24
#iwpriv wifi0 getAMPDUFrames
wifi0
getAMPDUFrames:24
AMPDULim
#iwpriv wifiN AMPDULim Byte Limit
This parameter will limit the number of bytes included in an AMPDU aggregate frame. Frames are added to an
aggregate until either a) the transmit duration is exceeded, b) the number of subframes is exceeded, c) the
maximum number of bytes is exceeded, or d) the corresponding queue is empty. The subframe that causes the
excess conditions will not be included in the aggregate frame, but will be queued up to be transmitted with the
next aggregate frame.
The default value of this parameter is 50000. This command has a corresponding get command.
#iwpriv wifi0 AMPDULim 48000
#iwpriv wifi0 getAMPDULim
wifi0
getAMPDULim:48000
34
PRELIMINARY
ANIEna
#iwpriv wifiN ANIEna 0|1
This parameter enables the Automatic Noise Immunity (ANI) processing in both the driver and the baseband
unit. ANI is used to mitigate unpredictable noise spurs in receive channels that are due to the host system that
the device is installed in. This feature was added for CardBus and PCIE devices sold in the retail market that
were not pre-installed in host systems. Most AP implementations will not enable ANI, preferring to limit noise
spurs by design.
#iwpriv wifi0 ANIEna 1
#iwpriv wifi0 GetANIEna
wifi0
GetANIEna:1
AntSwap
DivtyCtl
#iwpriv wifiN AntSwap 1|0
#iwpriv wifiN DivtyCtl AntSel
These commands are used to control antenna switching behavior. For 11n devices, these control which chains
are used for transmit. For Legacy devices, these are used to determine if diversity switching is enabled or
disabled. The AntSwap command is used to indicate when antenna A and B are swapped from the usual
configuration. This will cause Antenna “A” to be used by chain 1 or 2, and Antenna “B” will be used by chain
0. The default is 0, which indicates antennas are not swapped (Antenna “A” to chain 0, Antenna “B” to chain
1,2). The Diversity Control command will enable/disable antenna switching altogether. If Diversity control is
set to Antenna “A” (1) or Antenna “B” (2), the transmitting antenna will not change based on receive signal
strength. If Diversity Control is set to “Variable” (0), then the transmitting antenna will be selected based on
received signal strength. Both commands have associated get commands.
#iwpriv wifi0 AntSwap 1
#iwpriv wifi0 DivtyCtl 2
#iwpriv wifi0 GetAntSwap
wifi0
GetAntSwap:0
#iwpriv wifi0 GetDivtyCtl
wifi0
GetDivtyCtl:0
BcnNoReset
#iwpriv wifiN BcnNoReset 1|0
This controls a debug flag that will either reset the chip or not when a stuck beacon is detected. If enabled (1),
the system will NOT reset the chip upon detecting a stuck beacon, but will dump several registers to the
console. Additional debug messages will be output if enabled, also. The default value is 0. This command has
a corresponding get command.
#iwpriv wifi0 BcnNoReset 1
#iwpriv wifi0 GetBcnNoReset
wifi0
GetBcnNoReset:1
CABlevel
#iwpriv wifiN CABlevel % Multicast
This will set the amount of space that can be used by Multicast traffic in the Content After Beacon (CAB)
queue. CAB frames are also called Beacon Gated Traffic frames, and are sent attached to every beacon. In
certain situations, there may be such a large amount of multicast traffic being transmitted that there is no time
left to send management or Best Effort (BE) traffic. TCP traffic gets starved out in these situations. This
parameter controls how much of the CAB queue can be used by Multicast traffic, freeing the remainder for BE
traffic. The default value of this parameter is 80 (80% Multicast), and the command has a corresponding get
command
#iwpriv wifi0 CABlevel 50
#iwpriv wifi0 getCABlevel
wifi0
getCABlevel:50
35
PRELIMINARY
CCKTrgLow
CCKTrgHi
#iwpriv wifiN CCKTrgLow Low Threshold
#iwpriv wifiN CCKTrgHi High Threshold
These commands control the CCK PHY Error/sec threshold settings for the ANI immunity levels. A PHY error
rate below the low trigger will cause the ANI algorithm to lower immunity thresholds, and a PHY error rate
exceeding the high threshold will cause immunity thresholds to be increased. When a limit is exceed, the ANI
algorithm will modify one of several baseband settings to either increase or decrease sensitivity. Thresholds are
increased/decreased in the following order:
Increase:
raise Noise Immunity level to MAX from 0, if Spur Immunity level is at MAX;
raise Noise Immunity level to next level from non-zero value;
raise Spur Immunity Level;
(if using CCK rates) raise CCK weak signal threshold + raise FIR Step level;
Disable ANI PHY Err processing to reduce CPU load
Decrease:
lower Noise Immunity level;
lower FIR step level;
lower CCK weak signal threshold;
lower Spur Immunity level;
The default values for these settings are 200 errors/sec for the high threshold, and 100 errors/sec for the low
threshold.
Each of these commands has a corresponding get command.
#iwpriv wifi0 CCKTrgLow 80
#iwpriv wifi0 CCKTrgHi 220
#iwpriv wifi0 GetCCKTrgLow
wifi0
GetCCKTrgLow:100
#iwpriv wifi0 GetCCKTrgHi
wifi0
GetCCKTrgHi:200
CCKWeakThr
#iwpriv wifiN CCKWeakThr 1|0
This command will select either normal (0) or weak (1) CCK signal detection thresholds in the baseband. This
is used to toggle between a more sensitive threshold and a less sensitive one, as part of the Adaptive Noise
Immunity (ANI) algorithm. The actual settings are set at the factory, and are stored in EEPROM. If ANI is
enabled, this parameter may be changed independent of operator setting, so this command may be overridden
during operation.
The default value for this parameter is 0. This command has a corresponding Get command.
#iwpriv wifi0 CCKWeakThr 1
#iwpriv wifi0 GetCCKWeakThr
wifi0
GetCCKWeakThr:1
chainmasksel
#iwpriv wifiN chainmasksel 1|0
This command enables (1) automatic chainmask selection. This feature allows the system to select between 2
and 3 transmit chains, depending on the signal quality on the channel. For stations that are distant, using 3
chain transmit allows for better range performance. The default value of this parameter is 0 (disabled). This
command has a corresponding get command.
#iwpriv wifi0 chainmasksel 1
#iwpriv wifi0 get_chainmasksel
wifi0
get_chainmasksel:0
36
PRELIMINARY
CWMIgnExCCA
#iwpriv wifiN CWMIgnExCCA 1|0
This command allows the system to ignore the clear channel assessment (CCA) on the extension channel for
11n devices operating in HT 40 mode. Normally, to transmit, the device will require no energy detected on
both the control and extension channels for a minimum of a PIFS duration. This control will allow for ignoring
energy on the extension channel. This is not in conformance with the latest draft of the 802.11n specifications,
and should only be used in a test mode. The default value for this parameter is 0 (do NOT ignore extension
channel CCA). This command has a corresponding get command.
#iwpriv wifi0 CWMIgnExCCA 1
#iwpriv wifi0 GetCWMIgnExCCA
wifi0
GetCWMIgnExCCA:0
FIRStepLvl
#iwpriv wifiN FIRStepLvl level
This command will adjust the FIR filter parameter that determines when a signal is in band for weak signal
detection. Raising this level reduces the likelihood of adjacent channel interferers causing a large number of
(low RSSI) PHY errors, lowering the level allows easier weak signal detection for extended range. This
parameter is also modified by the ANI algorithm, so this may be change dynamically during operation, usually
in steps of single units. The default value for this parameter is 0. The command has a corresponding Get
command, but this returns the initialization (starting) value, and not the value that is currently in the operating
registers.
#iwpriv wifi0 FIRStepLvl 1
#iwpriv wifi0 GetFIRStepLvl
wifi0
GetFIRStepLvl:0
ForceBias
ForBiasAuto
#iwpriv wifiN ForBiasAuto 1|0
#iwpriv wifiN ForceBias Bias
This command activates the “force bias” feature. This is used as a workaround to a directional sensitivity issue
in the AR5133 PHY chip in 2.4 GHz bands. ForBiasAuto will automatically select the bias level depending on
the selected frequency. ForceBias will set the bias to a value between 0 and 7. These commands are only
available when the driver is compiled with the #define ATH_FORCE_BIAS parameter defined. Even when this
switch is enabled, the default values for both parameters are 0 (disabled). This should only be enabled if the
sensitivity issue is actually present.
The command has corresponding Get commands
#iwpriv wifi0 ForBiasAuto 1
#iwpriv wifi0 ForceBias 2
#iwpriv wifi0 GetForBiasAuto
wifi0
GetForBiasAuto:0
#iwpriv wifi0 GetForceBias
wifi0
GetForceBias:1
37
PRELIMINARY
HALDbg
#iwpriv wifiN HALDbg debug level
Used to set the debug level in the HAL code. This can be modified “on the fly” as required. The HAL must be
built with the AH_DEBUG parameter defined for this command to be available; otherwise it is conditionally
compiled out. The value provided is a bitmask selecting specific categories of debug information to select
from. Note that some categories will produce copious amounts of output, and should be used sparingly for a
few seconds.
Table 8 HAL Debug Flags
Symbolic Name
Enable Bit
Description
HAL_DBG_RESET
0x00000001
Information pertaining to reset processing and initialization
HAL_DBG_PHY_IO
0x00000002
PHY read/write states
HAL_DBG_REG_IO
0x00000004
Register I/O, including all register values. Use with caution
HAL_DBG_RF_PARAM
0x00000008
RF Parameter information, and table settings.
HAL_DBG_QUEUE
0x00000010
Queue management for WMM support
HAL_DBG_EEPROM_DUMP
0x00000020
Large dump of EEPROM information. System must be compiled with the EEPROM_DUMP
conditional variable defined
HAL_DBG_EEPROM
0x00000040
EEPROM read/write and status information
HAL_DBG_NF_CAL
0x00000080
Noise Floor calibration debug information
HAL_DBG_CALIBRATE
0x00000100
All other calibration debug information
HAL_DBG_CHANNEL
0x00000200
Channel selection and channel settings
HAL_DBG_INTERRUPT
0x00000400
Interrupt processing. WARNING: this produces a LOT of output, use in short bursts.
HAL_DBG_DFS
0x00000800
DFS settings
HAL_DBG_DMA
0x00001000
DMA debug information
HAL_DBG_REGULATORY
0x00002000
Regulatory table settings and selection
HAL_DBG_TX
0x00004000
Transmit path information
HAL_DBG_TXDESC
0x00008000
Transmit descriptor processing
HAL_DBG_RX
0x00010000
Receive path information
HAL_DBG_RXDESC
0x00020000
Receive descriptor processing
HAL_DBG_ANI
0x00040000
Debug information for Automatic Noise Immunity (ANI)
HAL_DBG_BEACON
0x00080000
Beacon processing and setup information
HAL_DBG_KEYCACHE
0x00100000
Encryption Key management
HAL_DBG_POWER_MGMT
0x00200000
Power and Tx Power level management
HAL_DBG_MALLOC
0x00400000
Memory allocation
HAL_DBG_FORCE_BIAS
0x00800000
Force Bias related processing
HAL_DBG_POWER_OVERRIDE
0x01000000
TX Power Override processing
HAL_DBG_UNMASKABLE
0xFFFFFFFF
Will be printed in all cases if AH_DEBUG is defined.
This command has a corresponding get command. Its default value is 0 (no debugging on), but this does not
disable the “Unmaskable” prints.
#iwpriv wifi0 HALDbg 0x84c03
#iwpriv wifi0 getHALDbg
wifi0
getHALDbg:50
38
PRELIMINARY
HTEna
#iwpriv wifiN HTEna 1|0
This command is used to enable (1) or disable (0) 11N (HT) data rates. This is normally only used as a test
command. The parameter is set to 1 (enabled) by default. The command has a corresponding Get command.
#iwpriv wifi0 HTEna 1
#iwpriv wifi0 GetHTEna
wifi0
GetHTEna:1
NoiseImmLvl
#iwpriv wifiN NoiseImmLvl level
This will select a specific noise immunity level parameter during initialization. This command only has effect
prior to creating a specific HAL instance, and should be done only during system initialization. Each noise
immunity level corresponds to a specific set of baseband parameters used to adjust the sensitivity of the
baseband receiver. The values are set at the factory, and are selected as a “set” by this parameter.
This level is also controlled by the ANI algorithm, so that the initial immunity level will be modified during
operation to select the optimal level for current conditions. The default value for this parameter is 4, and should
not be changed unless there is a specific reason. The command has a corresponding get command.
#iwpriv wifi0 NoiseImmLvl 3
#iwpriv wifi0 GetNoiseImmLvl
wifi0
GetNoiseImmLvl:4
OFDMTrgLow
OFDMTrgHi
#iwpriv wifiN OFDMTrgLow Low Threshold
#iwpriv wifiN OFDMTrgHi High Threshold
These commands control the OFDM PHY Error/sec threshold settings for the ANI immunity levels. A PHY
error rate below the low trigger will cause the ANI algorithm to lower immunity thresholds, and a PHY error
rate exceeding the high threshold will cause immunity thresholds to be increased. When a limit is exceed, the
ANI algorithm will modify one of several baseband settings to either increase or decrease sensitivity.
Thresholds are increased/decreased in the following order:
Increase:
raise Noise Immunity level to MAX from 0, if Spur Immunity level is at MAX;
raise Noise Immunity level to next level from non-zero value;
raise Spur Immunity Level;
(if using CCK rates) raise CCK weak signal threshold + raise FIR Step level;
Disable ANI PHY Err processing to reduce CPU load
Decrease:
OFDM weak signal detection on + increased Spur Immunity to 1;
lower Noise Immunity level;
lower FIR step level;
lower CCK weak signal threshold;
lower Spur Immunity level;
OFDM weak signal detection on, with the existing Spur Immunity level 0
The default values for these settings are 500 errors/sec for the high threshold, and 200 errors/sec for the low
threshold.
Each of these commands has a corresponding get command.
#iwpriv wifi0 OFDMTrgLow 100
#iwpriv wifi0 OFDMTrgHi 550
#iwpriv wifi0 GetOFDMTrgLow
wifi0
GetOFDMTrgLow:200
#iwpriv wifi0 GetOFDMTrgHi
wifi0
GetOFDMTrgHi:500
39
PRELIMINARY
OFDMWeakDet
#iwpriv wifiN OFDMWeakDet 1|0
This command will select normal (0) or weak (1) OFDM signal detection thresholds in the baseband register.
The actual thresholds are factory set, and are loaded in the EEPROM. This parameter corresponds to the
initialization value for the ANI algorithm, and is only valid prior to system startup. The default value for this
parameter is 1 (detect weak signals). The corresponding Get command will return the initialization value only.
#iwpriv wifi0 OFDMWeakDet 0
#iwpriv wifi0 GetOFDMWeakDet
wifi0
GetOFDMWeakDet:1
RSSIThrLow
RSSIThrHi
#iwpriv wifiN RSSIThrLow far threshold
#iwpriv wifiN RSSIThrHi near threshold
These settings are used to determine the relative distance of the AP from the station. This is used to determine
how the ANI immunity levels are selected. If the average beacon RSSI of beacons from the AP is greater than
RSSIThrHi, then the STA is determined to be at close-range. If the average beacon RSSI of beacons from the
AP is less than RSSIThrHi, but greater than RSSIThrLow, then the STA is determined to be at mid-range. If the
average beacon RSSI of beacons from the AP is less than RSSIThrLow, then the STA is determined to be at
long-range. The default values 40 for the high (near) threshold and 7 for the low (far) threshold. This
command has corresponding Get commands
#iwpriv
#iwpriv
#iwpriv
wifi0
#iwpriv
wifi0
wifi0 RSSIThrLow 6
wifi0 RSSIThrHi 45
wifi0 GetRSSIThrLow
GetRSSIThrLow:7
wifi0 GetRSSIThrHi
GetRSSIThrHi:40
setCountryID
setCountry
#iwpriv wifiN setCountryID Country ID Num
#iwpriv wifiN setCountry Country String
These are used to set the AP to the regulatory requirements of the indicated country. The SetCountryID
command takes an integer value that represents the country, such as 840 for US. The setCountry
command takes a string argument that includes the two character country string, plus “I” for indoor or
“O” for outdoor. The default value for country ID is 0 for debug, so that during initialization the country ID
must be defined. This is a requirement for the final system configuration. See Table 14 Country Code
Definition
for a full list of country IDs and strings.
Each command has a corresponding get command.
#iwpriv
#iwpriv
#iwpriv
wifi0
#iwpriv
wifi0
wifi0 setCountryID 840
wifi0 setCountry USI
wifi0 getCountryID
getCountryID:840
wifi0 getCountry
getCountry:USI
SpurImmLvl
#iwpriv wifiN SpurImmLvl level
This command will set the Spur Immunity level, corresponding to the baseband parameter, cyc_pwr_thr1 that
determines the minimum cyclic RSSI that can cause OFDM weak signal detection. Raising this level reduces
the number of OFDM PHY Errs/s (caused due to board spurs, or interferers with OFDM symbol periodicity),
lowering it allows detection of weaker OFDM signals (extending range). As with most ANI related commands,
this value is the initialization value, not the operating value. The default value for this command is 2. This
command has corresponding get commands.
40
PRELIMINARY
#iwpriv wifi0 SpurImmLvl 3
#iwpriv wifi0 GetSpurImmLvl
wifi0
GetSpurImmLvl:2
txchainmask
rxchainmask
#iwpriv wifiN txchainmask mask
#iwpriv wifiN rxchainmask mask
These parameters set the transmit and receive chainmask values. For MIMO devices, the chainmask indicates
how many streams are transmitted/received, and which chains are used. For some Atheros devices up to 3
chains can be used, while others are restricted to 2 or 1 chain. It’s important to note that the maximum number
of chains available for the device being used. For dual chain devices, chain 2 is not available. Similarly, single
chain devices will only support chain 0. The chains are represented in the bit mask as follows:
Chain 0
0x01
Chain 1
0x02
Chain 2
0x04
Selection of chainmask can affect several performance factors. For a 3 chain device, most of the time an RX
chainmask of 0x05 (or 0x03) is used for 2x2 stream reception. For near range operations, a TX chainmask of
0x05 (or 0x03) is used to minimize near range effects. For far range, a mask of 0x07 is used for transmit.
The default chainmask values are stored in EEPROM. This iwpriv command will override the current
chainmask settings. These commands have corresponding get commands
#iwpriv
#iwpriv
#iwpriv
wifi0
#iwpriv
wifi0
wifi0 txchainmask 0x05
wifiN rxchainmask 0x05
wifiN get_txchainmask
get_txchainmask:5
wifiN get_rxchainmask mask
get_rxchainmask:5
TXPowLim
#iwpriv athN TXPowLim limit
This command will set the current Tx power limit. This has the same effect as the iwconfig ath0 txpower
command. The Tx power will be set to the minimum of the value provided and the regulatory limit. Note that
this value may be updated by other portions of the code, so the effect of the value may be temporary. The value
is in units of 0.5 db increments. This command has a corresponding get command, and its default value is 0.
#iwpriv ath0 TXPowLim 30
#iwpriv ath0 getTxPowLim
wifi0
getTxPowLim:30
TXPwrOvr
#iwpriv athN TXPwrOvr overrideLimit
This command is used to override the transmit power limits set by iwconfig or the TXPowLim command. This
is used for testing only, and is still limited by the regulatory power. A value of 0 disables this override. The
command has a corresponding get command, and its default value is 0.
#iwpriv ath0 TXPowOvr 30
#iwpriv ath0 getTxPowOvr
wifi0
getTxPowOvr:30
2.5.2.4
Protocol Layer
The Protocol Layer (or 802.11 layer) commands are used to configure settings that are made per VAP. These
include such things as security modes, QoS settings, WMM parameters, and any other setting that is specific
to the specific VAP vice the radio. These commands are grouped according to general categories to keep
associated commands in the same section.
41
PRELIMINARY
2.5.2.5
WMM related
WMM commands are provided to manage the WMM link settings. In order to specify the proper parameters,
each command must specify the access category (AC) and mode (either STA or AP).
Table 9 Access Categories and Modes
Value
Symbol
Description
Access Categories
AC_BE
Best Effort
AC_BK
Background
AC_VI
Video
AC_VO
Voice
Mode Parameter
AP
AP Mode – update AP WMM table
STA
Station Mode – update Station WMM tables
The parameters accessible for WMM operations are specified in the WMM (including WMM Power Save)
Specification. These parameters control how the time slots or “TXOPs” are metered out for each traffic stream.
The parameters accessible in the Atheros Fusion driver are as follows:
Table 10 WMM Parameter Definitions
Parameter
Units
Description
ACM
1|0
Admission Control Mandatory. This flag indicates that Admission Control
is required for the specified AC. A value of 1 indicates that Admission
control is required, 0 indicates not required.
AIFSN
slots
This is the number of time slots inside the Arbitration Interframe space to be
used. The minimum value is 2.
logCWmin
CWmin 2logCWmin 1
Minimum backoff timer limit. This is specified in “log” units, where the
actual value of CWmin is expressed as shown
logCWmax
CWmax 2logCWmax 1
Maximum backoff timer limit. This is specified in “log” units, where the
actual value of CWmax is expressed as shown
TXOPlimit
32 us
Maximum duration for a TXOP as negotiated with the station. A value of 0
for this parameter indicates that a single MSDU or MMPDU in addition to a
possible RTS/CTS or CTS to itself may be transmitted at any PHY rate for
each TXOP.
NoACK Policy
1|0
A value of 1 indicates that there is no acknowledgement expected for the
frame, where a value of 0 indicates that an ACK frame is expected.
acm
#iwpriv athN acm AC Mode value
The ACM value for each access category is set using the acm command. The AC and Mode values must
be set for this command. The value is the ACM value (see Table 9 Access Categories and Modes
) for the specific access category. This command has a corresponding get command that returns the current
setting for the indicated AC and mode.
#iwpriv ath0 acm 0 1 1
#iwpriv ath0 get_acm 0 1
ath0
get_acm:1
42
PRELIMINARY
aifs
#iwpriv athN aifs AC Mode Value
This WMM command sets the AIFSN WMM parameter for either the AP or Station parameter set. This
parameter controls the frame spacing in WMM operations. The command takes 3 parameters: The first
value, AC, is the access class value. The second value indicates whether the command is to be applied
to the AP or Station tables, which are kept separately. Finally, the third parameter is the AIFSN value (see
Table 9 Access Categories and Modes
). This parameter has a corresponding get command, which requires the AC and Mode as arguments.
#iwpriv ath0 aifs 0 0 3
#iwpriv ath0 get_aifs 0 0
ath0
get_aifs:3
cwmax
#iwpriv athN cwmax AC Mode value
This command sets the CWmax WMM parameter for either the AP or station parameter set. The cwmax
command is a WMM command that must have the AC and Mode specified. The value is CWmax in units
as described in Table 9 Access Categories and Modes
. This command has a corresponding get command.
#iwpriv ath0 cwmax 3 1 4
#iwpriv ath0 get_cwmax 3 1
ath0
get_cwmax:4
cwmin
#iwpriv athN cwmin AC Mode value
This command sets the CWmin WMM parameter for either the AP or station parameter set. The cwmax
command is a WMM command that must have the AC and Mode specified. The value is CWmin in units
as described in Table 9 Access Categories and Modes
. This command has a corresponding get command which requires the AC and Mode to be specified.
#iwpriv ath0 cwmin 3 1 2
#iwpriv ath0 get_cwmin 3 1
ath0
get_cwmin: 2
noackpolicy
#iwpriv athN noackpolicy AC Mode 0|1
This command sets the No ACK policy bit in the WMM parameter set for either the AP or station. The
noackpolicy command is a WMM command that must have the AC and Mode specified. The value either sets
the policy to “no ACK sent” (1) or “send ACK” (0). This command has a corresponding get command.
#iwpriv ath0 noackpolicy 0 1 1
#iwpriv ath0 get_noackpolicy 0 1
ath0
get_noackpolicy:1
txoplimit
#iwpriv athN txoplimit AC Mode limit
This command will set the TXOP limit, described in Table 9 Access Categories and Modes
. The AC and Mode is as described at the beginning of this section. This command has a corresponding get
command.
#iwpriv ath0 txoplimit 1 0 10
#iwpriv ath0 get_txoplimit 1 0
ath0
get_txoplimit:10
wmm
#iwpriv athN wmm 1|0
43
PRELIMINARY
This command will enable or disable WMM capabilities in the driver. The WMM capabilities perform special
processing for multimedia stream data including voice and video data. This command has a corresponding get
command, and its default value is 1 (WMM enabled).
#iwpriv ath0 wmm 1
#iwpriv ath0 get_wmm
ath0
get_wmm:1
2.5.2.6
Security Related
These commands relate to the security subsystem, and also are specific interfaces required by the hostapd and
wpa_supplicant programs. Some of these may not be directly security related, but are included here due to their
use by the authenticator and supplicant
authmode
#iwpriv athN authmode mode
This command selects the specific authentication mode to configure the driver for. This command is also used
by host_apd to configure the driver when host_apd is used as an authenticator. The mode values are:
Value
Description
None specified
Open Authentication
Shared Key (WEP) Authentication
802.1x Authentication
Auto Select/accept authentication (used by host_apd)
WPA PSK with 802.1x PSK
The user will normally not use these commands. These commands have an associated get command, and its
default value is 0.
#iwpriv ath0 authmode 2
#iwpriv ath0 get_authmode
ath0
get_authmode:2
countermeasures
#iwpriv athN countermeasures 1|0
Enables or disables WPA/WPA2 countermeasures. Countermeasures perform additional processing on
incoming authentication requests to detect spoof attempts, such as repeating authentication packets. A value of
1 enables countermeasures, and 0 disables them. This command has a corresponding get command.
#iwpriv ath0 countermeasures 1
#iwpriv ath0 get_countermeasures
ath0
get_countermeasures:1
dropunencrypted
#iwpriv athN dropunencrypted 0|1
This command enables or disables dropping of unencrypted non-PAE frames received. Passing a value of 1
enables dropping of unencrypted non-PAE frames. Passing a value of 0 disables dropping of unencrypted nonPAE frames. This command has a corresponding get command, and its default value is zero.
#iwpriv ath0 dropunencrypted 1
#iwpriv ath0 get_dropunencry
ath0
get_dropunencry:1
keymgtalgs
#iwpriv athN keymgtalgs algs
This command is used by host_apd in managing WPA keys. This is essentially the same as the WPA
command, which is a combination of bits indicating different capabilities. The algs supported are as follows:
Value
Alg
WPA_ASE_NONE
WPA_ASE_8021X_UNSPEC
44
PRELIMINARY
WPA_ASE_8021X_PSK
The command is a combination of the above, so a value of 3 indicates both unspec and PSK support. The
command has a corresponding get command.
#iwpriv ath0 keymgtalgs 3
#iwpriv ath0 get_keymgtalgs
ath0
get_keymgtalgs:3
mcastcipher
#iwpriv athN mcastcipher cipher
Used mainly by the hostapd daemon, this command will set the cipher used for multicast. The value of cipher is
one of the following:
Value
Cipher Type
IEEE80211_CIPHER_WEP
IEEE80211_CIPHER_TKIP
IEEE80211_CIPHER_AES_OCB
IEEE80211_CIPHER_AES_CCM
IEEE80211_CIPHER_CKIP
IEEE80211_CIPHER_NONE
The iwpriv command sets the cipher type for the VAP. This is required to support operation of the host_apd
authenticator. It has no default value, and the command has a corresponding get command.
#iwpriv ath0 mcastcipher 1
#iwpriv ath0 get_mcastcipher
ath0
get_mcastcipher:1
mcastkeylen
#iwpriv athN mcastkeylen length
This is only valid for WEP operations. This command is used to set the key length of the WEP key. Key
lengths of 5 (40 bits) or 13 (104 bits) are the only valid values, corresponding to 64 or 128 bit WEP encoding,
respectively. This command has no default value. This command has a corresponding get command.
#iwpriv ath0 mcastkeylen 5
#iwpriv ath0 get_mcastkeylen
ath0
get_mcastcipher:5
privacy
#iwpriv athN privacy 1|0
The privacy flag is used to indicate WEP operations. This is not normally used by an application other than
host_apd. WEP operations are normally configured through the appropriate iwconfig command. This
command has a corresponding get command, and its default value is 0.
#iwpriv ath0 privacy 1
#iwpriv ath0 get_privacy
ath0
get_privacy:1
rsncaps
#iwpriv athN rsncaps flags
This command sets the RSN capabilities flags. The only valid capability flag is 0x01, RSN_CAP_PREAUTH,
which is used to configure the AP for preauthorization functionality. This is normally used only by host_apd
when configuring the VAP. This command has a corresponding get command.
#iwpriv ath0 rsncaps 0x01
#iwpriv ath0 get_rsncaps
ath0
get_rsncaps:1
45
PRELIMINARY
setfilter
#iwpriv athN setfilter filter
This command allows an application to specify which management frames it wants to receive from the VAP.
This will cause the VAP to forward the indicated frames to the networking stack. The filter is a set of bits with
the following values:
Bit
Frame type to forward
0x01
Beacon
0x02
Probe Request
0x04
Probe Response
0x08
Association Request
0x10
Association Response
0x20
Authentication
0x40
Deauthentication
0x80
Disassociation
0xff
ALL
This command is normally used by host_apd for configuring the VAP. It does NOT have a corresponding get
command.
#iwpriv ath0 setfilter 0x24
setiebuf
getiebuf
These commands are used by an application to set/get application Information Elements into/from various
frame types. The ieee80211req_getset_appiebuf structure is passed as an argument to the ioctl. There is no
command line equivalent for these commands, but the command does show up as a valid iwpriv command. The
definition of the required data structure is as follows:
struct ieee80211req_getset_appiebuf {
u_int32_t app_frmtype; /*management frame type for which buffer is added*/
u_int32_t app_buflen; /*application supplied buffer length */
u_int8_t app_buf[];
};
setkey
delkey
The host_apd application is required to do periodic rekeying of the various connections. These commands
allow for management of the key cache. The setkey command receives the ieee80211req_key structure as an
argument. This structure is defined as follows:
struct ieee80211req_key {
u_int8_t
ik_type;
/* key/cipher type */
u_int8_t
ik_pad;
u_int16_t
ik_keyix;
/* key index */
u_int8_t
ik_keylen;
/* key length in bytes */
u_int8_t
ik_flags;
u_int8_t
ik_macaddr[IEEE80211_ADDR_LEN];
u_int64_t
ik_keyrsc;
/* key receive sequence counter */
u_int64_t
ik_keytsc;
/* key transmit sequence counter */
u_int8_t
ik_keydata[IEEE80211_KEYBUF_SIZE+IEEE80211_MICBUF_SIZE];
};
The delkey command will pass the structure ieee80211req_del_key, as follows:
struct ieee80211req_del_key {
u_int8_t
idk_keyix;
/* key index */
u_int8_t
idk_macaddr[IEEE80211_ADDR_LEN];
};
Neither of these commands have any corresponding command line equivalents.
46
PRELIMINARY
setmlme
Another of the host_apd support commands, this command is used to perform direct access to the MLME layer
in the driver. This allows an application to start or terminate a specific association. Note that the
MLME_ASSOC sub command only makes sense for a station (AP won’t start an association). This command
will pass the ieee80211req_mlme structure:
struct ieee80211req_mlme {
u_int8_t
im_op;
/* operation to perform */
#define
IEEE80211_MLME_ASSOC
/* associate station */
#define
IEEE80211_MLME_DISASSOC
/* disassociate station */
#define
IEEE80211_MLME_DEAUTH
/* deauthenticate station */
#define
IEEE80211_MLME_AUTHORIZE
/* authorize station */
#define
IEEE80211_MLME_UNAUTHORIZE
/* unauthorize station */
u_int16_t
im_reason;
/* 802.11 reason code */
u_int8_t
im_macaddr[IEEE80211_ADDR_LEN];
};
This command has no command line equivalent.
ucastcipher
#iwpriv athN ucastcipher
This command is used mainly by the host_apd authenticator, and sets the unicast cipher type to the indicated
value. See the mcastcipher command for the definition of the values. This command has a corresponding get
command, but no default value.
#iwpriv ath0 ucastcipher 2
#iwpriv ath0 get_uciphers
ath0
get_uciphers:2
ucastkeylen
#iwpriv athN ucastkeylen length
This is only valid for WEP operations. This command is used to set the key length of the WEP key for unicast
frames. Key lengths of 5 (40 bits) or 13 (104 bits) are the only valid values, corresponding to 64 or 128 bit
WEP encoding, respectively. This command has no default value. This command has a corresponding get
command.
#iwpriv ath0 ucastkeylen 5
#iwpriv ath0 get_ucastkeylen
ath0
get_ucastcipher:5
wpa
#iwpriv athN wpa WPA Mode
This command will set the desired WPA modes. The value of WPA Mode indicates the level of support;
0 = No WPA support
1 = WPA Support
2 = WPA2 Support
3 = Both WPA and WPA2 support.
This command is typically overridden by the setting in the hostapd configuration file, which uses the same
interface to set the WPA mode, so this command is nor normally used during configuration. This command has
a corresponding get command. The default value is 0.
#iwpriv ath0 wpa 3
#iwpriv ath0 get_wpa
ath0
get_wpa:0
47
PRELIMINARY
2.5.2.6.1
802.11n related
These commands provide a set of parameters and actions that can be used to configure and test various
functions specified in 802.11n and 802.11e such as aggregation, block acknowledgement, channel width
management, and static rate settings.
addba
delba
#iwpriv athN addba AID AC BufSize
#iwpriv athN delba AID AC initiator reason
These test commands are used to manually add or delete Block Acknowledge Aggregation streams. Note that
automatic addba/delba processing must be turned off prior to using these commands (see setaddbaoper). Both
commands require the AID (association ID) and the AC specified. The Association ID is the value shown when
using the wlanconfig list command. When adding an aggregation link with addba, the BufSize parameter must
be set to the maximum number of subframes that will be sent in an aggregate. When deleting an aggregation
link, the initiator field indicates whether this link was initiated by the AP (1) or the remote station (0). The
reason code is an 8-bit value indicating the reason the link was shut down. These commands have no
corresponding get commands, nor do they have default values.
#iwpriv ath0 addba 1 0 32
#iwpriv ath0 delba 1 0 1 36
addbaresp
#iwpriv athN addbaresp AID AC status
This command will send an addba response frame on the indicated association ID (AID) and AC. The
Association ID is the value shown under the AID column when using the wlanconfig list command. The status
value is an 8 bit value indicating the status field of the response. This is normally used only during testing of
the aggregation interface. The command does not have a corresponding get command, nor does it have a
default value.
#iwpriv ath0 addbaresp 1 0 25
ampdu
#iwpriv athN ampdu 1|0
This is the same command as used in the Radio layer. This command will affect ALL VAPs that are attached to
the same radio. The command is used to enable/disable transmit AMPDU aggregation for the entire interface.
Receiving of aggregate frames will still be performed, but no aggregate frames will be transmitted if this is
disabled. This has a corresponding get command, and the default value is 1 (Enabled).
#iwpriv ath0 ampdu 1
#iwpriv ath0 get_ampdu
ath0
get_ampdu:1
ampdulimit
#iwpriv athN ampdulimit Byte Limit
This is the same command as used in the Radio layer; it affects ALL VAPs that are attached to the same radio.
This parameter limits the number of bytes included in an AMPDU aggregate frame. Frames add to an
aggregate until either the transmit duration is exceeded, the number of subframes is exceeded, the maximum
number of bytes is exceeded, or the corresponding queue is empty. The subframe causing excess conditions is
not included in the aggregate frame, but queues up to be transmitted with the next aggregate frame. The default
value of this parameter is 50000. This command has a corresponding get command.
#iwpriv ath0 ampdulimit 48000
#iwpriv ath0 get_ampdulimit
ath0
get_ampdulimit:48000
48
PRELIMINARY
ampdusframes
#iwpriv athN ampdusframes numFrames
This is the same command as used in the Radio layer. This command will affect ALL VAPs that are attached to
the same radio. This command will set the maximum number of subframes to place into an AMPDU aggregate
frame. Frames are added to an aggregate until either a) the transmit duration is exceeded, b) the number of
subframes is exceeded, c) the maximum number of bytes is exceeded, or d) the corresponding queue is empty.
The subframe that causes excess conditions is not included in the aggregate frame, but will be queued up to be
transmitted with the next aggregate frame. The default value is 32. This command has a corresponding get
command.
#iwpriv ath0 ampduframes 24
#iwpriv ath0 get_ampduframes
ath0
get_ampduframes:24
cwmmode
#iwpriv athN cwmmode mode
This command selects the CWM mode. The mode can be either static HT 20 (0), HT 20/40 (1), or static HT 40
(2). The Static HT 40 mode is only used for testing and must not be used in an operational configuration. This
command is used mostly in testing to fix the channel width at a certain value. Also, since the current draft of
the IEEE 802.11n specification does not allow HT 40 in the 2.4 MHz band, this is required to be set to 0 when
operating in that band. The command has a corresponding get command, and the default value is 1.
#iwpriv ath0 cwmmode 1
#iwpriv ath0 get_cwmmode
ath0
get_cwmmode:1
extbusythres
#iwpriv athN extbusythres pctBusy
This is used as part of the channel width management state machine. This threshold is used to determine when
to command the channel back down to HT 20 mode when operating at HT 40 mode. If the extension channel is
busy more often then the specified threshold (in percent of total time), then CWM will shut down the extension
channel and set the channel width to HT 20. This command has a corresponding get command, and its default
value is 30%.
#iwpriv ath0 extbusythres 50
#iwpriv ath0 get_extbusythres
ath0
get_extbusythres:50
extoffset
#iwpriv athN
This is used to select the offset channel. This command is deprecated, and should no longer be used in favor of
the channel mode setting. The value 1 indicates upper channel, and -1 indicates lower channel. This command
has a corresponding get command, and has no default value.
#iwpriv ath0 extoffset 1
#iwpriv ath0 get_extoffset
ath0
get_extoffset:1
get_chwidth
#iwpriv athN get_chwidth
This command retrieves the current channel width setting. This is not necessarily the value set by cwmode,
because it can be automatically overridden. The value returned is either 0 (HT 20), 1 (HT 20/40), or 2 (HT 40).
#iwpriv ath0 get_chwidth
ath0
get_chwidth:1
49
PRELIMINARY
htprot
#iwpriv athN htprot 1|0
HT protection modes are defined in the 802.11n specification, paragraph 9.13. Depending on conditions,
various protection modes are implemented. This command will override automatic protection settings and
enable protection for ALL modes. A value of 1 indicates all protection enabled, while a value of 0 indicates
dynamically calculated protection levels. This command has a corresponding get command, and its default
value is 0.
#iwpriv ath0 htprot 1
#iwpriv ath0 get_htprot
ath0
get_htprot:1
cwmenable
#iwpriv athN cwmenable 1|0
This command will enable or disable automatic channel width management. If set to 0, the CWM state machine
is disabled (1 enables the state machine). This is used when static rates and channel widths are desired. The
command has a corresponding get command, and its default value is 1.
#iwpriv ath0 cwmenable 1
#iwpriv ath0 get_cwmenable
ath0
get_cwmenable:1
set11NRates
#iwpriv athN Set11NRates rate_series
When performing tests at fixed data rates, this command is used to specify the data rate. The rate_series value
is specified as a group of 4 bytes in a 32 bit word. Each byte represents the MCS rate to use for each of 4 rate
fallback values. If the hardware does not receive an ACK when transmitting at the first rate, it will fall back to
the second rate and retry, and so on through the 4th rate. As a convention, the high bit in the rate byte is always
set, so for a rate of MCS-15 the rate value would be 0x8F. This command has a corresponding get command.
It has no default value
#iwpriv ath0 set11NRates 0x8F8F8C8C
#iwpriv ath0 get11NRates
ath0
get11NRates: 2408549516
Set11NRetries
#iwpriv athN set11NRetries
For each rate in the rate series, the hardware can retry the same rate step multiple times. This value sets the
number of retries for each step in the rate series. This is expressed as a group of 4 bytes in a 32 bit word, with
each byte indicating the number of times to retry the rate step. This command has a corresponding get
command, and it has no default value.
#iwpriv ath0 set11NRates 0x01010404
#iwpriv ath0 get11NRates
ath0
get11NRates: 16843780
setaddbaoper
#iwpriv athN setaddbaoper 1|0
This command will enable or disable automatic processing for aggregation/block ACK setup frames. To use
the manual addba/delba commands this must be set to 0 (off) to keep the driver from also responding. This
command has a corresponding get command, and its default value is 1 (enabled).
#iwpriv ath0 setaddbaoper 0
#iwpriv ath0 getaddbaoper
ath0
getaddbaoper:0
50
PRELIMINARY
shortgi
#iwpriv athN shortgi 1|0
This command will enable/disable the short Gating Interval (shortgi) when transmitting HT 40 frames. This
effectively increases the PHY rate by 25%. This is a manual control typically used for testing. This command
has a corresponding get command, and its default value is 1.
#iwpriv ath0 shortgi 1
#iwpriv ath0 get_shortgi
ath0
get_shortgi:1
tx_chainmask
rx_chainmask
#iwpriv athN tx_chainmask mask
#iwpriv athN rx_chainmask mask
These commands are identical to those commands in the radio layer, and have the same effect. These
parameters set the transmit and receive chainmask values. For MIMO devices, the chainmask indicates how
many streams are transmitted/received, and which chains are used. For some Atheros devices up to 3 chains
can be used, while others are restricted to 2 or 1 chain. It’s important to note that the maximum number of
chains available for the device being used. For dual chain devices, chain 2 is not available. Similarly, single
chain devices will only support chain 0. The chains are represented in the bit mask as follows:
Chain 0
0x01
Chain 1
0x02
Chain 2
0x04
Selection of chainmask can affect several performance factors. For a 3 chain device, most of the time an RX
chainmask of 0x05 (or 0x03 for two chain devices) is used for 2x2 stream reception. For near range operations,
a TX chainmask of 0x05 (or 0x03 for two chain devices) is used to minimize near range effects. For far range,
a mask of 0x07 is used for transmit.
It is recommended to use the radio version of these commands, since they may become deprecated in the future
through this interface. These setting affect ALL VAPS, not just the VAP that is being set.
The default chainmask values are stored in EEPROM. This iwpriv command will override the current
chainmask settings. These commands have corresponding get commands.
#iwpriv ath0 tx_chainmask 0x05
#iwpriv ath0 rx_chainmask 0x05
#iwpriv ath0 get_tx_chainmask
ath0
get_tx_chainmask:5
#iwpriv ath0 get_rx_chainmask mask
ath0
get_rx_chainmask:5
51
PRELIMINARY
2.5.2.6.2
Regulatory commands
These commands interface with the regulatory information in the driver, and are used to control the settings
affecting local requirements.
countryie
#iwpriv athN countryie 1|0
This is an enable/disable control that determines if the country IE is to be sent out as part of the beacon. The
country IE is used by 802.11h processing to allow stations to self-configure their regulatory tables to the
country they are in. Sending this IE will configure all such stations to the country the AP is configured to. This
command has a corresponding get command, and its default value is 1 (enabled).
#iwpriv ath0 countryie 1
#iwpriv ath0 get_countryie
ath0
get_countryie:1
coverageclass
#iwpriv athN coverageclass class
The coverage class is used to determine the air propagation time used in BSS operations. This command will
set the coverage class to a value between 0 and 31. This value is part of the country IE transmitted, and the
values can be found in the IEEE 802.11 Handbook, Table 13-1. Generally, the higher the number, the longer
distance that is allowed for coverage. This command has a corresponding get command.
#iwpriv ath0 coverageclass 12
#iwpriv ath0 get_coverageclass
ath0
get_ coverageclass:12
doth
#iwpriv athN doth 0|1
This enables or disables support for 802.11h regulatory information selection. For the AP, this enables or
disables transmission of country IE information in the beacon. Stations supporting 802.11h will configure their
regulatory information according to the information in the country IE. The default value is 1 (enabled). This
command has a corresponding get command.
#iwpriv ath0 doth 1
#iwpriv ath0 get_doth
ath0
get_doth:1
doth_chanswitch
#iwpriv athN doth_chanswitch channel tbtt
This command will force the AP to perform a channel change, and will force a channel change announcement
message to be sent. This is used for testing the 802.11h channel switch mechanism. The channel value
indicates the channel to switch to, and the tbtt value indicates the number of beacons to wait before doing the
switch. This command does not have a corresponding get command; it is an action rather than a setting.
#iwpriv ath0 doth_chanswitch 3 5
doth_pwrtgt
#iwpriv athN doth_pwrtgt target
This command sets the desired maximum power on the current channel, as reported in the beacon and the probe
response messages. This value is used by stations to set their output values as required. The value is capped by
the regulatory maximum power value. The power value target is expressed in 0.5 dBm steps. There is no
default value for this parameter. There is a corresponding get command.
#iwpriv ath0 doth_pwrtgt 25
#iwpriv ath0 get_doth_pwrtgt
ath0
get_doth_pwrtgt:25
52
PRELIMINARY
doth_reassoc
#iwpriv athN doth_reassoc value
This command instructs the driver to generate a reassociation request. The single value provided is not used.
This is more of a single-shot action rather than a setting. This command has no default, and no corresponding
get command.
#iwpriv ath0 doth_reassoc 1
get_countrycode
#iwpriv athN get_countrycode
This command will return the current setting of the country code. The country code values are listed in
Appendix A.
#iwpriv ath0 get_countrycode
ath0
get_countrycode:736
markdfs
#iwpriv athN markdfs 1|0
This command will enable or disable the “marking” of DFS channels. A channel is “marked” if a radar is
detected on the channel, and it is put in the Non-Occupancy List (NOL). This is only used for testing, and
should not be used in an operational environment. This command has a corresponding get command, and its
default value is 1.
#iwpriv ath0 markdfs 1
#iwpriv ath0 get_markdfs
ath0
get_markdfs:1
regclass
#iwpriv athN regclass 1|0
This command enables or disables the addition of the regulatory triplets into the country IE sent in the beacon.
A value of 1 will enable the regulatory triplets. This command has a corresponding get command, and its
default value is 1.
#iwpriv ath0 regclass 1
#iwpriv ath0 get_regclass
ath0
get_regclass:1
53
PRELIMINARY
General Commands
These are the common commands used for various functions during operations.
addmac
delmac
maccmd
#iwpriv athN maccmd cmd
#iwpriv athN addmac mac_addr
#iwpriv athN delmac mac_addr
These commands are used to setup and modify the MAC filtering list. MAC filtering allows the user to either
limit specific MAC addresses from associating with the AP, or specifically indicates which MAC addresses can
associate with the AP. The addmac and delmac will add specific MAC addresses to the Access Control List
(ACL). The maccmd value indicates how to use the ACL to limit access the AP. The following table indicates
the valid commands:
Value
Description
Disable ACL checking
Only ALLOW association with MAC addresses on the list
DENY association with any MAC address on the list
Flush the current ACL list
Suspend current ACL policies. Re-enable with a 1 or 2 command
These commands have no “get” equivalents. The default value of maccmd is 0.
#iwpriv ath0 maccmd 1
#iwpriv ath0 addmac 00:03:7f:00:00:20
#iwpriv ath0 delmac 00:03:7f:00:12:34
ap_bridge
#iwpriv athN ap_bridge mode
This command will enable or disable bridging within the AP driver. This has the effect of now allowing a
station associated to the AP to access any other station associated to the AP. This eliminates bridging between
clients. This command has a corresponding get command. Its default value is 0.
#iwpriv ath0 ap_bridge 0
#iwpriv ath0 get_ap_bridge
ath0
get_:0
bgscan
#iwpriv athN bgscan 1|0
This command will enable or disable background scanning. Background scanning occurs on a specified interval
to update the list of known AP’s. This command is only valid when a VAP is operating in station mode. The
command has a corresponding get command, and its default value is 1.
#iwpriv ath0 bgscan 1
#iwpriv ath0 get_bgscan
ath0
get_bgscan:1
bgscanidle
#iwpriv athN bgscanidle idlePeriod
This command sets the amount of time the background scan must be idle before it is restarted. This is different
from the background scan interval, in that if the background scan is delayed for a long period, when it is
complete it will be idle for this period even if the scan interval times out. This time is indicated in seconds.
The command has a corresponding get command, and its default value is 250 seconds.
#iwpriv ath0 bgscanidle 200
#iwpriv ath0 get_bgscanidle
ath0
get_bgscanidle:200
54
PRELIMINARY
bgscanintvl
#iwpriv athN bgscanintvl interval
This sets the interval to perform background scans. A scan is started each time the interval times out, or if the
idle interval is not timed out when the idle interval is complete. The interval timer is started when the scan is
started, so a idle period timeout will “shift” all subsequent scan intervals. The interval value is specified in
seconds. This command has a corresponding get command, and its default value is 300.
#iwpriv ath0 bgscanintvl 250
#iwpriv ath0 get_bgscanintvl
ath0
get_bgscanintvl:250
bintval
#iwpriv athN bintval beacon interval
This command will set the AP’s beacon interval value, in milliseconds. This value determines the number of
milliseconds between beacon transmissions. For the multiple VAP case, the beacons are transmitted evenly
within this interval. Thus, if 4 VAPs are created and the beacon interval is 200 milliseconds, a beacon will be
transmitted from the radio portion every 50 milliseconds, from each VAP in a round-robin fashion. The default
value of the interval is 100 milliseconds. This command has a corresponding get command.
#iwpriv ath0 bintval 400
#iwpriv ath0 get_bintval
ath0
get_bintval:200
blockdfschan
#iwpriv athN blockdfschan 1|0
This command will disable the selection of dfs channels when the 802.11h channel switch processing is
selecting a new channel. Typically, when a radar is detected on a channel, a new channel is picked randomly
from the list. DFS channels are normally included in the list, so if there are several radars in the area another hit
is possible. Setting this selection to 0 disables the use of DFS channels in the selection process, while a value of
1 enables DFS channels. The default value is 1.. This limits the number of available channels. This command
does not have a corresponding get command.
#iwpriv ath0 blockdfschan 1
burst
#iwpriv athN burst 1|0
This command enables (1) or disables (0) Atheros Super A/G bursting support in the driver. Passing a value of 1
to the driver enables SuperG bursting. Passing a value of 0 to the driver disables Super A/G bursting. This is
nor normally used when using 802.11n devices. This command has a corresponding get command, and its
default value is 0.
#iwpriv ath0 burst 0
#iwpriv ath0 get_burst
ath0
get_burst:0
chanbw
#iwpriv athN
This command sets manual channel bandwidth. The values indicate which channel bandwidth to use. Note that
this command only applies to legacy rates – HT rates are controlled with the corresponding 11n commands.
Value
Description
Full channel bandwidth
Half channel bandwidth
Quarter channel bandwidth
This command has a corresponding get command, and its default value is 0.
#iwpriv ath0 chanbw 1
#iwpriv ath0 get_chanbw
ath0
get_chanbw:1
55
PRELIMINARY
dbgLVL
#iwpriv athN
Yet another debug control. This parameter controls the debug level of the VAP based debug print statements.
It’s normally set to zero, eliminating all prints.
Table 11 802.11 Protocol Layer Debug Bitmask
Symbolic Name
Bit Value
Description
IEEE80211_MSG_11N
0x80000000
11n mode debug
IEEE80211_MSG_DEBUG
0x40000000
IFF_DEBUG equivalent
IEEE80211_MSG_DUMPPKTS
0x20000000
IFF_LINK2 equivalent
IEEE80211_MSG_CRYPTO
0x10000000
crypto work
IEEE80211_MSG_INPUT
0x08000000
input handling
IEEE80211_MSG_XRATE
0x04000000
rate set handling
IEEE80211_MSG_ELEMID
0x02000000
element id parsing
IEEE80211_MSG_NODE
0x01000000
node handling
IEEE80211_MSG_ASSOC
0x00800000
association handling
IEEE80211_MSG_AUTH
0x00400000
authentication handling
IEEE80211_MSG_SCAN
0x00200000
Scanning
IEEE80211_MSG_OUTPUT
0x00100000
output handling
IEEE80211_MSG_STATE
0x00080000
state machine
IEEE80211_MSG_POWER
0x00040000
power save handling
IEEE80211_MSG_DOT1X
0x00020000
802.1x authenticator
IEEE80211_MSG_DOT1XSM
0x00010000
802.1x state machine
IEEE80211_MSG_RADIUS
0x00008000
802.1x radius client
IEEE80211_MSG_RADDUMP
0x00004000
dump 802.1x radius packets
IEEE80211_MSG_RADKEYS
0x00002000
dump 802.1x keys
IEEE80211_MSG_WPA
0x00001000
WPA/RSN protocol
IEEE80211_MSG_ACL
0x00000800
ACL handling
IEEE80211_MSG_WME
0x00000400
WME protocol
IEEE80211_MSG_SUPG
0x00000200
SUPERG
IEEE80211_MSG_DOTH
0x00000100
11.h
IEEE80211_MSG_INACT
0x00000080
inactivity handling
IEEE80211_MSG_ROAM
0x00000040
sta-mode roaming
IEEE80211_MSG_ACTION
0x00000020
action management frames
56
PRELIMINARY
driver_caps
#iwpriv athN driver_caps caps
This command is used to manually set the driver capabilities flags. This is normally used for testing, since the
driver itself will fill in the proper capability flags. The flags are defined as follows:
0x00000001
WEP
0x00000200
Power Management
0x01000000
WPA 2
0x00000002
TKIP
0x00000400
Host AP
0x00800000
WPA 1
0x00000004
AES
0x00000800
Ad hoc Demo
0x02000000
Burst
0x00000008
AES_CCM
0x00001000
Software Retry
0x04000000
WME
0x00000010
HT Rates
0x00002000
TX Power Mgmt
0x08000000
WDS
0x00000020
CKIP
0x00004000
Short Slot time
0x10000000
WME TKIP MIC
0x00000040
Fast Frame
0x00008000
Short Preamble
0x20000000
Background Scan
0x00000080
Turbo
0x00010000
Monitor Mode
0x40000000
UAPSD
0x00000100
IBSS
0x00020000
TKIP MIC
0x80000000
Fast Channel Change
This command has a corresponding get command. It has no default value.
#iwpriv ath0 driver_caps 0x034000003
#iwpriv ath0 get_driver_caps
ath0
get_driver_caps:872415235
dtim_period
#iwpriv athN dtim_period delivery period
This is used to set the Delivery Traffic Indication Map (DTIM) period. The DTIM is an interval specified by
the AP to the station indicating when multicast traffic may be available for the station, requiring the STA to be
awake to receive the messages. This command will set the AP’s DTIM period, in milliseconds. A longer
DTIM will provide for a greater power savings, but will increase multicast latency. This parameter has a
default value of 1 millisecond. There is a corresponding get command.
#iwpriv ath0 dtim_period 5
#iwpriv ath0 get_dtim_period
wifi0
get_dtim_period:1
fastcc
#iwpriv athN fastcc 1|0
This enables fast channel change. A value of 1 indicates that channel changes within band will be done without
resetting the chip. A value of 0 indicates that any channel change will require a chip reset. This command has a
corresponding get command, and its default value is 0
#iwpriv ath0 fastcc 1
#iwpriv ath0 get_fastcc
ath0
get_fastcc:1
57
PRELIMINARY
getchaninfo
This command is used by external applications to get channel information from the driver. An example
application is the wlanconfig tool that uses this interface to get the channel information. The wireless tools do
not know how to parse the information provided, since it is returned in an Atheros driver specific data structure.
The data structures used are defined as follows:
struct ieee80211req_chaninfo {
u_int
ic_nchans;
struct ieee80211_channel ic_chans[IEEE80211_CHAN_MAX];
};
struct ieee80211_channel {
u_int16_t
ic_freq;
/*
u_int32_t
ic_flags;
/*
u_int8_t
ic_flagext;
/*
u_int8_t
ic_ieee;
/*
int8_t
ic_maxregpower;
int8_t
ic_maxpower;
/*
int8_t
ic_minpower;
/*
};
setting in MHz */
see below */
see below */
IEEE channel number */
/* maximum regulatory Tx power in dBm */
maximum Tx power in dBm */
minimum Tx power in dBm */
There is not command line equivalent interface for this command.
getRadio
#iwpriv athN getRadio
For dual concurrent operations, it is desirable to be able to determine which radio a particular VAP is attached
to. This command will return the index of the associated radio object (wifiN, where N is the radio number).
#iwpriv ath0 getRadio
ath0
getRadio:0
hide_ssid
#iwpriv athN hide_ssid 0|1
This will “hide” the SSID, disabling it in the transmitted beacon, when enabled. This is used for secure
situations where the AP does not want to advertise the SSID name. A value of 0 will enable the SSID in the
transmitted beacon. This command has a corresponding get command, and its default value is 0.
#iwpriv ath0 hide_ssid 1
#iwpriv ath0 get_hide_ssid
ath0
get_hide_ssid:1
inact
#iwpriv athN inact inactivity period
This sets the TSPEC inactivity period for the AP RUN state. This is an 802.11e mechanism that allows for
allocating QoS priority to certain traffic types. The inactivity period is a timer that counts the seconds that a
QoS stream is inactive during RUN state. This timer will delete a traffic stream after the indicated number of
seconds elapse. The default value is 300 seconds, and this command has a corresponding get command.
#iwpriv ath0 inact 250
#iwpriv ath0 get_inact
ath0
get_inact:300
58
PRELIMINARY
inact_auth
#iwpriv athN inact_auth inactivity period
This sets the TSPEC inactivity period for the AP AUTH state. This is an 802.11e mechanism that allows for
allocating QoS priority to certain traffic types. The inactivity period is a timer that counts the seconds that a
QoS stream is inactive during AUTH state. This timer will delete a traffic stream after the indicated number of
seconds elapse. The default value is 180 seconds, and this command has a corresponding get command.
#iwpriv ath0 inact_auth 150
#iwpriv ath0 get_inact_auth
ath0
get_inact_auth:180
inact_init
#iwpriv athN inact inactivity period
This sets the TSPEC inactivity period for the AP INIT state. This is an 802.11e mechanism that allows for
allocating QoS priority to certain traffic types. The inactivity period is a timer that counts the seconds that a
QoS stream is inactive during INIT state. This timer will delete a traffic stream after the indicated number of
seconds elapse. The default value is 30 seconds, and this command has a corresponding get command.
#iwpriv ath0 inact 10
#iwpriv ath0 get_inact_init
ath0
get_inact_init:30
mcast_rate
#iwpriv athN mcast_rate rate
This command is used to set multicast to a fixed rate. The rate value is specified in units of KBPS. This allows
the user to limit the impact of multicast on the overall performance of the system. The command has a
corresponding get command, and has no default value.
#iwpriv ath0 mcast_rate 10000
#iwpriv ath0 get_mcast_rate
ath0
get_mcast_rate: 10000
mode
#iwpriv athN mode desired_mode
This command will set the current operating mode of the interface. The argument is a string that defines the
desired mode of operation. The mode will also affect the configuration of the Radio layer, so this command
should be used when modifying the operating mode of the VAP. The following is a valid list of operating
modes:
Mode
Description
11NAHT20
802.11n A-band 20 MHz channels
11NGHT20
802.11n G-band 20 MHz channels
11NAHT40PLUS
Select frequency channels higher than the primary control channel as the extension channel
11NAHT40MINUS
Select frequency channels lower than the primary control channel as the extension channel
11NGHT40PLUS
Select frequency channels higher than the primary control channel as the extension channel
11NGHT40MINUS
Select frequency channels lower than the primary control channel as the extension channel
This command has a corresponding “get” command. The following example shows how to use the mode and
get_mode commands. The argument for mode is provided as a string. The get_mode command will return the
mode as a string value.
#iwpriv ath0 setmode 11NAHT20
# iwpriv ath0 get_mode
ath0
get_mode:11ng20
59
PRELIMINARY
protmode
#iwpriv athN protmode 0|1
This command will enable or disable 802.11 protection mode.. This will cause RTS/CTS sequence (or CTS to
Self) to be sent when 802.11 devices are detected on the 802.11 network. This is used to protect against
transmission by devices that do not recognize OFDM modulated frames. This command has a corresponding
get command, and its default value is 0.
#iwpriv ath0 protmode 0
#iwpriv ath0 get_protmode
ath0
get_protmode:0
pspoll
#iwpriv athN pspoll
This command forces a pspoll to be output from the VAP indicated. This command is only valid for a VAP
operating in station mode, and is only used for testing. This is an action command, and as such does not have a
get command or default value.
#iwpriv ath0 pspoll
pureg
#iwpriv athN pureg 1|0
This command enables or disables pure G mode. This mode does not allow 802.11 rates, and only used
OFDM modulation. This command has a corresponding get command, and its default value is 0.
#iwpriv ath0 pureg 1
#iwpriv ath0 get_pureg
ath0
get_pureg:1
qosnull
#iwpriv athN qosnull AC
Similar to the pspoll, this command will send a QoS NULL frame from the indicated VAP. The AC parameter
is the one defined in the WMM section. This command is only valid for a VAP operating in station mode, and
is typically only used for testing. This is an action command, thus does not have any get command or default
value.
#iwpriv ath0 qosnull 0
rate11a
rate11b
rate11g
#iwpriv athN
These commands set the roaming rate for each band usage. These rates are used to determine if a new AP is
required. If the data rate on the link drops below these values, the scan module will determine if a better AP on
the same ESS can be used. Values are specified in 500kbps increments, so a value of 48 indicates a rate of 24
Mbps. This command has a corresponding get command, and its default value is 48 for A band and 18 for B/G
band.
#iwpriv ath0 rate11a 32
#iwpriv ath0 rate11b 2
#iwpriv ath0 rate11g 10
#iwpriv ath0 get_rate11a
ath0
get_rate11a:32
#iwpriv ath0 get_rate11b
ath0
get_rate11b:2
#iwpriv ath0 get_rate11g
ath0
get_rate11b:10
60
PRELIMINARY
reset
#iwpriv athN reset
This command will force a reset on the VAP and its underlying radio layer. Note that any VAP connected to
the same radio in mBSSID configuration will be affected. This is an action command that has no get command
or default value.
#iwpriv ath0 reset
roaming
#iwpriv athN roaming mode
The roaming mode defines how state transitions are controlled in the AP, and what will cause a scan to happen.
The roaming mode can take the following values:
Value
Definition
ROAMING_DEVICE. Scans are started in response to management frames coming in from the
WLAN interface, and the driver starts the scan without intervention
ROAMING_AUTO. Scan algorithm is controlled by the 802.11 layer in the AP. Similar to
ROAMING_DEVICE, additional algorithms are applied to the decision of when to
scan/reassociate/roam.
ROAMING_MANUAL: Roaming decisions will be driven by IOCTL calls by external applications,
such as the wpa_supplicant.
The default value is ROAMING_AUTO when in STA mode. This parameter has no meaning when operating
in AP mode. The command has a corresponding get command.
#iwpriv ath0 roaming 1
# iwpriv ath0 get_roaming
ath0
get_roaming:1
rssi11b
rssi11g
#iwpriv athN rssi11b
#iwpriv athN rssi11g
These commands set the RSSI threshold for roaming in 11g and 11b modes. These thresholds are used to make
roaming decisions based on signal strength from the current set of APs available. The values are provided in
units of db. These commands have corresponding get commands. The default value for both is 24 dBm.
#iwpriv
#iwpriv
#iwpriv
ath0
#iwpriv
ath0
ath0 rssi11b 30
ath0 rssi11g 30
ath0 get_rssi11b
get_rssi11b:30
ath0 get_rssi11g
get_rssi11g:30
scanvalid
#iwpriv athN scanvalid period
This command sets the period that scan data is considered value for roaming purposes. If scan data is older than
this period, a scan will be forced to determine if roaming is required. The period is specified in seconds. This
command has a corresponding get command, and has a default value of 60 seconds.
#iwpriv ath0 scanvalid 30
#iwpriv ath0 get_scanvalid
ath0
get_scanvalid:30
setchanlist
getchanlist
This command is used by an application to set the channel list manually. Channels that are not valid from a
regulatory perspective will be ignored. This command is passed a byte array 255 bytes long that contains the
list of channels required. A value of 0 indicates “no channel”, but all 255 bytes must be provided. The
getchanlist will receive this array from the driver in a 255 byte array that contains the valid channel list. The
response is a binary array that WLAN tools cannot parse; therefore this cannot be used on the command line.
61
PRELIMINARY
shpreamble
#iwpriv athN shpreamble 1|0
This command will enable (1) or disable (0) short preamble. Short preamble will disable the use of a barker
code at the start of the preamble. This command affects ALL VAPs connected to the same radio. This
command has a corresponding get command, and its default value is 0.
#iwpriv ath0 shpreamble 1
#iwpriv ath0 get_shpreamble
ath0
get_shpreamble:1
sleep
#iwpriv athN sleep 1|0
This test command will force a STA VAP into (1) or out of (0) sleep mode. This is useful only for station
mode. When coming out of sleep, a null data frame will be sent. This command has a corresponding get
command that returns the power management state (1 enabled 0 disabled). This has no default value.
#iwpriv ath0 sleep 1
#iwpriv ath0 get_sleep
ath0
get_sleep:1
uapsd
#iwpriv athN uapsd 1|0
This command sets the corresponding bit in the capabilities field of the beacon and probe response messages.
This has no other effect. This command has a corresponding get command, and its default value is 0.
#iwpriv ath0 uapsd 1
#iwpriv ath0 get_uapsd
ath0
get_uapsd:1
wds
#iwpriv athN wds 1|0
This command enables (1) or disables (0) 4-address frame format for this VAP. Used for WDS configurations
(see section 3.5 for details). This command has a corresponding get command, and its default value is 0.
#iwpriv ath0 wds 1
#iwpriv ath0 get_wds
ath0
get_wds:1
wdsdetect
#iwpriv athN wdsdetect 1|0
Due to a hardware bug in early 11n chips, a workaround for WDS frames was implemented between Atheros
stations. For ar9000 series or later 802.11n products, this workaround is not required. This value enables (1) or
disables (0) the AR5416 workaround for WDS. When the workaround is enabled aggregation is not enabled for
the WDS link. This command has a corresponding get command, and its default value is 1.
#iwpriv ath0 wdsdetect 1
#iwpriv ath0 get_wdsdetect
ath0
get_wdsdetect:1
stafwd
#iwpriv athN stafwd 1|0
This command enables/disables station forwarding mode. In this mode, a client VAP will act as a “surrogate”
interface as an Ethernet device, using the MAC address of the surrogate as its own, allowing a non-WiFi device
to use a “dongle” to provide WiFi access without modification to the non-WiFi device. Setting to 1 will enable
this mode, where setting to 0 will disable this mode. Note that the proper wlanconfig command must be used to
set up the VAP in the first place. This command has a corresponding get command, and its default value is 0.
#iwpriv ath0 stafwd 1
#iwpriv ath0 get_stafwd
ath0
get_stafwd:1
62
PRELIMINARY
2.5.2.7
Changing parameters using iwconfig and iwpriv
Many of the parameters that can be accessed via iwconfig and iwpriv are initialization parameters. If they are changed
while the AP is running, they may not take effect until the VAP is brought down and up. For multiple BSS (multiple
VAP) configurations, some iwpriv parameters may affect ALL VAPs, not just the one of interest. Normally, the best
practice is to bring down ALL VAPs prior to making configuration changes using the “ifconfig down” command on the
interface, and then bringing them back up using the “ifconfig up” command.
It has been attempted to indicate those commands that may have adverse effects in the documentation for the command,
however not all effects may have been documented. Please keep in mind the nature of multiple VAP configurations that
use multiple radios, and use caution when changing parameters on the fly.
2.5.3 wlanconfig utility
The wlanconfig utility is an Atheros utility used to manage VAP instances. It provides the primary method to instantiate
a VAP, list the VAP status, and delete the VAP instance. It is an integral part of the configuration scripts. The Create,
List, and Delete interfaces are described in the following sections.
2.5.3.1
Creating a VAP
Creating a VAP requires a few parameters to indicate the specific nature of the VAP. A VAP can be either a client node
or an infrastructure node. Infrastructure notes are called “master” nodes, and client nodes are called “managed” nodes.
The following command is used to create a VAP instance:
# wlanconfig ath[N] create wlandev wifiN wlanmode [ap|sta|mon] [bssid] [nosbeacon]
The arguments are defined as follows:
2.5.3.2
Argument
Description
ath[N]
Name of the VAP. If the number at the end of the name is omitted, the system will
automatically use the next available interface number. The VAP name “ath” is not required,
any text string will do.
create
Verb indicating create action
wlandev wifiN
Indicates which interface to attach the VAP to. The interface number is required for this
argument. For dual concurrent operations, N indicates which radio to attach the VAP to.
wlanmode mode
Indicates the mode to open the VAP into. The valid modes are “ap”, indicating an
infrastructure node, “sta” indicating a station (client) node, and “mon” indicating a monitor
VAP. Note that “mon” is not implemented in the configuration scripts.
bssid
Optional parameter indicating that the MAC address should be cloned from the first VAP for
this interface. Not normally specified.
nosbeacon
Indicates that no beacons will be transmitted from this VAP. Used as part of station (client)
mode.
Listing VAP Parameters
The list command provides an extended listing of parameters from the VAP. Depending on the type of list for each
associated station. The list command is followed by a print of the VAP association list with the associated parameters:
# wlanconfig athN list [sta|ap|chan|keys|caps|wme]
The argument to the list verb defines the type of listing to produce. Each type is described in the following sections.
63
PRELIMINARY
2.5.3.2.1
Station (sta)
This type of list provides information for each station associated with the indicated VAP. The following
listing is produced:
ADDR
00:03:7f:08:62:23
AID CHAN RATE RSSI IDLE
36
6M
59 135
TXSEQ
13
RXSEQ CAPS ACAPS ERP
12128 E
STATE HTCAPS
33 Q
WME
The list elements are described as follows:
ADDR
MAC address of the station
AID
Association ID. This is used to determine the specific AP/Station association pair used in 802.11n test commands.
CHAN
Channel device is associated on
RATE
Current data rate of the association
RSSI
Signal strength of the last received packet. For MIMO devices, this is an average value over all active receive
chains.
IDLE
Current setting of the station inactivity timer. This is the time in ms when the station will go into power save of no
activity occurs on the link.
TXSEQ
Transmit sequence number of the last received packet
RXSEQ
Receive sequence number of the last received packet
CAPS
Current capabilities of the station. These are alphanumeric characters corresponding to specific 802.11 capability
bits in the beacon and probe response Responses are defined as follows:
ACAPS
ESS
Privacy
Short Slot Time
IBSS
Short Preamble
DSSS/OFDM
Pollable
PBCC
Poll Request
Channel Agility
Current Advanced (Atheros) capability flags. These are alphanumeric characters corresponding to the flags that are
set for the advanced Atheros capabilities. Defined as follows:
Turbo G
Fast Frame
Advanced Radio
Compression
XR Radio
Boost
ERP
Transmit Radiated Power (ERP) in dBm. A value of 0 indicates a legacy station. Printed in hexadecimal.
STATE
Current state of the station. This is an hexadecimal value that consists of the following individual bits:
HTCAPS
(no Header)
0x0001
Authorized for data transfer
0x0040
uAPSD enabled
0x0002
QoS enabled
0x0080
uAPSD triggerable
0x0004
ERP Enabled
0x0100
uAPSD SP in Progress
0x0008
HT Rates enabled
0x0200
This is an ATH node
0x0010
Power Save Mode enabled
0x0400
WDS Workaround req
0x0020
Auth reference held
0x0800
WDS link
The HT capabilities flags. These are character indicators that represent a capability of the 802.11n station
Advanced Coding
Static MIMO Power Save
Short GI enabled (HT 40)
HT40 Channel Width
Dynamic MIMO Power Save
Delayed block ACK
MIMO Power Save enabled
Greenfield Preamble
Max AMSDU size
All Information Elements for the attached station are printed. These have the following values:
WPA
WPA Information Element
VEN
Vendor Specific Information Element
WME
WMM Information Element
RSN
RSN Information Element
ATH
Atheros Vendor Information Element
???
Unknown Information Element
64
PRELIMINARY
2.5.3.2.2
AP List (ap)
This only applies to VAPs that are station VAPs. This is the result of a scan, providing a list of nearby APs.
The listing produced is as follows:
SSID
Atheros Guests
ney-11a
perseus-cis...
BILL-AP
apps-atheros1
CHAN RATE S:N
52
54M 13:0
60
54M 22:0
36
54M 30:0
36
54M 27:0
36
54M 26:0
INT
100
100
100
100
100
CAPS
Es
Es
EPs
WME
WME
WME
WME ATH
SSID
Name string of the AP as broadcast in the beacon
BSSID
BSSID value of the AP. Takes the form of a MAC address
CHAN
Channel the AP is servicing
RATE
Maximum rate of the AP
S:N
Signal to Noise ratio. The first number is the last received RSSI from the device, and the last number is the noise
value.
INT
Beacon interval, in milliseconds
CAPS
Current capabilities of the AP These are alphanumeric characters corresponding to specific 802.11 capability bits in
the beacon and probe response Responses are defined as follows:
(no Header)
2.5.3.2.3
BSSID
00:0b:85:5b:a6:e1
00:03:7f:00:de:ea
00:1d:45:29:39:50
00:03:7f:00:ce:ee
00:03:7f:00:ce:d3
ESS
Privacy
Short Slot Time
IBSS
Short Preamble
DSSS/OFDM
Pollable
PBCC
Poll Request
Channel Agility
All Information Elements for the attached station are printed. These have the following values:
WPA
WPA Information Element
VEN
Vendor Specific Information Element
WME
WMM Information Element
RSN
RSN Information Element
ATH
Atheros Vendor Information Element
???
Unknown Information Element
Channel (chan)
This listing provides a list of all available channels on the VAP. The following is a small portion of a list of
channels that provides the channel number and frequency in MHz.
Channel
Channel
Channel
Channel
2412
2417
2422
2427
MHz
MHz
MHz
MHz
11ng
11ng
11ng
11ng
CU
CU
CU
CU
Channel 64 : 5320*
Channel 100 : 5500*
Channel 104 : 5520*
Channel 108 : 5540*
MHz
MHz
MHz
MHz
11na
11na
11na
11na
CL
CU
CL
CU
The channel and frequency values are followed by a set of strings indicating specific channel capabilities, as
follows:
FHSS
FHSS Channel
11ng
2.4 GHz band 11n
capable
Turbo
Turbo Enabled
11na
5 GHz Band 11n
capable
11g
2.4 GHz band legacy
11n control channel
capable
11a
5 GHz Band legacy
11b
2.4 GHz band DSSS
only
CU
11n Upper Extension
Channel Enabled
65
CL
11n Lower Extension
channel Enabled
PRELIMINARY
2.5.3.2.4
Capabilities (caps)
This provides a list of the capabilities of the VAP referenced. These are output as a comma delimited string.
/etc/ath # wlanconfig ath0 list caps
ath0=3782e41f
The capability strings are defined as follows:
2.5.3.2.5
WEP
WEP Available
AHDEMO
Ad Hoc Demo Mode
BURST
Frame Bursting capable
CKIP
CKIP Available
SHPREAMBLE
Short GI Preamble available
AES_CCM
AES CCM
HOSTAP
Host AP Mode
WPA2
WPA 2 available
PMGT
Power Management Available
SHSLOT
Short Slot available
AES
AES OCB available
TXPMGT
TX Power Management
WPA1
WPA 1 available
IBSS
IBSS Mode available
TKIPMIC
TKIP MIC available
TKIP
TKIP Available
SWRETRY
TX Software Retry
WME
WME capable
TURBOP
ATH Turbo available
MONITOR
Monitor Mode
WMM Configuration (wme)
This listing provides the current settings of the VAP’s WME settings. The listing is as follows:
/etc/ath # wlanconfig ath0 list
AC_BE cwmin 4 cwmax 6
cwmin 4 cwmax 10
AC_BK cwmin 4 cwmax 10
cwmin 4 cwmax 10
AC_VI cwmin 3 cwmax 4
cwmin 3 cwmax 4
AC_VO cwmin 2 cwmax 3
cwmin 2 cwmax 3
wme
aifs
aifs
aifs
aifs
aifs
aifs
aifs
aifs
txopLimit
txopLimit
txopLimit
txopLimit
txopLimit
txopLimit
txopLimit
txopLimit
3008
3008
1504
1504
See section 2.5.2.5 for details on the parameters output.
2.5.3.3
Deleting a VAP
The delete interface is the simplest interface. Note that the VAP must be down to avoid any unpleasant interaction with
other VAPs prior to deleting. The form of the command is as follows:
# wlanconfig athN destroy
This command applies only to the VAP interface specified.
66
PRELIMINARY
AP Configuration Guide
3.1
AP Modes of Operation
The Access point can operate in several modes, including single or dual concurrent, multiple VAP, and with or without
WDS support. In addition, the channel mode (band selection and channel width) can be operated in one of several
configurations. Finally, the AP can be configured with several network options, including bridged mode and router
mode. The total operating state of the AP consists of the settings of the various subsystems that make up the AP. The
following sections define the various options to be specified, and the operating modes that can be employed on the AP.
3.1.1 Network Configuration
The network configuration portion of the configuration involves the way the Ethernet interfaces on the AP are
configured. All reference designs have both a WAN port (single Ethernet interface) and a LAN port (typically a 4 port
switch configured). These ports are configured as separate interfaces in the OS, typically designated eth0 and eth1.
Network configuration defines how the interfaces are assigned addresses, ether statically or remotely, and how the
packets received on the interfaces are routed to the other interfaces in the system.
The network configuration is usually set up by environmental variables in the /etc/ath/apcfg file, typically
WAN_MODE. While most of the configuration scripts expect the user to dynamically define the environmental
variables, the WAN_MODE and associated variables are usually set once in the /etc/ath/apcfg file and left. Note that the
settings are automatically picked up at bootup as part of the rcS script, so the user will not have to run anything once the
AP comes up.
3.1.1.1
Bridged Mode
The most common mode used is “bridged” mode. This is where the Ethernet interfaces are not assigned IP
addresses, but rather is included in a bridge group using the Linux brctl utility. To set up bridged mode, the
following environmental variables have to be set in the /etc/ath/apcfg file:
WAN_MODE=bridged
AP_IPADDR=ip address of the bridge
AP_NETMASK=netmask for the subnet
3.1.1.2
Static IP address Mode
If bridging is not desired, then each interface can be provided with its own IP address and the bridge
eliminated. Normally, a routing stack is not included in the distribution package, but the standard iptables
routing mechanism can be installed (see the Fusion QuickStart Guide). To configure this mode, set the
following variables in the /etc/ath/apcfg file:
WAN_MODE=static
WAN_IPADDR=ip address of the WAN Interface
WAN_NETMASK=netmask for the WAN
AP_IPADDR=ip address of the LAN Interface
AP_NETMASK=netmask for the LAN Interface
3.1.1.3
DHCP Client
When it is desired to obtain the IP address via DHCP, the WAN interface can be configured as a DHCP client.
Note that the LAN interface is always assumed to be either bridged or statically defined, so the scripts do not
support DHCP on the LAN interface. To configure the DHCP client on the WAN interface, set the following
variables in the /etc/ath/apcfg file.
WAN_MODE=dhcp
AP_IPADDR=ip address of the LAN Interface
AP_NETMASK=netmask for the LAN Interface
3.1.1.4
DHCP Server
The scripts do not support bringing up the DHCP server automatically. This can be added as a configuration
step if desired, since the dhcpd utility is provided. The configuration file is located at /etc/udhcpd.conf, and
should be configured as required for your network configuration.
67
PRELIMINARY
3.1.2 Radio Configuration
As part
of the WLAN bringup
g p script,
p , several environmental variables need to be set to configure the radio.
Most have default settings that are defined in Table 2 AP Environmental Variable
g The Access Point can
The most important
environmental variable for radio configuration
is the channel mode setting.
in several modes. The selection of the mode is generally
y made usingg the AP
_CHMODE and AP
_CHMODE_2
operate
AP_CHMODE
AP_CHMODE_2
pparameters. Thus AP_CHMODE_2
AP_CHMODE_2 is onlyy valid for dual
environmental variables. These are Radio level configuration
There are three major
j modes: Legacy
g y mode,, 11n Static HT 20 mode,, and 11n HT 20/40
concurrent configurations.
g mode and band selection ((2.4 GHz vs. 5 GHz)) are also
mode. Channel Bandwidth is selected byy the corresponding
indicated by the mode value. The following table shows the corresponding configuration for each channel mode.
Table 12 Channel Mode Parameters
Mode Type
Name
Band
Channel
Bandwidth
Legacy
11A
5 GHz
10 MHz
11B
2.4 GHz
10 MHz
11G
2.4 GHz
10 MHz
11NAHT20
5 GHz
20 MHz
11NGHT20
2.4 GHz
20 MHz
11NAHT40PLUS
5 GHz
40 MHz
11NAHT40MINUS
5 GHz
40 MHz
11NGHT40PLUS
2.4 GHz
40 MHz
11NGHT40MINUS
2.4 GHz
40 MHz
11n HT 20
11n HT 40
Note that if the channel is set to HT 40 mode, it still can support “lower” mode, e.g. stations requesting HT 20 channel
support can associate at the HT 20 rates, and so on. Thus the HT 40 mode will support both HT 20 an Legacy rates also.
3.1.3 Operating Mode
The operating mode of the AP controls the major features that are available on the AP. To select the operating mode, the
environmental variable AP_STARTMODE must be configured. The available starting modes are defined here.
Table 13 Starting Mode Parameters
Mode
Description
standard
Starts a single VAP on a single radio.
rootap
Configures a VAP as a root WDS VAP. See section 3.5 for details
client
Configures the AP to operate as a remote WDS client. Used for
implementing WiFi bridge between two Ethernet subnets. See
section 3.5 for details
repeater
Configures the AP to operate as a remote WDS repeater.. Used to
extend the BSS area with the same SSID for transparent roaming..
See section 3.5 for details
multi
Multiple BSS on the same radio. See section 3.4 for details
dual
Multiple BSS with Dual concurrent radios. See section 3.6 for
details.
68
PRELIMINARY
3.2
Security
The AP will support various security modes including WEP, WPA, WPA2, and WPA Enterprise modes. WPA/WPA2
modes will support both AES and TKIP encryption methods.
3.2.1 WEP Configuration
To configure an AP or Station for WEP operations, one will edit the WEP.conf file in /etc/ath/ and set the key values as
required. This is a simple script file that gets the AP name passed as an argument. Both AP and Client side can be
configured for WEP mode. Note that use of WEP will limit the link to legacy rates – WEP is not supported for HT rates.
Also, WEP MUST be on the first VAP (aht0) to be effective. This is due to a key cache limitation on the OWL
hardware. Therefore, a warning will be issued if WEP is configured for any other VAP than ath0.
Example: Setting up an AP VAP for WEP
This will create a VAP on channel 6 with an SSID of Atheros_XSpan, using WEP security mode with the default
values in the WEP.conf file
# export AP_SECMODE=WEP
# export AP_SECFILE=WEP.conf
# apup
3.2.2 WPA
The WPA configurations apply to both Client and AP sides. WPA can be configured for either pre shared key (PSK)
mode, or for Enterprise (EAP) mode. Pre shared key indicates that the key information is kept in both the AP and the
client side. For Enterprise WPA, a Radius server or other remote authentication server is required for the AP to
communicate with the authentication server the connection.
3.2.2.1
Enabling WPA Preauthorization (AP only)
This feature is controlled by the .conf file for hostapd. This file has two parameters that must be set, rsn_preauth and
rsn_preauth_interface. The first enables the feature, and the second indicates the specific interfaces where preauth
frames will be received from other routers. Ensure this is configured in the file prior to starting the apup script.
rsn_preauth=1
rsn_preauth_interfaces=br0
69
PRELIMINARY
3.2.2.2
WPA PSK
To enable WPA PSK on the VAP, set the AP_SECMODE variable to WPA, and select the proper security parameter
file. For the AP side, this file is located at /etc/ath/wpa2-psk.conf. For the client side, this file is located at /etc/ath/wpapsk.conf.
Note that the file formats are very different. This is because the AP side uses the hostapd program to perform the host
side protocol, and the client side uses the wpa_supplicant to perform the client side of the protocol. Note that the key
values must match. Also, the scripts will edit the files and replace the interface name and the SSID with the correct
values for the VAP being set up, so these do not need to be changed.
Example: Setting up an AP VAP for WPA-PSK
This will create a VAP on channel 6 with an SSID of Atheros_XSpan, using WPA-PSK security mode with
the default values in the wpa2-psk.conf file
# export AP_SECMODE=WPA
# export AP_SECFILE=wpa2-psk.conf
# apup
Example: Setting up the client side of a repeater for WPA-PSK
This will create a pair of VAPs on channel 6 with an SSID of Atheros_XSpan (one AP and one client), using
WPA-PSK security mode with the default values in the wpa2-psk.conf file for the AP and the default values
in wpa-psk.conf for the client side.
3.2.2.3
export
export
export
export
export
apup
AP_STARTMODE=repeater
AP_SECMODE=WPA
AP_SECFILE=wpa2-psk.conf
AP_SECMODE_2=WPA
AP_SECFILE_2=wpa-psk.conf
WPA Enterprise
The WPA-enterprise configurations can be quite complicated, depending on the configuration required. A single
configuration file, wpa2EAP.conf is provided for configuring the system in this mode. The interface name and the SSID
will be automatically updated for the VAP when brought up, but the other parameters (such as security server IP address
and port) will need to be edited in the file to conform to the configuration being used. No configuration file has been
provided for the Linux client side at this time.
Example: Setting up an AP VAP for WPA Enterprise
This will create a VAP on channel 6 with an SSID of Atheros_XSpan, using WPA Enterprise security mode
with the default values in the wpa2EAP.conf file
# export AP_SECMODE=WPA
# export AP_SECFILE=wpa2EAO.conf
# apup
3.2.3 WSC Configuration
WSC (Wireless Simple Configuration), aka WPS, is a method of setting up a WPA network without having to have the
user perform configuration of the AP or the client. This is intended as an extended user feature. Also, note that the WSC
support is not included in the default build. This is because the WSC files are extremely large, and will take up a large
footprint in the flash. It is recommended that WSC be included only if it is to be used.
3.2.3.1
3.2.3.2
Including WSC in the build
To include WSC in the build, you must edit the LSDK file in the build/scripts/(board type)/Makefile.(board
type), where (board type) is one of ob42, pb42 or pb44, depending on which evaluation board you have. The
“common_build” rule should have “hostapd” replaced with “wsc” (note that wsc will include the hostapd file
as a dependency). After making the edit, do a full build of the file system.
Activating WSC support on the AP
This example shows how to enable WSC mode on the default AP
# export AP_SECMODE=WSC
# apup
70
PRELIMINARY
3.3
VLAN Configuration
The Linux utility “vconfig” is provided to enable IEEE 802.1QVLAN support. A VLAN is a “virtual” network that
coexists over an actual physical interface, but only stations that are configured to interface to the VLAN participate in
network traffic on the VLAN. Normally VLANs have a DHCP server that provides an IP address for the VLAN
interface. Typically, some sort of security is required to start participation on a VLAN, but this is the responsibility of
higher layers (such as the DHCP server).
The APUP script is can configure the AP with VLANS in mBSSID mode. To configure VLANS, AP_STARTMODE
need to be set to multivlan and variables AP_VLAN, AP_VLAN_2, AP_VLAN_3 and AP_VLAN_4 need to be set to
corresponding VLAN tag values. For security support AP_SECMODE and AP_SECFILE variables need to be set and
corresponding security feature will be activated on tagged interface.
export
export
export
export
export
export
export
export
export
export
export
export
apup
AP_STARTMODE=multivlan
AP_SSID=FirstSSID
AP_VLAN=2
AP_SSID_2=SecondSSID
AP_VLAN=3
AP_SSID_3=ThirdSSID
AP_SECMODE_3=WPA
AP_SECFILE_3=wpa2-psk.conf
AP_SSID_4=FourthSSID
AP_VLAN_4=10
AP_SECMODE_4=WPA
AP_SECFILE_4=wpa2EAP.conf
After “apup” necessary bridges with names br2 , br3, br4 and br5 will be configured with corresponding tagged
athx.tag , eth0.tag and eth1.tag interfaces. The remainder of this section explains Linux commands to
configure singe VLAN interface on AP.
The vconfig command is quite straightforward. The following commands are used (taken from the Linux MAN pages).
Note the added # to indicate the command prompt:
To Add an interface to a VLAN
#vconfig add [interface-name] [vlan-id]
creates a vlan-device on [interface-name] (typically ath0 or ath1 in our scenarios). The
resulting vlan-device will be called according to the naming convention set.
To remove a VLANinterface
#vconfig rem [vlan-device]
Removes the named vlan-device
To configure the VLANinterface
#vconfig set_flag [vlan-device] 0 | 1
When 1, Ethernet header reorders are turned on. Dumping the device will appear as a common Ethernet device
without VLANs. When 0(default) however, Ethernet headers are not reordered, which results in vlan tagged
packets when dumping the device. Usually the default gives no problems, but some packet filtering programs
might have problems with it
#vconfig set_egress_map [vlan-device] [skb-priority] [vlan-qos]
This flags that outbound packets with a particular skb-priority should be tagged with the particular vlan priority
vlan-qos. The default vlan priority is 0.
#vconfig set_ingress_map [vlan-device] [skb-priority] [vlan-qos]
This flags that inbound packets with the particular vlan priority vlan-qos should be queued with a particular
skb-priority. The default skb-priority is 0.
#vconfig set_name_type VLAN_PLUS_VID | VLAN_PLUS_VID_NO_PAD | DEV_PLUS_VID | DEV_PLUS_VID_NO_PAD
Sets the way vlan-device names are created. Use vconfig without arguments to see the different formats.
Additional description of VLAN configuration can be found at the URL:
http://www.linuxjournal.com/article/7268
71
PRELIMINARY
3.3.1 Bridge Configuration in mBSSID and VLAN mode
If one prefers to use commands to configure VLANs in mBISSID mode. The following bridge configuration need to be
achieved. APUP script can get the following configuration when AP_STARTMODE is set to multivlan and
corresponding VLAN tag values.
br0 with no interfaces
br2 with ath0.second_tag, eth0.second_tag, eth1.second_tag
br3 with ath1.third_tag, eth0.third_tag, eth1.third_tag
br4 with ath2.fourth_tag, eth0.fourth_tag, eth1.fourth_tag
br5 with ath3.fifth_tag, eth0.fifth_tag, eth1.fifth_tag
For all other IP communications IP address need to be assigned to eth0.
Here is sample the output from ‘brctl show’ command when configured in multivlan mode.
3.4
bridge name
br5
bridge id
8000.0e037f0ca088
STP enabled
no
br4
8000.0a037f0ca088
no
br3
8000.06037f0ca088
no
br2
8000.00037f0ca088
no
interfaces
eth0.5
ath3.5
eth0.4
ath2.4
eth0.3
ath1.3
eth0.2
ath0.2
Multiple BSS
The design of the Atheros driver allows for the association of multiple VAP instances to a single ath hardware instance.
This is called Multiple BSSID, or mBSSID. The repeater case is an example of an mBSSID configuration. These are
typically used to create separate classes of interfaces (one secure, the other open) to allow a single AP to perform
multiple roles.
The scripting system has been designed to support mBSSID configurations through defining environmental variables. It
is assumed that no client type VAPs will be created for the mBSSID cases. This can be revisited in future releases.
To configure multiple VAPs, all relevant environmental variables must be configured. For the AP_SSID,
AP_SECMODE, and AP_SECFILE variables, extended versions with _2, _3, and _4 appended are provided to specify
the configuration for the appropriate VAP. To enable a specific VAP instance, you simply need to define the AP_SSID
variable for the instance (VAP 1 is always assumed to be defined). VAP instances must be defined in order, e.g. it is
illegal to define VAP 2 and VAP 4 without defining VAP 3.
For this release, the beacon interval is automatically set to 400 microseconds when defining multiple VAPs. This is to
support spreading of beacons out to reduce impact on traffic.
3.4.1 Multiple Open APs
This configuration is a simple creation of a number of VAPs using no security modes. The following example shows the
creation of 4 VAPs with different SSIDs. Note that ALL VAPs must be on the same channel, and will have the same RF
parameters. This is a property of the shared ath object, and cannot be multiply defined.
export
export
export
export
export
apup
AP_STARTMODE=multi
AP_SSID=FirstSSID
AP_SSID_2=SecondSSID
AP_SSID_3=ThirdSSID
AP_SSID_4=FourthSSID
72
PRELIMINARY
3.4.2 Multiple APs With Different Security Modes
This example shows how a set of VAPs with different security modes can be defined. NOTE THAT THE WEP VAP IS
ATH0. This is required due to hardware limitations.
export
export
export
export
export
export
export
export
export
export
export
export
apup
AP_STARTMODE=multi
AP_SSID=AP_wep
AP_SECMODE=WEP
AP_SECFILE=WEP.conf
AP_SSID_2=AP_open
AP_SECMODE_2=NONE
AP_SSID_3=AP_psk
AP_SECMODE_3=WPA
AP_SECFILE_3=wpa2-psk.conf
AP_SSID_4=AP_eap
AP_SECMODE_4=WPA
AP_SECFILE_4=wpa2EAP.conf
3.4.3 Changing Parameters in mBSSID Modes
It is highly recommended that the environmental variable method for configuring the AP be used. Since the ATH object
is shared, any configuration change that causes changes in the ATH object will also affect all defined VAPs. Some of
these changes can cause unstable behavior if the VAPs are running while they are made. Therefore, if ANY
configuration change is to be made, ALL VAPs must be brought down using ifconfig, and brought back up after the
configuration changes have been made.
3.5
Wi-Fi Distribution System (WDS)
The WDS system is used to create a network of AP’s that can be used as a single “virtual” AP. This is accomplished by
the 4 address frame format as specified by the 802.11 specification, in conjunction with layer 2 bridging implemented in
the AP. The MAC frames are forwarded to the appropriate AP based on the final destination MAC address provided.
WDS is essentially a tunneling protocol, and is unique to 802.11 implementations.
Several configurations can be implemented, as outlined in the following sections. All rely on a “root” AP device that is
the center of a “star” configuration of nodes.
3.5.1 AP With Single WDS Repeater
This configuration provides a single RF repeater station/AP that is used to bridge between a root AP and remote clients.
The repeater will have two VAPs: one that is a STA that connects to the root AP, and one that provides an Access Point
for the remote stations to associate to. The link between the Repeater and the Root AP uses the WDS mechanism with 4
address frames.
Laptop computer
(STA)
Laptop computer
ATH1
ATH0
Ethernet
ATH0
Root AP
Laptop computer
(STA)
Repeater
Laptop computer
3.5.1.1
Laptop computer
(STA)
Limitations
When running in repeater mode, the following limitations apply:
VAP configuration after start are subject to the conditions specified in
section 3.4.3 and section 0
Use the environmental variable method to configure the VAPs.
Atheros Communications, Inc.
COMPANY CONFIDENTIAL
Atheros AP System User’s Guide •
Jan 2009
73
73
PRELIMINARY
3.5.1.2
Setup Instructions
This mode requires a different configuration file in the root AP and in the repeater. The root AP is responsible for the
main “distribution” of the data packets. Each repeater will pass packets to its associated STA clients. Note that a station
will associate with the AP with the strongest signal – associating to the Root AP is allowed. Ensure you are using hard
wired connections if you are trying to force a specific configuration.
Also note that the IP addresses of the root AP and the repeater must be different, but on the same subnet. DHCP should
be enabled on only one of the routers (the root AP), or on a separate device attached to the network. Finally, both units
must have the same SSID to form a single BSS. If you want to specify a specific channel or SSID for the setup, ensure
you include all required environmental variable definitions (e.g. AP_SSID, AP_PRIMARY_CH, AP_CHMODE) before
you start apup.
Configuring the Root AP
The following will set up a root AP using the default SSID on channel 6.
# export AP_STARTMODE=rootap
# apup
Configuring the repeater
The following will set up a repeater using the default SSID on channel 6.
# export AP_STARTMODE=repeater
# apup
Ensure both systems are set up prior to starting the APs. The Root AP and the repeater can be started in any order.
Ensure the clients for a system under test associate with the repeater by either using a “hard wired” air interface, ensuring
the repeater signal is greater than the Root AP signal at the clients, or by using a hardware “air” interface.
3.5.2 AP with Multiple Repeaters
This is the extended version of the previous configuration. Multiple repeaters can be associated with a single Root AP,
providing a larger coverage area. This type of configuration is designed to be used in situations where the two repeater
stations do not “see” each other, therefore there is typically no link between the repeaters themselves – all traffic goes
through the Root AP. Testing should be accomplished in the same manner – the two repeaters should not “see” each
other.
Laptop computer
(STA)
ATH0
ATH1
Repeater
Laptop computer
Laptop computer
(STA)
ATH0
Ethernet
Root AP
Laptop computer
(STA)
Laptop computer
ATH1
ATH0
Repeater
Laptop computer
(STA)
74
PRELIMINARY
3.5.2.1
3.5.2.2
Limitations
When running in the multiple repeater mode, the following limitations apply:
VAP configuration after start is subject to the conditions specified in
section 3.4.3 and section 0.
Use the environmental variable method to configure the VAPs.
Setup Instructions
This configuration is set up in the same manner as the previous configuration. Note that each repeater must have a
unique IP address, on the same subnet. The SSID for both repeaters, as well as the Root AP must be identical to form a
BSS. The root AP controls the security mode, so ensure both repeaters are set up to be consistent with the Root AP.
Ensure that the repeaters have the AP_STARTMODE environmental variable set to “repeater”, as shown in section
3.5.1.2. The root AP is configured with the same setup as in section 3.5.1.2. The AP’s can be started in any order. To
ensure that the repeater stations associate to the root AP (and not each other, since they are using the same SSID), define
the ROOTAP_MAC environmental variable in the form xx:xx:xx:xx:xx:xx. This is required to force association to the
root AP. This is only required in this situation where multiple repeaters have the same SSID, and may accidentally be
closer than the root AP to another repeater AP.
3.5.3 WDS Bridge with single span
This configuration is a wireless bridge between two Ethernet subnets. This configuration uses the WDS feature to
provide the bridging. Client stations can either be attached to one of the two Ethernet subnets, or can associate directly
with the Root AP. The latter case is not typically tested in this configuration, but is not disallowed. This situation is
different from the repeater mode in that the Station node does not also have an AP VAP, so no station can associate with
the station (no Ad-Hoc allowed). This makes either the WDS link, or the Ethernet links the only way traffic enters/exits
the AP.
This solution is typically used in cases where the user wants to join subnets that are located a distance from each other,
or in a home situation where it is preferable not to run wires between rooms. Only one of the servers on this network
should be serving DHCP addresses – typically the Root AP.
Laptop computer
Laptop computer
Laptop computer
Ethernet
Ethernet
Root AP
WDS STA
Laptop computer
3.5.3.1
Laptop computer
Limitations
When running in the WDS Bridge mode, the following limitations apply:
VAP configuration after start is subject to the conditions specified in
section 3.4.3 and section 0.
Use the environmental variable method to configure the VAPs.
75
PRELIMINARY
3.5.3.2
Setup Instructions
To create this configuration, the Root AP and the Client must be configured accordingly. The root AP configuration is
identical to that used in the repeater case. The Client setup however, is set to “client” mode vice “repeater” mode. This
creates only a single station VAP that associates with the Root AP. Again, to setup different channel/SSID
configurations, ensure the proper environmental variables are set.
Configuring the Root AP
The following will set up a root AP using the default SSID on channel 6.
# export AP_STARTMODE=rootap
# apup
Configuring the repeater
The following will set up a client using the default SSID on channel 6, associating with a particular root AP.
# export AP_STARTMODE=client
# export ROOTAP_MAC=00:03:04:32:45:56
# apup
Again, the client AP and the root AP must have the same SSID to form a BSS, but unique IP addresses. Once
configured, the APs can be started in any order. Note that if a client is attached to a remote subnet, and the root AP is the
DHCP server, that the remote clients will not get a DHCP address until the root AP is up, and the client AP is associated
with it.
3.5.4 WDS Bridge with multiple span
As with the repeater case, the multiple-WDS Bridge scenario is an extension of the single bridge scenario. Multiple AP
clients associate with a single root AP, which provides the center of a “star” network topology. In this situation, the
stations are used to link multiple Ethernet subnets into a single large subnet. Again, only a single DHCP server is
allowed in this configuration. The Root AP can have other stations associate with it in the normal manner.
Laptop computer
Ethernet
WDS STA
Laptop computer
Laptop computer
Ethernet
Laptop computer
Root AP
Laptop computer
Laptop computer
Ethernet
WDS STA
Laptop computer
3.5.4.1
Limitations
When running in the WDS Bridge mode, the following limitations apply:
VAP configuration after start is subject to the conditions specified in 3.4.3
and section 0.0
Use the environmental variable method to configure the VAPs.
76
PRELIMINARY
3.5.4.2
Setup Instructions
Setup is identical to the single span case. All clients must have the client configuration in apcfg, each must have an
unique IP address, but all must be configured with the same SSID. The root/clients can be started in any order.
3.6
Dual Concurrent Operations
Dual concurrent operations go hand in hand with multiple VAP operations, because to operate in dual concurrent mode
multiple VAPs must be instantiated. These VAPs can have the same SSID and security configurations, but will have
different MAC addresses. Further, the hardware must support dual concurrent mode in that it has multiple physical WiFi
chipsets implementing individual radio interfaces. The VAPs have to be assigned to a specific
interface. The followingg
example
p will create an AP operating
g in the 2.4 GHz band on the wifi0 interface, and an AP operating in the 5.0 GHz
band with the same ESSID on the wifi1 interface:
export
export
export
export
export
apup
AP_STARTMODE=multi
AP_SSID=DualAP
IF_NUM=0:RF:11:11G
AP_SSID_2=DualAP
IF_NUM_2=1:RF:36:11NGHT40PLUS
77
PRELIMINARY
Appendix A Country Code Definition
The following table identifies the country definition, country string, and country code used to set the country ID for
802.11 and regulatory requirements.
Table 14 Country Code Definition
Country Define
Country String
Country ID
CTRY_DEBUG
"DB"
CTRY_DEFAULT
"NA"
CTRY_ALBANIA
"AL"
CTRY_ALGERIA
"DZ"
12
CTRY_ARGENTINA
"AR"
32
CTRY_ARMENIA
"AM"
51
CTRY_AUSTRALIA
"AU"
36
CTRY_AUSTRALIA2
5000
CTRY_AUSTRIA
"AT"
40
CTRY_AZERBAIJAN
"AZ"
31
CTRY_BAHRAIN
"BH"
48
CTRY_BELARUS
"BY"
112
CTRY_BELGIUM
"BE"
56
CTRY_BELIZE
"BZ"
84
CTRY_BOLIVIA
"BO"
68
CTRY_BOSNIA_HERZEGOWINA
"BA"
CTRY_BRAZIL
“BR”
76
CTRY_BRUNEI_DARUSSALAM
"BN"
96
CTRY_BULGARIA
"BG"
100
CTRY_CANADA
"CA"
124
CTRY_CANADA2
5001
CTRY_CHILE
"CL"
CTRY_CHINA
"CN"
152
CTRY_COLOMBIA
"CO"
170
CTRY_COSTA_RICA
"CR"
191
CTRY_CROATIA
"HR"
CTRY_CYPRUS
"CY"
196
CTRY_CZECH
"CZ"
203
CTRY_DENMARK
"DK"
208
CTRY_DOMINICAN_REPUBLIC
"DO"
214
CTRY_ECUADOR
"EC"
218
CTRY_EGYPT
"EG"
818
CTRY_EL_SALVADOR
"SV"
222
78
PRELIMINARY
CTRY_ESTONIA
"EE"
CTRY_FAEROE_ISLANDS
233
234
CTRY_FINLAND
"FI"
246
CTRY_FRANCE
"FR"
250
CTRY_FRANCE2
"F2"
255
CTRY_GEORGIA
"GE"
268
CTRY_GERMANY
"DE"
276
CTRY_GREECE
"GR"
300
CTRY_GUATEMALA
"GT"
320
CTRY_HONDURAS
"HN"
340
CTRY_HONG_KONG
"HK"
344
CTRY_HUNGARY
"HU"
348
CTRY_ICELAND
"IS"
352
CTRY_INDIA
"IN"
356
CTRY_INDONESIA
"ID"
360
CTRY_IRAN
"IR"
364
CTRY_IRAQ
368
CTRY_IRELAND
"IE"
372
CTRY_ISRAEL
"IL"
376
CTRY_ITALY
"IT"
380
CTRY_JAMAICA
388
CTRY_JAPAN
"JP"
392
CTRY_JAPAN1
"J1"
393
CTRY_JAPAN2
"J2"
394
CTRY_JAPAN3
"J3"
395
CTRY_JAPAN4
"J4"
396
CTRY_JAPAN5
"J5"
397
CTRY_JAPAN6
"J6"
399
CTRY_JAPAN7
"JP"
4007
CTRY_JAPAN8
"JP"
4008
CTRY_JAPAN9
"JP"
4009
CTRY_JAPAN10
"JP"
4010
CTRY_JAPAN11
"JP"
4011
CTRY_JAPAN12
"JP"
4012
CTRY_JAPAN13
"JP"
4013
CTRY_JAPAN14
"JP"
4014
CTRY_JAPAN15
"JP"
4015
CTRY_JAPAN16
"JP"
4016
79
PRELIMINARY
CTRY_JAPAN17
"JP"
4017
CTRY_JAPAN18
"JP"
4018
CTRY_JAPAN19
"JP"
4019
CTRY_JAPAN20
"JP"
4020
CTRY_JAPAN21
"JP"
4021
CTRY_JAPAN22
"JP"
4022
CTRY_JAPAN23
"JP"
4023
CTRY_JAPAN24
"JP"
4024
CTRY_JAPAN25
4025
CTRY_JAPAN26
4026
CTRY_JAPAN27
4027
CTRY_JAPAN28
4028
CTRY_JAPAN29
4029
CTRY_JAPAN30
4030
CTRY_JAPAN31
4031
CTRY_JAPAN32
4032
CTRY_JAPAN33
4033
CTRY_JAPAN34
4034
CTRY_JAPAN35
4035
CTRY_JAPAN36
4036
CTRY_JAPAN37
4037
CTRY_JAPAN38
4038
CTRY_JAPAN39
4039
CTRY_JAPAN40
4040
CTRY_JAPAN41
4041
CTRY_JAPAN42
4042
CTRY_JAPAN43
4043
CTRY_JAPAN44
4044
CTRY_JAPAN45
4045
CTRY_JAPAN46
4046
CTRY_JAPAN47
4047
CTRY_JAPAN48
4048
CTRY_JAPAN49
4049
CTRY_JAPAN50
4050
CTRY_JAPAN51
4051
CTRY_JAPAN52
4052
CTRY_JAPAN53
4053
CTRY_JAPAN54
4054
80
PRELIMINARY
CTRY_JAPAN55
4055
CTRY_JAPAN56
4056
CTRY_JORDAN
"JO"
400
CTRY_KAZAKHSTAN
"KZ"
398
CTRY_KENYA
"KE"
404
CTRY_KOREA_NORTH
"KP"
408
CTRY_KOREA_ROC
"KR"
410
CTRY_KOREA_ROC2
"K2"
411
CTRY_KOREA_ROC3
412
CTRY_KUWAIT
"KW"
414
CTRY_LATVIA
"LV"
428
CTRY_LEBANON
"LB"
422
CTRY_LIBYA
434
CTRY_LIECHTENSTEIN
"LI"
438
CTRY_LITHUANIA
"LT"
440
CTRY_LUXEMBOURG
"LU"
442
CTRY_MACAU
"MO"
446
CTRY_MACEDONIA
"MK"
807
CTRY_MALAYSIA
"MY"
458
CTRY_MALTA
470
CTRY_MEXICO
"MX"
484
CTRY_MONACO
"MC"
492
CTRY_MOROCCO
"MA"
504
CTRY_NETHERLANDS
"NL"
528
CTRY_NEW_ZEALAND
"NZ"
554
CTRY_NICARAGUA
558
CTRY_NORWAY
"NO"
578
CTRY_OMAN
"OM"
512
CTRY_PAKISTAN
"PK"
586
CTRY_PANAMA
"PA"
591
CTRY_PARAGUAY
600
CTRY_PERU
"PE"
604
CTRY_PHILIPPINES
"PH"
608
CTRY_POLAND
"PL"
616
CTRY_PORTUGAL
"PT"
620
CTRY_PUERTO_RICO
"PR"
630
CTRY_QATAR
"QA"
634
CTRY_ROMANIA
"RO"
642
81
PRELIMINARY
CTRY_RUSSIA
"RU"
643
CTRY_SAUDI_ARABIA
"SA"
682
CTRY_SERBIA_MONTENEGRO
891
CTRY_SINGAPORE
"SG"
702
CTRY_SLOVAKIA
"SK"
703
CTRY_SLOVENIA
"SI"
705
CTRY_SOUTH_AFRICA
"ZA"
710
CTRY_SPAIN
"ES"
724
CTRY_SRI_LANKA
"LK"
CTRY_SWEDEN
"SE"
752
CTRY_SWITZERLAND
"CH"
756
CTRY_SYRIA
"SY"
760
CTRY_TAIWAN
"TW"
158
CTRY_THAILAND
"TH"
764
CTRY_TRINIDAD_Y_TOBAGO
"TT"
780
CTRY_TUNISIA
"TN"
788
CTRY_TURKEY
"TR"
792
CTRY_UAE
"AE"
784
CTRY_UKRAINE
"UA"
804
CTRY_UNITED_KINGDOM
"GB"
826
CTRY_UNITED_STATES
"US"
840
CTRY_UNITED_STATES_FCC49
"US"
842
CTRY_URUGUAY
"UY"
858
CTRY_UZBEKISTAN
"UZ"
860
CTRY_VENEZUELA
"VE"
862
CTRY_VIET_NAM
"VN"
704
CTRY_YEMEN
"YE"
887
CTRY_ZIMBABWE
"ZW"
716
82
This device is intended for use under the following conditions:
1. The transmitter module may not be co-located with any other transmitter or antenna.
2. The module is approved using the FCC “unlicensed modular transmitter approval” method.
As long as these two conditions are met, further transmitter testing will not be required. However,
the OEM integrator is still responsible for testing their end product for any additional compliance
measures necessitated by the installation of this module (i.e. digital device emissions, PC
peripheral requirements, etc.).
Note: In the event that these conditions cannot be met (i.e. co-location with another transmitter),
then the FCC authorization is no longer valid and the corresponding FCC ID may not be used on
the final product.
The end user should NOT be provided with any instructions on how to remove or install the
modular. The following sentence has to be displayed on the outside of device in which the
transmitter module is installed "Contains FCC ID: TFJAG1311"

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.6
Linearized                      : Yes
Author                          : slee
Create Date                     : 2013:10:22 10:31:08+08:00
Modify Date                     : 2013:10:22 10:31:08+08:00
Title                           : 
XMP Toolkit                     : Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26
Metadata Date                   : 2013:10:22 10:31:08+08:00
Creator Tool                    : PScript5.dll Version 5.2.2
Format                          : application/pdf
Creator                         : slee
Document ID                     : uuid:ecad52d8-1dbc-45a1-890c-891935eaedce
Instance ID                     : uuid:cf10e945-a6f1-4fcd-b48a-7e0cbf206d68
Producer                        : Adobe Acrobat 10.1.7
Page Count                      : 83

EXIF Metadata provided by EXIF.tools

Uniform AG1311 Contactless Smart Card Reader Module User Manual

Uniform Industrial Corp. Contactless Smart Card Reader Module Users Manual

Users Manual

FCC ID Filing: TFJAG1311

Navigation menu

Namespaces

Views

Navigation