> Ideally, if a new Acct-Start comes in on the same NAS/port
> combination as an old session, the old one should be
> effectively radzap'd. rlm_sql may or may not do this, I can't
> remember.
I don't think so, at least I found nothing in the source which could do
it (as far as I understand it)
But this won't help me either because in many circumstances I don't even
have a useful nas-port (IPSec-clients, PPPoE/L2TP tunnels)
> The main problem with radzap is that it zeros the
> octet counters which may have had valid data from Alive
> packets in 'em.
Ok, this at least means radzap is nothing for me ;) octets are quite
vital for volume based billing. furthermore, I have no access to some of
the NASes..
What I don't know now: can I PREpend the below query in sql.conf to i.e.
"accounting_start_query" with a trailing ";" without disturbing
operation ? because this will result in what I want, maintaining stale
session without running any external stuff.
I'm currently constructing some SQL-queries which might be able to
handle this.
- this only works if ever any Alive-packet was received to prevent
closing sessions on NASes not sending updates.
- close every session stale for more than 10 minutes.
--- cut ---
UPDATE radacct
SET
AcctStopTime = FROM_UNIXTIME(unix_timestamp(AcctStartTime) +
AcctSessionTime),
AcctTerminateCause = 'NoStopRecv',
AcctStopDelay = (unix_timestamp(now()) -
(unix_timestamp(AcctStartTime) + AcctSessionTime))
WHERE
AcctStopTime = ''
AND (unix_timestamp(now()) - (unix_timestamp(AcctStartTime) +
AcctSessionTime)) > 600
AND AcctSessiontime > 0
;
--- cut ---
The next one is for records without any alive every received, stale for
>24hours (this is my max-session timeout)
--- cut ---
UPDATE radacct
SET
AcctStopTime = AcctStartTime,
AcctTerminateCause = 'NoStop-AliveRecv',
AcctStopDelay = (unix_timestamp(now()) -
(unix_timestamp(AcctStartTime)))
WHERE
AcctStopTime = ''
AND AcctSessionTime = 0
AND (unix_timestamp(now()) - unix_timestamp(AcctStartTime)) >
86400
;
--- cut ---
This issue is also related to the Simultaneous-Use stuff for anybody
without direct NAS-access I think but this I'll look into another time;
currently I don't care as I don't have any flatrate-users which might
take adavantage of using an account for multiple logins. but I'm still
thinking about how to detect the keepalive-frequence with least changes
to freeradius and the sql-db..
Michael
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html