> 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