(RADIATOR) Problem with session database and wireless reauthe ntication

[Hugh Irvine]

Hello Roy -

You should have a look at a trace 4 debug of the sequence of requests 
to see if there is something different between the initial 
authentication and the subsequent re-authentication(s). If there is 
something different between them you can use Handlers to do something 
like this:

<SessionDatabase ....>
	Identifier MySDB
	.....
</SessionDatabase>

<SessionDatabase NULL>
	Identifier NullSDB
</SessionDatabase>

# Handler for accounting

<Handler Request-Type = Accounting-Request>
	SessionDatabase MySDB
	.....
</Handler>

# Handler for re-authentication(s)

<Handler ......>
	SessionDatabase NullSDB
	.....
</Handler>

# Handler for initial authentication

<Handler>
	SessionDatabase MySDB
	......
</Handler>


hth

regards

Hugh


On 10 Jan 2005, at 23:51, Roy Badami wrote:

>>>>>> "Frank" == Frank Danielson <fdanielson at csky.com> writes:
>
>     Frank> Another option is to have a handler for authentication with
>     Frank> a <SessionDatabase NULL> and a seperate handler for the
>     Frank> accounting with your <SessionDatabase SQL>. The downside to
>     Frank> this is that if you miss an accounting Start for some
>     Frank> reason, radwho won't show the session.
>
> This will mean that the session limit isn't checked, though.  It's a
> cleaner alternative to hacking the source though (I didn't realize
> that you could pub SessionDatabase clauses inside a handler).
>
> I'll probably do this for the moment.  Thanks.
>
>     Frank> You may also want to try and use a DeleteQuery value in
>     Frank> your <SessionDatabase SQL> that only works during
>     Frank> accounting requests by using the special variables in
>     Frank> section 6.2 of the manual. Something like delete from
>     Frank> RADONLINE where NASIDENTIFIER='%1' and NASPORT=0%2 AND
>     Frank> %{Acct-Status-Type} = 'Stop'. This will only delete from
>     Frank> the table during Stop accounting requests and not access
>     Frank> requests. The downside here and the reason why there is a
>     Frank> delete during access requests is that you will get a hung
>     Frank> session in the table if you miss an accounting Stop.
>
> Currently I'm using <SessionDatabase DBM> so this won't work for me.
> I'll bear it in mind for when we switch to using SQL.
>
>     Frank> requests. The downside here and the reason why there is a
>     Frank> delete during access requests is that you will get a hung
>     Frank> session in the table if you miss an accounting Stop.
>
> Won't a subsequent accounting start for that port update the session
> db anyway?  This will cause a problem with session limits in some
> cases, but I think the session limit check can safely be skipped if
> the user authenticating is the same as the user listed for that port
> in the session database (since connecting to a port that RADIATOR
> thinks you're already using can never increase the number of
> concurrent sessions for that user)
>
> 	   -roy
>
>
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

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?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
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.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.