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
hillman@talstar.com
> Josh Hillman wrote:
> >
> > Is there a way to add additional info to RadLogs, such as
AcctSessionID?
>
> 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
people
> > logging in and off that it's very difficult trying to match up these
(since
> > there are no real logins mentioned) with the corresponding start/stop
> > records in Calls. If there's a way to add AcctSessionID, then it
shouldn't
> > 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
that's
> > 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
in
> > the pool from 48 to 50, then from 50 to 57, and now there are
60something.
> > Increasing the IP addresses to be allocated seems to fix it for a
while,
> > 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
with
> > what appears in RadLogs, it's tough to narrow down. At the moment,
Ascend
> > hasn't really helped at all. They're asking questions that I already
> > presented answers to in my original support message to them.