Packet to client reached max retries, removing the client – Cisco Aironet AP 1142

During a recent deployment of Cisco Aironet LAP1142’s I came across a rather annoying handling of low signal client devices by the default config of Maximum Data Packet Retries when configured via the WebGUI.

The Problem:

Clients in low signal areas or at great distances from the AP would experience constant disconnects and WPA2 rekeys, when they should have been able to persist on the wireless network, just with greater latency and packet loss at low signal strength. This is evidenced in the Cisco AP log with the following lines (that will often repeat many many times)

May 19 13:31:01.885: %DOT11-4-MAXRETRIES: Packet to client aabb.ccdd.eeff reached max retries, removing the client
May 19 13:31:01.886: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station aabb.ccdd.eeff Reason: Previous authentication no longer valid
May 19 13:31:05.213: %DOT11-6-ASSOC: Interface Dot11Radio0, Station aabb.ccdd.eeff Associated KEY_MGMT[WPAv2 PSK]

Why this happens

It turns out, that although you can control the Max Data Packet Retries variable in the WebGUI, you do not get given any contextual information, or the ability to set the additional parameter of “drop-packet”

Without settng “drop-packet”, the AP resorts to it default behaviour of dealing with a MAXRETRIES event by outright disconnecting the client and forcing a rekey.

The Fix:

Via CLI (either SSH/Telnet or serial console), modify the interface config for the Radio in question (or all of them), set the packet retries setting to 128 and enable drop-packet:

en
conf t
int Dot11Radio0
packet retries 128 drop-packet
int Dot11Radio1
packet retries 128 drop-packet
do write mem

This resolved my issue, low signal clients and clients at great distances from the AP now have low signal, lower speed and increased latency, but they DO stay connected to the network. In my opinion, this is far more typical behaviour for a WiFi network, and in most cases, general public users excuse the speed and latency when they notice they have poor WiFi signal. They DO NOT excuse being constantly booted from the network over and over again.

To be clear, the correct fix for this would be to ensure good signal coverage in all service areas, and avoid Radio band interference. However, this is not possible in this scenario, and the fix above works.

This is a working fix on an AIR1142, but will work on all 1140 series, 1200 series, 2800 series and 3800 series (And probably more IOS based access points of the same era)