Hi Alan, Thank you for your reply. I have ran freeradius in debug mode and closely inspected each packet. No NAS is sending accounting stop packet incorrectly (At least it is not getting printed in logs).<br/> We do not have simultaneous user check or any SQL counter active. I will check for option C, mentioned by you. What i have observed(and mentioned earlier) there is an update query which may be the culprit. It is updating acctstop time for all records where nasipaddress = '192.168.182.1' and acctstoptime is null. This results in mass update of all such records. All openwrt nas have nasipaddress as 192.168.182.1 and hence the incorrect result.<br/> Could you please tell me what executes this query? In the mean time i will try and log all SQL queries. Thanks a lot!! On Sunday, December 11, 2016 8:15 AM, Alan DeKok <aland@deployingradius.com> wrote: On Dec 10, 2016, at 2:22 AM, Sachin Yadav via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
We have a large deployment of about 600 NAS (mixed openwrt/mikrotik/others). I have noticed that for some records, incorrect acctstoptime was marked while user session was still going on and accounting was happening.
FreeRADIUS doesn't invent accounting packets. You have a few choices: a) your NAS is incorrectly sending accounting "stop" packets for sessions which are ongoing - rare, but not impossible. b) something else is writing to the DB and setting acctstoptime - maybe you have Simultaneous-Use checking configured, and it's going wrong? c) you've configured the server to write stop times for non-stop packets - possible, but not common.
Or there may be some mis-configuration as our end. Kindly let me know.
Log all SQL queries, and all accounting packets. Then, see which ones update acctstoptime. And find out why... Alan DeKok.