Association RSSI Threshold: Stopping Wi-Fi Spill-Over Connections
An Association RSSI threshold stops devices outside your premises from joining your Wi-by refusing any client whose signal reaches the AP too weakly.
The spill-over problem
Wi-Fi does not stop at the wall. Signals leak into car parks, corridors, the street and neighbouring units, and devices there still see the SSID and try to join it.
These far-away clients cause three problems:
• Waste airtime. A weak client falls back to the lowest data rates (1 to 6 Mbps). Its frames take far longer to send, so every user on the channel slows down. This hurts most on 2.4 GHz, which has only three non-overlapping channels.
• Poor experience. Connections at the edge drop, retry and time out, which leaves a bad user experience.
• Expose the network. Visitors or passers-by outside the controlled area can attempt MITM attacks or reach the login or captive portal.
The Association RSSI threshold answers this at the AP: if the client is too far away, the AP simply does not let it in.
How the threshold works
The AP measures the signal strength of each incoming open authentication frame that arrives before the association request and drops the frame if the value is below the threshold. The client never gets an answer, so it cannot associate.
On the ALE Stellar AP used for this article, the setting is in (Enterprise mode ) Configure > Wireless > RF Profiles > Edit RF Profile > Association RSSI Threshold, with separate values for 2.4G and 5G. In the lab profile, 2.4G was 0 (disabled) and 5G All was 40.
Why is the value positive (12, 15, 20, 36) and not like -75? RSSI in dBm is always negative for Wi-Fi. The positive number you configure is an SNR, and the AP uses it to set the minimum RSSI:
SNR (dB) = RSSI (dBm) - Noise floor (dBm)
That is:
RSSI (dBm) = Noise floor (dBm) + SNR (dB)
For example, with a noise floor of -93 dBm and an SNR of 35, the minimum RSSI is -93 + 35 = -58 dBm.
So the setting is effectively a minimum SNR a client needs to join. Two units to keep apart:
Term | Unit | Meaning | Typical values |
RSSI in dBm | dBm (absolute) | Received power, referenced to 1 mW | -30 (very strong) to -90 (barely there) |
SNR, or "RSSI" on Qualcomm APs | dB (relative) | How far the signal is above the noise | 10 (unreliable) to 40+ (excellent) |
The 802.11 standard leaves the RSSI scale to each vendor, which is why the same field name means dBm on one product and SNR on another. Some interfaces also take the magnitude only, so "75" means -75 dBm. A field that accepts only small values (0 to 100) and recommends 15 to 20 is almost certainly SNR.
Converting the threshold to dBm
To see what a threshold means as a signal level, add it to the noise floor of that radio: minimum RSSI (dBm) ≈ noise level + threshold. Take the noise level from iwconfig on the AP, per interface.
On the 5 GHz radio ath101 (SSID Wireless@ALE), iwconfig reports a noise level of -93 dBm. The connected client shows a signal of -52 dBm, so its SNR is -52 - (-93) = 41 dB, above the threshold of 40.
With a -93 dBm noise floor, the threshold values translate as follows:
Threshold (SNR, dB) | Approx. minimum RSSI | Effect |
12 | -81 dBm | Blocks only clients that are barely hanging on |
15 | -78 dBm | Gentle; common starting point |
20 | -73 dBm | Moderate; good where APs overlap |
36 | -57 dBm | Very aggressive; roughly same-room only |
40 | -53 dBm | Lab test value; near the AP only |
Lab test: proving the threshold works
The test was run twice, at 02:08 and 02:34 UTC. Both times, the 5 GHz radio rejected the client below an SNR of 40, and the client joined the 2.4 GHz radio instead, where the threshold was 0.
Setup
• AP: Alcatel-Lucent Enterprise Omni Access Stellar (Qualcomm chipset), SSID Wireless@ALE with 802.1X / PEAP. RF profile: Association RSSI Threshold 2.4G = 0, 5G All = 40.
• Interfaces: ath0xx = 2.4 GHz radio (ath001, ath002, ath003), ath1xx = 5 GHz radio (ath101, ath102).
• Test client: 84:1b:77:b3:1c:58, moved away from the AP to lower its signal.
Where to look. Please download the log for the Access point and look for the file name “debug”
The test client is 84:1b:77:b3:1c:58, highlighted in yellow. Rejections are in red; successful steps are in green.
Test 1: 02:08 UTC (10:08 SGT)
Time (UTC) | Interface | Client MAC | Log message |
02:08:56.983274 | ath101 (5 GHz) | 84:1b:77:b3:1c:58 | Recv a auth frame with algorithm 0(IEEE80211_AUTH_ALG_OPEN) seq 1, rssi=36 |
02:08:56.983292 | ath101 (5 GHz) | 84:1b:77:b3:1c:58 | Rssi 36 lower than access rssi threshold 40 |
02:08:57.468877 | ath101 (5 GHz) | 84:1b:77:b3:1c:58 | Recv a auth frame with algorithm 0(IEEE80211_AUTH_ALG_OPEN) seq 1, rssi=34 |
02:08:57.468895 | ath101 (5 GHz) | 84:1b:77:b3:1c:58 | Rssi 34 lower than access rssi threshold 40 |
02:08:58.218570 | ath001 (2.4 GHz) | 84:1b:77:b3:1c:58 | Recv a auth frame with algorithm 0(IEEE80211_AUTH_ALG_OPEN) seq 1, rssi=28 |
02:08:58.220015 | ath001 (2.4 GHz) | 84:1b:77:b3:1c:58 | Send auth response, status 0(Successful) |
02:08:58.230725 | ath001 (2.4 GHz) | 84:1b:77:b3:1c:58 | Recv assoc request, rssi=28 |
02:08:58.232108 | ath001 (2.4 GHz) | 84:1b:77:b3:1c:58 | Assoc response, status 0(Successful) reassoc 0 |
Test 2: 02:34 UTC (10:34 SGT)
Time (UTC) | Interface | Client MAC | Log message |
02:34:07.184777 | ath101 (5 GHz) | 84:1b:77:b3:1c:58 | Recv a auth frame with algorithm 0(IEEE80211_AUTH_ALG_OPEN) seq 1, rssi=37 |
02:34:07.184795 | ath101 (5 GHz) | 84:1b:77:b3:1c:58 | Rssi 37 lower than access rssi threshold 40 |
02:34:07.654097 | ath101 (5 GHz) | 84:1b:77:b3:1c:58 | Recv a auth frame with algorithm 0(IEEE80211_AUTH_ALG_OPEN) seq 1, rssi=35 |
02:34:07.654115 | ath101 (5 GHz) | 84:1b:77:b3:1c:58 | Rssi 35 lower than access rssi threshold 40 |
02:34:08.646169 | ath001 (2.4 GHz) | 84:1b:77:b3:1c:58 | Recv a auth frame with algorithm 0(IEEE80211_AUTH_ALG_OPEN) seq 1, rssi=35 |
02:34:08.647613 | ath001 (2.4 GHz) | 84:1b:77:b3:1c:58 | Send auth response, status 0(Successful) |
02:34:08.652552 | ath001 (2.4 GHz) | 84:1b:77:b3:1c:58 | Recv assoc request, rssi=35 |
02:34:08.654031 | ath001 (2.4 GHz) | 84:1b:77:b3:1c:58 | Assoc response, status 0(Successful) reassoc 0 |
What each step shows:
1. 5 GHz rejected the client twice in each test (SNR 36 and 34, then 37 and 35) because every attempt was below the threshold of 40. No auth response was sent: the frame was silently dropped.
2. The client fell back to 2.4 GHz about one second later (SNR 28, then 35) and was accepted both times. The RF profile has Association RSSI Threshold 2.4G = 0, so nothing is enforced on that band.
3. The WAM log confirms the 2.4 GHz connection completed end to end: PEAP authentication succeeded, the 4-way handshake completed, Access Role "staff" was applied and DHCP assigned 192.168.14.86. That log shows the same event at 10:08:58 local time, because downloaded driver logs use UTC (Singapore is UTC+8).
The 5 GHz threshold works as intended. A spill-over client would still get in through 2.4 GHz until the same setting is applied there.
Recommended values and deployment
Start at 15 and tune with a walk test; go higher only where APs overlap enough for clients to roam. Please take note of the real-time noise value of the environment, which plays a vital role.
Environment | Suggested threshold (SNR) | Approx. cutoff at -93 dBm noise |
Single AP, or sparse coverage | Off, or 10 to 12 | -83 to -81 dBm |
Typical office, overlapping APs | 15 to 20 | -78 to -73 dBm |
Dense deployment, small cells | 20 to 25 | -73 to -68 dBm |
Lab validation only | 36 to 40 | -57 to -53 dBm |
Deployment steps:
1. Survey the boundary: walk the car park, street or neighbouring areas and note the SNR clients see there.
2. Set the threshold a few dB above that boundary SNR, on both 2.4 GHz and 5 GHz for the SSID.
3. Walk test from inside the premises to make sure legitimate users at the edges still connect.
4. Check the driver association log for "lower than access rssi threshold" entries from outside devices.
5. Pair it with lower transmit power or higher minimum data rates if spill-over remains.
Other vendors. The same idea exists under different names. On HPE Aruba controllers (ArubaOS 8), it sits in the WLAN SSID profile as SNR values in dB:
The probe threshold ignores weak probe requests; the auth threshold ignores weak authentication requests, which is the closer match to this article. Aruba Central and AOS 10 call them Probe Request SNR Threshold and Authentication Request SNR Threshold. Aruba advises care when combining the probe threshold with Client Match.
Conclusion
Association RSSI threshold is a simple, effective guard against spill-over Wi-Fi: set as a minimum SNR, it keeps distant devices off the network before they authenticate. Our lab log proves the mechanism works, with a client rejected on 5 GHz at SNR 34 to 37 across two tests. It also shows the most common mistake: the same client walked in through 2.4 GHz at SNR 28 and 35, because the 2.4G threshold was 0. Apply the threshold to every band of the SSID, start around 15, validate with a walk test, and read the driver association log to confirm.
Comments