Accounting Start Queries getting lost
Hi, We are having an issue where, in some sessions, an Authentication Request is sent successfully (and inserted into RADPOSTAUTH table), but the Accounting Start Query is never run/received. Subsequently, Accounting Update Queries come through, but fail due to the fact that a relevant RADACCT session has not been inserted to begin with. It only happens in a small amount of cases, < 1% of sessions, but nonetheless opens us to loss of data that is not being billed for properly. Is this a known issue? Is there a workaround? We're looking at changing the Acct Update Query to insert a new session if it cannot find an existing one. Any help will be appreciated. henk -- Henk Kleynhans CTO & Founder Skyrove (Pty) Ltd Technology Top 100 - Most Promising Emerging Enterprise 2006 Tel: +27 (21) 4488843 Cell: +27 (84) 3073451 Fax: +27 (86) 6204077 henk@skyrove.com blog: www.geekrebel.com ------ "A person with ubuntu is open and available to others, affirming of others, does not feel threatened that others are able and good, for he or she has a proper self-assurance that comes from knowing that he or she belongs in a greater whole and is diminished when others are humiliated or diminished, when others are tortured or oppressed." - Desmond Tutu
Henk Kleynhans wrote:
Hi,
We are having an issue where, in some sessions, an Authentication Request is sent successfully (and inserted into RADPOSTAUTH table), but the Accounting Start Query is never run/received.
Subsequently, Accounting Update Queries come through, but fail due to the fact that a relevant RADACCT session has not been inserted to begin with.
It only happens in a small amount of cases, < 1% of sessions, but nonetheless opens us to loss of data that is not being billed for properly.
Is this a known issue? Is there a workaround? We're looking at changing the Acct Update Query to insert a new session if it cannot find an existing one.
Any help will be appreciated.
You should never rely on receiving accounting queries. They are UDP and easily go missing. You could even receive duplicates (e.g. two start packets). What I have done (pseudo code): if (Start) { Try to insert Session If already exists, update } elseif (Interim) { Try to update Session If not exist, insert } elsif (Stop) { Try to update Session If not exist, insert } -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
We are having an issue where, in some sessions, an Authentication Request is sent successfully (and inserted into RADPOSTAUTH table), but the Accounting Start Query is never run/received.
Subsequently, Accounting Update Queries come through, but fail due to the fact that a relevant RADACCT session has not been inserted to begin with.
It only happens in a small amount of cases, < 1% of sessions, but nonetheless opens us to loss of data that is not being billed for properly.
Is this a known issue? Is there a workaround? We're looking at changing the Acct Update Query to insert a new session if it cannot find an existing one.
Default dialup.conf has alternative queries to deal with this. If UPDATE fails it will do an INSERT. But if you have made custom queries ... Ivan Kalik Kalik Informatika ISP
participants (3)
-
Henk Kleynhans -
Ivan Kalik -
Johan Meiring