Slow RADIUS Authentication for WiFi Networks with UniFi Access Points

Knowledge Base Community
, , ,
1

Problem: Slow RADIUS Authentication for WiFi Networks with UniFi Access Points

Summary

A customer reported significantly delayed WiFi authentication when using RADIUS-based authentication on UCS. The UniFi Wireless Controller repeatedly logged warnings such as:

“RADIUS Authentication took more than 10 seconds on AP-xxxx.”

Despite these warnings, the system load on the UCS RADIUS server was low and did not indicate resource exhaustion.

The issue was reproducible only with specific UniFi access point models and firmware versions and was not caused by UCS, FreeRADIUS, or LDAP performance issues.

Affected Environment

  • UCS Version: UCS 5.2

  • RADIUS: FreeRADIUS 3.2.1

  • Authentication Backend: LDAP

  • Wireless Infrastructure: UniFi Controller with the following AP models:

    • UniFi U6-Pro
    • UniFi U6-Enterprise
    • UniFi UAP-AC-Pro-Gen2

Symptoms

  • Long authentication times (>10 seconds) for WiFi clients

  • UniFi Controller error notifications:

    • “RADIUS Authentication took more than 10 seconds”

  • No noticeable CPU, memory, or I/O bottlenecks on the UCS RADIUS server

  • Issue only occurs with specific UniFi AP models

Debug and Diagnostic Steps

1. Immediate Diagnosis on the RADIUS Server

Start FreeRADIUS in debug mode to analyze request processing and LDAP response times:

freeradius -X

Pay close attention to:

  • Delays during LDAP queries

  • Messages such as:

    • All ldap connections are in use
    • Long pauses between Access-Request and Access-Accept

This helps determine whether the latency originates from LDAP lookups or RADIUS processing.

2. Test LDAP Query Latency Independently

To rule out LDAP performance issues, execute the following command on the UCS system running the RADIUS service, ideally while connected via WiFi as an affected client:

time univention-ldapsearch uid=<username>,cn=users,$(ucr get ldap/base)

If this command returns quickly, LDAP itself is not the root cause, and the delay is introduced elsewhere in the authentication flow.

3. Related Knowledge Base Articles

The following articles provide additional background and troubleshooting guidance:

Investigation Results

The problem could be reproduced only with UniFi access points and specific firmware versions. Logs from the UniFi Controller and APs showed repeated authentication retries, FT (Fast Transition) events, and timing anomalies during WPA/WPA2-Enterprise authentication.

Excerpt from UniFi logs:

Error Notification: RADIUS Authentication took more than 10 seconds

Multiple users in the UniFi community reported the same behavior for the affected AP models. One particularly relevant finding is documented here:

UniFi Community Thread (Reply #41):
Error Notification: RADIUS Authentication took more than 10 seconds

A user reported that enabling RADIUS DAS/DAC (Change of Authorization, CoA) in the UniFi Controller immediately resolved the issue.

Root Cause

Based on customer observations and community reports, the root cause is a firmware-related issue in certain UniFi AP models that leads to delayed RADIUS authentication handling.

The issue is not caused by UCS, FreeRADIUS, or LDAP, but by how the affected UniFi APs handle authentication state changes and retries.

Enabling RADIUS DAS/DAC (CoA) changes the interaction pattern between the UniFi infrastructure and the RADIUS server and appears to mitigate the firmware issue.

Based on the firmware version from the APs in the logs, you can get this problem.

  • U6-Pro-6.7.33
  • U6-Enterprise-6.7.33
  • UAP-AC-Pro-Gen2-6.6.77
2025-11-17 07:32:00    User.Notice    10.2.1.200    Nov 17 07:32:00 AP-Serverraum ac8ba935376d,U6-Pro-6.7.33+15578: syswrapper[27417]: Trigger rrm scan(3): sleep 2;iwpriv wifi1ap8 acsrrm 48; sleep 1;
2025-11-17 07:32:01    Kernel.Error    10.2.1.88    Nov 17 07:32:01 AP-Pausenhalle 9c05d6a5355d,U6-Enterprise-6.7.33+15578: kernel: [249571.144780] wlan: [0:E:ANY] wlan_get_peer_dp_stats: Failed to fetch peer_stats for peer mac f6:86:52:24:e2:0e
2025-11-17 07:32:01    Daemon.Info    10.2.1.73    Nov 17 07:32:01 AP-KL-Haus-03 e063da64212c,UAP-AC-Pro-Gen2-6.6.77+15402: hostapd[7803]: ath9: STA 9e:60:a2:69:61:df RADIUS: starting accounting session 43E7484C17673CE6
2025-11-17 07:32:01    Daemon.Info    10.2.1.3    Nov 17 07:32:01 AP-R003 e063da641dac,UAP-AC-Pro-Gen2-6.6.77+15402: stahtd: stahtd[7808]: [STA-TRACKER].stahtd_dump_event(): {"message_type":"STA_ASSOC_TRACKER","mac":"12:4a:ec:b8:d8:8c","vap":"ath12","event_type":"failure","assoc_status":"0","dns_timeouts":"0","ip_delta":"-1418038720","ip_assign_type":"N/A","wpa_auth_delta":"40000","assoc_delta":"20000","auth_delta":"0","event_id":"1","auth_ts":"237939.934737","dns_resp_seen":"no","avg_rssi":"-61"}
2025-11-17 07:32:01    Kernel.Error    10.2.1.8    Nov 17 07:32:01 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: kernel: [237811.548746] wlan: [0:I:ANY] [UNSPECIFIED] vap-4(wifi1ap12): [6e:2c:83:bc:80:c3]recv auth frame with algorithm 2 seq 1 rssi:32 minrssi:0
2025-11-17 07:32:01    Daemon.Debug    10.2.1.8    Nov 17 07:32:01 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: hostapd[11900]: wifi1ap12: STA 6e:2c:83:bc:80:c3 IEEE 802.11: binding station to interface 'wifi1ap12'
2025-11-17 07:32:01    Kernel.Warning    10.2.1.8    Nov 17 07:32:01 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: kernel: [237811.553566] [wifi1ap12] ieee80211_set_node_vid node 6e:2c:83:bc:80:c3 lan[0] dvlan stas 0
2025-11-17 07:32:01    Daemon.Debug    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: hostapd[11900]: wifi1ap12: STA 6e:2c:83:bc:80:c3 IEEE 802.11: authentication OK (FT)
2025-11-17 07:32:01    Daemon.Debug    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: hostapd[11900]: wifi1ap12: STA 6e:2c:83:bc:80:c3 MLME: MLME-AUTHENTICATE.indication(6e:2c:83:bc:80:c3, FT)
2025-11-17 07:32:01    Kernel.Error    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: kernel: [237811.587345] wlan: [0:I:ANY] [UNSPECIFIED] vap-4(wifi1ap12): [6e:2c:83:bc:80:c3]recv auth frame with algorithm 2 seq 1 rssi:32 minrssi:0
2025-11-17 07:32:01    Kernel.Error    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: kernel: [237811.587444] wlan: [0:I:ANY] [UNSPECIFIED] vap-4(wifi1ap12): [6e:2c:83:bc:80:c3]recv another auth frame when previous is in progress
2025-11-17 07:32:01    Kernel.Error    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: kernel: [237811.634703] wlan: [0:I:ANY] [UNSPECIFIED] vap-4(wifi1ap12): [6e:2c:83:bc:80:c3]recv auth frame with algorithm 2 seq 1 rssi:32 minrssi:0
2025-11-17 07:32:01    Kernel.Error    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: kernel: [237811.634764] wlan: [0:I:ANY] [UNSPECIFIED] vap-4(wifi1ap12): [6e:2c:83:bc:80:c3]recv another auth frame when previous is in progress
2025-11-17 07:32:01    Kernel.Error    10.2.1.88    Nov 17 07:32:02 AP-Pausenhalle 9c05d6a5355d,U6-Enterprise-6.7.33+15578: kernel: [249571.658984] wlan: [0:F:OBJMGR] wlan_objmgr_iterate_log_del_obj_handler: #peer in L-state,MAC: f6:86:52:24:e2:0e
2025-11-17 07:32:01    Kernel.Error    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: kernel: [237811.989019] wlan: [0:I:ANY] [UNSPECIFIED] vap-4(wifi1ap12): [6e:2c:83:bc:80:c3]recv auth frame with algorithm 2 seq 1 rssi:32 minrssi:0
2025-11-17 07:32:01    Daemon.Debug    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: hostapd[11900]: wifi1ap12: STA 6e:2c:83:bc:80:c3 IEEE 802.11: binding station to interface 'wifi1ap12'
2025-11-17 07:32:01    Kernel.Warning    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: kernel: [237811.997366] [wifi1ap12] ieee80211_set_node_vid node 6e:2c:83:bc:80:c3 lan[0] dvlan stas 0
2025-11-17 07:32:01    Daemon.Debug    10.2.1.8    Nov 17 07:32:02 AP-R008 ac8ba92f5d66,U6-Pro-6.7.33+15578: hostapd[11900]: wifi1ap12: STA 6e:2c:83:bc:80:c3 IEEE 802.11: authentication OK (FT)
<skip>

Possible Workarounds (Not Verified)

The following workaround was reported by multiple users in the UniFi community but has not yet been officially validated by Univention.

Enable RADIUS DAS/DAC (CoA)

1. FreeRADIUS 3.2.1 Configuration on UCS

1.1 Enable the CoA Listener (Port 3799)

Verify or add a CoA listener in FreeRADIUS 3.x. Configuration files are usually located under:

/etc/freeradius/3.0/

Check radiusd.conf or files in sites-enabled/ and ensure a listener similar to the following exists:

listen {
    type   = coa
    ipaddr = 0.0.0.0
    port   = 3799
}

1.2 Add the UniFi Controller as a CoA Client

Edit the client configuration file, typically:

/etc/freeradius/3.0/clients.conf

Add an entry for the UniFi Controller:

client unifi-controller {
    ipaddr = <IP_OF_UNIFI_CONTROLLER>
    secret = <RADIUS_SHARED_SECRET>
    coa_server = coa
}

Important:
The coa_server = coa directive is mandatory for DAS/CoA support.

1.3 Restart FreeRADIUS

Apply the changes:

systemctl restart freeradius

Verify that the CoA port is listening:

ss -tuln | grep 3799

2. UniFi Controller Configuration

  1. Navigate to Settings → WiFi (or Wireless Networks in older versions).
  2. Edit the affected 802.1X / WPA-Enterprise WLAN.
  3. In Advanced / RADIUS Settings, configure:
Setting Value
RADIUS Authentication Server UCS IP, Port 1812
RADIUS Accounting Enabled
Accounting Server UCS IP, Port 1813
Enable RADIUS CoA / DAS Enabled
CoA Server IP UCS IP
CoA Port 3799
CoA Shared Secret Same as RADIUS secret
  1. Save the configuration.

After this change, the UniFi Controller will send CoA messages to the UCS RADIUS server, which may prevent the long authentication delays observed with affected AP firmware versions.

Conclusion

  • The reported slow WiFi authentication is not caused by UCS or FreeRADIUS.
  • The issue is linked to specific UniFi AP firmware behaviors.
  • Enabling RADIUS DAS/DAC (CoA) is a promising workaround reported by multiple users.
  • Univention recommends monitoring UniFi firmware updates and validating this workaround in a test environment before rolling it out to production.