A wired 802.1X or NAC login that fails could be broken at the client, at the access device enforcing the port, or at the RADIUS server behind it — and the reason code points somewhere different each time. This is the chain to check in order, what the EAP exchange looks like at each hop, the real error codes and CLI to read, and where this differs from a Portal login or a wireless authentication failure.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
802.1X authenticates the port itself, before the client ever gets an IP address — which is exactly why it breaks differently from Portal or wireless.
On a wired switch or firewall port running 802.1X, nothing above Layer 2 has happened yet when the exchange starts — no DHCP, no IP address, no HTTP redirect. That is the core difference from a Portal login, which authenticates a device that already has an address and is trying to reach a captured web page. It also means the chain that has to work is short and strict: the client's 802.1X supplicant, the access device enforcing the port and relaying to the RADIUS server, and the RADIUS/AAA server itself deciding accept or reject.
What follows is that chain, what the EAP exchange looks like at each hop, the access-authentication error codes and CLI that actually explain most tickets, where the escape/fallback question fits, and how this differs from a Portal-login failure or a wireless-specific one.
Client, access device, RADIUS server — three links, and the sequence of EAP messages between them tells you which one actually broke.
Reading this sequence top to bottom before touching any configuration tells you whether the client never even sent EAPOL-Start, whether the access device never relayed to RADIUS, or whether RADIUS answered but with a reject.
Diagram labels are kept in English for engineering clarity.
Steps 1 through 3 happen before the access device has even talked to RADIUS — if the client never gets past step 2 or 3, look at the client and the port, not the RADIUS server. Steps 4 through 9 are where an authentication-domain policy, a locked account, or a mismatched credential shows up as an Access-Reject. Step 11 is the one people forget: an Access-Accept at step 9 does not guarantee the user stays online — an accounting failure afterward can still force them off.
Three checks, in order — who is actually online, why anyone who is not online got dropped, and whether the account itself is the problem.
[HUAWEI] display access-user interface 10ge 1/0/1
Total: 1
UserID Username IP address MAC Status
32984 lulu 192.85.11.2 00e0-fc55-0102 Success
<HUAWEI> display authentication-profile configuration name p1
...
Authentication mode : multi-authen
<HUAWEI> display domain name test
Domain-name : test
Domain-state : Block
// Block forces every user in this domain offline — not a credential problem
<HUAWEI> display remote-user authen-fail blocked
// lists remote accounts currently locked out after repeated authentication failuresReal access-authentication error codes, what they actually mean, and the command that confirms it.
SYMPTOMEAPOL client timeout (error code 206): the client simply does not respond to the EAP request.
CAUSEOn a wireless authentication failure the same code is very often a weak-signal problem. On a wired port there is no radio link to blame — it is almost always the 802.1X supplicant itself: not running, misconfigured, or a driver fault on the client.
FIXConfirm the supplicant is actually running and correctly configured on the client before touching the port or the RADIUS server; only retry authentication once the client side is confirmed healthy.
SYMPTOMRemote user is blocked (error code 519) and Authenticate fail (error code 147): a remote account gets locked out after too many failed attempts within the retry window, and every device still using it fails from that point on.
CAUSEIf several 802.1X clients are configured to authenticate with the same account, one device with a stale or wrong password can lock that account for every other device using it — a single bad password field turns into an office-wide outage.
FIXCheck display remote-user authen-fail blocked, unblock the account with remote-user authen-fail unblock once the correct credential is confirmed, and — if shared accounts are unavoidable — disable per-account lockout for that scenario with undo access-user remote authen-fail.
<HUAWEI> display remote-user authen-fail blocked
[HUAWEI-aaa] remote-user authen-fail unblock
[HUAWEI-aaa] undo access-user remote authen-failSYMPTOMDomain policy failed force user to offline (error code 371): users with entirely correct credentials still cannot come online.
CAUSEThe authentication domain itself is in Block state — a domain-level switch that overrides individual credential checks entirely, and is easy to overlook because the symptom looks identical to a bad password.
FIXCheck display domain name <domain> for the Domain-state field before troubleshooting individual accounts; reactivate it in the AAA domain view with state active.
SYMPTOMBeyond access limit (error code 57): a new device cannot come online on a port that already has one authenticated.
CAUSEsingle-terminal and multi-share modes only allow one device online at a time on that port; single-voice-with-data allows exactly one voice and one data device. A port with an IP phone daisy-chaining a PC, or several endpoints behind a small unmanaged switch, needs multi-authen — anything else will reject the second device by design, not by fault.
FIXCheck display authentication-profile configuration and display access-user interface together before assuming a RADIUS or licensing problem; switch the profile to multi-authen with an appropriate max-user-number if the port genuinely needs to carry more than one or two authenticated devices.
SYMPTOMEAPOL client user name is different (error code 420): the client re-initiates authentication mid-session with a different username than the one it started with.
CAUSESome client software or manual retries switch accounts between attempts without fully logging off first — the access device treats the mismatch as a fault condition rather than a clean new login.
FIXMake sure the client logs off cleanly (EAPOL-Logoff) before retrying with a different account, rather than switching credentials mid-session.
SYMPTOMAccounting server no response (error code 410): the user authenticates successfully and then gets dropped shortly after.
CAUSEAuthentication and accounting are separate RADIUS exchanges. A working authentication path with a broken or unreachable accounting link — a different server, a different link, a different failure mode entirely — still forces the user offline even though their credentials were fine.
FIXPing the accounting server specifically and check its own logs and status — don't assume an accounting-stage failure is the same problem as the authentication stage that already succeeded.
Pulled straight from the field — the ones worth having an answer ready for.
Portal authenticates a device that already has an IP address and is trying to reach a captured web page over HTTP — the failure modes are a page that won't push, or RADIUS approving a login that the client still sees as rejected. 802.1X/NAC authenticates the port itself at Layer 2, before DHCP ever runs, using EAPOL and EAP rather than a web page. If the client never gets an IP address at all and there's no login page involved, you're troubleshooting 802.1X, not Portal — see Portal Authentication Fails on Enterprise Routers for the Portal-specific chain.
The access-authentication error codes are largely shared across wired and wireless — the same EAPOL client timeout code, for instance, can fire in both. The difference is cause: on wireless, that code is very often a weak-signal or roaming problem specific to the radio link; on a wired port there's no radio to blame, so the same symptom almost always points at the client's supplicant or the cable/port itself. Diagnose the two differently even when the error code matches.
This happens when several 802.1X clients are configured to authenticate against the same shared account. Enough failed attempts within the retry window locks that account per display remote-user authen-fail blocked, and every other device still using it fails from that point on — not because of anything wrong on their end. Unblock the account with remote-user authen-fail unblock, and consider undo access-user remote authen-fail if shared accounts are unavoidable in your environment.
The authentication domain model separates the authentication scheme from the accounting scheme, which is what makes a local, RADIUS-independent authentication scheme possible as a fallback for a given domain. The exact escape/bypass mechanism for a specific access device is a switch or AC platform feature outside what this firewall-focused source material covers in depth — see the honest limits note below before assuming a specific command exists on your device.
Authentication and accounting are two separate RADIUS exchanges. An Access-Accept confirms the credentials were correct; it doesn't guarantee the accounting link is healthy. Accounting server no response (error code 410) forces the user offline afterward even though authentication itself succeeded — check the accounting server and the link to it specifically, not the authentication path again.
This note is built from Huawei's shared access-authentication error-code reference and AAA/domain CLI, cross-checked across the HiSecEngine USG6000F/USG6000G/USG12000 and USG6000E/USG9500 maintenance material. It covers the client-access device-RADIUS chain, the EAP exchange, and the error codes and commands that reference shows in practice. It does not cover a specific vendor's escape/bypass VLAN mechanism for an unreachable RADIUS server, or AC-specific wireless roaming behavior, in depth — those live in a switch or AC platform's own documentation.
Tell us the error code or symptom from display aaa online-fail-record, and whether it's wired or wireless — we'll help you read it.