Home / Notes / Wireless Authentication Troubleshooting

NOTES · WLAN AUTHENTICATION TROUBLESHOOTING

Wi-Fi Users Can't Authenticate: Portal, PSK and 802.1X Troubleshooting

A client that associates with the SSID and then fails to log in can be stuck at any one of four links — the terminal itself, the AP, the wireless controller (AC), or the authentication server behind it. This is the diagnostic order that finds which link is actually broken, the real display and configuration commands for Portal, PSK and 802.1X, and the causes that account for most of these tickets.

By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026

Why the Chain Matters More Than the Error Message

"Wrong password" on a phone screen can mean four completely different failures underneath it — which is exactly why working through the chain in order beats guessing.

A Wi-Fi client that finds the SSID, associates with the AP, and then fails to log in is a wireless-side problem — the fault sits in the terminal-to-AP link, the AP-to-AC (wireless controller) link, or the AC-to-authentication-server link behind it: a Portal server for a web-page push, or a RADIUS server for 802.1X. That's a different chain from a wired deployment, where the client is already plugged into a switch port and the redirect happens at the router or gateway itself — if that's what you're actually looking at, our wired-router Portal authentication troubleshooting note covers that chain instead.

What follows is the client-AP-AC-server chain as a diagnostic tree, the checks for each stage with the exact commands to run against a Huawei AC/WAC, the causes that show up again and again across Portal, PSK and 802.1X once you're past the first few checks, and field FAQ answers.

Follow the Chain Before You Touch Any Configuration

Wi-Fi authentication splits into two shapes: no server is involved at all, or the AC is relaying the request to a Portal or RADIUS server somewhere behind it.

Placing the symptom on this chain first tells you which stage section below actually applies, instead of restarting the AP and hoping.

Diagram labels are kept in English for engineering clarity.

PSK and open authentication are settled entirely between the client and the AP's security profile — no AC-side server round-trip involved. Portal and 802.1X both depend on the AC successfully relaying a request to a server behind it, which means a config mismatch on either side of that hand-off, not just the client, can be the real fault.

Working Through Each Stage

Five stages, five different sets of things to look at — and the command that tells you which one you're actually stuck in.

Stage 0 — Confirm the Client Actually Reaches the AP's Security Policy

Before chasing Portal or RADIUS, confirm the VAP the client associated with is actually up and running the security policy you think it is.

Check display ap all to confirm the AP is in normal (nor) state and online under the right AP group — an AP stuck in a fault or standby state won't accept authentication correctly no matter what the profiles say.
Check display vap ssid <ssid-name> for the SSID the client is trying to join. Status has to read ON; if it doesn't, the VAP was never actually created on that radio and the client is associating with nothing.
Read the Auth type column in the same output — it has to match what you configured (WPA/WPA2-PSK, WPA2-802.1X, or Open) and what the client is actually attempting. A client set to WPA2-Personal against an SSID that's actually open (or vice versa) will fail before Portal or RADIUS is even reached.
Check the STA count column to confirm at least one station is actually associated on that VAP — if it's 0, the problem is association itself, not authentication, and belongs in an RF/channel/association investigation instead.

<AC1> display ap all
Total AP information:
nor : normal           [1]
Total: 1
-----------------------------------------------------------------------------------------------------------------------
ID MAC               Name          Group      IP          Type           State STA Uptime
-----------------------------------------------------------------------------------------------------------------------
0    00e0-fc76-e360 area_1           ap-group1 10.23.100.254 AirEngine5776-26 nor 1
-----------------------------------------------------------------------------------------------------------------------

<AC1> display vap ssid wlan-net
WID : WLAN ID
Total: 2
--------------------------------------------------------------------------------
AP ID AP name RfID WID BSSID                   Status Auth type        STA SSID
--------------------------------------------------------------------------------
0    area_1 0 1          00E0-FC76-E360 ON            WPA/WPA2-PSK 1            wlan-net
0    area_1 1 1          00E0-FC76-E370 ON            WPA/WPA2-PSK 0            wlan-net
------------------------------------------------------------------------------------
// Status ON confirms the VAP was created on this radio; Auth type confirms the running security policy; STA is the associated-client count

Stage 1 — PSK / Open Authentication: Client ↔ AP Only

PSK and open authentication never touch the AC's server-facing configuration — if this stage is broken, the fault is entirely in the security profile and the passphrase, nothing further downstream.

Check display security-profile name <profile> on the AC to see the exact security policy applied — WPA/WPA2 PSK+AES, or the newer mixed WPA2/WPA3 psk-sae mode. Confirm it's the same standard the client's own network settings expect.
If the security profile uses security wpa-wpa2 psk pass-phrase, the passphrase is stored and displayed in cipher form — a typo on either the AC or the note handed to end users isn't something you can catch by reading the running configuration back. Re-enter the passphrase deliberately on the AC and hand out the plaintext value fresh, rather than assuming a previously distributed passphrase is still correct.
Check that the VAP profile's referenced security-profile actually matches the SSID the client is joining — in networks running both an open guest SSID and a PSK-protected staff SSID off the same AP, a VAP-to-security-profile binding mix-up will silently swap which SSID enforces which policy.
If the client is a legacy device, confirm the AC isn't running WPA3-only (SAE) on that profile — a mixed wpa2-wpa3 psk-sae line is what lets both old and new clients connect off one SSID; a pure SAE profile locks out anything that can't do WPA3.

[AC1] wlan
[AC1-wlan] security-profile name wlan-net
[AC1-wlan-sec-prof-wlan-net] security wpa-wpa2 psk pass-phrase YsHsjx_202206 aes
[AC1-wlan-sec-prof-wlan-net] quit
// mixed WPA2/WPA3 profile that still accepts SAE-capable clients on the same SSID:
[AC1-wlan] security-profile name wlan-net
[AC1-wlan-sec-prof-wlan-net] security wpa2-wpa3 psk-sae pass-phrase YsHsjx_202206 aes

Stage 2 — Portal: AC ↔ Portal Server

If the client sees the login page but every credential fails, or never sees the page at all, this is the AC-to-Portal-server leg, not the client.

Check display this under the web-auth-server view (or display current-configuration) for server-ip, port, url and shared-key on the AC — these have to match the Portal server's own listening address, port and pre-shared secret exactly, or the AC's push and the server's replies won't be trusted by either side.
Confirm server-detect is enabled if you're relying on Portal escape — without it, a Portal server outage looks identical to a misconfiguration, since the AC has no way to notice the server is unreachable and fail open.
Check that the portal-access-profile actually references the right web-auth-server template by name, and that the authentication-profile applied to the VAP references that portal-access-profile — a correctly configured Portal server behind a VAP that's still pointing at the wrong access profile behaves exactly like a broken one.
If MAC-priority Portal is in use (returning MAC-known clients straight through without a login page), check the mac-access-profile and free-rule-template bindings on the same authentication-profile — a missing free-rule for the Portal server or DNS address blocks the redirect itself before the client ever reaches the login page.
Confirm the url configured on the AC's web-auth-server points at a redirect address the client's DNS can actually resolve and reach — an internal hostname or an address unreachable from the client's assigned VLAN produces the same blank-page symptom as a server that's actually down.

[AC1] web-auth-server server-source all-interface
[AC1] web-auth-server abc
[AC1-web-auth-server-abc] server-ip 172.16.1.1
[AC1-web-auth-server-abc] shared-key cipher YsHsjx_202206
[AC1-web-auth-server-abc] port 50200
[AC1-web-auth-server-abc] url https://172.16.1.1:8445/portal
[AC1-web-auth-server-abc] server-detect
[AC1-web-auth-server-abc] quit
[AC1] portal-access-profile name portal1
[AC1-portal-access-profile-portal1] web-auth-server abc
[AC1-portal-access-profile-portal1] quit
[AC1] free-rule-template name default_free_rule
[AC1-free-rule-default_free_rule] free-rule 1 destination ip 172.16.1.2 mask 24
[AC1-free-rule-default_free_rule] quit
[AC1] authentication-profile name p2
[AC1-authentication-profile-p2] portal-access-profile portal1
[AC1-authentication-profile-p2] mac-access-profile mac1
[AC1-authentication-profile-p2] free-rule-template default_free_rule
[AC1-authentication-profile-p2] access-domain example.com force
// server-ip, port and shared-key must match the Portal server's own listening configuration exactly

Stage 3 — 802.1X: AC ↔ RADIUS Server

802.1X authentication fails between the AC and the RADIUS server far more often than it fails on the client's supplicant — check the shared secret and the EAP method before touching anything on the terminal.

Check radius-server template on the AC — the authentication and accounting IP addresses, ports (1812/1813 by default) and shared-key cipher have to match the RADIUS server's own client entry for this AC exactly.
Confirm the aaa authentication-scheme bound to the domain actually uses authentication-mode radius, and that the domain itself binds both the authentication scheme and the correct radius-server template — a client can be sent down a domain that never touches RADIUS at all if the domain binding is wrong.
802.1X access profiles default to EAP authentication — confirm the RADIUS server actually supports and is configured for the EAP method the client's supplicant is sending (PEAP, EAP-TLS, etc.); a RADIUS server that only expects PAP/CHAP will reject every EAP request outright, which looks identical to a wrong password from the client's side.
Check that the authentication-profile applied to the VAP references the right dot1x-access-profile and the right access-domain force — an 802.1X profile bound to the wrong domain sends every request to a RADIUS server that was never told about these users.

[AC1] radius-server template radius_huawei
[AC1-radius-radius_huawei] radius-server authentication 10.23.200.1 1812
[AC1-radius-radius_huawei] radius-server accounting 10.23.200.1 1813
[AC1-radius-radius_huawei] radius-server shared-key cipher YsHsjx_202206mc@1
[AC1-radius-radius_huawei] quit
[AC1] aaa
[AC1-aaa] authentication-scheme scheme1
[AC1-aaa-authen-scheme1] authentication-mode radius
[AC1-aaa-authen-scheme1] quit
[AC1-aaa] domain example.com
[AC1-aaa-domain-example.com] authentication-scheme scheme1
[AC1-aaa-domain-example.com] radius-server radius_huawei
[AC1-aaa-domain-example.com] quit
[AC1-aaa] quit
[AC1] dot1x-access-profile name d1
[AC1-dot1x-access-profile-d1] quit
[AC1] authentication-profile name p1
[AC1-authentication-profile-p1] dot1x-access-profile d1
[AC1-authentication-profile-p1] access-domain example.com force
// 802.1X access profiles use EAP authentication by default -- the RADIUS server must support EAP, or every request is rejected

Stage 4 — Login Succeeds, Traffic Still Doesn't Pass

A client that authenticates cleanly and still can't reach anything is no longer an authentication problem — it's VLAN, ACL or free-rule scope.

Check the service-vlan configured on the vap-profile the client landed on — a client authenticated into the wrong business VLAN reaches the network, just not the resources it needs.
For Portal deployments, check the free-rule-template bound to the authentication-profile — rules meant only to let pre-auth traffic reach the Portal server and DNS can be scoped too broadly or too narrowly, either exposing resources before login or blocking legitimate post-login traffic that happens to match the same rule.
Check for a user-isolation or ACL policy applied at the AC or upstream switch that's scoped to the wrong VLAN or user group — this is common after copying a working profile to a new SSID without updating the VLAN it isolates.

[AC1] wlan
[AC1-wlan] vap-profile name wlan-net2
[AC1-wlan-vap-prof-wlan-net2] forward-mode tunnel
[AC1-wlan-vap-prof-wlan-net2] service-vlan vlan-id 101
[AC1-wlan-vap-prof-wlan-net2] security-profile wlan-net2
[AC1-wlan-vap-prof-wlan-net2] ssid-profile wlan-net2
[AC1-wlan-vap-prof-wlan-net2] authentication-profile p2
// confirm service-vlan is the VLAN this user group is actually supposed to land on, not a leftover from a copied profile

5 Root Causes That Show Up Again and Again

Once the stages above have told you where the problem sits, these five account for most of what's actually wrong.

1. PSK Passphrase or Security Mode Doesn't Actually Match

SYMPTOMClient shows "authentication failed" or "incorrect password" immediately after association, even though the user is confident the password is correct.

CAUSEWith WPA/WPA2-PSK, the passphrase configured in security wpa-wpa2 psk pass-phrase is stored and displayed in cipher form on the AC — a typo made when it was first configured, or a passphrase that was changed on the AC but not communicated to users, isn't something you can catch by reading the running configuration back. Separately, if the profile was migrated to the mixed wpa2-wpa3 psk-sae mode, a client hard-coded to plain WPA2-only settings can also fail even with the right password.

FIXRe-enter the passphrase on the AC deliberately and hand out the plaintext value fresh rather than trusting a previously distributed one; if legacy clients are failing after a WPA3 migration, confirm the profile uses the mixed psk-sae mode rather than SAE-only.

[AC1-wlan] security-profile name wlan-net
[AC1-wlan-sec-prof-wlan-net] security wpa-wpa2 psk pass-phrase YsHsjx_202206 aes

2. Portal Server Unreachable, or the Shared Key Doesn't Match

SYMPTOMThe login page never appears at all — the browser just times out or redirects nowhere — rather than appearing and rejecting a correct password.

CAUSEThe AC's web-auth-server entry has to match the Portal server's own listening IP, port and shared-key exactly; a mismatch on any one of the three means the AC's push either never reaches the server or the server's reply is never trusted. If server-detect isn't enabled, an actual Portal server outage produces the identical blank-page symptom, because the AC has no heartbeat telling it the server is down.

FIXCompare server-ip, port and shared-key cipher on the AC against the Portal server's own configuration side by side, and enable server-detect so a real outage is distinguishable from a config error.

[AC1] web-auth-server abc
[AC1-web-auth-server-abc] server-ip 172.16.1.1
[AC1-web-auth-server-abc] shared-key cipher YsHsjx_202206
[AC1-web-auth-server-abc] port 50200
[AC1-web-auth-server-abc] server-detect
// Warning: The shared-key complexity is low. It is recommended that the password contain at least sixteen characters...

3. RADIUS Shared Secret or EAP Method Doesn't Line Up

SYMPTOM802.1X clients hang at "authenticating" and then fail, with no obvious client-side error to explain why.

CAUSEradius-server shared-key cipher on the AC has to be character-for-character identical to the shared secret configured for this AC as a client entry on the RADIUS server; because it's stored in cipher form, a mismatch isn't visible by reading the AC's own configuration. Separately, 802.1X access profiles default to EAP authentication — if the RADIUS server isn't configured to handle the specific EAP method the client's supplicant sends (PEAP, EAP-TLS, EAP-MSCHAPv2), it rejects the request outright, which looks identical to a wrong password from the client's side.

FIXRe-enter the shared-key on the AC and confirm it against the RADIUS server's client-entry configuration directly, and confirm with the RADIUS administrator which EAP method the server actually has configured for this AC's requests.

[AC1] radius-server template radius_huawei
[AC1-radius-radius_huawei] radius-server shared-key cipher YsHsjx_202206mc@1
[AC1-radius-radius_huawei] quit
[AC1] dot1x-access-profile name d1
// 802.1X access profiles use EAP authentication by default; confirm the RADIUS server supports the client's EAP method

4. Authentication Profile Bound to the Wrong Access Domain — or Not Bound at All

SYMPTOMSome users on the same SSID authenticate fine while others on the same physical AP fail, or authentication succeeds but accounting/session records never appear on the server.

CAUSEThe authentication-profile applied to a VAP has to bind both the correct access profile (dot1x-access-profile or portal-access-profile) and the correct access-domain force — the domain is what actually ties a request to a specific authentication scheme, accounting scheme and RADIUS or Portal server template. A VAP whose authentication-profile still points at a leftover or default domain silently authenticates against the wrong scheme, or against no configured scheme at all.

FIXCheck authentication-profile on the AC for the domain actually bound with access-domain force, and confirm that domain itself is bound to the authentication-scheme, accounting-scheme and radius-server (or web-auth-server, for Portal) you expect.

[AC1] aaa
[AC1-aaa] domain example.com
[AC1-aaa-domain-example.com] authentication-scheme scheme1
[AC1-aaa-domain-example.com] accounting-scheme scheme2
[AC1-aaa-domain-example.com] radius-server radius_huawei
[AC1-aaa-domain-example.com] quit
[AC1-aaa] quit
[AC1] authentication-profile name p1
[AC1-authentication-profile-p1] dot1x-access-profile d1
[AC1-authentication-profile-p1] access-domain example.com force

5. Post-Auth Traffic Blocked by VLAN, ACL or Free-Rule Scope

SYMPTOMThe client authenticates successfully — no error at all — and still can't reach the internet or internal resources.

CAUSEThis is no longer an authentication fault; it's the service-vlan configured on the vap-profile putting the client in the wrong VLAN, a user-isolation/ACL policy scoped to the wrong group, or — for Portal deployments — a free-rule-template that's too narrow to let legitimate post-login traffic through because it was written only to permit pre-auth traffic to the Portal server and DNS.

FIXConfirm service-vlan on the vap-profile matches the VLAN this user group is meant to land in, and review the free-rule-template and any ACL/isolation policy for scope that's leftover from a copied profile rather than written for this SSID.

[AC1-wlan] vap-profile name wlan-net2
[AC1-wlan-vap-prof-wlan-net2] service-vlan vlan-id 101
[AC1-wlan-vap-prof-wlan-net2] authentication-profile p2

Six Questions That Come Up Constantly

Pulled straight from the field — the ones worth having an answer ready for.

The client shows "authentication failed" immediately — how do I know if it's PSK, Portal or 802.1X without asking the user anything else?

Check display vap ssid <ssid-name> on the AC. The Auth type column tells you the security policy actually running on that SSID — WPA/WPA2-PSK, WPA2-802.1X, or Open (which means any failure has to be Portal, since there's no key or RADIUS exchange to fail). That one field rules out two of the three paths immediately.

Everyone on the SSID fails at once — is that more likely PSK or server-side?

An SSID-wide, all-at-once failure that starts at a specific moment points at the AC's server side — the RADIUS server, the Portal server, or the shared-key/domain binding between the AC and either of them — rather than PSK, since a passphrase mismatch would have been failing consistently since it was set, not suddenly for everyone together.

One user fails while everyone else on the same SSID is fine — where do I look?

That pattern is almost always client-side: a stale saved passphrase on that one device, a supplicant configured for the wrong EAP method, or (for MAC-priority Portal) a MAC address that isn't matching the mac-access-profile the way it's expected to. It's rarely worth touching the AC's authentication-profile or domain binding for a single-user symptom.

Can PSK and 802.1X run on the same AP at the same time?

Yes — each is configured as its own SSID with its own VAP profile, security profile and authentication profile, all bound to the same AP group and radio. A common pattern is a WPA2/WPA3-PSK SSID for guests or BYOD next to a WPA2-802.1X SSID for managed corporate devices on the same physical AP.

What's MAC-priority Portal, and why would a network use it?

It's an authentication-profile that binds both a mac-access-profile and a portal-access-profile — known devices (already in the MAC database) get authenticated silently by MAC address, while unknown devices fall through to the Portal login page. It's the usual way to let staff-owned managed devices skip the captive portal while still pushing it to guest and BYOD traffic on the same SSID.

Does a client that fails 802.1X also show up as a Portal failure, or are the two logs completely separate?

Completely separate, because they're different authentication-profile bindings on different VAPs — a client trying to join a WPA2-802.1X SSID never reaches the Portal server code path at all, and vice versa. If you're seeing errors that look like a mix of both, first confirm which physical SSID and VAP the client actually associated with; it's common to mistake two neighboring SSIDs for one.

Honest Limits of This Note

Honest Limits of This Note

This note is built around the Huawei AC/WAC (WLAN controller) configuration model and the display ap all / display vap ssid / display security-profile commands behind it, plus the RADIUS/Portal binding logic that model uses. If your controller is a different vendor, the exact commands change, but the client-AP-AC-server chain and the order in which to check it carries over directly. It doesn't cover RF-layer causes of association failure itself (channel, power, interference), WIDS/rogue-AP containment interactions, or cloud-managed AP platforms that hide these CLI views behind a web console.

Stuck on a specific Wi-Fi login failure?

Tell us which stage it's stuck at — client-AP association, PSK, Portal, or 802.1X — plus the display vap ssid or RADIUS server logs, and we'll help you read it.

WhatsApp an engineer →