I did not modify the default schema. I am just using the radius client that is in debian in order to authenicate pptp clients. Everything is on the same server so it is not a issue with packets being lost.
i radiusclient1 - /bin/login replacement which uses the RADIUS protocol for authentication I do blame the nas and have cursed at pptp quite a bit, not I just want the dam thing to only send one radacct packet. ----- Original Message ----- From: Fajar A. Nugraha <[email protected]> To: Ski Mountain <[email protected]>; FreeRadius users mailing list <[email protected]> Cc: Sent: Wednesday, February 15, 2012 10:48 PM Subject: Re: duplicate radacct entries On Thu, Feb 16, 2012 at 10:13 AM, Ski Mountain <[email protected]> wrote: > The problem appears to be that for the second entry there is never a > acctstoptime entered into the databse, Both entries have DIFFERENT acctsessionid (and thus, different acctuniqueid). That means the NAS is sending acct for two different sessions. > or is there a way to make it so only entry is entered into the database. > where is just says 0000-00-00 00:00:00. Blame the NAS. It's possible that: - on the first record, the NAS is only sending acct-stop - an acct-stop packet is lost - you modified the default scheme, since by default an accounting record without acct-stop would have NULL in acctstoptime I suggest you: (1) log acct packets to detail file as well. e.g. accounting { ... detail sql ... } that way you can examine the detail file later to see what packets FR recieved from the NAS. That way you can correctly determine which of the three possibilites above actually happen (2) add an additional column: acct-status-type, and modify the sql queries accordingly. Similar to the above, but this way you can quickly determine whether an acct-stop packet is lost. -- Fajar - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
