Hello, I have a setup wich Is a follow: NASes ----------------FREERADIUS Auth+live acct ----------------FREERADIUS Acct only In this setup, users connect to NASes, which authenticate them against the front freeradius (Auth + live acct). The front freeradius, maintain a db of the connected users using acct tickets. Basicly it does: INSERT in table upon Start ticket reception DELETE from table upon Stop ticket reception. In turns the front freeradius proxies acct tickets to the back freeradius (Acct only), which keeps track of all sessions doing: INSERT in table upon Start ticket reception UPDATE table upon Stop ticket reception. This work as epected for most of my NASes. Unfortunately, i have some NASes that are behind a satelite link, which is a very unreliable link with regular packets loss. UDP retramission of packet make the systems work even with that kind of link, but I have one scenario that create errors: When a stop ticket is transmitted once and reaches correctly the freradius servers (nas -> front -> back), Session record is deleted from the "live acct" table, packet is then proxied to the 2nd freeradius and session in Acct table is marked as stoped (acctstoptime=something). If the front freeradius acks the Stop packet and that Ack is lost on the link, the NAS retransmit the STOP. Same thing occur,: - front radius tries to delete the sessions using its acct_stop_query, wich result in no line being modified and so tries to run its acct_stop_query_alt (which basicly does the same thind: delete). alt query also modify no lines but no error is logged. retransmitted packet is then proxied to the back server, wich in turns tries ti run its acct_stop_query (tries to update a session with no acctstoptime). That query fails as the previous Stop ticket for that session already updated the recod. It then tries to run the acct_stop_query_alt, which is designed to try to insert a new session record based on the content of the stop ticket (this is done to deal with the case where start ticket is lost and only stop ticket is received, i guess). In my case this last query fails because of some unicity constraint in the oracle database (to prevent one session from being recorded multiple times), and an error is logged in freeradius. I can't really afford to get rid of the unique constraint, and I think changing the acct_stop_query_alt for a non insert statement would not be a good idea either. Does anybody have an idea on how to deal with that (minor) problem so I have no more regular error messages. I was maybe thinking of not proxying to the back server, packets retransmitted du to ACK loss, but I can't really find out how to do that... Thanks for reading that long post (I hope it's understandable enough). -- <http://www.horoa.net> Alexandre Chapellon Ingénierie des systèmes open sources et réseaux. Follow me on twitter: @alxgomz <http://www.twitter.com/alxgomz>