Hi I've been trying to debug why accounting information isn't making it into the SQL database on our main FR server (2.1.11) - it seems that this has been the case since upgrading from version 1.something ancient a few months back. I have a fairly simple MySQL backed setup - and minimal changes of the config files to enable this; just to be clear this was a fresh install of the OS + FreeRADIUS so no danger of old configuration files still lurking around. sql is uncommented in both the authorization and accounting sections of the sites-available/default file (accounting section shown below), and the sql module is enabled in radiusd.conf - the server works just fine for auth via SQL as can be seen in the debug. accounting { # # Create a 'detail'ed log of the packets. # Note that accounting requests which are proxied # are also logged in the detail file. detail # daily # Update the wtmp file # # If you don't use "radlast", you can delete this line. unix # # For Simultaneous-Use tracking. # # Due to packet losses in the network, the data here # may be incorrect. There is little we can do about it. radutmp # sradutmp # Return an address to the IP Pool when we see a stop record. # main_pool # # Log traffic to an SQL database. # # See "Accounting queries" in sql.conf sql # # If you receive stop packets with zero session length, # they will NOT be logged in the database. The SQL module # will print a message (only in debugging mode), and will # return "noop". # # You can ignore these packets by uncommenting the following # three lines. Otherwise, the server will not respond to the # accounting request, and the NAS will retransmit. # # if (noop) { # ok # } # # Instead of sending the query to the SQL server, # write it into a log file. # # sql_log # Cisco VoIP specific bulk accounting # pgsql-voip # For Exec-Program and Exec-Program-Wait exec # Filter attributes from the accounting response. attr_filter.accounting_response # # See "Autz-Type Status-Server" for how this works. # # Acct-Type Status-Server { # # } } I can see accounting requests being received, but there seems to be no sql module action happening to insert them into the database; but I cannot see why from the debug. I've not changed any of the pre-defined SQL queries. The debug log attached (it was a bit big to post inline) has had three minor hand-amendments: - SQL server password removed. - Shared secret for the two clients removed. - The very long list of clients loaded from SQL reduced to the router being tested. Any pointers/suggestions gratefully received. Regards, Paul.