[RADIATOR] RADIUS/Radiator concurrency enforcement race condition?

[Hugh Irvine]

Hello Joe, Hello Dave -

Yes, exactly what I would do too.

The standard Radiator default behaviour is to insert a record in the  
session database on the accounting start, but sometimes you need the  
record inserted (temporarily) when the access accept is returned.

Thanks Joe!

regards

Hugh


On 8 Jul 2008, at 16:47, Joe Hughes wrote:

> 2008/7/7 Dave Kitabjian <dave at netcarrier.com>:
>> Hi folks,
>> In other words, the problem is caused by the fact that the step  
>> that checks
>> for concurrency is separated from the step that logs the session.  
>> A DB Admin
>> will describe this as a lack of "transaction processing".
>>
>> Now, normally, this might be a rare situation. But we are working  
>> on a
>> solution that will use Radiator to enforce concurrency with a  
>> "NAS" that
>> will be hit with an automatic (software) dialer which will rapid- 
>> fire the
>> requests as illustrated.
>
> I had to work around a similar situation. We have DSL customers who do
> he normal 'Access-Request, Access-Accept, Accounting-Start' scenario -
> and we create the session on the Start. This caused us weird problems
> because some DSL customers (unfiltered, poor lines) were sending login
> attempts every couple of seconds. The NAS woudls sometimes only do
> 'Access-Request, Access-Accept, .... {No Start}..... Access-Request,
> Access-Accept,' So it wouldn't send a START message if a DSL session
> broke down during the login processs.
>
> I worked around this by having two AuthBy SQL clauses, the second one
> would fire only if the first was successful (ContinueWhileAccept). The
> first clause would authenticate the Access-Request using our database
> and enforce any session limits. Within the second clause, I can assume
> the credentials were correct so I then create a session in our session
> table.
>
> I then have a datetime Accounting-Start column which is by default
> NULL. In 99.9% of cases, when I send back the Accept, I will receive a
> 'Start' within seconds - in which case I set the Accounting-Start
> column to said value. If I don't receive an Accounting-Start message
> within a time-frame (30 seconds for instance) - I can assume the
> Session didnt come up and I can clear it from our table (where
> Accounting-Start is NULL). Obviously during this 30s period any
> duplicate attempts are blocked, until my procedure clears the session
> down.
>
> I think this would solve your problem because as soon as the first
> client successfully authenticates, a session is created (albeit
> temporary) and is ratified when the START is received. If no START is
> received, then the session is cleared down.
>
> Rather than using the built-in session management, I actually wrote
> our own session table\management using a combination of triggers on
> the accounting table and sprocs just to give some added flexibility.
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator



NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.