Troubleshooting 802.1X
Real problems, real solutions. These are the issues that waste hours if you don’t know them.
Critical: iwd vs wpa_supplicant Conflict
| iwd and wpa_supplicant cannot coexist for WiFi management. This is the most common cause of inconsistent WiFi behavior on Linux. |
Symptoms
-
WiFi connects but requires manual DHCP every time
-
Interface state flaps between
COMPLETEDandDISCONNECTED -
wpa_state=INTERFACE_DISABLEDinwpa_cli status -
wlan0interface disappears randomly -
Authentication succeeds but connection drops seconds later
Root Cause
Both tools compete for WiFi interface control:
-
iwd — Modern WiFi daemon, good for PSK networks, installed by default on some distros
-
wpa_supplicant — Required for 802.1X EAP-TLS
They cannot both manage the same interface.
Solution
Disable iwd completely:
# Stop iwd
sudo systemctl stop iwd
# Disable iwd from starting
sudo systemctl disable iwd
# Mask iwd to prevent accidental start
sudo systemctl mask iwd
# Verify iwd is disabled
systemctl is-enabled iwd
# Expected: masked
Then ensure wpa_supplicant is running:
# Enable wpa_supplicant for WiFi
sudo systemctl enable wpa_supplicant-wifi@wlan0
sudo systemctl start wpa_supplicant-wifi@wlan0
# Verify
systemctl status wpa_supplicant-wifi@wlan0
Interface Disappears
When your network interface vanishes after driver issues or service conflicts:
Symptoms
-
ip linkdoesn’t show the interface -
wpa_supplicant fails to start with "interface not found"
-
Interface appeared briefly then disappeared
Solution (Intel WiFi)
# Check if interface exists
ip link | grep wlan
# If missing, reload Intel WiFi drivers
sudo modprobe -r iwlmvm iwlwifi
sudo modprobe iwlwifi
# Verify interface returns
ip link | grep wlan
# Restart wpa_supplicant
sudo systemctl restart wpa_supplicant-wifi@wlan0
# Force reassociation
sudo wpa_cli -i wlan0 reassociate
DHCP Not Working After Authentication
Authentication succeeds but no IP address assigned.
Symptoms
-
wpa_cli statusshowswpa_state=COMPLETED -
ip addr showshows no IP -
dhcpcdreports "sending commands to dhcpcd process"
DNS Resolution Failure
Connected with IP but DNS doesn’t work.
Symptoms
-
pingby IP works -
pingby hostname fails: "Temporary failure in name resolution" -
/etc/resolv.confis empty or stale
Diagnosis
# Check resolv.conf
cat /etc/resolv.conf
# Check if dhcpcd is running
pgrep -a dhcpcd
# If nothing shows, dhcpcd is NOT running
Solution
# Start dhcpcd for the interface
sudo dhcpcd <interface>
# Verify DNS is configured
cat /etc/resolv.conf
# Should show nameserver entries from DHCP
Why This Happens
dhcpcd.service doesn’t automatically start dhcpcd for WiFi interfaces after wpa_supplicant authenticates. When switching from wired to WiFi, /etc/resolv.conf becomes stale.
Permanent Fix
Option 1: Run dhcpcd without interface argument (manages all interfaces):
sudo dhcpcd
Option 2: Add systemd dependency:
# In [email protected]
[Unit]
Wants=dhcpcd@%i.service
Certificate Issues
Certificate Chain Incomplete
Symptom: Authentication fails, RADIUS logs show "certificate verify failed"
Solution: Ensure the full chain is available:
# Create chain file (Root + Intermediate)
cat root-ca.pem intermediate-ca.pem > /etc/ssl/certs/ca-chain.pem
# Verify chain validates your cert
openssl verify -CAfile /etc/ssl/certs/ca-chain.pem \
/etc/ssl/certs/<hostname>-eaptls.pem
# Expected: certificate.pem: OK
EKU Mismatch
Symptom: Certificate valid but authentication rejected
Check EKU:
openssl x509 -in /etc/ssl/certs/<hostname>-eaptls.pem -noout -text | grep -A2 "Extended Key"
# Must include:
# TLS Web Client Authentication (1.3.6.1.5.5.7.3.2)
If missing, reissue certificate with correct template.
Certificate Expired
# Check certificate dates
openssl x509 -in /etc/ssl/certs/<hostname>-eaptls.pem -noout -dates
# Shows:
# notBefore=Jan 1 00:00:00 2025 GMT
# notAfter=Jan 1 00:00:00 2026 GMT
Private Key Mismatch
Symptom: "private key does not match certificate"
Verify key matches certificate:
# Get cert modulus
openssl x509 -in /etc/ssl/certs/<hostname>-eaptls.pem -noout -modulus | md5sum
# Get key modulus
openssl rsa -in /etc/ssl/private/<hostname>-eaptls.key -noout -modulus | md5sum
# Both MD5 hashes must match
Common Issues Quick Reference
| Issue | Solution |
|---|---|
Certificate chain incomplete |
Import ROOT CA to RADIUS trust store |
EKU mismatch |
Reissue cert with Client Auth EKU |
Private key password wrong |
Verify |
Switch not sending RADIUS |
Check AAA configuration on switch |
Interface missing |
Reload driver: |
iwd + wpa_supplicant conflict |
Mask iwd: |
DHCP not working after auth |
Kill stale dhcpcd: |
Identity format rejected |
Match RADIUS server’s expected format (CN, UPN, FQDN) |
Log Analysis
wpa_supplicant Logs
# Follow logs in real-time
sudo journalctl -u wpa_supplicant-wired@<interface> -f
# Filter for EAP events
sudo journalctl -u wpa_supplicant-wired@<interface> | grep -iE '(eap|tls|auth)'
# Last 50 lines
sudo journalctl -u wpa_supplicant-wired@<interface> -n 50
Key Log Messages
| Message | Meaning |
|---|---|
|
Authentication succeeded |
|
Authentication failed (check RADIUS logs) |
|
Port authorized, network access granted |
|
Connection lost |
|
CA cert issue or expired cert |
|
TLS handshake completed successfully |
Force Reauthentication
When testing changes:
# From Linux - logoff then logon
sudo wpa_cli -i <interface> logoff
sudo wpa_cli -i <interface> logon
# Check new status
sudo wpa_cli -i <interface> status
Packet Capture
For deep debugging, capture the EAP exchange:
# Capture EAPOL frames
sudo tcpdump -i <interface> -w /tmp/eap-capture.pcap 'ether proto 0x888e'
# Then trigger authentication
sudo wpa_cli -i <interface> logoff && sudo wpa_cli -i <interface> logon
# Stop capture (Ctrl+C) and analyze
wireshark /tmp/eap-capture.pcap
Look for: - EAP-Request/Identity from switch - EAP-Response/Identity from client - TLS handshake messages - EAP-Success or EAP-Failure