System Utilities / RadiusReport

RadiusReport

What is RadiusReport?

RadiusReport is a radius log analysis program written in perl. It will
allow you to produce many, varied, types of reports from one or several
radius log files. See examples here.
Also checkout the Readme from the latest beta.

What type of radius logs will RadiusReport work on?

RadiusReport works on various accounting logs produced by different
Radius accounting servers. Supported ones include:

Livingson Radius V2.0, V2.01 & V1.16

Dale Reed's RadiusNT

Merit Radius

Ascend Radius

Radiator

Novell's BorderManager Authentication Services after its logs have been pre-processed with my BMAS-preparser.pl perl script.

If you don't see yours listed here then try it anyway, it should work.

RadiusReport does not work with Microsoft Radius logfiles. Ask Microsoft to fix it.

What is the latest version?

RadiusReport is relatively new and I consider it pre-release, but it appears
to be very stable.

*Important*If your Radius accounting server does not log a 'Timestamp =' field then
RadiusReport needs to decode the record date information (the first
line of the record e.g. Tue Jul 3 12:00:30 1997). To do this
RadiusReport needs access to the
POSIX perl module which is available from any
CPAN archive.
(the POSIX module comes bundled with perl).
I have written a perl script to check POSIX mktime() complience in
your particular perl installation. If you have problems with
RadiusReport figuring out the dates in your logs then run this program
and send me the output along with and example section of your detail
logfile. Script: posixchk.pl

I'm using Windows NT, will it work for me?

Yes, RadiusReport does work on NT given the following:

A properly installed Perl version 5.

Your logs contain a field "Timestamp = ??????????" style line.

NT-Perl doesn't have POSIX so, comment out 2 lines in the code:

Line 64: use POSIX;

Line 880: my $cal = mktime....

Comments are denoted in perl by placing a '#' symbol at the start of
the line.

I'm working on a full release 1.0 which aleady has the following
features:

Active logfile parsing.

Intelligent parsing of files - no longer needs the POSIX module which
was the bain of all NT users (and some badly installed unix perls).
I wrote the POSIX function I needed in perl and embedded it in the code.

Using the active logs reports are generated in seconds (rather than
minutes).

CGI program to generate reports via the web.

Currently 30% faster than any previous version of RadiusReport.

Fully Y2K complient (will work up to 2038).

Features still to be added:

Increase RadiusReports Intelligence with logfiles. I plan on making
it such that RadiusReport doesn't actually need to know the names of
Radius Attributes in the detail file (see Templates below)

Output Templates fully customisable by the end user. Using templates
all radius versions will be supported by default - just modify the
keys in your template and heh presto, working reports.

Alpha code has been added to 0.3b4 which calculates
the approximate phone bill (telco) charges the user will have.
I have not extensively tested the code, but so far testing has
proved successful.
Approximate, because Radius cannot know how long the modem
establishment phase took and so cannot include that time in
calculating the chargesDone: V0.3b4

Report on specific months - Using a runtime flag you can specify
which month (or months) you want to report on. This is useful when
you have many users who's login would 'roll over' from one month
to the next and if you simply split your radius logs by month then
you will be left with many start records without stop records. Using
the select month(s) allows complete monthly logs per user.
Done: V0.3b5

Interim Log Parsing. Radius Logs for a months worth of logins can
be very large. RadiusReport currently builds hash tables of the
log file(s) in memory - which means RadiusReport can get *extremely*
large. RadiusReport will take approximately 5 times as much memory
as the radius logs it is parsing. The goal of interim log parsing
is to produce disk based indexes, thereby speeding up the reporting
process by causing less swap and CPU overhead in building such large
indexes in memory.