Hello Anand -
On Wed, 24 Nov 1999, Anand Buddhdev wrote:
> I am running Radiator 2.14.1 on my site. I recently set it up
> to write session data into a DBM file, which we use for blocking
> multiple logons. I have a secondary server too, which does not
> authenticate, but only logs accouting data (I realise that this
> can cause a problem with Session Databases, and I'm trying to
> use SQL instead of DBM. In the meantime, I just delete stale
> entries from the Session DB by hand).
>
> Yesterday I noticed a problem. A user had connected at about 10.30 am
> and he then disconnected at about 11.15 am. However, the session
> database still showed him as logged in, and he therefore was unable
> to log on a few minutes later. I thought it might have been because
> the stop accounting packet from the NAS might have been logged
> to the secondary accounting server instead of the primary. So I
> went and looked at the detail file on the secondary. However, the
> stop accounting packet was not there either. Strangely though,
> the NAS (3COM total control) is also configured to do syslogging
> of events to the secondary accounting server, and in the syslog
> message file, the user is shown as logging on and then logging
> off. We however, don't make use of the syslog for any particular
> billing. I rely on the detail files for time-based billing. When I
> combined the 2 detail files from both servers, and ran it through
> the radacct.cgi script, there was no information about this
> particular user, presumably because the script uses the stop
> packet for determining the connect time, and it was missing.
>
> So my manager is worried that if this is happening to more users,
> then we may be losing accounting data. I know that RADIUS uses
> UDP for accounting, and UDP can sometimes lose data, because there's
> no acknowledgement. However, usually UDP is fairly reliable on a LAN
> (or so I've read and I'm told).
>
> Have other people experienced this kind of problem? If so, then
> it may give me some proof to present to management that we are
> not alone in experiencing this problem.
>
> Any pointers will be much appreciated.
Yes, this has been discussed on the list previously. Have a look at the archive:
http://www.thesite.com.au/~radiator/
regards
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
