Re: Need additional info for RadLogs

Josh Hillman ( (no email) )
Tue, 28 Apr 1998 13:06:59 -0400

> From: Dale E. Reed Jr. <>
> I really don't undestand your question, though. Radlogs contains FAILED
> authentication requests. Therefore, there should not be any corresponing
> Accounting records (or Acct-Session-ID entries). Maybe I am missing
> something here?

I've got a bunch of entries (stop records) in the Calls table with
usernames of 'null' and a few that are blank. I thought that these were
the acct records that corresponded to the failed attempts. Every so-often,
I go and delete all entries from Calls where the username = 'null' or ''.
These records started showing up in the Calls table as soon as I added
RadLogs and RadLogMsgs to the Emerald (SQL) db last summer.

Josh Hillman

> Josh Hillman wrote:
> >
> > Is there a way to add additional info to RadLogs, such as
> Not currently.
> > We're having a problem with 2 of our Maxes and pooling ("pools-Max4004"
> > (and 4048) keeps showing up in the Radlogs and this is causing problems
> > with the people who are dialing up at that time. We have so many
> > logging in and off that it's very difficult trying to match up these
> > there are no real logins mentioned) with the corresponding start/stop
> > records in Calls. If there's a way to add AcctSessionID, then it
> > be a problem matching them up. I just now noticed that NASIdentifier,
> > NASPort, and CallerID are in RadLogs, but they're all = (null) for some
> > reason.
> Those three fields are not supported yet either. I've mentioned this
> to many people who've inquired, but my goal is to make the RadLogs table
> like the Calls table, in that RadiusNT will dynamically create the
> INSERT based on the core set of fields and any additional ones that match
> entries from the authentication request.
> > Is anyone else running into this same problem? It started a week and a
> > half ago on 2 of our Maxes and there's only a problem when all (or near
> > all?) lines/modems are in use on the Max. At the moment, the one
> > more problematic than the other has 48 lines/modems, all working and to
> > temporarily alleviate the problem, I had to increase the amount of IPs
> > the pool from 48 to 50, then from 50 to 57, and now there are
> > Increasing the IP addresses to be allocated seems to fix it for a
> > then the problem comes back after a while. We've never had this
problem in
> > the past, but without knowing exactly which records in Calls match up
> > what appears in RadLogs, it's tough to narrow down. At the moment,
> > hasn't really helped at all. They're asking questions that I already
> > presented answers to in my original support message to them.