Radius accounting bug in .90 ??

Josh Hillman ( (no email) )
Thu, 1 May 1997 22:24:32 -0400

I upgraded my Radius .60 to .90 on the primary radius (ODBC only) server
(same machine that hosts SQL Server with the Emerald database) just before
6pm today (Thursday) and everything was working just fine until somewhere
between 6:23 and 6:28pm. At this time, Radius apparently stopped dealing
with accounting records, but still was authenticating properly with the
database. The accounting records were then sent to a backup radius server
(still using .60) and reading only from a "users" file on that backup
server. The users file was created (using Emerald 2.1.11) a minute or two
before upgrading Radius on the primary server so all account info was
up-to-date.

It just happened again, and this time, I cought it in debug mode
(radius -x15 -o -r97). The output of the final accounting record is at the
bottom of this message. Once again, Radius .90 continued authenticating,
but accounting went to the backup server. Right now, I reverted back to
Radius .60 on the primary machine and it's authenticating and handling
accounting ok (at least so far).

One problem with this was that anyone logged on prior to the accounting
switching to the other machine, was still "online" according to
callsonline. Because we use concurrency control (everyone but 2 or 3
people are able to only dialup once under one login), some people had hung
up sometime after 6:38, but when they tried getting back on, they couldn't
because authentication was still being handled by the primary server (ODBC)
and it still showed that some of these users were "still online". People
who were not "still online" could log on just fine because there were no
open start records on the primary server for them.

There were no errors anywhere in SQL error logs or the Event Viewer. There
were also no Dr. Watson errors.

debug output of last accounting record:

radrecv: Request from host c72cc20a code=4, id=43, length=104
NAS-Identifier = 199.44.194.10
NAS-Port = 20106
Acct-Status-Type = Stop
Acct-Delay-Time = 0
Acct-Session-Id = "229668958"
Ascend-Disconnect-Cause = 185
Ascend-Connect-Progress = 31
Ascend-Data-Rate = 0
Ascend-PreSession-Time = 22
Ascend-Pre-Input-Octets = 0
Ascend-Pre-Output-Octets = 0
Ascend-Pre-Input-Packets = 0
Ascend-Pre-Output-Packets = 0
Allocating Statement...

SQL Statement: INSERT INTO Calls
(CallDate,NASIdentifier,NASPort,AcctStatusType
,AcctDelayTime,AcctSessionId,AscendDisconnectCause,AscendConnectProgress,Asc
endD
ataRate,AscendPreSessionTime,AscendPreInputOctets,AscendPreOutputOctets,Asce
ndPr
eInputPackets,AscendPreOutputPackets) VALUES
(GetDate(),'199.44.194.10',20106,2,
0,'229668958',185,31,0,22,0,0,0,0)

ODBC: SQLExecDirect Error:
[Microsoft][ODBC SQL Server Driver][SQL Server]The column UserName in
table Cal
ls may not be null.

Response Time: 62
--------------------------------
Translations:
Ascend-Connect-Progress = 32 = prModemWaitDCD (Waiting for DCD)
Ascend-Disconnect-Cause = 185 = remoteEndHungUp
(signal loss from remote end)

Josh Hillman
hillman@talstar.com