FreeRADIUS Not Working Read the Debug Output with freeradius -X
FreeRADIUS tells you exactly why every login succeeded or failed — if you ask it properly. Debug mode narrates each request line by line, and each failure pattern points at one precise fix.
✍️ Technical Anshu🐧 Ubuntu Server📡 FreeRADIUS 3
🎥 Watch the full FreeRADIUS setup in the video, step by step
Every FreeRADIUS beginner reaches the same moment: a login fails and the normal log says almost nothing. The tool for this moment is debug mode, freeradius -X. It stops the guesswork by narrating one request from arrival to verdict. This page shows how to run it safely, how to read the four situations you will actually meet, and which lighter logs to use for everyday questions afterwards.
Terminal — freeradius -X debug output during one login
$ sudo freeradius -X
...
(0) Received Access-Request Id 182 from 192.168.1.10:54321
(0) User-Name = "testuser"
(0) files: users -> testuser
(0) pap: Login attempt with password
(0) pap: User authenticated successfully
(0) Sent Access-Accept Id 182 to 192.168.1.10:54321
👆 Debug mode narrates one login line by line: request received, user matched, password checked, Access-Accept sent (panel recreated with the real FreeRADIUS 3 debug wording)
1
Debug Mode Is the Only Honest Troubleshooter
When a login fails, guessing is slow and logs in the normal log file are brief. FreeRADIUS has a better tool built in: run it in the foreground with full debug output and it narrates every request — what arrived, which files and modules touched it, and exactly where the decision went wrong.
Stop the background service first — both cannot own the ports: sudo systemctl stop freeradius
Start debug mode: sudo freeradius -X and wait for Ready to process requests
Now make one login attempt from the device and watch the output scroll
Stop with Ctrl + C and restart the service when done: sudo systemctl start freeradius
2
Read the Four Situations You Will Actually See
Nothing scrolls at all during a login attempt — the request never reached the server. Wrong server IP on the device, no client entry for that device's address, a firewall drop, or a secret mismatch (the server silently discards packets whose secret fails — debug cannot show what it refused to process)
"Login incorrect" or a failed password line — the request arrived and the user was found, but the password did not match what the users file or directory holds
An EAP error part-way down — for WiFi logins this is the certificate or method stage; the last EAP lines before the failure name the problem
A module name with an error — the output names the exact module and config file. Fix that one thing, validate with sudo freeradius -C, and test again
The golden rule of this output: read the last error, not the first line. The server explains its final decision at the end of the request's block.
3
The Everyday Logs, for When Debug Is Overkill
For routine questions — who logged in, when did this device last ask — you do not need debug mode:
Main log file: sudo tail -f /var/log/freeradius/radius.log — service events and login summaries
Who is connected right now (with accounting on): radwho
Recent session history: radlast
One etiquette rule: debug output can include usernames and sensitive detail while you watch it live. Run it for a real fault, capture what you need, and return the server to normal service mode afterwards — do not leave a production server running in a terminal window.
🔴 Change one thing, then test: the debug output rewards patience. If you edit three files between two tests, the output cannot tell you which edit fixed — or broke — the login. One change, one freeradius -C check, one login attempt, read the result.
🎥 Watch the Full FreeRADIUS Setup Video
The complete setup on a real Ubuntu server — install, first client, first user and the live test, all shown step by step in the video.
Why must I stop the service before running freeradius -X?
Because the background service already owns UDP ports 1812 and 1813. A second copy started in debug mode cannot bind those ports and will fail or behave confusingly. Stop the service, run debug, read your answer, then start the service again so normal logins resume.
The debug window shows nothing when my access point tries. What does that mean?
The request never reached the server in a form it would process. Check in order: the server IP set on the access point, a clients.conf entry for the access point's address, the firewall allowing UDP 1812 from that address, and the shared secret — a wrong secret is discarded silently by design, so it produces exactly this empty result.
Where are normal FreeRADIUS logs kept on Ubuntu?
The main log is /var/log/freeradius/radius.log, recording service events and login summaries. For live session questions, radwho shows who accounting says is connected now and radlast shows recent sessions. Debug mode is reserved for active faults because it only exists while you run it in the foreground.
This guide is based on the Technical Anshu FreeRADIUS video • Stuck on any step? Ask in the video comments — you will get an answer there 🙏