In article <[EMAIL PROTECTED]>,
c <[EMAIL PROTECTED]> wrote:
>On Tue, 24 Jul 2001 20:11, Miquel van Smoorenburg wrote:
>
>> If that is the case, then the 'sac' program you're using is buggy.
>>
>> The radwtmp file and the detail files are written at the same time,
>> with the same info. The difference is that a lot of data is left out
>> in the radwtmp file (it's incomplete) and if some accounting packets
>> get dropped or arrive in the wrong order there will be corrupt or
>> missing entries in the radwtmp file.
>
>radiusd-cistron here on 240 busy lines and we find
>that radwtmp get's so out of whack the admin staff
>have to completely ignore it... they only use it to
>find a users IP number if the user reports online
>difficulties (connected but can't surf).
Very possible.
>We suspect (but can't prove yet) that we are losing
>around 5% of accounted logins (twice my wage) but
>luckily no one knows how to get the right data out
>of the Cisco 5300 NAS to actually compare, otherwise
>I'd get the bullet.. and possibly a bill for the
>missing 5% of unaccounted sessions and data.
You should NEVER bill based on the wtmp file and ALWAYS based on
the detail files. The detail files contain the right accounting
packets.
>I'm really hoping freeradius is "better".
Nope. It uses the same radwtmp algorithm, which you should not
use, as I noted above, and it, just like Cistron radius, simply
stores all accounting packets in detail files (or an SQL database).
If there are missing packets, they are either not sent by the
Cisco NAS or they are lost before they reach the radius server.
In the latter case, the NAS should retry until it gets an ack,
if it doesn't do this it's broken.
If the radius server doesn't receive an accounting packet in
the first place there is no way it can magically detect that
and materialize a new one out of thin air
Mike.
--
"dselect has a user interface which scares small children"
-- Theodore Tso, on debian-devel
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
