dealing with 'corrupt' detail file

[Arran Cudbard-Bell]

-----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-----