-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
(I've already got, on my list, use Calling-Station-Id instead of NAS-Port for the unique function as many NAS use the same port for every accounting packet :-|) Create a patch, and send it to the list via git format-patch. "Best practices" really need to go into the server configuration. Anything else is too frustrating for the end users.
I was hoping to get a small discussion initiated that would hopefully bring up a few things that people find they have to do to their configs ...at the end of which we get a nice comprehensive list of updates needed for the core server configuration (and hopefully a large number of 'you need to change this or add that' blog/wiki/random document entries removed across the world) We write out a different detail file per hour. If for whatever reason the account buffer gets to be big, and you have to restart the server, at least you only have to deal with an hours worth of duplicate accounting logs.
And just as Alan DeKok suggested: accounting { # # Log traffic to an SQL database. # # See "Accounting queries" in sql.conf sql { invalid = 2 } if (invalid) { ok } } You can log it to a rejects detail file as well, if you want to dissect the packets later. The other (far more difficult) to handle one, is where you're using this to Proxy eduroam Accounting records back to an ORPS. If the administrator of the ORPS has been particularly... obnoxious. Then the ORPS will not send Accounting-Responses, and the packet will be stuck in the detail file indefinitely. Our workaround is: accounting { # # Icky workaround for lack of universal eduroam accounting support # Really need NRPS to manufacture accounting response. # if((Acct-Delay-Time < 600) || (Realm != 'remote.jrs')){ proxy_to_realm } # # Since we're proxying, we don't log anything # locally. Ensure that the accounting section # "succeeds" by forcing an "ok" return. ok } This sucks, because perfectly valid Accounting Requests might be lost if they were received at around the same time as invalid ones. I'd be interested to hear if anyone has a better solution than the above. Thanks, Arran -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkono1MACgkQcaklux5oVKKh8ACdHgDLbeRIF6wpJY9boGATfybU AiUAoIsSVWWYt6LUETZ6Ky15Out8Fm+w =cShM -----END PGP SIGNATURE-----