Intermittent access-reject even though password is correct

Sachin Yadav sachin0235 at yahoo.com
Mon May 26 12:30:07 CEST 2014


Hi,

I am getting intermittent access-reject response from free-radius even though password was correct. User have to try again and this time user is allowed. Following are the debug logs for one such transaction -

rad_recv: Access-Request packet from host 122.176.209.171 port 23328, id=41, length=321
ChilliSpot-Version = "1.3.0"
User-Name = "aqua"
CHAP-Challenge = 0x86b6482ac2204b1801b4705ca5d43722
CHAP-Password = 0x00662b9af994945519294eb931419a5e21
Service-Type = Login-User
Acct-Session-Id = "5380389300000002"
Framed-IP-Address = 192.168.182.3
NAS-Port-Type = Wireless-802.11
NAS-Port = 2
NAS-Port-Id = "00000002"
Calling-Station-Id = "60-FA-CD-D1-45-CE"
Called-Station-Id = "C8-D3-A3-6C-F2-53"
NAS-IP-Address = 192.168.182.1
NAS-Identifier = "moka_ug"
WISPr-Location-ID = "isocc=,cc=,ac=,network=xxxxxxx"
WISPr-Location-Name = "xxxx"
WISPr-Logoff-URL = "http://192.168.182.1:3990/logoff"
Message-Authenticator = 0xe8d077bea1e4565958097834c2143975
# Executing section authorize from file /etc/raddb/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
[chap] Setting 'Auth-Type := CHAP'
++[chap] returns ok
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "aqua", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[files] returns noop
[sql] expand: %{User-Name} -> aqua
[sql] sql_set_user escaped user --> 'aqua'
rlm_sql (sql): Reserving sql socket id: 1
[sql] expand: SELECT id, username, attribute, value, op           FROM radcheck           WHERE username = '%{SQL-User-Name}'           ORDER BY id -> SELECT id, username, attribute, value, op           FROM radcheck           WHERE username = 'aqua'           ORDER BY id
[sql] User found in radcheck table
[sql] expand: SELECT id, username, attribute, value, op           FROM radreply           WHERE username = '%{SQL-User-Name}'           ORDER BY id -> SELECT id, username, attribute, value, op           FROM radreply           WHERE username = 'aqua'           ORDER BY id
[sql] expand: SELECT groupname           FROM radusergroup           WHERE username = '%{SQL-User-Name}'           ORDER BY priority -> SELECT groupname           FROM radusergroup           WHERE username = 'aqua'           ORDER BY priority
[sql] expand: SELECT id, groupname, attribute,           Value, op           FROM radgroupcheck           WHERE groupname = '%{Sql-Group}'           ORDER BY id -> SELECT id, groupname, attribute,           Value, op           FROM radgroupcheck           WHERE groupname = 'gartino_ug'           ORDER BY id
[sql] User found in group gartino_ug
[sql] expand: SELECT id, groupname, attribute,           value, op           FROM radgroupreply           WHERE groupname = '%{Sql-Group}'           ORDER BY id -> SELECT id, groupname, attribute,           value, op           FROM radgroupreply           WHERE groupname = 'gartino_ug'           ORDER BY id
rlm_sql (sql): Released sql socket id: 1
++[sql] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING: Auth-Type already set.  Not setting to PAP
++[pap] returns noop
Found Auth-Type = CHAP
# Executing group from file /etc/raddb/sites-enabled/default
+- entering group CHAP {...}
[chap] login attempt by "aqua" with CHAP password
[chap] Using clear text password "mango" for user aqua authentication.
[chap] Password check failed
++[chap] returns reject
Failed to authenticate the user.
Using Post-Auth-Type Reject
# Executing group from file /etc/raddb/sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} -> aqua
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 3601 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.




Can someone please help me understand what's going wrong? I am using coovachilli as a capative portal solution which automatically send these packets to radius server for AAA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140526/f7990fcd/attachment.html>


More information about the Freeradius-Users mailing list