(RADIATOR) Radiator logging
Hugh Irvine
hugh at open.com.au
Thu Jun 23 19:46:13 CDT 2005
Hello Ash -
From the log (for which many thanks) it appears to be taking about
0.15 seconds to process a single request.
Fri Jun 24 10:19:19 2005 41832: DEBUG: Packet dump:
.......
Fri Jun 24 10:19:19 2005 56228: DEBUG: Packet dump:
It therefore follows that anything over about 7 requests per second
will cause the radius buffer queue to fill up and eventually overflow.
regards
Hugh
On 23 Jun 2005, at 20:25, Ash Garg wrote:
> Hugh,
>
> Radiator does not spend much time processing the packet as per the
> log below
> however the process is running at 80%, postgres at 15% and its
> dropping
> packets.
>
> Fri Jun 24 10:19:19 2005 41832: DEBUG: Packet dump:
> *** Received from xxxxx port 1035 ....
> Code: Access-Request
> Identifier: 94
> Authentic: 1234567890123456
> Attributes:
> User-Name = "xxxxx"
> User-Password = "xxxxx"
> Service-Type = Framed-User
>
> Fri Jun 24 10:19:19 2005 42942: DEBUG: Handling request with Handler
> 'Realm=DEFAULT'
> Fri Jun 24 10:19:19 2005 43687: DEBUG: Rewrote user name to xxxxx
> Fri Jun 24 10:19:19 2005 44420: DEBUG: Deleting session for xxxxx,
> yyyyy,
> Fri Jun 24 10:19:19 2005 44987: DEBUG: Handling with Radius::AuthTISQL
> Fri Jun 24 10:19:19 2005 45463: DEBUG: Handling with
> Radius::AuthTISQL:
> Fri Jun 24 10:19:19 2005: ERR: Attribute number 79 is not defined
> in your
> dictionary
> Fri Jun 24 10:19:19 2005 46256: ERR: Attribute number 79 is not
> defined in
> your dictionary
> Fri Jun 24 10:19:19 2005 46957: DEBUG: Query is: xxxxx
>
> Fri Jun 24 10:19:19 2005 48730: DEBUG: Query is: xxxxx
>
> Fri Jun 24 10:19:19 2005 50608: DEBUG: Query is: xxxxx
>
> Fri Jun 24 10:19:19 2005 52956: DEBUG: Radius::AuthTISQL looks for
> match
> with xxxxx
> Fri Jun 24 10:19:19 2005 54172: DEBUG: Radius::AuthTISQL ACCEPT:
> Fri Jun 24 10:19:19 2005 55010: DEBUG: Access accepted for xxxxx
> Fri Jun 24 10:19:19 2005 56228: DEBUG: Packet dump:
> *** Sending to xxxxx port 1035 ....
> Code: Access-Accept
> Identifier: 94
> Authentic: 1234567890123456
> Attributes:
> cisco-avpair = "xxxxx"
> Framed-MTU = 1500
> Service-Type = Framed-User
> Framed-Protocol = PPP
> Framed-IP-Netmask = 255.255.255.255
> Framed-Routing = None
>
>
>
> Ash
>
> -----Original Message-----
> From: owner-radiator at open.com.au [mailto:owner-radiator at open.com.au]On
> Behalf Of Hugh Irvine
> Sent: Thursday, 23 June 2005 11:56 PM
> To: ash at telstra.net
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) Radiator logging
>
>
>
> Hello Ash -
>
> If tcpdump sees the requests, but Radiator does not, it can only be
> because the radius UDP ports are overflowing the buffer pool.
>
> You can check how long Radiator is taking to process requests by
> looking at a trace 4 debug with a LogMicroseconds logger (requires
> Time-HiRes from CPAN). Performance problems with Radiator are almost
> always due to database performance issues.
>
> regards
>
> Hugh
>
>
> On 22 Jun 2005, at 21:51, Ash Garg wrote:
>
>
>> Guys,
>>
>> We have the following two options in our radiator config to log to
>> a file.
>>
>> Trace 4
>> LogDir /data/log/radius
>>
>>
>> In addition I'm also tcpdumping all transactions on port 1645 to a
>> file.
>> I've noticed that all access accepts are logged by both methods.
>> However
>> tcpdump reports the correct number of access requests hitting the
>> server
>> where as the radiator logfile does not.
>>
>> The server is a 4 CPU machine running FreeBSD 4.11 and Radiator 3.9
>> into a
>> reasonably well tuned Postgres db. Any ideas?
>>
>>
>> Regards,
>> Ash
>>
>>
>> \\\|||///
>> \\ ^ ^ //
>> ( 6 6 )
>> -----------------------------------------oOOo-(_)-oOOo---
>> Ash Garg 5/490 Northbourne Ave
>> Network Specialist DICKSON 2602
>> Internet Network Development
>> Telstra
>>
>> Email: <<mailto:Ash.Garg at telstra.net>>
>> BH: +612 6208 1994
>> Mob: 0408 687 642
>> Fax: +612 6248 6165
>>
>>
>> This communication may contain CONFIDENTIAL or copyright
>> information of Telstra Corporation Limited (ABN 33 051 775 556).
>> If you are not an intended recipient, you MUST NOT keep,
>> forward, copy, use, save or rely on this communication, and
>> any such action is unauthorised and prohibited. If you have
>> received this communication in error, please reply to this e-mail
>> to notify the sender of its incorrect delivery, and then delete
>> both it and your reply. Thank you.
>>
>> ----------------------------------------------------------
>>
>>
>> --
>> 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.
>>
>>
>
>
> NB: I am travelling this week, so there may be delays in our
> correspondence.
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>
> --
> 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.
>
NB: I am travelling this week, so there may be delays in our
correspondence.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
--
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.
More information about the radiator
mailing list