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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.