FreeRadius authentication problems

[Taneli Virtanen]

User[client mac address] fails authentication too many times in a row when
joining WLAN[opetus-x/opetusx] at
AP[ap1<https://192.168.154.12/admin/mon_ap.jsp?n=c4:01:7c:1a:50:60>].
User[client mac address] is temporarily blocked from the system for [30
seconds].

Ok, after doing some searching I found more comprehensive logs on Ruckus
which reveal the previous lines when trying to connect to the radius
network.

So, apparently it never actually does connect to it, but since the
authentication happens OK on the FreeRadius side, I'm left to believe that
it is in fact Ruckus who isn't happy with me trying to join the network.


2012/12/3 Taneli Virtanen <virtanentaneli at gmail.com>

> Well, I'm home right now, but tomorrow when I get back to work I'll see
> what I can do. Client is a Windows 7, but I can also test with XP and Win 8
> clients if necessary.
>
>
> 2012/12/3 Primož Marinšek <pmtelos at gmail.com>
>
>> I know a little about Ruckus. Can you SSH to the ZD and input the
>> following
>>
>> enable
>> show aaa
>> show wlan
>>
>> and send me the output direclty. Maybe there is something strange there.
>>
>> Also tell me which FW you are using and which OS the client is using
>> (tell me which SP if Windows)
>>
>> Regards
>>
>> On 3 December 2012 12:30, Arran Cudbard-Bell <a.cudbardb at freeradius.org>
>> wrote:
>> >>
>> >> ++[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 192.168.154.12 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?
>> >
>> > -Arran
>> > -
>> > List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>>
>>
>> --
>> Primož Marinšek
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20121204/03fcc156/attachment.html>