I did read the whole thing. I did not include settings of other sections
because
I thought they took too much space in the mail,
but I did uncomment the 'daily' stanza in the accounting section.

Currently I have:

module {
...
        counter daily {
                filename = ${raddbdir}/db.daily
                key = User-Name
                count-attribute = Acct-Session-Time
                reset = daily
                counter-name = Daily-Session-Time
                check-name = Max-Daily-Session
                allowed-servicetype = Outbound-User
                cache-size = 5000
        }
....
}

instantiate {
        expr
        daily
}

authorize {
        preprocess
      sql
        files
        daily
}

accounting {
        acct_unique
      sql
        detail
        daily
        radutmp
}

And I have the following setting in 'users'
Alex    Max-Daily-Session := 30
DEFAULT Max-Daily-Session := 20

This is the log I get from radisud

=============
rad_recv: Access-Request packet from host 192.168.1.100:2100, id=40,
length=68
        User-Name = "Alex"
        User-Password = "alextest"
        NAS-IP-Address = 192.168.1.100
        NAS-Port = 1
        NAS-Port-Type = Ethernet
        NAS-Port-Id = "1234"
modcall: entering group authorize
....
rlm_counter: Entering module authorize code
rlm_counter: Key = User-Name, string value = Alex
rlm_counter: Check VP name = Max-Daily-Session, value = 30
rlm_counter: Set user_counter to 0
rlm_counter: Search for key_datum.dptr 'Alex'
rlm_counter: gdbm_fetch returns count_datum.dptr == NULL
rlm_counter: Counter attribute = 'Acct-Session-Time'
rlm_counter: create reply item Session-Timeout, value = 30
rlm_counter: (Check item - counter) is greater than zero
rlm_counter: Authorized user Alex, check_item=30, counter=0
rlm_counter: Sent Reply-Item for user Alex, Type=Session-Timeout, value=30
  modcall[authorize]: module "daily" returns ok
modcall: group authorize returns ok
auth: type Crypt
Sending Access-Accept of id 40 to 192.168.1.100:2100
        Service-Type := Outbound-User
        Class := 0x566973612050726570616964
        Session-Timeout = 30
Finished request 0
=============


( The extra rlm_counter messages are from the DEBUG2 statements I sprinkled
in
  rlm_counter.c to see the code flow.)

So far so good.  I then sent in account start/stop requests

=============
rad_recv: Accounting-Request packet from host 192.168.1.100:2101, id=41,
length=61
        User-Name = "Alex"
        Acct-Status-Type = Start
        NAS-IP-Address = 192.168.1.100
        NAS-Port = 1
        NAS-Port-Type = Ethernet
        Acct-Session-Id = "100"
        NAS-Port-Id = "1234"
modcall: entering group accounting
....
rlm_counter: We only run on Accounting-Stop packets.
....
modcall: group accounting returns ok
Sending Accounting-Response of id 41 to 192.168.1.100:2101
Finished request 1
...
rad_recv: Accounting-Request packet from host 192.168.1.100:2102, id=42,
length=61
        User-Name = "Alex"
        Acct-Status-Type = Stop
        NAS-IP-Address = 192.168.1.100
        NAS-Port = 1
        NAS-Port-Type = Ethernet
        Acct-Session-Id = "100"
        Acct-Session-Time = 10
...
modcall: entering group accounting
...
rlm_counter: Packet Unique ID = 'ac378b971733fdb1'
  modcall[accounting]: module "daily" returns noop
...
Sending Accounting-Response of id 42 to 192.168.1.100:2102
Finished request 2
...
rad_recv: Access-Request packet from host 192.168.1.100:2103, id=43,
length=68
        User-Name = "Alex"
        User-Password = "alextest"
        NAS-IP-Address = 192.168.1.100
        NAS-Port = 1
        NAS-Port-Type = Ethernet
        NAS-Port-Id = "1234"
modcall: entering group authorize
...
rlm_counter: Entering module authorize code
rlm_counter: Key = User-Name, string value = Alex
rlm_counter: Check VP name = Max-Daily-Session, value = 30
rlm_counter: Set user_counter to 0
rlm_counter: Search for key_datum.dptr 'Alex'
rlm_counter: gdbm_fetch returns count_datum.dptr == NULL
rlm_counter: Counter attribute = 'Acct-Session-Time'
rlm_counter: create reply item Session-Timeout, value = 30
rlm_counter: (Check item - counter) is greater than zero
rlm_counter: Authorized user Alex, check_item=30, counter=0
rlm_counter: Sent Reply-Item for user Alex, Type=Session-Timeout, value=30
  modcall[authorize]: module "daily" returns ok
modcall: group authorize returns ok
auth: type Crypt
Sending Access-Accept of id 43 to 192.168.1.100:2103
        Service-Type := Outbound-User
        Class := 0x566973612050726570616964
        Session-Timeout = 30
Finished request 3
=============

The Session-Timeout returned from the server for user 'Alex' is always 30.
It seems in request 2 the counter module 'daily' does not do anything and in
request 3
the counter cannot find the record of user 'Alex' so it just returns the
same value.

I do not know what I have missed in the counter settings or attributes I
should have
sent to the server to make it work.


> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> Alan DeKok
> Sent: Friday, July 25, 2003 2:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Session Timeout
>
>
> "Alex Chen" <[EMAIL PROTECTED]> wrote:
> > 2. Counter uses 'User-Name' as the key and creates a counter for it.
> >    It looks for a counter attribute, 'Acct-Session-Time',
> in the accounting
> >    packets and increments the value of this attribute in
> its DB by the
> >    amount specified in the request.
>
>   Are you sure?  Have you tried running it in debugging mode to see
> this happening?
>
> > The example uses Max-Daily-Session, but these is no such
> attribute name and
> > radiusd fails to start if I set it, so I used 'Session-Timeout'.
>
>   And you expect it to work?
>
>   The instructions an examples in radiusd.conf are there for a
> REASON.  FOLLOW THEM.
>
> > The setting in radiusd.conf
> >
> > module {
> > ...
> >     counter daily {
> ...
>
>   You do realise that the 'counter' module will be totally ignored,
> unless you also list it in the 'accounting' section"?
>
>   Have you read the REST of 'radiusd.conf', to see where else the
> counter module should be used?
>
>
>   I fail to understand why you've only read half of 'radiusd.conf',
> and why you've done something OTHER than what it says to do.  I'm even
> more surprised that you're wondering why it doesn't work.
>
>   While I understand that the documentation for the server could use
> some work, it is MORE than adequate to solve the problem you're trying
> to address.
>
>   Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to