sqlcounter problem after upgrading to 2.1.0

[Abraham Jacob]

Hi JT,

 You can apply following patch to prevent group attributes with
operator := overwriting user attributes. Just commenting out the
overwritng code in valuepair.c

Regards,
Abraham

--- src/main/valuepair.c.orig   2008-09-17 16:57:25.000000000 +0530
+++ src/main/valuepair.c        2008-09-17 16:58:41.000000000 +0530
@@ -631,11 +631,13 @@
                         */
                case T_OP_SET:          /* := */
                        if (found) {
+                               /*
                                VALUE_PAIR *vp;

                                vp = found->next;
                                memcpy(found, i, sizeof(*found));
                                found->next = vp;
+                               */
                                continue;
                        }
                        break;



On 9/17/08, tnt at kalik.net <tnt at kalik.net> wrote:
> It's to do with operators rather than tables. "=" will not replace
>  attribute value if one already exists. ":=" will.
>
>  There is a case for blocking this in cases when same attribute has both
>  user and group sql entry. That would enable for user entries to take
>  preferance over group entries even when ":=" operator is used.
>
>
>  Ivan Kalik
>  Kalik Informatika ISP
>
>
>
> Dana 17/9/2008, "J M Toms" <jmtoms at gmail.com> piše:
>
>
>  >FYI, radreply items override radgroupreply. I have Idle-Timeout in
>  >both radreply and radgroupreply and user's values override what is set
>  >in groups.
>  >
>  >Why is this processing order different for check items? It is quite
>  >natural to set default values in group and override the defaults for
>  >some users by setting it in user table. Just curious..
>  >
>  >Thanks,
>  >JT
>  >
>  >
>  >On Tue, Sep 16, 2008 at 5:14 PM, J M Toms <jmtoms at gmail.com> wrote:
>  >> Hello Ivan,
>  >> Thanks for quick reply. Deleting the radgroupcheck entry did the trick.
>  >>
>  >> Regards,
>  >> JT
>  >>
>  >> 2008/9/16  <tnt at kalik.net>:
>  >>> And the point of radgroupcheck entry (apart from overwriting the radcheck
>  >>> entry - radcheck entry gets processed first, than radgruopcheck entry
>  >>> overwrites it) is? Remove that entry and store that value somewhere else
>  >>> - not in radius schema. Create an additional table and store such stuff
>  >>> there.
>  >>>
>  >>> Ivan Kalik
>  >>> Kalik Informatika ISP
>  >>>
>  >>>
>  >>
>  >-
>  >List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>  >
>  >
>
>  -
>  List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>