RE: rlm_sql bug in 64-bit architecture ?
I would love to know what the: Invalid operator for item Expiration: reverting to '==' I get them like so: Invalid operator for item User-name: reverting to '==' All three of my server logs are filled with them and I've been unable to find the reason why. All the username's listed in the huntgroup can successfully authenticate. -----Original Message----- From: freeradius-users-bounces+cbell=thig.com@lists.freeradius.org [mailto:freeradius-users-bounces+cbell=thig.com@lists.freeradius.org]On Behalf Of Richard Cotrina Sent: Tuesday, July 24, 2007 2:57 PM To: FreeRadius users mailing list Subject: rlm_sql bug in 64-bit architecture ? Hi everyone : I've been searching for the possible causes of a problem, that appears when sqlcounter is enabled, and just in 64-bits plattforms (FreeBSD/Sparc64). The radius_xlat function performed by rlm_sql seems to not reading well some attributes like "Expiration" and always complains about "Invalid Operator", not matter what operator is put [1]. Note the big difference between the responses obtained in the 64-bit and 32-bit arch, using radtest and running radiusd in debug mode: rlm_sql can't read neither the value nor the operator for Expiration attribute, despite the fact that in both cases, the database used is the same. (rlm_sql debug options enabled in rlm_sql.c). freeradius 1.1.6 / FreeBSD Sparc64 ========================== radius_xlat: 'prueba@test.com' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := "prueba" Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration <INVALID-TOKEN> "Dec 31 1969 19:00:00 PET" <--- Notice this (where this value come from ?) rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' rlm_sql (sql): No matching entry in the database for request from user [prueba@test.com] modcall[authorize]: module "sql" returns notfound for request 9 rlm_sqlcounter: Entering module authorize code rlm_sqlcounter: Could not find Check item value pair modcall[authorize]: module "dailycounter" returns noop for request 9 [snip] --> Got an Access-Reject response freeradius 1.1.6 / FreeBSD i386 ======================= radius_xlat: 'prueba@test.com' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := "prueba" Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration := "Sep 24 2007 11:30:00 PET" <--- get the correct 'op' and 'value' rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 modcall[authorize]: module "sql" returns ok for request 0 rlm_sqlcounter: Entering module authorize code [snip] --> Got an Access-Accept response What could be going wrong with rlm_sql ? Is there any bug in freeradius code related to 64-bit architectures ? I'd appreciate any suggestion to solve this. Richard Cotrina [1]. http://archives.free.net.ph/message/20070517.165523.c7432a23.en.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html CONFIDENTIAL NOTICE: This email including any attachments, contains confidential information belonging to the sender. It may also be privileged or otherwise protected by work product immunity or other legal rules. This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this emailed information is strictly prohibited. If you have received this email in error, please immediately notify us by reply email of the error and then delete this email immediately.
If you have: somegroup User-Name = "whatever" That is normal. Huntgroup check item should have operator == not = and server is "clever" enough to fix it. But it will grumble in the log so you can change incorrect entries. Ivan Kalik Kalik Informatika ISP Dana 24/7/2007, "Chris Bell" <CBell@thig.com> piše:
I would love to know what the:
Invalid operator for item Expiration: reverting to '=='
I get them like so:
Invalid operator for item User-name: reverting to '=='
All three of my server logs are filled with them and I've been unable to find the reason why. All the username's listed in the huntgroup can successfully authenticate.
-----Original Message----- From: freeradius-users-bounces+cbell=thig.com@lists.freeradius.org [mailto:freeradius-users-bounces+cbell=thig.com@lists.freeradius.org]On Behalf Of Richard Cotrina Sent: Tuesday, July 24, 2007 2:57 PM To: FreeRadius users mailing list Subject: rlm_sql bug in 64-bit architecture ?
Hi everyone :
I've been searching for the possible causes of a problem, that appears when sqlcounter is enabled, and just in 64-bits plattforms (FreeBSD/Sparc64). The radius_xlat function performed by rlm_sql seems to not reading well some attributes like "Expiration" and always complains about "Invalid Operator", not matter what operator is put [1].
Note the big difference between the responses obtained in the 64-bit and 32-bit arch, using radtest and running radiusd in debug mode: rlm_sql can't read neither the value nor the operator for Expiration attribute, despite the fact that in both cases, the database used is the same. (rlm_sql debug options enabled in rlm_sql.c).
freeradius 1.1.6 / FreeBSD Sparc64 ==========================
radius_xlat: 'prueba@test.com' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := "prueba" Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration <INVALID-TOKEN> "Dec 31 1969 19:00:00 PET" <--- Notice this (where this value come from ?) rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' Invalid operator for item Expiration: reverting to '==' rlm_sql (sql): No matching entry in the database for request from user [prueba@test.com] modcall[authorize]: module "sql" returns notfound for request 9 rlm_sqlcounter: Entering module authorize code rlm_sqlcounter: Could not find Check item value pair modcall[authorize]: module "dailycounter" returns noop for request 9 [snip]
--> Got an Access-Reject response
freeradius 1.1.6 / FreeBSD i386 =======================
radius_xlat: 'prueba@test.com' rlm_sql (sql): [snip] radius_xlat: [snip] rlm_sql: check items User-Password := "prueba" Auth-Type := Local Simultaneous-Use := 1 Max-Daily-Session := 3600 Expiration := "Sep 24 2007 11:30:00 PET" <--- get the correct 'op' and 'value' rlm_sql: reply items Framed-Protocol = PPP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1500 Service-Type = Framed-User Idle-Timeout = 300 modcall[authorize]: module "sql" returns ok for request 0 rlm_sqlcounter: Entering module authorize code [snip]
--> Got an Access-Accept response
What could be going wrong with rlm_sql ? Is there any bug in freeradius code related to 64-bit architectures ?
I'd appreciate any suggestion to solve this.
Richard Cotrina
[1]. http://archives.free.net.ph/message/20070517.165523.c7432a23.en.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
CONFIDENTIAL NOTICE: This email including any attachments, contains confidential information belonging to the sender. It may also be privileged or otherwise protected by work product immunity or other legal rules. This information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this emailed information is strictly prohibited. If you have received this email in error, please immediately notify us by reply email of the error and then delete this email immediately. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Chris Bell said: : RE: rlm_sql bug in 64-bit architecture ?
I would love to know what the:
Invalid operator for item Expiration: reverting to '=='
I get them like so:
Invalid operator for item User-name: reverting to '=='
All three of my server logs are filled with them and I've been unable to find the reason why. All the username's listed in the huntgroup can successfully authenticate.
My bet is you have an = in a check attribute line in your users file, like: DEFAULT User-Name = "foo" Some-Attribute = "bar" For a check item (the first line) it should be an ==. DEFAULT User-Name == "foo" Some-Attribute = "bar" The "=" is an assignment operator (set Some-Attribute to have value "bar"). The "==" is a comparison operator (does User-Name have the value "foo"?). It is illegal to use the "=" on the check attribute line. -- hugh
Chris Bell wrote:
Invalid operator for item User-name: reverting to '=='
All three of my server logs are filled with them and I've been unable to find the reason why. All the username's listed in the huntgroup can successfully authenticate.
Have you looked at all of your references to User-Name in the configurations? What operator are they using? Is the operator correct? Alan DeKok.
participants (4)
-
Alan DeKok -
Chris Bell -
Hugh Messenger -
tnt＠kalik.co.yu