Re: IP Address

Josh Hillman ( (no email) )
Wed, 5 Mar 1997 16:00:04 -0500

Dale, here's the debug info from RadiusNT .52 with an Ascend Max 4004 using
5.0A, that you asked about. Right now, there's no IP address showing in
the online area of Emerald for this call (or any where scripting or
manually logging in is involved):

Response Time: 125
radrecv: Request from host c72cc20a code=1, id=15, length=86
User-Name = "test"
Password = "l]\317\205'\332\021\003\267\241\235"
NAS-Identifier = 199.44.194.10
NAS-Port = 20123
NAS-Port-Type = Async
User-Service = Login-User
State = ""
Ascend-Third-Prompt = ""
Framed-Address = 199.44.194.100
Acct-Session-Id = "226325960"
rad_authenticate_ODBC()
Password = "l]\317\205'\332\021\003\267\241\235"
Decrypted Password: testing123
Allocating Statement...

SQL Statement: Select DateAdd(Day, ma.extension, maExpireDate),
DateAdd(Day, sa
..extension, saExpireDate), sa.AccountID, sa.AccountType, sa.Password,
sa.Login,
sa.Shell From MasterAccounts ma, SubAccounts sa Where (sa.Login='test' or
sa.She
ll='test') AND ma.CustomerID=sa.CustomerID and sa.Active<>0 and
ma.Active<>0

Freeing SQL Statement...
Allocating Statement...

SQL Statement: Select ra.RadAttributeID, Name, Data, Value, Type From
RadConfig
s rc, RadAttributes ra Where ra.RadAttributeID=rc.RadAttributeID AND
rc.AccountI
D=118

Freeing SQL Statement...
Loading radius defaults for this type...
Allocating Statement...
Allocating Statement...

SQL Statement: Select ra.RadAttributeID, Name, Data, Value, Type From
RadATConf
igs rc, RadAttributes ra Where ra.RadAttributeID=rc.RadAttributeID AND
rc.Accou
ntType='PPP'

User-Service = Framed-User (2)
Framed-Protocol = PPP (1)
Ascend-Idle-Limit = 1200 (1200)
Freeing SQL Statement...
Sending Ack of id 15 to c72cc20a (max.talstar.com)
User-Service = Framed-User
Framed-Protocol = PPP
Ascend-Idle-Limit = 1200

Response Time: 250
radrecv: Request from host c72cc20a code=4, id=16, length=69
User-Name = "test"
NAS-Identifier = 199.44.194.10
NAS-Port = 20123
Acct-Status-Type = Start
Acct-Delay-Time = 0
Acct-Session-Id = "226325960"
Acct-Authentic = RADIUS
Allocating Statement...

SQL Statement: INSERT INTO Calls
(CallDate,UserName,NASIdentifier,NASPort,AcctS
tatusType,AcctDelayTime,AcctSessionId,AcctAuthentic) VALUES
(GetDate(),'test','1
99.44.194.10',20123,1,0,'226325960',1)

Freeing SQL Statement...
Sending Accounting Ack of id 16 to c72cc20a (max.talstar.com)

-----

The original message I sent is at the end of this message...

Josh Hillman
hillman@talstar.com

>
> RadiusNT just forwards the information into the database. Did the start
> record have a Framed-Address in the debug mode for your test?
>
> I believe I remember hearing this and the problem was that the
> IP Address is negotiated AFTER the start record is sent, for manual
> or script logins. This is just faint memory, though. :(
>
> --
> Dale E. Reed Jr. (daler@iea.com)

> Josh Hillman wrote:
> >
> > I too found this problem literally about 5 minutes after upgrading our
> > Ascend Max 4004 from 4.6Cp11 to 5.0A. Only 4 users ever display this
> > "problem". The lack of an IP address being displayed in Emerald
(on-line)
> > is only one part of the missing data. If you check the calls table for
> > that particular call, you'll notice other data missing from the start
> > record. Everything appears to be normal for the stop records.
> >
> > I don't know if RadiusNT (in my case, it's still .52) has anything to
do
> > with it or not, but as I said, the first time this problem popped up
was
> > immediately after upgrading the Max to 5.0A. The callers experience no
> > problems apparently.

Original message I sent on 2/22/97:
-------
On Friday 2/21, I upgraded the software in my Max 4004 from version 4.6Cp11
to 5.0A (file: tm.m40) and it appears that everything went smoothly,
however with 4 users, I'm missing some data that should have gone in with
the start and stop records. I ran this SQL script to see what info is
missing from the calls table:

-------------------
select * from calls
where calldate >= "Feb 21 12:37PM 1997"
and (username = "graylane" or username = "moon" or username = "rtunnell" or
username = "gsgppp")
order by username
-------------------

After peering at the data for a while, I haven't come across anything
conclusive as to what's causing this, but here's what's missing or unusual
about the calls:

NASPorts: varied / normal -- problems aren't associated with any
particular port.
CallDate: varied / normal -- problems aren't associated with any
particular date/time.
UserName: only the 4 users mentioned in the script have been affected
FramedProtocol:
Start: (null) -- this is normally 1
Stop: 1
AscendPreInputPackets:
Start: (null)
Stop: 0 -- this is normally some other number
AscendPreOutputPackets: (same as above)
AscendDisconnetCause: (varied -- 11, 45, 100, 185)
AscendDataRate: (varied -- 9600, 19200, 24000, 26400, 28800
one user actually has a 9600 bps modem which
accounts for that low speed)

Operating systems used by the 4 users affected:
Windows NT 3.51 using modem pooling
Windows 3.1 (9600bps modem) -- "rtunnell"
Mac

All other records appear to be "normal" -- these include records for all
users prior to the upgrade and also all users after the upgrade, with the
exception of the 4 previously mentioned users. "rtunnell" had 2 "normal"
sessions after the upgrade--the others were abnormal.
To the best of my knowledge, none of the users have any problems online
that are associated with the missing data.

Anyone have any idea why this is happening?
I'd attach the results of the above script, but the data takes up 17k...

I'm using:
Ascend Max 4004 5.0A
RadiusNT .52 running as a service
MSSQL 6.5
RadAttributes and RadValues have been updated in accordance with
the latest Ascend RADIUS dictionary

Thanks for any help!,

Josh
hillman@talstar.com