Re: Strange behaviour of rlm_chap (freeradius 1.1.7+mysql)
Dan Searle wrote: > Here's a trace of two login's the first works fine, the second a few > moments later fails, the username and password supplied in both cases > are correct and exactly the same. Can anyone shed any light on this? > I've tried rebuilding the mysql database from scratch, and recompiling > and installing the radius server, but to no avail... (a) bad RAM on the server (b) other memory corruption in the RADIUS daemon process (c) a buggy NAS Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Strange behaviour of rlm_chap (freeradius 1.1.7+mysql)
Hi, Hello? Is there anybody out there? Can someone who knows how CHAP works please explain to me how this could be happening? Does a CHAP challenge time-out after a certain amount of time? Does the rlm_chap module hold a copy of old CHAP challenge's and prevent the same one being re-used to stop replay attacks? If so how do I switch this off? Anyone? Anything? Dan... Thursday, August 30, 2007, 3:08:16 PM, you wrote: > Hi, > I've been running a free radius server for a while now, but today for > no apparent reason I'm getting a lot of intermittent authentication > failures using the rlm_chap module. > Here's a trace of two login's the first works fine, the second a few > moments later fails, the username and password supplied in both cases > are correct and exactly the same. Can anyone shed any light on this? > I've tried rebuilding the mysql database from scratch, and recompiling > and installing the radius server, but to no avail... > > rad_recv: Access-Request packet from host 81.178.20.107:1024, id=25, > length=204 > NAS-Port-Type = Wireless-802.11 > Calling-Station-Id = "00:14:A4:87:DF:FF" > Called-Station-Id = "rural-ap1" > NAS-Port-Id = "wlan2" > User-Name = "[EMAIL PROTECTED]" > NAS-Port = 2149580817 > Acct-Session-Id = "80200011" > Framed-IP-Address = 10.5.50.254 > Mikrotik-Host-IP = 10.5.50.254 > CHAP-Challenge = 0xx[removed] > CHAP-Password = 0xx[removed] > Service-Type = Login-User > WISPr-Logoff-URL = "http://10.5.50.1/logout"; > NAS-Identifier = "rural-ap1" > NAS-IP-Address = 10.0.0.249 > Processing the authorize section of radiusd.conf > modcall: entering group authorize for request 3 > modcall[authorize]: module "preprocess" returns ok for request 3 > rlm_chap: Setting 'Auth-Type := CHAP' > modcall[authorize]: module "chap" returns ok for request 3 > users: Matched entry DEFAULT at line 54 > radius_xlat: '/usr/local/bin/mtauth.pl [EMAIL PROTECTED]' > modcall[authorize]: module "files" returns ok for request 3 > radius_xlat: '[EMAIL PROTECTED]' > rlm_sql (sql): sql_set_user escaped user --> '[EMAIL PROTECTED]' > radius_xlat: 'SELECT id, UserName, Attribute, Value, op > FROM radcheck WHERE Username = '[EMAIL PROTECTED]' ORDER > BY id' > rlm_sql (sql): Reserving sql socket id: 0 > rlm_sql_mysql: query: SELECT id, UserName, Attribute, Value, op > FROM radcheck WHERE Username = '[EMAIL PROTECTED]' ORDER > BY id > radius_xlat: 'SELECT > radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op > FROM radgroupcheck,usergroup WHERE usergroup.Username = > '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupcheck.GroupName ORDER > BY radgroupcheck.id' > rlm_sql_mysql: query: SELECT > radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op > FROM radgroupcheck,usergroup WHERE usergroup.Username = > '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupcheck.GroupName ORDER > BY radgroupcheck.id > radius_xlat: 'SELECT id, UserName, Attribute, Value, op > FROM radreply WHERE Username = '[EMAIL PROTECTED]' ORDER > BY id' > rlm_sql_mysql: query: SELECT id, UserName, Attribute, Value, op > FROM radreply WHERE Username = '[EMAIL PROTECTED]' ORDER > BY id > radius_xlat: 'SELECT > radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op > FROM radgroupreply,usergroup WHERE usergroup.Username = > '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupreply.GroupName ORDER > BY radgroupreply.id' > rlm_sql_mysql: query: SELECT > radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op > FROM radgroupreply,usergroup WHERE usergroup.Username = > '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupreply.GroupName ORDER > BY radgroupreply.id > rlm_sql (sql): Released sql socket id: 0 > modcall[authorize]: module "sql" returns ok for request 3 > modcall: leaving group authorize (returns ok) for request 3 > rad_check_password: Found Auth-Type CHAP > auth: type "CHAP" > Processing the authenticate section of radiusd.conf > modcall: entering group CHAP for request 3 > rlm_chap: login attempt by "[EMAIL PROTECTED]" with CHAP password > rlm_chap: Using clear text password "xxx" for user [EMAIL PROTECTED] > authentication. > rlm_chap: chap user [EMAIL PROTECTED] authenticated succesfully > modcall[authenticate]: module "chap" returns ok for request 3 > modcall: leaving group CHAP (returns ok) for request 3 > Exec-Program output: Session-Timeout=1173, > Mikrotik-Xmit-Limit=1073222818, Mikrotik-Recv-Limit=1073515121, > Exec-Program-Wait: value-pairs: Session-Timeout=
Re: Strange behaviour of rlm_chap (freeradius 1.1.7+mysql)
And how can anyone help? You have deleted the most relevant parts of the debug (CHAP attributes and the password, which, according to the server, are not the same in both cases). If you don't want to use data from a real user, create a test one and post that. Ivan Kalik Kalik Informatika ISP Dana 6/9/2007, "Dan Searle" <[EMAIL PROTECTED]> piše: >Hi, > >Hello? Is there anybody out there? Can someone who knows how CHAP >works please explain to me how this could be happening? > >Does a CHAP challenge time-out after a certain amount of time? Does >the rlm_chap module hold a copy of old CHAP challenge's and prevent >the same one being re-used to stop replay attacks? If so how do I >switch this off? > >Anyone? Anything? > >Dan... > >Thursday, August 30, 2007, 3:08:16 PM, you wrote: > >> Hi, > >> I've been running a free radius server for a while now, but today for >> no apparent reason I'm getting a lot of intermittent authentication >> failures using the rlm_chap module. > >> Here's a trace of two login's the first works fine, the second a few >> moments later fails, the username and password supplied in both cases >> are correct and exactly the same. Can anyone shed any light on this? >> I've tried rebuilding the mysql database from scratch, and recompiling >> and installing the radius server, but to no avail... > >> > > >> rad_recv: Access-Request packet from host 81.178.20.107:1024, id=25, >> length=204 >> NAS-Port-Type = Wireless-802.11 >> Calling-Station-Id = "00:14:A4:87:DF:FF" >> Called-Station-Id = "rural-ap1" >> NAS-Port-Id = "wlan2" >> User-Name = "[EMAIL PROTECTED]" >> NAS-Port = 2149580817 >> Acct-Session-Id = "80200011" >> Framed-IP-Address = 10.5.50.254 >> Mikrotik-Host-IP = 10.5.50.254 >> CHAP-Challenge = 0xx[removed] >> CHAP-Password = 0xx[removed] >> Service-Type = Login-User >> WISPr-Logoff-URL = "http://10.5.50.1/logout"; >> NAS-Identifier = "rural-ap1" >> NAS-IP-Address = 10.0.0.249 >> Processing the authorize section of radiusd.conf >> modcall: entering group authorize for request 3 >> modcall[authorize]: module "preprocess" returns ok for request 3 >> rlm_chap: Setting 'Auth-Type := CHAP' >> modcall[authorize]: module "chap" returns ok for request 3 >> users: Matched entry DEFAULT at line 54 >> radius_xlat: '/usr/local/bin/mtauth.pl [EMAIL PROTECTED]' >> modcall[authorize]: module "files" returns ok for request 3 >> radius_xlat: '[EMAIL PROTECTED]' >> rlm_sql (sql): sql_set_user escaped user --> '[EMAIL PROTECTED]' >> radius_xlat: 'SELECT id, UserName, Attribute, Value, op >> FROM radcheck WHERE Username = '[EMAIL PROTECTED]' ORDER >> BY id' >> rlm_sql (sql): Reserving sql socket id: 0 >> rlm_sql_mysql: query: SELECT id, UserName, Attribute, Value, op >> FROM radcheck WHERE Username = '[EMAIL PROTECTED]' ORDER >> BY id >> radius_xlat: 'SELECT >> radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op >> FROM radgroupcheck,usergroup WHERE usergroup.Username = >> '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupcheck.GroupName ORDER >> BY radgroupcheck.id' >> rlm_sql_mysql: query: SELECT >> radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op >> FROM radgroupcheck,usergroup WHERE usergroup.Username = >> '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupcheck.GroupName ORDER >> BY radgroupcheck.id >> radius_xlat: 'SELECT id, UserName, Attribute, Value, op >> FROM radreply WHERE Username = '[EMAIL PROTECTED]' ORDER >> BY id' >> rlm_sql_mysql: query: SELECT id, UserName, Attribute, Value, op >> FROM radreply WHERE Username = '[EMAIL PROTECTED]' ORDER >> BY id >> radius_xlat: 'SELECT >> radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op >> FROM radgroupreply,usergroup WHERE usergroup.Username = >> '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupreply.GroupName ORDER >> BY radgroupreply.id' >> rlm_sql_mysql: query: SELECT >> radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op >> FROM radgroupreply,usergroup WHERE usergroup.Username = >> '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupreply.GroupName ORDER >> BY radgroupreply.id >> rlm_sql (sql): Released sql socket id: 0 >> modcall[authorize]: module "sql" returns ok for request 3 >> modcall: leaving group authorize (returns ok) for request 3 >> rad_check_password: Found Auth-Type CHAP >> auth: type "CHAP" >> Processing the authenticate section of radiusd.conf >> modcall: entering group CHAP for request 3 >> rlm_chap: login attempt by "[EMAIL PROTECTED]" with CHAP password >> rlm_chap: Using cle
Re: Strange behaviour of rlm_chap (freeradius 1.1.7+mysql)
Dan Searle wrote: > Hello? Is there anybody out there? Are you going to read previous responses on this list? http://lists.freeradius.org/pipermail/freeradius-users/2007-August/065807.html > Can someone who knows how CHAP > works please explain to me how this could be happening? See the previous message. > Does a CHAP challenge time-out after a certain amount of time? Does > the rlm_chap module hold a copy of old CHAP challenge's and prevent > the same one being re-used to stop replay attacks? No, and no. Try it using radclient. Take the attributes printed out in debugging mode from the Access-Request, and put them into a file. Replace the CHAP-Password hex stuff with the real password (radclient will do the CHAP hashing). Use radclient to send the packet to the server... multiple times a) you see the same thing: bad RAM or memory corruption b) radclient always works: throw away your NAS and buy one that works. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re[2]: Strange behaviour of rlm_chap (freeradius 1.1.7+mysql)
Hi, I can assure you the password is exactly the same in both cases. I'll try and setup a test user later on and post the results. But the passwords in the two traces I posted below were the same. Dan... Thursday, September 6, 2007, 10:47:34 AM, you wrote: > And how can anyone help? You have deleted the most relevant parts of the > debug (CHAP attributes and the password, which, according to the server, > are not the same in both cases). If you don't want to use data from a > real user, create a test one and post that. > Ivan Kalik > Kalik Informatika ISP > Dana 6/9/2007, "Dan Searle" <[EMAIL PROTECTED]> piše: >>Hi, >> >>Hello? Is there anybody out there? Can someone who knows how CHAP >>works please explain to me how this could be happening? >> >>Does a CHAP challenge time-out after a certain amount of time? Does >>the rlm_chap module hold a copy of old CHAP challenge's and prevent >>the same one being re-used to stop replay attacks? If so how do I >>switch this off? >> >>Anyone? Anything? >> >>Dan... >> >>Thursday, August 30, 2007, 3:08:16 PM, you wrote: >> >>> Hi, >> >>> I've been running a free radius server for a while now, but today for >>> no apparent reason I'm getting a lot of intermittent authentication >>> failures using the rlm_chap module. >> >>> Here's a trace of two login's the first works fine, the second a few >>> moments later fails, the username and password supplied in both cases >>> are correct and exactly the same. Can anyone shed any light on this? >>> I've tried rebuilding the mysql database from scratch, and recompiling >>> and installing the radius server, but to no avail... >> >>> >> >> >>> rad_recv: Access-Request packet from host 81.178.20.107:1024, id=25, >>> length=204 >>> NAS-Port-Type = Wireless-802.11 >>> Calling-Station-Id = "00:14:A4:87:DF:FF" >>> Called-Station-Id = "rural-ap1" >>> NAS-Port-Id = "wlan2" >>> User-Name = "[EMAIL PROTECTED]" >>> NAS-Port = 2149580817 >>> Acct-Session-Id = "80200011" >>> Framed-IP-Address = 10.5.50.254 >>> Mikrotik-Host-IP = 10.5.50.254 >>> CHAP-Challenge = 0xx[removed] >>> CHAP-Password = 0xx[removed] >>> Service-Type = Login-User >>> WISPr-Logoff-URL = "http://10.5.50.1/logout"; >>> NAS-Identifier = "rural-ap1" >>> NAS-IP-Address = 10.0.0.249 >>> Processing the authorize section of radiusd.conf >>> modcall: entering group authorize for request 3 >>> modcall[authorize]: module "preprocess" returns ok for request 3 >>> rlm_chap: Setting 'Auth-Type := CHAP' >>> modcall[authorize]: module "chap" returns ok for request 3 >>> users: Matched entry DEFAULT at line 54 >>> radius_xlat: '/usr/local/bin/mtauth.pl [EMAIL PROTECTED]' >>> modcall[authorize]: module "files" returns ok for request 3 >>> radius_xlat: '[EMAIL PROTECTED]' >>> rlm_sql (sql): sql_set_user escaped user --> '[EMAIL PROTECTED]' >>> radius_xlat: 'SELECT id, UserName, Attribute, Value, op >>> FROM radcheck WHERE Username = '[EMAIL PROTECTED]' >>> ORDER BY id' >>> rlm_sql (sql): Reserving sql socket id: 0 >>> rlm_sql_mysql: query: SELECT id, UserName, Attribute, Value, op >>> FROM radcheck WHERE Username = '[EMAIL PROTECTED]' >>> ORDER BY id >>> radius_xlat: 'SELECT >>> radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op >>> FROM radgroupcheck,usergroup WHERE usergroup.Username = >>> '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupcheck.GroupName ORDER >>> BY radgroupcheck.id' >>> rlm_sql_mysql: query: SELECT >>> radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op >>> FROM radgroupcheck,usergroup WHERE usergroup.Username = >>> '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupcheck.GroupName ORDER >>> BY radgroupcheck.id >>> radius_xlat: 'SELECT id, UserName, Attribute, Value, op >>> FROM radreply WHERE Username = '[EMAIL PROTECTED]' >>> ORDER BY id' >>> rlm_sql_mysql: query: SELECT id, UserName, Attribute, Value, op >>> FROM radreply WHERE Username = '[EMAIL PROTECTED]' >>> ORDER BY id >>> radius_xlat: 'SELECT >>> radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op >>> FROM radgroupreply,usergroup WHERE usergroup.Username = >>> '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupreply.GroupName ORDER >>> BY radgroupreply.id' >>> rlm_sql_mysql: query: SELECT >>> radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op >>> FROM radgroupreply,usergroup WHERE usergroup.Username = >>> '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupreply.GroupName ORDER >>> BY radgroupreply.id >>> rlm_sql (sql): Released sql socket id: 0 >>> modcall[authorize]:
Re[4]: Strange behaviour of rlm_chap (freeradius 1.1.7+mysql)
Hi, No, again I can assure you that the same password is sent in both cases, and it matches the password on the server (stored in clear text). Thursday, September 6, 2007, 11:04:12 AM, you wrote: > Password on the server is most likely the same. Password sent most likely > isn't. > Ivan Kalik > Kalik Informatika ISP > Dana 6/9/2007, "Dan Searle" <[EMAIL PROTECTED]> piše: >>Hi, >> >>I can assure you the password is exactly the same in both cases. I'll >>try and setup a test user later on and post the results. But the >>passwords in the two traces I posted below were the same. >> >>Dan... >> >>Thursday, September 6, 2007, 10:47:34 AM, you wrote: >> >>> And how can anyone help? You have deleted the most relevant parts of the >>> debug (CHAP attributes and the password, which, according to the server, >>> are not the same in both cases). If you don't want to use data from a >>> real user, create a test one and post that. >> >>> Ivan Kalik >>> Kalik Informatika ISP >> >> >>> Dana 6/9/2007, "Dan Searle" <[EMAIL PROTECTED]> piše: >> Hi, Hello? Is there anybody out there? Can someone who knows how CHAP works please explain to me how this could be happening? Does a CHAP challenge time-out after a certain amount of time? Does the rlm_chap module hold a copy of old CHAP challenge's and prevent the same one being re-used to stop replay attacks? If so how do I switch this off? Anyone? Anything? Dan... Thursday, August 30, 2007, 3:08:16 PM, you wrote: > Hi, > I've been running a free radius server for a while now, but today for > no apparent reason I'm getting a lot of intermittent authentication > failures using the rlm_chap module. > Here's a trace of two login's the first works fine, the second a few > moments later fails, the username and password supplied in both cases > are correct and exactly the same. Can anyone shed any light on this? > I've tried rebuilding the mysql database from scratch, and recompiling > and installing the radius server, but to no avail... > > rad_recv: Access-Request packet from host 81.178.20.107:1024, id=25, > length=204 > NAS-Port-Type = Wireless-802.11 > Calling-Station-Id = "00:14:A4:87:DF:FF" > Called-Station-Id = "rural-ap1" > NAS-Port-Id = "wlan2" > User-Name = "[EMAIL PROTECTED]" > NAS-Port = 2149580817 > Acct-Session-Id = "80200011" > Framed-IP-Address = 10.5.50.254 > Mikrotik-Host-IP = 10.5.50.254 > CHAP-Challenge = 0xx[removed] > CHAP-Password = 0xx[removed] > Service-Type = Login-User > WISPr-Logoff-URL = "http://10.5.50.1/logout"; > NAS-Identifier = "rural-ap1" > NAS-IP-Address = 10.0.0.249 > Processing the authorize section of radiusd.conf > modcall: entering group authorize for request 3 > modcall[authorize]: module "preprocess" returns ok for request 3 > rlm_chap: Setting 'Auth-Type := CHAP' > modcall[authorize]: module "chap" returns ok for request 3 > users: Matched entry DEFAULT at line 54 > radius_xlat: '/usr/local/bin/mtauth.pl [EMAIL PROTECTED]' > modcall[authorize]: module "files" returns ok for request 3 > radius_xlat: '[EMAIL PROTECTED]' > rlm_sql (sql): sql_set_user escaped user --> '[EMAIL PROTECTED]' > radius_xlat: 'SELECT id, UserName, Attribute, Value, op > FROM radcheck WHERE Username = '[EMAIL PROTECTED]' > ORDER BY id' > rlm_sql (sql): Reserving sql socket id: 0 > rlm_sql_mysql: query: SELECT id, UserName, Attribute, Value, op > FROM radcheck WHERE Username = '[EMAIL PROTECTED]' > ORDER BY id > radius_xlat: 'SELECT > radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op > FROM radgroupcheck,usergroup WHERE usergroup.Username = > '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupcheck.GroupName > ORDER BY radgroupcheck.id' > rlm_sql_mysql: query: SELECT > radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op > FROM radgroupcheck,usergroup WHERE usergroup.Username = > '[EMAIL PROTECTED]' AND usergroup.GroupName = radgroupcheck.GroupName > ORDER BY radgroupcheck.id > radius_xlat: 'SELECT id, UserName, Attribute, Value, op > FROM radreply WHERE Username = '[EMAIL PROTECTED]' > ORDER BY id' > rlm_sql_mysql: query: SELECT id, UserName, Attribute, Value, op > FROM radreply WHERE Username = '[EMAIL PROTECTED]' > ORDER BY id > radius_xlat: 'SELECT > radgroupreply.id,radgroupreply.GroupName,radgrouprepl
