annoying stop retransmissions.

[Alexandre Chapellon]

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>