At 10:11 AM 24/07/01 +0000, you wrote:
>In article <[EMAIL PROTECTED]>,
>Simon Byrnand <[EMAIL PROTECTED]> wrote:
>>Check out the program 'sac' from ftp://mama.indstate.edu/linux/sac/
>>
>>I looked long and hard before I found this program :) It is very flexible
>>and should do what you want. It will parse either radius detail files, or
>>alternatively the radwtmp. (Most people say dont trust radwtmp, but I've
>>found it more accurate in my particular case, after adding up times by hand
>>to double check the results)
>
>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.
>
>That could be fix to a certain extent by only writing radwtmp entries
>(both start and stop) at the arrival of a STOP packet. Disadvantage
>would be that active entries wouldn't be show as (still logged in).
>
>Mike.
Hi Mike,
We've had some problems with stop records going missing from time to time
from a remote NAS, (over which we have no direct control) and when this
happens, the user of course shows as online when they're not.
There are two ways this incorrect state (eventually) gets resolved, one is
that the user disconnects (or gets disconnected) and reconnects, and
checkrad determines they're not really there anymore - and radiusd seems to
reduce their previous session time to zero and write a logout entry in the
radwtmp to that effect. (I see a 0 length session time with radlast, anyhow)
However it does NOT write a stop record into any detail file as far as I
can see, and to do so would be improper anyway, since it never received
one. Now in this situation the times for a user reported by analyzing
detail files and the radwtmp are clearly going to be different, and the
radwtmp is the more conservative of the two. A program reading the detail
files has no way of knowning that checkrad discovered a stuck session.
The other thing that happens is that somebody else logs into the same port
on the NAS, and radiusd immediately notices the previous session must have
been stuck, however in this case it doesnt zero the time in radwtmp, it
just assumes they logged out at the same time the other user logged into
the same port. A program like sac analyzing the detail files _should_ be
able to notice this apparent reuse of the same NAS port and deduce that a
lost stop record occured and give the same result as reading the radwtmp,
however I have _not_ confirmed that sac 1.8 actually does this, so at this
stage it is supposition.
I've done extensive comparisions of the times calculated from radwtmp, and
those calculated from detail files (using sac) for users that havn't
suffered lost stop records, and calculated times are _identical_ within
about 1 second, and in every case where there were lost stop records, the
radwtmp gives the more conservative time of the two. I'd rather err on the
safe side when I know a NAS box is giving incomplete data...
Have I missed anything in this analysis ? This is for cistron-radiusd
1.6.4, btw, I don't know if the accounting of stuck sessions has changed
for freeradius ? (I'd be interested to know)
Regards,
Simon Byrnand
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
