You are running in both mode and have an error in your users
files. You need to look around the user test and see what the
error is and correct it. If you are not using the users file,
change to ODBC only mode.
> And another from my AcctLog:
> ODBC Error:23000:2627:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Violation of PRIMARY KEY constraint 'pk_Calls': Attempt to insert duplicate key in object 'Calls'.
This is not a big deal. Its just RadiusNT saying that it already has
this accounting record. This is typical under heavy load or when
you have a NAS configured with a very low accounting timeout.
> I have Added three field to Calls (ConnectInfo, AcctInputOctets and AcctOutputOctets). Is there someplace else in RadiusNT I need to identify these as accounting columns? ConnectInfo and AcctInputOctets seem to be loading fine. Since I added AcctOutputOctets I have had a problem with some stop records being loaded into the calls table. Could this be problem be caused by one of the errors above or is it just getting dropped somewhere.
Does RadiusNT show the new fields when it starts up in -x15
debug mode? Adding the fields should not cause any issues with
RadiusNT unless you add them with the wrong type. For example if
you added AcctOutputOctets as a varchar rather than a string,
the insert would fail with a type mismatch error.
> Also, with the stop record not showing up, my CallsOnline table makes it look like the user is still online. However, I can still call up and log on with the same user name and password. I have Concurrency Control checked, but it still authorizes the user. I don't know if it makes a difference, but the UserName still has the realm appended (on each concurrent login). The Login field in SubAccounts does not have it. (We are successfully using the roaming feature to strip it as it is passed to us from merit - Great feature.)
Does the realm show in the callsonline view? If so, that could be
what is causing the problem.
> The lost stop record has only happened a couple of times, but this could be a big headache if it happens on a regular basis. How do I clean up the RadiusNT accounting info when this happens. Last time it happened I just deleted the start record for that session and deleted the UserName, AcctStatusType, CallDate and FramedAddress fields from ServerPorts. Does this sound right?
Its probably overkill. There isn't much you really need to do,
since not havin the matching start/stop record will not prevent
RadiusNT from functioning. You might just change the AcctStatusType
field in the ServerPorts to 2 to clear the log, though.
-- Dale E. Reed Jr. (email@example.com)_________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com