Easy way to replay 802.11 frames

This is a quick way to replay 802.11 frames using Commview for Wifi (am using the demo version)

When you first launch the tool, there will be a pop up shown as follows which will show the list of compatible wireless nic cards and prompt you to install the drivers needed to put the wireless card into promiscuous mode.

below you can see two adapters listed. I have tried and tested the EnGenius EUB1200AC usb adapter.

Below shows the steps to capture and or replay the frames

I am just covering the steps to capture and replay packets.

1. first you choose the channel which you want to sniff from the right pane
2. You just need to hit play to start capturing the frames on the designated channel. If using the demo version, a pop up with show up indicating the same and you will have to wait 15 seconds before you can hit start.
3. the packets tab shows you the captured packets 
4. the icon (atom like shape) is the tab for the packet generator. you can right click on one of the captured packet and hit send selected or once you open the send packet window you can just drop a frame or multiple frames which can be replayed.

 

In the Send Packet window you can use the hex editor to edit the various fields.

You can also select the 802.11 rate at which you want to send the frame, if you want to send select number of frames or continuous.

BlockAck Mechanism and AP debugging for BlockAck exchange

Block Acknowledgement 

• • It is initialized by ADDBA request / response from between originator and recipient.
  • after initiation blocks of QoS data are transmitted from originator to recipient.
  • the originator can start transmitting the blocks of data after a polled TXOP or by winning the EDCA contention.
  • the MPDUs within the block of transmitted frames are acknowledged by a BlockAck frame which is request by the originator in the BlockAckReq (BAR) frame.
  • there are two flavors - Immediate Block Ack and Delayed Block Ack
  • • Immediate Block Ack and Delayed Block Ack differ in the way BAR and BA are handled. With Immediate Block Ack, the BA is required after the receipt of BAR whereas with Delayed Block Ack, the BAR itself is acknowledged (by recipient) with a simple Ack frame and the BA is sent later on separately which also gets acknowledged (by originator) separately.
  • the originator or the recipient may tear down the Block Ack agreement by sending the DELBA (delete BA) Request which, if received successfully, is acknowledged with an Ack. 

Chart showing BlockAck mechanism

a) Setup

• • Originator first checks if the recipient STA is capable of Block Ack mechanism by checking Delayed Block Ack and Immediate Block Ack capability bits (as seen in Beacons, Association / Reassociation request, and Response frames).
  • If the recipient is capable of Block Ack mechanism the originator sends a ADDBA Request frame indicating the TID (traffic ID) for which Block Ack is being set up.
  • for Block Ack mechanism between HT-STAs the buffer size field in the ADDBA Request can be changed by the recipient of ADDBA Req frame.
  • the recipient responds with the ADDBA Response frame and can chose to accept or reject the request.
  • if the recipient rejects, the originator may not use the Block Ack mechanism.
  • when recipient accepts, it indicates the number of buffers it allocates for this Block Ack agreement. Buffer size may be different for different Block Ack agreements. 
  • the originator changes the size of the transmission window based on the ADDBA response from the recipient. The originator may increase or decrease the size in accordance to the recipient response but is not greater than value of 64.
  • the originator sets the A-MSDU supported field to 1 indicating it might transmit A-MSDU with the TID and recipient can set the same field to 1 to indicate it is capable of receiving an A-MSDU with this TID. The recipient can technically respond with any value of the A-MSDU supported field and if the originator does not like it, it can tear down the Block Ack agreement and send frames using normal ack.
  • Block Ack Timeout Value: duration after which the Block Ack session is terminated when there are no frame exchanges.
  • Start Sequence Number (SSN): the sequence number of the first data frame from the originator for this Block Ack session.

b) Data and Block Ack

• • Once the Immediate Block Ack or Delayed Block Ack is setup, the originator may transmit a block of QoS data frames separated by a SIFS (Short Inter-frame Space) duration with total number of data frames not exceeding buffer size as defined by ADDBA Response. 
  • the originator may do the following 
  • • separate the Block and Basic BlockAckReq frames into separate TXOPs
    • split a Block frame across multiple TXOPs
    • split transmission of data MPDUs sent under Block Ack policy across multiple TXOPs
    • Interleave MPDUs with different TIDs within same TXOP
    • sequence or interleave MPDUs for different RAs within a TXOP
  • Originator uses SSN to indicate to the recipient of the sequence number of first frame in the block for which acknowledgment is expected. 
  • Recipient maintains a Block Ack record which consists of originator address, TID and acknowledgment state of the data frames received from the originator.
  • In case of Immediate Block Ack policy - recipient responds to basic BlockAckReq frame from originator with a basic BlockAck frame which indicates any missing frames. The originator retries any frames that are not acknowledged in the basic BlockAck frame in another block or individually.
  • The difference with Delayed Block Ack policy is that the recipient responds to the BlockAckReq frame with a normal Ack and then transmits the BlockAck frame in a TXOP obtained later. The originator responds to the basic BlockAck with an Ack and then retries the unacknowledged frames from the BlockAck frame in another block or individually.
  • In BlockAck frame the recipient only acknowledges the frames starting from the starting sequence number (SSN) until the highest sequence number that has been received correctly and sets the bit in the BlockAck bitmap of other frames (frames not received correctly from originator) to 0. The recipient reports the status of old and prior frames (frames before the first frame that the originator sends - SSN) as successfully recieved (bit is the bitmap set to 1). 
  • The recipient maintains a field called NextExpectedSequenceNumber which is set to 0 when the Block Ack mechanism is negotiated. if the recipient receives a frame with a sequence number older than the NextExpectedSequenceNumber for that Block Ack agreement than the recipient drops the frame thinking its either old or a duplicate.

c) Teardown

• • When originator has not more data to send and the final frame in the Block has been sent the originator signals the end of the Block Ack mechanism by sending the DELBA (Delete BlockAck) frame to the recipient.
  • There is no response needed from the recipient. It just releases all resources allocated for that Block Ack agreement.
  • The Block Ack agreement may be torn down if there are no BlockAck, BlockAckReq or QoS data frames (sent under the Block Ack policy) for the Block Ack's TID received from the peer within duration of the Block Ack timeout value.

AP Debugs:

debug dot11 d1 monitor address 7cd1.c392.3232

debug dot11 d1 tr pr clients xmt rcv ba

*Apr 10 00:15:05.471: 8893F78B r 12      28/17/28/34 77- B000 030 EBBF4F 923232 EBBF4F 1600 auth l 6

*Apr 10 00:15:05.471: 8893F7A2-1 923232 - newauth  

*Apr 10 00:15:05.471: 8893F7AD-1 923232 - restart B0 300

*Apr 10 00:15:05.471: 8893F7CC-1 923232 - stop: re-assoc aid 1

*Apr 10 00:15:05.471: 8893F990 t 12     0  - B000 001 923232 EBBF4F EBBF4F 0000 auth l 37

*Apr 10 00:15:05.471: 8893FA55 r 12      29/18/29/35 76- 0000 030 EBBF4F 923232 EBBF4F 1610 assreq l 109

*Apr 10 00:15:05.471: 8893FA6E-1 923232 - restart 0 300

*Apr 10 00:15:05.475: 8893FEFF-1 923232 - clrfp    

*Apr 10 00:15:05.475: 8894003D t 12     0  - 1000 000 923232 EBBF4F EBBF4F 0000 assrsp l 123

*Apr 10 00:15:05.475: 889402A0-1 923232 - add request

*Apr 10 00:15:05.475: 88940368-1 923232 - client restart pend - clear and set new key

*Apr 10 00:15:05.475: 889405D6-1 923232 - add AID:(status ST_CAN_BF [10]) (mode SHORT_GI_20MHZ WME AMSDU_LONG AMSDU [3280]) (vrates [0014000030]) (age [300]) (blk [400]) (rate [00FCFFFFFF]) (AID [1]) (VLAN [1]) (0 []) (istatus ST_REQ_BF ST_AMSDU_REQUEUE ST_VLAN_ADDED ST_WAS_PSP [40144]) (encr [0])

*Apr 10 00:15:05.475: 889405EB-1 923232 - uapsd_compliant_client 0

*Apr 10 00:15:05.479: 88941929 r  m0-2   28/20/30/32 75- 8809 03C EBBF4F 923232 B92348 0000 q0 l36

   ARP1 hdw 1 prot 800 7cd1.c392.3232 10.0.0.107 > 0000.0000.0000 10.0.0.1

  0001 0800 0604 0001 7CD1 C392 3232 0A00 006B 0000 0000 0000 0A00 0001

*Apr 10 00:15:05.479: 8894199C r 12      34/24/35/40 70- 4801 030 EBBF4F 923232 EBBF4F 1620 null l0

*Apr 10 00:15:05.479: 88941A88-1 923232 - Request addba 0

*Apr 10 00:15:05.479: 88941DC3-1 923232 - xmt ADDBA req pri 0, seq E0F0, window 64 timeout 0 1               ----> transmit ADDBA req for priority 0, SSN 3599

*Apr 10 00:15:05.479: 88941DD3-1 923232 - fc DOT11_ACTION [D0] mode SHORT_GI_20MHZ WME AMSDU_LONG AMSDU [3280] istatus ST_REQ_BF ST_AMSDU_REQUEUE ST_VLAN_ADDED ST_WAS_PSP [40144] status ST_CAN_BF 10

*Apr 10 00:15:05.479: 88941DDA-1 923232 - fc DOT11_ACTION [D0] mode SHORT_GI_20MHZ WME AMSDU_LONG AMSDU [3280] istatus ST_REQ_BF ST_AMSDU_REQUEUE ST_VLAN_ADDED ST_WAS_PSP [40144] status ST_CAN_BF 10

*Apr 10 00:15:05.479: 88941EE5 t 12     0  - D000 C8EC 923232 EBBF4F EBBF4F 0000 action l 40                 ----> same as above. actual frame transmission

*Apr 10 00:15:05.479: 88942164 r  m0-2   29/25/33/31 70- 8809 03C EBBF4F 923232 mFFFFFF 0010 q0 l336

  C392 3232 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

*Apr 10 00:15:05.479: 889421E3 r m23-2   35/25/36/38 69- 8801 030 EBBF4F 923232 m333300 0020 q0 l56

  SNAP  86DD 6002 839F 0008 3AFF FE80 0000 0000 0000 7ED1 C3FF FE92 3232

*Apr 10 00:15:05.479: 88942293 r 12      36/25/36/41 70- D000 030 EBBF4F 923232 EBBF4F 1630 action l 9    ---> received ADDBA response for priority 0 from client

*Apr 10 00:15:05.483: 8894229C-1 923232 - fc DOT11_ACTION [D0] mode SHORT_GI_20MHZ WME AMSDU_LONG AMSDU [3280] istatus ST_REQ_BF ST_AMSDU_REQUEUE ST_VLAN_ADDED ST_WAS_PSP [40144] status ST_CAN_BF 10

*Apr 10 00:15:05.483: 889422AB-1 923232 - rcv ADDBA rsp pri 0, window 64 timeout 0             ----> same as above. above is actual frame

*Apr 10 00:15:05.483: 889427A4 t  m2-2  4  - 880A 000 923232 EBBF4F B92348 E0F0 q0 l58     ---> TID 0 data frame transmit to client (last 3 octect 92:32:32)

   ARP2 hdw 1 prot 800 ecc8.82b9.2348 10.0.0.1 > 7cd1.c392.3232 10.0.0.107

  0001 0800 0604 0002 ECC8 82B9 2348 0A00 0001 7CD1 C392 3232 0A00 006B

*Apr 10 00:15:05.483: 889428B2-1 923232 - send BAR 0 E100

*Apr 10 00:15:05.483: 889429EA t 12     0  - 8400 1750 923232 EBBF4F 0004 E100 bar        ----> sent BAR (BlockAckReq) for priority 0 and SSN 3600 (E10)

Note: the response to BAR which is BA is not seen in the debug outputs

As you see above the clients indicates the missing frames which the originator may resend using another Block Ack mechanism or send them individually.

Note: The aim of this article is to try and summarize the key points involved in the Block Ack mechanism. This article is by no means a comprehensive guide for the Block Ack process. For detailed info please refer to the IEEE 802.11-2012 standard.

Processing AAA Error 'Out of Memory'

This error is sometimes seen in large scale deployments where large number of client authentication requests fill up the RADIUS queues on the WLC. The WLC should typically be able to recover automatically but in certain cases if there is a lot of latency in the AAA server responses the WLC gets stuck in this state for a long time (have seen recovery times of more than 30-40 mins).

Typical response times from AAA server in normal functioning are in low milliseconds but can spike up to 1-10 second period. 

Most customers that I have worked with have typical radius timeout value set to 5 seconds and radius retries set to default of 5 retries. 

(Cisco Controller) >show radius summary 
Vendor Id Backward Compatibility............ Disabled
Credentials Caching......................... Disabled
Call Station Id Type........................ IP Address
Administrative Authentication via RADIUS.... Enabled
Aggressive Failover......................... Disabled
Keywrap..................................... DisabledAuthentication Servers

!--- This portion of code has been wrapped to several lines due to spatial!
--- concerns.
Idx  Type  Server Address    Port    State    Tout RFC3576
---  ----  ----------------  ------  --------  ----  -------
1    N     10.48.76.50       1812    Enabled   2    Enabled

this is how to configure the RADIUS timeout

This is how to configure:

config radius auth retransmit-timeout 1 5

During the RADIUS Queue full issue on the WLC, the WLC is start rejecting NEW authentication requests from the clients till more space is created in the RADIUS Queue to accommodate new auth requests. In the meanwhile, the WLC will continue to empty the Queue and processing the current authentications requests.

On WLC with version 7.6 you can use the devshell command below to see the accounting and authentication queues

(5508-5) >devshell printRadiusPktIdInQ

 Printing Radius IDs in Queue

 Queue [0]  Count [0]               ----> Accounting Queue

 Queue [1]  Count [143]           -----> Authentication Queue

value = 2 = 0x2

(5508-5) >devshell printRadiusPktIdInQ

 Printing Radius IDs in Queue

 Queue [0]  Count [0]

 Queue [1]  Count [255]

value = 2 = 0x2

On WLC running version 8.0 

(5508-5) >show radius queue

Radius Queue

  Auth Alloc         : 223642

  Acct Alloc         : 0

  Auth Free          : 223642

  Acct Free          : 0

  Auth Alloc Err     : 0

  Acct Alloc Err     : 0

Queue depth in above case is calculated by Auth alloc - Auth Free values.

The Queue depth for both Accounting and Authentication is 256 [0 - 255]

The WLC keeps rolling from 0 - 255 and back to 0 and so on.

 Here if you take a WLC port channel capture (capture filter udp port 1812), you can see the RADIUS exchange between the WLC and the AAA server. I have a display filter applied sourced from the WLC's ip address and have applied a Wireshark column to display the 'RADIUS IDs'. if you see closely the ids rotate from 0-255 and back to 0.

You can have a quick view of the auth requests the WLC sends out and the responses by plotting a Wireshark IO graph. Here my graph 1 in black is the auth requests sent by the WLC (filter: radius.code == 1)

and graph2 in red is responses coming back from the AAA server (access challenge, access accept and access-rejects) (filter: radius.code==2 or radius.code==3 or radius.code==4)

typically you would like to see both the graphs follow close with each other. This can also show any spikes in the authentications per second seen/sent by the WLC.

The client debugs will show something like this

Client RADIUS authentication fails.  "debug client" shows a message similar to this:

*Dot1x_NW_MsgTask_7: Dec 17 11:43:36.983: 00:11:22:33:44:55 Entering Backend Auth Response state for mobile f0:d1:a9:24:d8:a7
*Dot1x_NW_MsgTask_7: Dec 17 11:43:36.985: 00:11:22:33:44:55 Processing AAA Error 'Out of Memory' (-2) for mobile f0:d1:a9:24:d8:a7
*Dot1x_NW_MsgTask_7: Dec 17 11:43:36.999: 00:11:22:33:44:55 Sent Deauthenticate to mobile on BSSID 20:37:06:00:11:22 slot 0(caller 1x_auth_pae.c:1394)

at the same time, the msglog shows a message similar to this:

*Dot1x_NW_MsgTask_7: Dec 17 12:30:23.296: #DOT1X-3-ABORT_AUTH: 1x_bauth_sm.c:447  Authentication Aborted for client 00:11:22:33:44:55

and the traplog shows a message like this:

297 Mon Dec 17 12:36:29 2012 Client Deauthenticated: MACAddress:00:11:22:33:44:55
                             Base Radio MAC:20:37:06:00:11:22 Slot: 1 User
                             Name: unknown Ip Address: unknown Reason:Unspecif
                             ied  ReasonCode: 1

Remediations/ Workarounds:

1. try and reduce the auth storm/ reduce number of auths coming in

2. reduce latency between WLC-AAA. 

3. can use multiple radius servers and point individual dot1s WLANs to different radius servers.

4. enable client exclusion to help alleviate the high auth rate

5. Can use multiple WLCs to split up the client load