(RADIATOR) Problem with session database and wireless reauthe ntication

[Roy Badami]

>>>>> "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.