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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] >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: '[EMAIL PROTECTED]' >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 >[EMAIL PROTECTED] > 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: '[EMAIL PROTECTED]' >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 > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
