(RADIATOR) RE: Radiator Session Handling and SNMP...

Mon May 16 02:37:30 CDT 2005

Hello Mike!

Here is a trace for the initial request (before the backoff):

*** Received from 194.154.133.218 port 2440 ....

Packet length = 72
01 14 00 48 33 10 d0 cc ff db 5a 3b d0 fc 16 fb
59 8c a3 80 01 0a 70 73 74 6e 74 65 73 74 02 12
3f ce 04 24 a5 e8 b9 2a ad 96 16 6a 49 39 37 19
04 06 01 02 03 04 05 06 00 00 00 65 3d 06 00 00
00 00 28 06 00 00 00 01
Code:       Access-Request
Identifier: 20
Authentic:  3<16><208><204><255><219>Z;<208><252><22><251>Y<140><163><128>
Attributes:
	User-Name = "pstntest"
	User-Password = "?<206><4>$<165><232><185>*<173><150><22>jI97<25>"
	NAS-IP-Address = 1.2.3.4
	NAS-Port = 101
	NAS-Port-Type = Async
	Acct-Status-Type = Start

Fri May 13 17:37:01 2005: DEBUG: Handling request with Handler ''
Fri May 13 17:37:01 2005: DEBUG:  Deleting session for pstntest, 1.2.3.4,
101
Fri May 13 17:37:01 2005: DEBUG: do query is: 'EXECUTE
[RADIATOR_DeleteSession]
@NASIPAddress='1.2.3.4', at NASPort='101', at NASPortId='', at AcctSessionId=NULL, at Cl
ass='', at Time='May 13, 2005
17:37:01', at DelayAdjustedTime='', at Timestamp=0, at AcctStatusType='Start', at AcctIn
putOctets='', at AcctOutputOctets='', at AscendDataRate='', at AscendXmitRate=''': 
Fri May 13 17:37:01 2005: DEBUG: Handling with Radius::AuthSQL
Fri May 13 17:37:01 2005: DEBUG: Handling with Radius::AuthSQL: theAuthBySQL
Fri May 13 17:37:01 2005: DEBUG: Query is: 'EXECUTE
[RADIATOR_ProcessUserAuthRequest]
@UserName='pstntest', at NASIPAddress='1.2.3.4', at NASPort='101', at NASPortId='', at N
ASPortType='Async', at ServiceType='', at AcctSessionId='', at AcctMultiSessionId='',
@FramedIPAddress='', at FramedIPNetmask='', at CallingStationId='', at CalledStationI
d='', at Time='May 13, 2005 17:37:01', at RadiatorCode='PRIMARY'': 
Fri May 13 17:37:01 2005: DEBUG: Radius::AuthSQL looks for match with
pstntest
Fri May 13 17:37:01 2005: DEBUG: Query is: 'EXECUTE [RADIATOR_CountSessions]
@NASIPAddress='1.2.3.4', at NASPort='101', at NASPortId='', at AcctSessionId='', at Clas
s='F6832D59-511E-42B4-813B-F23BB6A08B7F'':

Fri May 13 17:37:01 2005: DEBUG: Checking if user is still online: Cisco,
pstntest, 1.2.3.4, 100,  
Fri May 13 17:37:01 2005: DEBUG: Running command
`c:/apps/netsnmp/bin/snmpget.exe -c "skummitet" 1.2.3.4
.iso.org.dod.internet.private.enterprises.9.2.9.2.1.18.100 2>&1`

Fri May 13 17:37:08 2005: ERR: The command 'c:/apps/netsnmp/bin/snmpget.exe
-c "skummitet" 1.2.3.4
.iso.org.dod.internet.private.enterprises.9.2.9.2.1.18.100 2>&1' failed with
an error: Timeout: No Response from 1.2.3.4.

Fri May 13 17:37:08 2005: DEBUG: Cisco: snmpget result: Timeout: No Response
from 1.2.3.4.

Fri May 13 17:37:08 2005: INFO:  Session for pstntest at 1.2.3.4:100 has
gone away

Fri May 13 17:37:08 2005: DEBUG:  Deleting session for pstntest, 1.2.3.4,
100

Fri May 13 17:37:08 2005: DEBUG: do query is: 'EXECUTE
[RADIATOR_DeleteSession]
@NASIPAddress='1.2.3.4', at NASPort='100', at NASPortId='', at AcctSessionId=NULL, at Cl
ass='F6832D59-511E-42B4-813B-F23BB6A08B7F', at Time='May 13, 2005
17:37:08', at DelayAdjustedTime='', at Timestamp=0, at AcctStatusType='Start', at AcctIn
putOctets='', at AcctOutputOctets='', at AscendDataRate='', at AscendXmitRate=''': 
Fri May 13 17:37:08 2005: DEBUG: Radius::AuthSQL ACCEPT: 
Fri May 13 17:37:08 2005: DEBUG: AuthBy SQL result: ACCEPT, 
Fri May 13 17:37:08 2005: DEBUG: Handling with Radius::AuthRADIUS
Fri May 13 17:37:08 2005: DEBUG: AuthBy RADIUS result: ACCEPT, 
Fri May 13 17:37:08 2005: DEBUG: Access accepted for pstntest
Fri May 13 17:37:08 2005: DEBUG: do query is: 'EXECUTE
[RADIATOR_ProcessUserAuthResult] @Time='May 13, 2005
17:37:08', at RadiatorCode='PRIMARY', at IsSuccess=1, at Message=NULL, at UserName='pstn
test', at NASIPAddress='1.2.3.4', at NASPort='101', at NASPortId='', at NASPortType='Asy
nc', at AcctSessionId='', at AcctMultiSessionId='', at ServiceType='', at FramedIPAddres
s='', at FramedIPNetmask='', at CallingStationId='', at CalledStationId='', at Class='F6
832D59-511E-42B4-813B-F23BB6A08B7F'': 

As you can see the Radiator calls 'snmpget' to check for the session on port
'100'. The snmpget returns a timeout because it can not contact '1.2.3.4'
(because it is fake). Regardless of the fact that the NAS can not be
contacted Radiator decides to remove the existing session on port '100'.

I am using NAS type 'Cisco'. We will probably (hopefully) go with
'CiscoSessionMIB' later on.

This is a Radiator version 3.11 running on a Windows box.

-----Original Message-----
From: Mike Mccauley [mailto:mikem at open.com.au] 
Sent: 12 May 2005 21:16
To: Hugh Irvine
Cc: Rickard Ekeroth; RadiatorMaillist
Subject: Re: Radiator Session Handling and SNMP...

Hello Richard,

I dont think I saw this description of your problem before, so thanks for
sending it.
I would have expected the online code to react the same way to the initial
failure and subsequent backoff events. Can you pls send me a trace 4 log
showing what happens? What NasType do you have configured?

Cheers.

On Thu, 2005-05-12 at 14:21 +1000, Hugh Irvine wrote:
> Hi Richard -
> 
> Mike is overseas at the moment, so he hasn't had much time to reply.
> 
> He should be back next week and he is copied on this mail.
> 
> regards
> 
> Hugh
> 
> 
> 
> On 11 May 2005, at 22:04, Rickard Ekeroth wrote:
> 
> >
> > Hello Hugh!
> >
> > I wrote to you guys a while ago about the behaviour of Radiator when 
> > it queries a NAS using SNMP. I am not sure if my reply to the reply 
> > that you sent me was sent properly. Anyway here are my thoughts 
> > again:
> >
> > If Radiator fails to query a NAS for a specific session using SNMP 
> > it will assume that the session in question is not on the NAS. 
> > However during the following back-off period (60 seconds) the 
> > behaviour is the reverse:
> > Radiator assumes that the session is still on the NAS and the user 
> > is denied access based on max session count.
> >
> > Should not the behaviour be the same in both cases? Personally I 
> > would prefer if the Radiator denied access in both cases. This is 
> > because I have a consumption debit scheme based on accounting stop 
> > packets and I would prefer not to delete sessions unless I am sure 
> > that it is not on the NAS anymore (because I can not debit a session 
> > that did not receive a stop packet since I do not know the actual 
> > session time).
> >
> > Regards,
> >
> > Rickard Ekeroth @ SpiderNet
> > Software Developer / Analyst
> > rickard at spidernet.net
> > +35722844870
> >
> >
> 
> NB:
> 
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive 
> (www.open.com.au/archives/radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets), 
> together with a trace 4 debug showing what is happening?
> 

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.