Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

ARM Processor Wireless Connectivity FAQ

From Texas Instruments Wiki
Jump to: navigation, search

1. Do I need to calibrate my device?

2. How can I run a continuous Tx from the wlan cu?

3. Does BT and WLAN require Calibration?

4. What tools should I use in order to run TX BiP?

5. How can I run Tx BIP (WLAN Calibration)?

6. Do I need to Re-Run Tx BIP every time?

7. What is the purpose of WL_RS232_TX and WL_RS232_RX signals?

8. What is the purpose of BT_WU and BT_HOST_WU?

9. BT - perform continuous transmission

10. Unable to run BT Init script

11. What is the diffrent between Beacon and DTIM?

12. What are the different power modes ?

13. How to control which data packets will get to the Driver?

14. How to configure which data packets will get to the Driver?

15. How to set a WPS-PIN security connection?

16. How to enable roaming?

17. Is it possible to enable High throughput and Block ACK at the WLAN station?

18. Can you please explain how to simulate MIC failure security attack?

19. Does WEP security type supported in 11n?

20. How to configure Rx Streaming?

21. How to set periodic scan (connection scan )?





HomepageIcon.jpgHOME

Do I need to calibrate my device?

There is no need to Calibrate the device , Assuming you have ran the Tx BIP and NVS was created, there is no need to calibrate the device, The Device runs periodic calibration while the firmware is running due to temperature, voltage and driver state (like new connection)

How can I run a continuous Tx from the WLAN CLI?

Load the driver and leave it disconnected from AP, follow the following steps:

  •   put device in Ative mode

/ w p 1 f 2

  • Tune to channel 11

/ t r h 0 11

  • In order to Tx in 11G mode (Rate 54M) you need to run the following command:

/ t r t n 2000 4096 1000 0 16375 0 3 0 0 4 0 0 1 1 11:22:33:44:55:66


  •  In order to Tx in 11N mode (MCS7) you need to run the following command:

/ t r t n 2000 1048576 1000 0 15875 0 3 0 0 6 0 0 1 0 11:22:33:44:55:66


  •  In order to Tx in 11B mode (Rate 11) you need to run the following command:
    / t r t n 2000 32 2048 0 22125 0 3 0 0 0 0 0 1 1 11:22:33:44:55:66 / q

Folowing is a short description of the command fields:
* 0 – Delay : 5000 ( 5 ms)
* 1 – Rate: 1 Mbps
* 2 – Size: 2000 bytes
* 3 – Amount: 0 (we are using continuous, no need to know how many we are sending)
* 4 – Power: 2000
* 5 – Seed: 10000
* 6 - Packet Mode: 3 (continuous)
* 7 - DCF On/Off: 0 (off)
* 8 – GI: 0 (long 800ns)
* 9 – Preamble: 1 (short)
* 10 – Type: 0 (Data)
* 11 – Scrambler: 0 (off)
* 12 - Enable CLPC: 0 (disabled)
* 13 - Sequence no. Mode: 1 (incremental)
* 14 - Destination MAC Address

BT & WLAN Calibration

Does BT and WLAN require Calibration?

Question:
It seems as BT core does not require any RF calibration. Is this the same for WLAN? Answer:
BT calibrations are applied as part of the init script as such there is no need to perform BT Calibration. However, WLAN calibrations need to be applied by the customer as part of a TX BiP (TX Built In Production line testing). The TX calibration aims to reduce/eliminate any temperature/voltage/process variations.

What tools should I use in order to run TX BiP?

there are two approaches.

  • using the Radio Scope tool. It connects directly to the WiLink chip via WL_RS232_TX and WL_RS232_RX lines. It requires the FW to be loaded to the chip.
  • using the WLAN_CU utility. This utility runs from the Linux command line. It requires not only FW uploading but also the WiLink driver to be loaded.

How can I run Tx BIP (WLAN Calibration)?

Tx BIT procedure

1) in case there is no Antenna connect a 50 Ohm termination on the RF connector.
2) Download the WLAN driver and bring up the CLI
3) Wake up the device by typing the folowing command in the CLI “/ w p 1 l 2 f 2”
4) Run the following TX BIP commands:
“/ t r h 0 7”
“/ t b b 375 128 0”
“/ t b t 1 0 0 0 0 0 0 0”
5) reset the Board after NVS FILE generation is completed.

Do I need to Re-Run Tx BIP every time?

No, Tx BIP should be run only once per platform, and and the data you get from it is saved to the NVS file, You do not need to run Tx BIP again for Costumer modifications in the INI file.

What is the purpose of WL_RS232_TX and WL_RS232_RX signals?

Question:
we’re planning to use the SDIO port to interface to the WLAN radio; do we need to use signals WL_RS232_TX and WL_RS232_RX? What is the purpose of these signals?
Answer:
WL_RS232_TX and WL_RS232_RX signals are UART signals used for RF testing. These lines are not needed for a regular operation of the chip and are solely used on the “ramp up” phase (early stages of a project in case there are issues with the RF). However, for RF debugging, it is recommended to mount test points for these lines.

What is the purpose of BT_WU and BT_HOST_WU?

Question:
If we’re planning to use the 4-wire UART to interface to the BT radio, what is the functionality of the signals BT_WU and BT_HOST_WU? Are they required?
Answer:
BT communication is applied over a common 4-wire UART interface. The additional two signals, BT_WU and BT_HOST_WU are used for a 6-wire UART support.
The WU stands for Wake Up, i.e. when the host desires to wake up the chip, it asserts BT_WU signal and when the chip desires to wake up the host, it asserts the BT_HOST_WU signal.
Please notice that TI proprietary deep sleep protocol (HCILL or eHCILL) is using 4-wire UART interface. Thus, unless 6-wire UART is a must from the host side, 4-wire UART is the interface to be used.

Bluetooth

BT - perform continuous transmission

Question:
I’m trying to send a Tx continuous command using the following vendor specific command: hcitool cmd 0x3F 0x0184 0x00 0x00 0x00 15 0x00 0x00. However, it returns with error. What is wrong?
Answer:
hcitool needs the exact number of bytes for all parameters. In this case, the two last parameters of the HCI_VS_DRPb_Con_TX command are 4 bytes each. Thus, the correct format is as follows: hcitool cmd 0x3F 0x0184 0x00 0x00 0x00 0x0f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00.

Unable to run BT Init script

Question:
I’m using BlueZ BT stack and applying the hciattach command. The arguments are as follows: hciattach /dev/ttyS1 texas. However, I cannot communicate with the chip. What is wrong? Answer:
A: according to the arguments you sent, you are using ttyS1 serial device with a default baud rate of 115,200. You need to verify that ttyS1 is physically connected to the correct UART port. In addition, you need to verify that the UART speed is not changed by a command in the init script (the speed on the command line must match the speed in the init script).

What is the diffrent between Beacon and DTIM?

Question:
Can you please list the diffrence between Beacon and DTIM
Answer:
DTIM (Delivery Traffic Indication Message) When any single wireless client associated with an access point has 802.11 power-save mode enabled, the access point buffers all multicast frames and sends them only after the next DTIM beacon, which may be every one, two, or three beacons. The DTIM interval can be set in the access point configuration. 802.11 power-save modes is optionally set by the user on the wireless client device, generally via the wireless client configuration utility or user interface. The use of DTIM intervals was put in the 802.11 standard to allow sleeping stations implementing the power-save function to know when to wake up and receive multicast traffic (i.e. after every DTIM beacon) and to allow flexible configuration of the network (i.e. DTIM interval) that offers a trade-off between battery life and performance. If none of the 802.11 radios associated with the access point has power-save mode enabled, then the access point will send multicast traffic immediately and will not wait until after the next DTIM beacon.

BEACON The beacon frame, which is a type of management frame, provides the "heartbeat" of a wireless LAN, enabling stations to establish and maintain communications in an orderly fashion. A typical beacon frame is approximately fifty bytes long, with about half of that being a common frame header and cyclic redundancy checking (CRC) field. As with other frames, the header includes source and destination MAC addresses as well as other information regarding the communications process. The destination address is always set to all ones, which is the broadcast Medium Access Control (MAC) address. This forces all other stations on the applicable channel to receive and process each beacon frame. The CRC field provides error detection capability. The beacon's frame body resides between the header and the CRC field and constitutes the other half of the beacon frame. Each beacon frame carries the following information in the frame body:

Beacon interval. This represents the amount of time between beacon transmissions. Before a station enters power save mode, the station needs the beacon interval to know when to wake up to receive the beacon (and learn whether there are buffered frames at the access point).

Timestamp. After receiving a beacon frame, a station uses the timestamp value to update its local clock. This process enables synchronization among all stations that are associated with the same access point. Service Set Identifier (SSID). The SSID identifies a specific wireless LAN. Before associating with a particular wireless LAN, a station must have the same SSID as the access point. By default, access points include the SSID in the beacon frame to enable sniffing functions to identify the SSID and automatically configure the wireless network interface card (NIC) with the proper SSID. Some access point vendors have an option to disable the SSID from being broadcast in beacon frames to reduce security issues

Supported rates. Each beacon carries information that describes the rates that the particular wireless LAN supports. As a result, an 802.11 station would stay within limits and not use other rates.

Parameter Sets. The beacon includes information about the specific signaling methods .For example, a beacon would include in the appropriate parameter set the channel number that an 802.11 access point is using

Capability Information. This signifies requirements of stations that wish to belong to the wireless LAN that the beacon represents. For example, this information may indicate that all stations must use WEP security in order to participate on the network.

Traffic Indication Map (TIM). An access point periodically sends the TIM within a beacon to identify which stations using power saving mode have data frames waiting for them in the access point's buffer. The TIM identifies a station by the association ID that the access point assigned during the association process.

What are the different power modes ?

Question:
Please explain the diffrence power modes supported by the TI solution
Answer:
Many wireless applications require long battery life without sacrificing network connectivity. As with any other network interface, powering down the TX module can lead to great power savings in wireless networks. While the TX is off, we can name it sleeping, dozing, or in power-saving mode (PS). While the TX is on, we can name it awake, active, or simply on.


802.11 mobile stations can maximize battery life by shutting down the radio transceiver and sleeping periodically. During the module sleeping periods, access points (AP's) buffers any unicast frames for the sleeping stations. These frames are announced by subsequent Beacon frames. Dozing stations must wake up periodically to retrieve buffered frames. Stations awaking from their slumber transmit a PS-Poll massage frame to the AP along with this request, awaking stations includes the association ID (AID) that indicates which BSS they belongs to, so the access point can determine which frames were buffered for them. The AID number that included in the PS-Poll frame can range from 1 to 2,007.

Access points may respond to the PS-Poll immediately after a short inter-frame space (SIFS), if the buffered frame is large, it may require fragmentation. Instead of an immediate response, access points can also respond with a simple acknowledgment. This is called a deferred response because the access point acknowledges the request for the buffered frame but doesn't respond immediately.

A station requesting a frame with a PS-Poll must stay awake until the requested frame is delivered (there is a time limit). Under contention-based service, however, the access point can deliver a frame at any point. After receiving a data frame, the station must remain awake until the next Beacon is transmitted. Beacon frames only note whether frames are buffered for a station and have no way of indicating the number of frames. Once the station receives a frame indicating that no more traffic is buffered, it can conclude that it has received the last buffered frame and return to a low-power mode. The station sends a "Null frame" massage, indicating that the station switch to low-power mode.

A station cannot switch to a low-power mode until it receives a Beacon frame in which its bit in the traffic indication map (TIM) is clear =0, meaning no more data. To receive broadcast and multicast frames, a mobile station must be awake for DTIM transmissions. Each BSS has a parameter called the DTIM Period - a special type of TIM, which is transmitted by the AP at a fixed number of Beacon intervals, in contrast to TIM's, transmitted with every Beacon. Buffered broadcast and multicast traffic are transmitted after a DTIM Beacon .The AP includes in the Beacon a massage flag that indicate he has a stored data for the station. A station can be configured to sleep for its listen period without regard to DTIM transmissions. This is determined as Enhanced Low Power (ELP), ultra power-saving mode, or deep sleep.

Different Power mode description:

  • Auto This is used for maximum power saving providing the best throughput. This mode toggles between the work modes (ACTIVE,SHORT_DOZE and LONG_DOZE) by its own internal algorithm. (Acts according to the ini file configuration).
  • Active power save, the host interface and the radio are always active. The station doesn't TX p.s poll packets to the AP at all
  • Short Dose is placed in ELP/PD Doze state and wakes at every beacon and if the AP has data its sends p.s poll to receive the AP stored data. The firmware wakes up the host for every beacon passes the data stored in the beacon to the driver /host and then returns to ELP/PD Doze.
  • Long Dose the system is placed in ELP/PD Doze state and the station wakes at every DTIM, This mode consumes the least power, while it still wakes for every specific number of beacons as defined by the AP DTIM.


We are also implemented “Beacon early termination feature”In this feature the firmware reads the first part of the beacon and discard the rest of beacon if the data isn't relevant, So upon internal values set at the device ini file,the firmware reads a complete beacon and deliver it to the driver.The following lines should be added to the tiwlan.ini file:
BetEnable = 1
MaxlFullBeaconReceptionInterval =XXX
For example if the AP Beacon interval =100ms and we want to upload full Beacon into the Driver every 5 Beacons ,we will set the interval time to=500.

BetEnable = 1
MaxlFullBeaconReceptionInterval = 500


How to control which data packets will get to the Driver?

ARP Request

In order to filter arp request and to answer only to exclusive arp request to the unit address please take the following steps:

1. Configure arp filtering mode = enabled, in the tiwlan.ini file

ArpIp_Filter_ena = 1

2. Configure the ARP fitering address in the tiwlan.ini file to match the Station IP address

for example if the WLAN port IP address is 10.1.4.6 set the ARP IP Address as followes:
ArpIp_Addr = 0a 01 04 06 
comment: use Hex small letters {e.g. 10.1.4.6 = 0a 01 04 06} 

3. After modifying tiwlan.ini file save the configuration and reboot the board
4. Now the Station will respond only to ARP request that are directed to it.

Filtering multicast packets

The target is to filter out multicast frame that are not directed to the Station.
The way to do it is by defining the Multicast filter Address to match the source MAC address
please follow these steps: 1.Configure Multicast Filtering mode = enabled in the tiwlan.ini file

Mac_Filter_Enabled = 1


2.Set the number of addresses to XXX. It can vary between 0 to 8. This value will define the number of address the Station will accept multicast data from them.

numGroupAddrs = XXX

Now need to enter the MAC address of the desired source that we want to accept multicast packets from them,please add this command at the tiwlan.ini file upon each MAC address that we want to accept:(for example)

 
Set Group_addr0 = 01 00 5e 00 00 01
Set Group_addr1 = 01 00 5e 00 00 02


3.If any change as been done at the tiwlan.ini file it has to be saved and need to reboot the Station
4.Now the Station will respond only to multicast packets intended only to him upon the MAC address that we add.
5.To disable Multicast Filtering mode please disabled in the tiwlan.ini file

Mac_Filter_Enabled = 0

6.If any change as been done at the tiwlan.ini file it has to be saved and need to reboot the Station

Filtering Beacon

Enabling of this feature will upload to the Station Driver only beacons from associate AP.
To enable the Beacon Filtering on the Station please type in Station CLI:

 / m n s 1

The beacon filtering should be activated only while the station is in power save mode.
It operates only on beacons with the TIM bit(Data for the Station) not set for the station.
If the TIM bit is set for the station,the beacon is always forward to the driver upon arrival.
If the filter is at enabled state, the beacons will be buffered in the FW until reaching the maximum number of beacons stored, and only then they will be forwarded to the driver.The maximum number of beacons stored can be configured from tiwlan.ini file and the parameter name is:

Beacon_Filter_Stored = 1

values can be vary from 0 to 8,default is = 1
If configured to 0,the beacons will be dropped.

How to configure which data packets will get to the Driver?

Question:
Please explain how to configure the driver to filter packets (s/w filter)?
Answer:
This feature known by the name PACKET FILTERING or WAKE ON LAN,is designed to block packets from going up from the firmware layer into the driver layer. The enabling of this feature requested two separate diffrent commands.
1. Enable the feature.
2. Configure the filter different variants.
If the filter is activated and the user didn't define the filter variants ,then all packets will be blocked from arriving to the driver layer.
The solution supports activation of up to 4 parallel filters, however usualy we will save one for the ARP request filter hence have additional 3 for user configuration filters.
In order to enable the filter feature please type at the CLI:

 / m v f e

In order to disable the filter feature please type at the CLI:

 / m v f d

In order to add the filter feature please type at the CLI:

 / m v f a <filter format>
filter format: <mask> <content>
<mask> string of 0 and 1
*0: ignore packet content byte that is located at that specific place 
*1: consider packet content byte that is located at that specific place,
 and compare to <content> field.

In order to remove the filter feature please type at the CLI:

 / m v f r <filter format> 

Packet format

Following is Ethernet packet general format, which is used as a reference to build the filter structure.

  1. Destination MAC address: Station MAC address
  2. Source MAC address: MAC address of the Source device connected to the WLAN network that generates the Packets to the Station (for example PC behind the AP)
  3. Protocol: for example IP protocol (0x0800)
  4. IP Protocol: for example ICMP (0x11)
  5. Source IP address: IP address of the Source device connected to the WLAN network that generates the Packets to the Station (for example PC behind the AP)
  6. Destination IP address: Station IP address
  7. Entire Data Payload

Packet format 1.jpg

Example - how to define ARP filter

In order to define a new packet filter it is advise to use an Ethernet sniffer s/w utility (Like WireShark or any other tool).The filter is define at Ethernet level as such using a sniffer to capture the desired packet will assist us defining the filter.
In order to design the filter we will use specific sub fields inside the packet and converts some of the parameters into hexadecimal format and use them at the filter message contents.
For example in order to filter out ARP request packets,we need to filter incoming messages only upon "IP Protocol" field. The value of the IP Protocol is (0x0806), as such the filter mask field have to be set to "1" in the appropriate place in the "IP Protocol" field place.
The other fields are not required for this type of filter ,so they will be set to value "0".
Filter:
•Protocol: ARP-IP (0x0806)
Parameters:
Offset = 0

• Mask And Data:

Protocol (Bytes 12-13)
Mask 11
Data 08 06

At the images below from the WireShark sniffer we can see step by step the ARP message content
Destination MAC address
Destination MAC image.jpg Source MAC address
Source MAC image.jpg Protocol
Type image.jpg
following is the CLI commands for implementing ARP filter:

 
/ m v f e 
/ m v f a 12 11 0806

In order to remove and disable this filter please type the folloeing CLI command.

 
/ m v f r 12 11 0806
/ m v f d


How to set a WPS-PIN security connection?

WPS-PIN security connection Background At CES 2007 in Las Vegas today, the Wi-Fi Alliance said it has certified the first products supporting Wi-Fi Protected Setup (WPS). This is an optional technology meant to make it easier for home and small office network operators – those without an IT staff — to deploy secure wireless LANs. WPS requires support of Wi-Fi Protected Access (WPA) or WPA2, a super-set of the 802.11i security specification from the IEEE. Legacy products with WPA/WPA2 only can still join the network, but they have to go through the usual extra steps required today. The setup of a WPS network is simple. Use a push button configuration (PBC) on the Wi-Fi router, or enter a 4- or 8-digit PIN code if there's no button. Each client laptop, camera, game device, phone, or what-have-you supporting WPS will come with a hard-coded PIN code. Set an initial client up to talk with the router/gateway and it becomes the master device used to enter PIN codes of other clients that want network access.
Question:
Can you please explain how to set a WPS-PIN connection with the TI solution?
Answer:
The support for this feature within Texas Instruments is listed at the following steps:
1.Generate a random pin code
2.Try to assosate with the desired AP
3.The driver s/w will genrate a random PIN nember
4.Enter the generated pin number at the AP sub menu
5.The driver will continue the connection process

1.At the CLI menu please type the following:

  / c p i 12345678

The respond will be
.../wPs> Pin, pBc, Stop, set pIn WPS PIN set 12345678
Now please type at the CLI menu:

/ c p p

The respond will be
.../wPs> Pin, pBc, Stop, set pIn WPS in PIN mode started
2.Now try to associate with the AP (in this example AP name is vic_BSS)

/ c c vic_BSS

3.The driver s/w will genrate a ramdom pin number that we should enter at the TI AP menu

Calculated checksum = 0, wsc_pin[7] = 8, Randomizing new PIN...
Random PIN: 3-2-5-4-7-9-1-7

The following print screens are captured from TI AP( should very for diffrent APs menus)
1.Click on refresh
Discover the wireless station at the TI AP menu

Discover.jpg

2.Please select the device upon MAC
Select the device

Chose.jpg

3.Please enter the PIN code genrated by the wireless station
Enter the PIN code
Enter the pin number.jpg


Now at the CLI menu you should get the following messages and by
the end of the process the connection should be established.

/ c c vic_BSS
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, poWer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
.../Connection> Bssid_list, Connect, Disassociate, Status, Full_bssid_list, wPs/
1
Trying to associate with SSID 'vic_BSS'
wsc_supplicant: Entered wsc_supplicant_associate
wsc_supplicant: wsc_supplicant_BuildProbeRequest: built 71 byte message
OK
Associated with 00:50:f1:00:18:63
CTRL-EVENT-EAP-STARTED EAP authentication started
EAP-WSC: Entered eap_wsc_init
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 254 (WSC) selected
EAP-WSC: Entered eap_wsc_process
EAP-WSC: EapWsc_BuildMsgM1: built 507 byte message
EAP-WSC: Entered eap_wsc_process
EAP-WSC: EapWsc_ProcessMsgM2: EapWsc_ProcessMsgM2 of 395 byte message
EAP-WSC: EapWsc_BuildMsgM3: EapWsc_BuildMsgM3 built 114 byte message
EAP-WSC: Entered eap_wsc_process
EAP-WSC: EapWsc_ProcessMsgM4: EapWsc_ProcessMsgM4 of 182 byte message
EAP-WSC: EapWsc_BuildMsgM5: EapWsc_BuildMsgM5 built 110 byte message
EAP-WSC: Entered eap_wsc_process
EAP-WSC: EapWsc_ProcessMsgM6: EapWsc_ProcessMsgM6 of 110 byte message
EAP-WSC: EapWsc_BuildMsgM7: EapWsc_BuildMsgM7 built 110 byte message
EAP-WSC: Entered eap_wsc_process
EAP-WSC: EapWsc_ProcessMsgM8: EapWsc_ProcessMsgM8 of 190 byte message
EAP-WSC: EapWsc_ProcessMsgM8: authType = 33
EAP-WSC: EapWsc_ProcessMsgM8: encrType = 8
EAP-WSC: EapWsc_BuildMsgDone: EapWsc_BuildMsgDone built 50 byte message
CTRL-EVENT-EAP-FAILURE EAP authentication failed
Trying to associate with SSID 'vic_BSS'
Associated with 00:50:f1:00:18:63
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully (based on lower layer success)
WPA: Could not find AP from TIWLAN: 473.556849: ************ NEW CONNECTION ************
the scan resultsTIWLAN: 473.563349: -- SSID  = vic_BSS

WPA: Key negotTIWLAN: 473.568445: -- BSSID = 0-50-f1-0-18-63
iation completedTIWLAN: 473.574732: ****************************************
 with 00:50:f1:00:18:63 [PTK=CCMP GTK=CCMP]
CTRL-EVENT-CONNECTED - Connection to 00:50:f1:00:18:63 completed (auth) [id=1 id_str=]

How to enable roaming?

Roaming Module
The roaming feature enables to a wireless station to roam between different Access Points based on certain roaming event triggers, while minimizing the amount of data loss. Roaming takes place before the link to the current AP is broken due to signal loss. Pre condition for roaming is roaming feature is in enabled state and there is a scan policy stored in the system (it will store the default Scan policy parameters). At the cli menu plese type:

/ g e 
/ a p s


In order to confirm roaming candidates please type at the CLI:

/ a p t


The station's ability to roam between AP’s is based on the assumption that another AP is available within the area with the same configuration (for example, SSID and encryption type) as the AP currently the station is connected to. If there is no such other AP available, roaming does not occur. Roaming applies to infrastructure (AP-->station) connections only (not for IBSS /Ad Hoc connections). In order to perform roaming between AP’s there should be several preconditions at the wireless station. An example of this is WPA2 Pre-Authentication and gathering of the neighbors AP list. The wireless station monitors the quality of connection to the network. When connection deterioration is detected, the event is signaled to the Roaming mechanism. Roaming is triggered by one of the following events:
Type 1 Event Low Receive Signal Strength Indicator (RSSI): The reception rate has fallen below a predetermined, user-defined threshold. Low Transmit Rate: A predetermined, user-defined minimum rate for transmission has been reached.
Type 2 Event
BSS Loss: A predetermined, user-defined number of beacons have been missed over a specific period of time and the AP did not acknowledge a predetermined, user-defined number of unicast packets. Consecutive TX Retry Limit Exceeded: A predetermined, user-defined number of packets have not been acknowledged. 802.11h Switch Channel Announcement: Radar was detected by the AP.
Type 3 Event
AP Disconnect: The AP De-Authenticates or Disassociates the Station. Security Attack: The Station detected security attack.
Tested functionality
Candidate AP selection process takes place when the first roaming trigger was received by the roaming process while the roaming process is not in the Handover phase. From the start of the Candidate AP selection phase till the end of the Handover phase any roaming triggers during the Roaming process are ignored. When the need to roam is detected, the roaming process notifies the Station functionality with prepare to Roaming indication. Roaming process obtains the list of candidate AP’s for roaming achieved from the scan manager. If there were no candidate APs found in the background scan, then immediate scan is invoked (Full/Partial). The immediate scan is done on all possible channels (Full), if there was no neighbor APs list, or only on the neighbor AP list (Partial). If the roaming trigger was of Type 1, then any AP with RSSI lower than the Quality threshold is removed from the list. The candidate AP selection process starts with the selection of the potential roaming candidates list and filters the list to select a single AP candidate. There are three types of handovers:
Fast handover: Reassociation to the new AP without full authentication, when CCKM AKM is used or WPA2 PMK, the 802.1x full authentication is skipped.
Full handover: Reassociation to the new AP with full authentication, when 802.1x authentication is required. In this handover, it is assumed that all the keys in the station have been erased and full authentication and key handshake is required.
Reconnect to current AP: In this handover the station reconnects the current AP, even though the station never de-authenticated it.Handover is performed on the selected AP. If no AP was found, even after performing immediate scan, then no handover is performed. These two cases are detailed below:
Selected AP Exists:
Roaming Trigger type 1 or Type 2: The station performs fast handover to the selected AP. Roaming Trigger type 3: The station performs full handover to the selected AP.
No AP is selected:
Roaming Trigger type 1: The station remains connected to the current AP, without performing any handover, only if it hasn't attempted a handover to a different AP. If such a handover has already been performed, then station re-connects to the current AP.
Roaming Trigger from Type 2 or Type 3: The station disconnects the current AP. In this case the roaming moves to IDLE state and the roaming initialization procedure should be performed.
Roaming setup

Roaming.jpg

Roaming sequence sniffer print screen At the below sniffer print screen you can watch roaming sequence. At the top part you can wathc the station leaving the AP and the AP Sends Deauth messages towards the staion.At the buttom part we can see the Reassoc between the new AP and the Station.In order to determine roaming sequence duration,we need to calculate the diffrence between the time tags (at the sniffer absolute time columm)of the Deauth and Reassoc messages

Roaming procedure.JPG

Scan Manager Module The scan manager is a software module in the MCP-WL6 1.0 platform. Its role is to maintain a list of available roaming candidates at all times to enable the fast roaming process. To do so, the scan manager continuously scans for access points (APs), using the configuration from the user mode application. The scan manager operates for a configurable period of time. It wakes up at each defined interval and performs scans as necessary to maintain the roaming candidates list. This list is populated according to discovery scan results and updated according to tracking scan results. At each defined interval, the scan manager initiates a tracking scan to track APs already available in the roaming candidate list. After tracking is complete, the scan manager removes APs from the roaming candidates list that were not found during the last few consecutive scans. The exact number of such scans is configurable. This operation is referred to as aging.If the number of APs in the roaming candidates list is less than a configurable threshold, the scan Manager initiates a discovery scan to find new APs.

How to use tiwlan_loader command line options?

This application is used as part of WLAN driver initialization sequence. tiwlan_loader copies the content of firmware.bin,tiwlan.ini and nvs_map.bin files into the WLAN driver internal structures.

The following is the list of possible options:

-e <filename> - eeprom image file name. default=./nvs_map.bin
-n - no eeprom file
-i <filename> - init file name. default=tiwlan.ini
-f <filename> - firmware image file name. default=firmware.bin

Example1: Loading NVS file from different location.

#tiwlan_loader -e /nvs_map.bin  


Example2: Loading tiwlan.ini and WL12xx firmware image from different location.

#tiwlan_loader -e ../nvs_map.bin -f /root/home/demo/firmware.bin 



INI file essentials

How to configure Auto/Manual connection mode in tiwlan.ini file?


1. Connection AUTO Mode - WLAN driver initiates SCAN automatically based on the configuration and selects an appropriate BSSID.

2. Connection MANUAL Mode - WLAN driver does not initiate SCAN operation and does not select a BSSID. In this the external application is responsible for SCAN for SCAN initiation , AP selection and establishing connection.

Example in tiwlan.ini file:

SmeConnectMode = 0 # Set Auto Connection Mode           
SmeConnectMode = 1 # Set Manual Connection Mode              


How configure supported rates?


Table of possible rates value:

Value Supported Rates
0 1,2 Mbps
1 1,2,5.5,11Mbps
2 1,2,5.5,11,22 Mbps
3 1,2,5.5,11,6,9,12,18 Mbps
4 1,2,5.5,11,6,9,12,18,24 Mbps
5 1,2,5.5,11,6,9,12,18,24,36 Mbps
6 1,2,5.5,11,6,9,12,18,24,36,48 Mbps
7 1,2,5.5,11,6,9,12,18,24,36,54 Mbps
8 1,2,5.5,11,6,9,12,18,24,36,54 Mbps
9 6,9,12,18,24,36,48,54 Mbps
10 1,2,5.5,11,6,9,12,18,24,36,54. MCS0-MCS7


Parameters used in INI file for rates configuration:

Parameter Name in INI file Default value Range
dot11SupportedRateMaskB 2 0-2
dot11SupportedRateMaskG 8 0-8
dot11SupportedRateMaskA 7 0-7
dot11SupportedRateMaskAG 9 0-9
dot11SupportedRateMaskN 10 10


Example (tiwlan.ini) file :

dot11SupportedRateMaskB = 1 # configure the following supported rates for B-only mode: 1,2,5.5,11 Mbps


Is it possible to enable High throughput and Block ACK at the WLAN station?


High throughput and Block ACK are integrated features within the WLAN release. The following parmeters should be by default at the tiwlan.ini file
Parmeters in tiwlan.ini file:

HT_Enable=1  # 0 = diable 802.11n support / 1=Enable
BaPolicyTid_0 = 3         

In order to confirm the changes at the throughput,please follow these steps:

  1. Confirm the parmeters listed above are valid at the tiwlan.ini file
  2. Enable "quality of service policy" and "WMM" features at your access point.
  3. verify Throughput improvement with traffic generation s/w utility like iperf.


Can you please explain how to simulate MIC failure security attack?

The purpose of the test is to verify that wireless station is able to react to "Security Attack" event.
Below is an example to simulate MIC Failure using Cisco Access Point

  • Configure Cisco AP to support WPA TKIP security encryption.
  • Establish wireless connection between the Cisco AP and the Wireless Station.
  • Connect an Ethernet cable between the PC Ethernet port and the Access Point.
  • Define the PC Ethernet port and the Access Point to work at the same IP network.
  • Send unlimited ping (option –t in the ping command) from the PC connected to the AP to the wireless station.
  • Execute telnet command with the AP IP address using DOS command shell windows.

Expected results: a DOS command windows should appear on your PC screen.
Cmd window.JPG
Telnet window.JPG

  • Disable the Cisco AP MIC failure support using telnet command:
Cisco
Cisco
en
Cisco
configure terminal
interface dot11radio 0
countermeasure tkip hold-time 0
exit
exit


  • Send MIC failure command to the Cisco AP (via telnet)(u is for unicast traffic)
test dot11 tx-bad-mic u 


  • Within 60 sec from the first command send the MIC failure command line again.
  • Expected results:After second time the MIC failure command is been sent to the AP (within 60 sec between the 2 commands)the wireless station should disconnect from AP,Ping should stop.

Wireless station CLI displays the following message:

TIWLAN: 2232.860682: MIC failure detected
Michael MIC failure detected
WPA: Sending EAPOL-Key Request (error=1 pairwise=0 ptk_set=1   
len=99)


  • After 60 sec the Wireless station will establish wireless connection with the AP again.
  • Ping should resume.


Does WEP security type supported in 11n?


The 802.11n standard only allows the use of AES keys.
The main reason for this is the known vulnerabilities of the WEP (Wired Equivalent Privacy), the original local-link encryption standard in 802.11b, and the TKIP which came after it.
This issue sometimes provokes confusing statements about its capabilities as some manufactures says they support 802.11n with WEP or TKIP only at 54 Mbps, where it is better to say 802.11n drops down to 802.11g to handle these older security types.

How to configure Rx Streaming?

802.11 standard does not provide a comprehensive solution for latency sensitive RX streams while working in 802.11 Power-Save Mode. This feature is particularly relevant for mobile devices in which the reduced power consumption provided when working in 802.11 Power Save Mode (PSM) is significant. Advanced RX delivery support is a WLAN device mechanism which sends triggering packets to the associated AP per configured RX stream and time period when the device is in 802.11 PSM and there was no other triggering packet sent within the configured period. Therefore, the device is polling the AP at the frequency configured to each RX stream and so maintains the streams’ required latencies. Advanced RX delivery support (also known as Rx Streaming) is implemented in firmware. The WLAN driver is responsible for configuring Rx Streaming for the desired AC.

Rx Streaming Feature Cnfiguration table:

Type Name Description
UINT8 TID The ID of the traffic stream.Possible values 0 – 7
UINT8 Traffic Period The traffic period of the RX stream.
It is considered to be the same for TX streams in bidirectional flows.
Specified in milliseconds. Possible Values 1 - 100.
UINT8 TX Timeout The timeout value on host TX transmission
used to indicate that device generated packets should be sent.
Specified in milliseconds.
Possible values 0 -200 (0- indicates that the traffic stream is Rx only and Tx is not occur)
UINT8 Enable A flag indicating if the RX PSD mechanism for the TID is enabled or disabled.
Possible values 0 – disabled, 1 – enabled


The Rx streaming feature can be configured using the CLI.

CLI Configuration Example:

.../qOs> aP params, ap Capabilities, ac Status, dEsired ps mode, set ps rX streaming, get ps rx
streAming, Qosparams, Rx timeout, Insert class, remoVe class, Tspec/
x
Set PS Rx Streaming: set ps rX streaming <TID (0..7)>
<Stream Period (mSec) (10..100)>
<Tx Timeout (mSec) (0..200)>
<Enable (0..1)>


.../qOs> aP params, ap Capabilities, ac Status, dEsired ps mode, set ps rX streaming, get ps rx
streAming, Qosparams, Rx timeout, Insert class, remoVe class, Tspec/
x 6 20 30 1


.../qOs> aP params, ap Capabilities, ac Status, dEsired ps mode, set ps rX streaming, get ps rx
streAming, Qosparams, Rx timeout, Insert class, remoVe class, Tspec/
g

PS Rx Streaming Parameters:
+-----+--------------+------------+---------+

| TID | StreamPeriod | uTxTimeout | Enabled |

+-----+--------------+------------+---------+
|   0 |            0 |          0 |       0 |
|   1 |            0 |          0 |       0 |
|   2 |            0 |          0 |       0 |
|   3 |            0 |          0 |       0 |
|   4 |            0 |          0 |       0 |
|   5 |            0 |          0 |       0 |
|   6 |            20|          30|       1 |
|   7 |            0 |          0 |       0 |
+-----+--------------+------------+---------+

HomepageIcon.jpgHOME

How to set periodic scan ( connection scan )?

In order to start periodic scan you need first to change the SME to manual ( / m d 1 ).

Then you need to set the following settings according to your needs.

And finally you start the periodic scan ( / a e t )

Global: ( / a e g )

 <RSSI Threshold (-100..0)> - Filter-out AP with RSSI below this value 

 <SNR threshold (-10..100)> - Filter-out AP with SNR below this value 

 <Report threshold (1..8)> - FW to report scan results if number of results exceeds this value. 

 <Terminate on report (0..1)> - Possible values: 0 – continue after reporting. 1 – if SSID_Type is "0" then stop after reporting. 

If SSID_Type<>"0" then stop after reporting, provided there was at least one SSID match. 

 <BSS Type (0-independent, 1-infrastructure, 2-any) (0..2)> - 1-infra,2-ibss,3-any. 

 <Probe request number! (0..5)> - Number of Probe requests (used for Active scan) 

 <Number of scan cycles (0..100)> - Number of scan intervals. 0 means infinity. 

 <Number of SSIDs (0..8)> - Number of SSID to report 

 <SSID List Filter Enabled (0..1)> - Possible values: 0 – disable report all APs. 1 – Report only APs on the list. 

 <Number of channels (0..32)> - Number of channels to scan.


Interval: ( / a e i )

Array of 16 values, each represents cycle’s size. Cycle #0 starts after delay of IntervalSize[0]. 

For n=1,…,15, scan cycle #n starts IntervalSize[n] sec after start of cycle #(n-1). 

For n>15, the cycle length is IntervalSize[15]. 

 Example: /a e i 0 4 ( set first interval to be 4 ms) 

Ssid: ( / a e s ) 

 A list of SSIDs to scan. This list is used only if SSID list filter is set to 1 in global configuration setting ( / a e g ) 


The Periodic connection scan will run scan periodically according to configured parameters ( see above).
Each discovered SSID will be added to SSID list and won’t be removed unless a one shot scan ( / a s ) will be execute or the periodic scan will be restarted ( / a e p and then / a e t ) .
In order to update the SSID list with irrelevant APs ( for example delete AP that was turned-off ) the periodic connection scan should be stopped and run again or application scan should be executed. To build such a mechanism from the application it is possible to set a timeout for the periodic scan which will trigger the application with event complete – when such event raised the application can start again the periodic connection scan (e.g / a e t from CLI ).
It is not recommend and usually it is not useful to set more than 2 probe-request for each channel – many probe-requests on the same channel can block most of channel time and leave a very short time to receive the probe-response without a collision.