(RADIATOR) Concurrency limit and platypus

[Hugh Irvine]

Hello Cameron -

>
>Hi Everyone,
>
>We've been experiencing a few issues since we switched to radiator running
>into concurrency limits for various customers.
>Users who haven't logged in for a day or two have their access rejected due
>to violation of their simultaneous use. We use the platypus billing system
>and essentially use the authby emerald module to authenticate.
>
>We had to modify our authemerald.pm file to correctly enforce session limits
>as we were unable to supply a full list of NAS addresses. And everything has
>worked perfectly aside from this issue. The only solution we found to
>temporarily supply access to our customers was to increase their
>simultaneous use limit in our plat database. Obviously this isn't the ideal
>solution, which is why i'm posting this to the list. Our system
>configuration is a redhat box running radiator connecting via the sybase DBI
>drivers to our sql server odbc connection directly so any issues with
>windows memory caching wouldnt seem to be an issue.
>
>Does anyone have any ideas why customers are likely to be denied access when
>they aren't violating the rules for simultaneous use specified in the
>database?
>

The reason for this sort of problem is almost always missing 
accounting records, specifically accounting stops in this case.

You will need to look at a trace 4 debug from Radaitor to ascertain 
exactly what is happening.

hth

Hugh


-- 

NB: I am travelling this week, so there may be delays in our correspondence.

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
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.