(RADIATOR) strange behaviour of tacacs+ for accounting ?

Mohamed.Raddahi at alcatel-lucent.be Mohamed.Raddahi at alcatel-lucent.be
Mon Jan 29 15:19:26 CST 2007


Hi all,

I am currently evaluating RADIATOR v3.16 on RH linux 9.0 and found 
following strange behaviour with tacacs+ :

When I send accounting messages from my NAS-client, I get an 
authentication reply before the accounting reply:

Server                          NAS-client
================================================
                       < authorization request
authorization reply >
                       < accounting request
authentication reply >
accounting reply >

This can also be seen in the radiator logfile below.
Why is the authentication reply sent first before sending the accounting 
reply ?
Can this behaviour be modified ? I looked in the documentation but could 
not find anything related.

Thanks in advance for any information,

Mohamed.



Mon Jan 29 21:59:51 2007: DEBUG: New TacacsplusConnection created for 
ipv6:1234:
:1234:50557
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection request 192, 2, 1, 
0, 2521
, 62
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection Authorization 
REQUEST 6, 1
, 1, 1, ipv6user1, telnet, , 3, service=shell cmd=show cmd-arg=version
Mon Jan 29 21:59:51 2007: DEBUG: AuthorizeGroup rule match found: permit 
.* {  }
Mon Jan 29 21:59:51 2007: INFO: Authorization permitted for ipv6user1, 
group bot
h, args service=shell cmd=show cmd-arg=version
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection Authorization 
RESPONSE 1,
, ,
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection disconnected from 
ipv6:123
4::1234:50557
Mon Jan 29 21:59:51 2007: DEBUG: New TacacsplusConnection created for 
ipv6:1234:
:1234:50558
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection request 192, 3, 1, 
0, 4338
, 104
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection Accounting REQUEST 
4, 6, 1
, 1, 1, ipv6user1, telnet, 138.203.70.107, 5, task_id=1 timezone=UTC 
service=she
ll priv-lvl=1 cmd=show version
Mon Jan 29 21:59:51 2007: DEBUG: TACACSPLUS derived Radius request packet 
dump:
Code:       Accounting-Request
Identifier: UNDEF
Authentic:  <240><247>9<14>Q<152>S<240><240><163><247><25><130>|<214><177>
Attributes:
        NAS-IP-Address = ipv6:1234::1234
        NAS-Port-Id = "telnet"
        Calling-Station-Id = "138.203.70.107"
        User-Name = "ipv6user1"
        Acct-Status-Type = Stop
        cisco-avpair = "task_id=1"
        cisco-avpair = "timezone=UTC"
        cisco-avpair = "service=shell"
        cisco-avpair = "priv-lvl=1"
        cisco-avpair = "cmd=show version "
 
Mon Jan 29 21:59:51 2007: DEBUG: Handling request with Handler 
'Realm=DEFAULT'
Mon Jan 29 21:59:51 2007: DEBUG: radiator_tmp Deleting session for 
ipv6user1, ip
v6:1234::1234,
Mon Jan 29 21:59:51 2007: DEBUG: do query is: 'delete from RADONLINE where 
NASID
ENTIFIER='ipv6:1234::1234' and NASPORT=0':
Mon Jan 29 21:59:51 2007: ERR: do failed for 'delete from RADONLINE where 
NASIDE
NTIFIER='ipv6:1234::1234' and NASPORT=0': Table 'radiator_tmp.RADONLINE' 
doesn't
 exist
Mon Jan 29 21:59:51 2007: ERR: do failed for 'delete from RADONLINE where 
NASIDE
NTIFIER='ipv6:1234::1234' and NASPORT=0': Table 'radiator_tmp.RADONLINE' 
doesn't
 exist
Mon Jan 29 21:59:51 2007: DEBUG: Handling with Radius::AuthSQL
Mon Jan 29 21:59:51 2007: DEBUG: Handling accounting with Radius::AuthSQL
Mon Jan 29 21:59:51 2007: DEBUG: AuthBy SQL result: ACCEPT,
Mon Jan 29 21:59:51 2007: DEBUG: Accounting accepted
Mon Jan 29 21:59:51 2007: DEBUG: Packet dump:
*** Reply to TACACSPLUS request:
Code:       Accounting-Response
Identifier: UNDEF
Authentic:  <240><247>9<14>Q<152>S<240><240><163><247><25><130>|<214><177>
Attributes:
 
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection result 
Accounting-Response
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection Authentication REPLY 
2, 0,
 ,
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection disconnected from 
ipv6:123
4::1234:50558
Mon Jan 29 21:59:51 2007: DEBUG: TacacsplusConnection Accounting REPLY 1, 
,
 








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.open.com.au/pipermail/radiator/attachments/20070129/4ec606ed/attachment.html>


More information about the radiator mailing list