Wi-Fi Access-Point Admission Rejections: Avoid Treating Capacity Failures as Bad Credentials
A station rejected because the AP cannot admit it should retain its credentials and report an admission problem. Preserve the protocol phase, received status and AP-side resource evidence before deciding that a password is wrong. Even the commonly relevant status 17 is a category of rejection, not proof of one specific capacity limit.
This guide pins hostapd 2.11 and wpa_supplicant 2.11 for a single-link infrastructure reference. AP firmware and controller offload may produce different diagnostics. The procedure distinguishes admission evidence from credential validation; it does not replace a general provisioning recovery state machine or an Enterprise authentication-policy investigation.
Capture phase and status as one observation
For each connection attempt, record the selected test AP, client profile revision, authentication algorithm, last completed phase, response status if received, timeout indication and later disconnect reason separately. Keep credentials concealed. A generic “authentication failed” string often loses the distinction between an 802.11 management exchange, an EAP method and a four-way handshake.
In the 2.11 definitions, WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA is status 17. WLAN_STATUS_ASSOC_REJECTED_TEMPORARILY is status 30, a different result. Status codes from response frames are not the same namespace as deauthentication/disassociation reason codes or local driver errors. Never decode a bare integer without its event type. hostapd 2.11, ieee802_11_defs.h
Wpa_supplicant 2.11’s association-reject reporting preserves the status code and, where supplied, a separate timeout marker and reason. Retain those fields instead of mapping every reject event to “bad password.” A timeout without a received rejection is an unknown-response outcome, not evidence that the AP sent status 17. wpa_supplicant 2.11 association-reject event handling
| Observed boundary | Interpretation to investigate | Unsafe automatic conclusion |
|---|---|---|
| 802.11 authentication response rejects admission | AP station/resource admission at that stage | The application password was checked and rejected |
| Association response status 17 | AP cannot handle this station; correlate its reason | The configured station-count limit is definitely full |
| Association response status 30 | Temporary rejection and applicable retry information | Permanent credential failure |
| No response before local timeout | Reception, AP availability, processing or timeout path | A specific wire rejection occurred |
Use the AP implementation to narrow status 17
Hostapd 2.11’s station allocator returns failure when its station table reaches max_num_sta, but it can also fail allocation or related setup. Callers can translate such failure into status 17. The association path also uses that status for AID exhaustion, certain driver-add failures and an enabled MBO association-disallow condition. Therefore, status 17 alone cannot distinguish “table full” from every other admission failure. hostapd 2.11, ap_sta_add() and authentication/association handlers
The station table is also not identical to a user interface’s count of fully authorized online clients. An entry can exist before the final connection is authorized. Record the actual AP table and limit at the attempt time, plus the corresponding implementation diagnostic. A screenshot taken after entries have expired can miss the condition that caused rejection.
Where firmware owns admission, obtain its supported per-attempt evidence and resource counters. Hostapd logs may show only a driver failure. Do not claim a host memory shortage, hardware station limit or controller policy unless the observed branch supports it.
Test capacity with a small controlled limit
- Use a dedicated AP and two authorized test clients. Establish that each client can connect alone with the unchanged intended security profile. This is a positive control for compatibility, not a reason to weaken authentication.
- Apply a supported small admission limit. In an isolated maintenance test, configure the AP so one admitted client fills the intended test capacity. Record the exact effective limit and whether the AP or firmware owns it. Do not flood a production AP with synthetic stations.
- Connect the first client and inspect state. Confirm the relevant table/resource occupancy and successful service. Keep its connection alive through normal bounded test traffic, not an unrelated stress generator.
- Attempt the second connection. Capture the client’s phase/status and the AP’s contemporaneous decision. Verify that the product reports an admission-related result without erasing or rewriting the profile.
- Release the occupied slot through normal teardown. Confirm the AP actually removed or freed the relevant state. A client application closing its socket does not necessarily release its Wi-Fi association.
- Retry the second client under the normal owner policy. If it now connects with identical credentials, the paired trace supports the capacity hypothesis. Preserve both attempts and the resource transition.
Restore the original test configuration afterward. Separately exercise an authorized policy-disallow case or simulated driver error where the platform supports it, so the product does not label every status 17 as “AP full.” Record unsupported cases rather than manufacturing them through uncontrolled resource exhaustion.
Keep retry and user feedback bounded
Let the existing connection manager own reconnection. A product may expose a bounded retry budget with backoff and jitter, an explicit retry action and an administrator-facing capacity message, but it should not launch a second loop that races the supplicant. Preserve per-attempt results and stop conditions. Temporary-rejection timing information should be handled through the selected stack’s supported behavior rather than ignored by a busy retry loop.
For an admission-related rejection, a useful message is that the access point could not accept the device and the saved settings were retained. If the precise cause is not proven, say so. Offer credential editing as an authorized user action, not an automatic reaction to an unrelated resource code.
Hostapd 2.11 additionally offers no_probe_resp_if_max_sta, which can suppress broadcast-probe responses to unassociated stations when its table is full. If enabled, capacity can affect discovery before association is attempted. Treat a missing response as a separate observation and check the AP configuration; it still does not prove a wrong credential. hostapd 2.11 admission-related probe-response setting
Close with a reproducible interpretation
In a hypothetical installer test, the second client receives status 17 while the AP records a full station table. After the first client is disconnected and its entry removed, the second connects using the same profile. This supports a capacity diagnosis for that trace. A later status 17 accompanied by a driver-add failure must remain a different case.
No AP limit, radio connection or rejection test was executed here. The pinned source branches were inspected. Release with phase-preserving client events, correlated AP decisions, the one-slot-release test and bounded retry behavior. That evidence avoids destructive credential recovery when the actual problem is admission capacity or policy.
