FreeRadius authentication problems

Arran Cudbard-Bell a.cudbardb at
Mon Dec 3 12:30:11 CET 2012

> ++[pap] returns noop
> Found Auth-Type = Accept
> Auth-Type = Accept, accepting the user
> # Executing section post-auth from file /etc/freeradius/sites-enabled/default
> +- entering group post-auth {...}
> ++[exec] returns noop
> Sending Access-Accept of id 9 to port 1065
> Finished request 0.
> Going to the next request
> Waking up in 4.9 seconds.
> Cleaning up request 0 ID 9 with timestamp +7
> Ready to process requests.
> I followed the plain mac auth guide to get this far, and the system sort of works, but not quite. So the configs must be out of whack somehow, but since radius doesn't give any debug info when I get booted out of the network I'm at loss here. Any help?

If you're not seeing any information in the FreeRADIUS debug, then the Ruckus controller isn't sending anything. If you enable RADIUS accounting on the Ruckus you *may* get an Accounting-Request with the Acct-Terminate-Cause, which may give you a clue as to what's happening.

First though I would enable debugging logs on the controller to see if it's complaining about the Access-Accept coming back, it may be missing some attributes that the Ruckus controller needs.

I'd also verify the Access-Accept is actually reaching the controller (maybe dodgy routing).

It may also be that the Ruckus requires a Message-Authenticator in the Access-Accept, in which case inserting:

update reply {
	Message-Authenticator = 0x00 

Should trigger its generation.

I'd also try:

update reply {
	Service-Type = Framed-User

(some NAS require a service type).

The delay suggests that the Ruckus may be discarding the responses from the RADIUS server, or never actually received the response. Do you see the request sent multiple times?


More information about the Freeradius-Users mailing list