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 = 22.214.171.124
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
SQL Statement: INSERT INTO Calls
ODBC: SQLExecDirect Error:
[Microsoft][ODBC SQL Server Driver][SQL Server]The column UserName in
ls may not be null.
Response Time: 62
Ascend-Connect-Progress = 32 = prModemWaitDCD (Waiting for DCD)
Ascend-Disconnect-Cause = 185 = remoteEndHungUp
(signal loss from remote end)