802.1X Supplicant Troubleshooting: EAPOL Debug Step by Step

When 802.1X stops working, the complaint is always the same: "the port is down". The port is not down for no reason - it is sitting in a state machine waiting for a supplicant that never sent the right thing, or for a RADIUS server that rejected it, or for a certificate that expired three months ago. Debugging this quickly is a matter of knowing which side to look at first and being able to tell the four EAPOL messages apart.

This article is a practical troubleshooting order for wired and wireless 802.1X, with the commands that produce evidence on each side and a checklist of causes that account for most real incidents.

Know the Exchange You Are Debugging

EAP over LAN is a small protocol. The authentication exchange on a wired port is:

Supplicant                Authenticator (switch)         Authentication Server
    |                              |                              |
    |------ EAPOL-Start --------->|                              |
    |<----- EAP-Request/Identity -|                              |
    |------ EAP-Response/Identity-|                              |
    |                              |----- RADIUS Access-Request -->|
    |                              |<---- RADIUS Access-Challenge-|
    |<----- EAP-Request/TLS --------|                              |
    |------ EAP-Response/TLS ------>|---- RADIUS Access-Request --->|
    |<----- EAP-Success ------------|<---- RADIUS Access-Accept ----|
    |  (port moves to authorised, VLAN assignment applied)         |

Every failure is visible as an interruption at a specific point in that diagram, which means you can localise the problem in one capture instead of guessing.

Step 1: Is Anything Arriving?

On the switch, start with state rather than debug:

! Cisco IOS-XE
show authentication sessions interface GigabitEthernet1/0/10
show dot1x interface GigabitEthernet1/0/10 details
show authentication sessions interface Gi1/0/10 details

! ArubaOS-CX
show port-access clients interface 1/1/10
show port-access authenticator interface 1/1/10

! Junos (EX/QFX)
show dot1x interface ge-0/0/10.0 extensive

If the session shows nothing at all, the supplicant is not transmitting. Common causes: the OS has the physical adapter disabled for 802.1X, the wired autoconfig service is stopped (Windows), or the client is behind an unmanaged switch that is dropping EAPOL frames. EAPOL is a link-local protocol - a dumb switch in the middle will usually pass it, but a device that filters multicast to 01:80:C2:00:00:03 will not.

Step 2: Turn On Targeted Debug

Keep debug scoped to one interface and one MAC. A global debug dot1x all on a busy access switch will flood the console and mask the event you are chasing.

! IOS-XE - scoped debug with terminal monitoring
debug dot1x packet interface GigabitEthernet1/0/10
debug dot1x events interface GigabitEthernet1/0/10
debug radius
terminal monitor
! ... reproduce the failure ...
undebug all
show log | include (DOT1X|RADIUS|AUTHMGR)

What you are looking for is which message got a response. An EAP-Request/Identity that is never answered means the client stack is broken. An identity that is answered but produces no Access-Request means the authenticator could not map the request to a method. An Access-Reject means the credential or certificate was wrong and the answer is on the RADIUS server, not the switch.

! RADIUS side - check the actual reason instead of the generic reject
show aaa servers
debug radius
show radius statistics

On FreeRADIUS, run it in debug for one attempt rather than reading the log after the fact:

radiusd -X
# or, if already running as a service
systemctl stop freeradius && radiusd -X

Typical FreeRADIUS output that ends a session points to certificate chain problems (TLS Alert write:fatal:unknown CA), clock skew (certificate not yet valid), or identity mismatch (Certificate CN or SAN does not match User-Name). Those three account for a very large share of EAP-TLS failures and are all fixed on the PKI side, not on the switch.

Step 3: Look From the Client

The supplicant's own view is the fastest confirmation that the certificate is the problem.

# Linux
sudo wpa_supplicant -i eth0 -c /etc/wpa_supplicant/wired.conf -dd
journalctl -u wpa_supplicant -n 100 --no-pager

# Windows - both the WLAN and wired trace sources are useful
netsh wlan show interfaces
netsh trace start capture=yes report=yes tracefile=C:\temp\dot1x.etl
netsh trace stop
# Wired: check the service and per-adapter authentication settings
Get-NetAdapterAdvancedProperty -Name Ethernet | Where-Object DisplayName -like "*802.1X*"
Get-Service dot3svc, WlanSvc | Select Name, Status

# macOS
log stream --predicate 'subsystem == "com.apple.network"' --level debug

On Linux, -dd prints each EAP exchange and the exact reason a method is abandoned. On Windows, the most common finding is that the profile is set to validate a specific server name that no longer matches the RADIUS certificate.

Step 4: Certificate and Time Checks

Run these before you blame anything else:

# what the supplicant will present (client cert + key)
openssl x509 -in client.crt -noout -subject -issuer -dates -ext subjectAltName
# what the RADIUS server presents
openssl s_client -connect radius.example.com:2083 -showcerts < /dev/null | openssl x509 -noout -subject -issuer -dates
# is the chain complete?
openssl verify -CAfile root_ca.crt -untrusted intermediate_ca.crt client.crt
# is the clock sane?
timedatectl status
chronyc tracking

Certificate validation fails silently in a lot of clients. If the client time is more than a few minutes off, validation fails and the supplicant retries with a lower-priority method, which looks to the switch like a credential problem. Always confirm time sync first.

The Failures That Actually Happen

• Wrong VLAN after success. Authentication worked, authorisation did not. Check the RADIUS reply attributes - Tunnel-Type, Tunnel-Medium-Type and Tunnel-Private-Group-ID must all be present and consistent, or the port authorises into the default VLAN and the user reports "no network".
• MAB fallback masking the real fault. With MAC authentication bypass enabled, a failing supplicant silently falls back to MAB and lands in a different VLAN. Confirm which method actually authenticated with show authentication sessions before trusting the result.
• RADIUS reachability. Check the source interface used for RADIUS, the shared secret match, and that the port is permitted through any intermediate firewall. A switch that cannot reach RADIUS will fail open or closed depending on configuration - decide that deliberately.
• Certificate expiry on the authentication server. The most common outage: the RADIUS server's EAP certificate expires and every wireless and wired client fails at once. Monitor it like any other certificate.

For the wider deployment picture, the roles and configuration of the authenticator are covered in this 802.1X on the access switch guide, and a complete wired deployment including EAP-TLS certificate setup is described in this FreeRADIUS EAP-TLS guide. On ArubaOS-CX line cards the equivalent role and MAB behaviour is documented in this port-access with RADIUS and MAB guide. If you are choosing between the two authentication protocols for device administration as well as port access, this RADIUS vs TACACS+ comparison covers the trade-offs.

Order of Operations

Always work outward from the wire: is EAPOL present, did the authenticator forward it, did the server answer, and was the answer applied. Skipping straight to the switch configuration wastes time on the one component that is usually working correctly. Capture once, read the state machine, then fix the side that did not respond.

原文链接：https://www.rfc-editor.org/rfc/rfc3748.html