This is a known issue with the MAX and TNT. I had this discussion several
months ago and managed to work through it with Mike and an Josh Bailey and
Engineer for Ascend. Here was the outcome:
Sending stop only for failed connections is customary Ascend behaviour -
it's been done for many years. The reason we do it is to allow customers
to calculate login failure rates - for example - people trying to use
problematic authentication protocols - faulty modems (identifiable by-port
with some of our VSAs) - people connecting with disabled protocols, etc.
I include a terminal session from my lab TNT which shows two variables
which can be disabled to stop this behaviour. I recommend against it,
however, because IMHO the information is useful as a diagnostic tool.
NB. The Max has one equivalent variable - "stop-only" in Ethernet/Mod
Config/Accounting. It does *not* have the "drop-stop-on-auth-fail"
variable - it is possible that someone giving a null response to PAP will
generate a stop record with no start, even though stop-only = no.
admin> read extern
EXTERNAL-AUTH read
admin> list rad-acct-cli
[in EXTERNAL-AUTH:rad-acct-client]
acct-server-1 = 203.22.111.7
acct-server-2 = 0.0.0.0
acct-server-3 = 0.0.0.0
acct-port = 1813
acct-src-port = 0
acct-key = xxxxxxx
acct-timeout = 3
acct-sess-interval = 0
acct-id-base = acct-base-10
acct-reset-time = 0
acct-checkpoint = 0
acct-stop-only = yes
acct-limit-retry = 0
acct-drop-stop-on-auth-fail = no
acct-radius-compat = old-ascend
admin> set acct-stop-only ?
acct-stop-only:
Send to RADIUS Accounting Stop packets that have username=0. These are
caused by connections that are dropped before authentication is done.
Boolean field, 'no' or 'yes'
admin> set acct-drop-stop ?
acct-drop-stop-on-auth-fail:
If Yes, do not send RADIUS Accounting Stop/Checkpoint packets for users
that failed authentication.
Boolean field, 'no' or 'yes'
Cheers
John
At 01:15 PM 01-11-99 -0600, you wrote:
>Hi all,
>
>I am a new radiator user, and I have been testing radiator for about a
>week now. Well I am finally looking at our results in depth and I have
>noticed that raidator reported a LOT of Null's in our accounting
>database. We are running radiator on Windows NT across ODBC to MS SQL
>7.0. Everything seems to be working correctly, and I don't have any
>errors in the error log, but I am getting about 200 null records a
>day. That is about an eight of the daily records. I have left most
>everything as the default including the sql calls. We are using the
>Ascend dictionary, and work with Max TNT's. The only other thing I have
>noticed is that all of the null records were stop records. I'm not sure
>why this is happening. Has anyone seen this before, or know what I can do
>to stop this.
>
>Thanks for any help.
>
>If you any questions please contact me at:
>
>Personal Address
>[EMAIL PROTECTED]
>
> Opinions are mine and do not necessarily reflect
> those of wyoming.com
>
>
>===
>Archive at http://www.thesite.com.au/~radiator/
>To unsubscribe, email '[EMAIL PROTECTED]' with
>'unsubscribe radiator' in the body of the message.
--
John Vorstermans || We are what we repeatedly do.
Technical Manager || - Aristotle
Actrix Networks
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
