I agree--this is a bit strange. After looking at the Calls data, I did
verify that is what's causing the problem. On occasion, the
Calls.NASIdentifier (really NAS-IP-Address) has a different IP between the
start and stop records for the same session, although the AcctSessionIDs do
match.
To remedy this problem, would the following change work in the
"calls_insert" (insttrig.sql)?
I wasn't sure if the two links related to the Servers table were really
necessary, so I left it in there. AT&T sends the AcctSessionID as
"2000033115491400", so it's accurate to the second. Maybe "AND sp.UserName
= i.UserName" would also need to be added to the modified trigger for better
accuracy in preventing some rare accidental update?
Change this:
WHERE s.IPAddress = i.NASIdentifier AND
s.ServerID = sp.ServerID AND
sp.Port = i.NASPort AND
(DateAdd(Second, 0-i.AcctDelayTime, i.CallDate) >= sp.CallDate OR
sp.CallDate IS NULL)
To:
WHERE ((s.IPAddress = i.NASIdentifier AND
s.ServerID = sp.ServerID) OR
sp.AcctSessionID = i.AcctSessionID) AND
sp.Port = i.NASPort AND
(DateAdd(Second, 0-i.AcctDelayTime, i.CallDate) >= sp.CallDate OR
sp.CallDate IS NULL)
> Josh Hillman wrote:
> >
> > From: Dale E. Reed Jr. <daler@iea-software.com>
> > > The trigger ignores older records than the current one in the
> > > ServerPorts. If there are some delays, it could cause the
> > > record to not make it into the ServerPorts table.
> >
> > I thought I had this problem taken care of when I reinstalled the calls
> > trigger, but apparently it had no effect.
> > Stop records are being inserted into the Calls table with no problems,
but
> > it's not reaching the CallsOnline table.
> > I DID notice that the NASIdentifier is sometimes different with the stop
> > record, so it doesn't match up with the NASIdentifier with the start
record.
> > Could this be causing the problem? If so, how might I get around this
> > quirk?
>
> > Josh
> >
> > > Josh Hillman wrote:
> > > >
> > > > We're having a problem with users not being cleared in the
CallsOnline
> > view
> > > > when they disconnect, but the stop record IS received and does get
> > entered
> > > > into the Calls table without any problems. This is causing RadiusNT
to
> > > > reject sessions because it thinks the users are still online
eventhough
> > > > they're not.
> > > > The sessions are only coming from specific NASes (via AT&T) and are
> > > > associated with new Servers entries made last week.
> > > > Unfortunately, there's no way to implement SNMP concurrency checking
> > with
> > > > these NASes.
> > > >
> > > > What would cause this?
> > > > How can it be fixed?
> > >
> > > The trigger ignores older records than the current one in the
> > > ServerPorts. If there are some delays, it could cause the
> > > record to not make it into the ServerPorts table.
> >
> > For more information about this list (including removal) go to:
> > http://www.iea-software.com/support/maillists/liststart
>
>
> --
>
> Dale E. Reed Jr. Emerald and RadiusNT
> __________________________________________
> IEA Software, Inc. www.iea-software.com
>
> For more information about this list (including removal) go to:
> http://www.iea-software.com/support/maillists/liststart
>
For more information about this list (including removal) go to:
http://www.iea-software.com/support/maillists/liststart