(RADIATOR) some question about the radiator
Foo Donald (Products O2)
Donald.Foo at O2.com
Sat Jun 28 03:26:38 CDT 2003
Hi Hugh,
Thanks again, since the handler is dealing with the rejction which match the
calling-station-id, is there any way to reject the accounting in INTERNAL? I
know that is rare since accounting will only send when authentication pass,
but in our case the GGSN will only send the accounting to radiator while the
authentication is done by other service.
Thanks and Regards,
Donald
-----Original Message-----
From: Hugh Irvine
To: Foo Donald (Products O2)
Cc: ''radiator at open.com.au' '
Sent: 2003/6/28 ?U?E 04:01
Subject: Re: (RADIATOR) some question about the radiator
Hello Donald -
This is very strange, but you can alter your AuthBy INTERNAL as follows:
<AuthBy INTERNAL>
AcctResult ACCEPT
DefaultResult REJECT
....
</AuthBy>
regards
Hugh
On Saturday, Jun 28, 2003, at 09:07 Australia/Melbourne, Foo Donald
(Products O2) wrote:
> Hi Hugh,
> Thank you very much for all the information, I am almost there, i
found
> something very strange with <AuthBy INTERNAL> during my test.
> Herewith is my code
>
> <Handler Calling-Station-Id=/^65987/>
> RejectHasReason
> <AuthBy INTERNAL>
> DefaultResult REJECT
> RejectReason You are not our customer
>
> </AuthBy>
>
> <AuthLog SQL>
> DBSource dbi:mysql:radius
> DBUsername root
> DBAuth root
> LogFailure
> FailureQuery insert into RADAUTHLOG (TIME_STAMP,
> USERNAME,
> TYPE, REASON, Calling_Station) values (%t, '%n', 0
> , %1, '%{Calling-Station-Id}')
> </AuthLog SQL>
> </Handler>
>
> It works for all Authentication, but for accounting it can only accept
> not
> reject.
> Let me show you some of my debug.
> If I put it DefaultResult ACCPET and send a accounting start/stop
>
>
> Sat Jun 28 06:51:24 2003: DEBUG: Packet dump:
> *** Received from xx.xx.xx.xx port 4358 ....
> Code: Accounting-Request
> Identifier: 138
> Authentic:
<4><229><244>j><129><205>J<154><<28><214><12><18><187><226>
> Attributes:
> <delete>
> Calling-Station-Id = "6598765432"
>
> Sat Jun 28 06:51:24 2003: DEBUG: Handling request with Handler
> 'Calling-Station-Id=/65987/'
> Sat Jun 28 06:51:24 2003: DEBUG: Adding session for test, 1.1.1.1, 20
> Sat Jun 28 06:51:24 2003: DEBUG: Handling with AuthINTERNAL:
> Sat Jun 28 06:51:24 2003: DEBUG: Accounting accepted
> Sat Jun 28 06:51:24 2003: DEBUG: Packet dump:
> *** Sending to xx.xx.xx.xx port 4358 ....
> Code: Accounting-Response
> Identifier: 138
> Authentic:
<4><229><244>j><129><205>J<154><<28><214><12><18><187><226>
> Attributes:
>
>
> Work smooth no problem.
> If I put it DefaultResult REJECT and send a accounting start/stop
>
>
> Sat Jun 28 06:58:11 2003: DEBUG: Packet dump:
> *** Received from xx.xx.xx.xx port 4359 ....
> Code: Accounting-Request
> Identifier: 139
> Authentic:
> <145><129>)<154><156>q<10><212><21><191><16>5<187><8><134><177>
> Attributes:
> <delete>
> Calling-Station-Id = "6598765432"
>
> Sat Jun 28 06:58:11 2003: DEBUG: Handling request with Handler
> 'Calling-Station-Id=/65987/'
> Sat Jun 28 06:58:11 2003: DEBUG: Adding session for test, 1.1.1.1, 20
> Sat Jun 28 06:58:11 2003: DEBUG: Handling with AuthINTERNAL:
> !!!hang here!!!
> Sat Jun 28 06:58:13 2003: DEBUG: Packet dump:
> *** Received from xx.xx.xx.xx port 4359 ....
> Code: Accounting-Request
> Identifier: 139
> Authentic:
> <145><129>)<154><156>q<10><212><21><191><16>5<187><8><134><177>
> Attributes:
> <delete>
> Calling-Station-Id = "6598765432"
>
> Sat Jun 28 06:58:13 2003: INFO: Duplicate request id 139 received from
> xx.xx.xx.xx(4359): ignored
>
>
> Any suggestion?
>
> Regards,
> Donald
>
> -----Original Message-----
> From: Hugh Irvine
> To: Foo Donald (Products O2)
> Cc: 'radiator at open.com.au'
> Sent: 2003/6/27 ?U?E 01:37
> Subject: Re: (RADIATOR) some question about the radiator
>
>
> Hello Donald -
>
> I am not sure what your configuration file is meant to do, but you
> might consider using seperate Handlers for Authentication and
> Accounting as you can then use different AuthByPolicy's for the two
> cases.
>
> # define Handlers for accounting and authentication
>
> <Handler Request-Type = Accounting-Request>
> AuthByPolicy ContinueAlways
> ....
> </Handler>
>
> <Handler>
> AuthByPolicy ContinueWhileAccept
> ....
> </Handler>
>
> regards
>
> Hugh
>
>
> On Friday, Jun 27, 2003, at 15:32 Australia/Melbourne, Foo Donald
> (Products O2) wrote:
>
>> Hi Hugh,
>> Looks great with my test machine, appreciate. Besides I cannot find
>> much
>> information for ContinueAlways, will it got disadvantage when using
> it?
>>
>> Actually I was using ContinueWhileAccept (Continue trying to
>> authenticate as
>> long as it is Accepted), it should continue if it accept, but I don't
>> understand why it did continue with other <auth radius>(cannot see
>> accounting goto the rest 3 accounting server, only first one)
>> Previous
>> AuthByPolicy ContinueWhileAccept
>> AuthBy CheckSQLBlacklist
>> AuthBy CheckSQLNormal
>> follow with 4 auth radius.....
>>
>>
>> Regards,
>> Donald
>>
>> p.s. the detail configuration should be at last of the email.
>>
>>
>>
>>
>> -----Original Message-----
>> From: Hugh Irvine [mailto:hugh at open.com.au]
>> Sent: Friday, June 27, 2003 12:42 PM
>> To: Foo Donald (Products O2)
>> Cc: 'radiator at open.com.au'
>> Subject: Re: (RADIATOR) some question about the radiator
>>
>>
>>
>> Hello Donald -
>>
>> It is difficult to say what is happening without a complete
>> configuration file and an accompanying trace 4 debug.
>>
>> I suspect what is happening here is you have not correctly configured
>> an AuthByPolicy to control the execution of the AuthBy clauses. In
the
>> case you show below you should probably use this:
>>
>> AuthByPolicy ContinueAlways
>>
>> regards
>>
>> Hugh
>>
>>
>> On Friday, Jun 27, 2003, at 13:59 Australia/Melbourne, Foo Donald
>> (Products O2) wrote:
>>
>>> Hi Hugh,
>>> Sorry for push so hard ,any update for this? We need to fix the
>>> accounting
>>> proxy asap.
>>> The current status is one radiator proxy to 4 accoutning server
>>> (A,B,C,D).
>>> Now we only can see the accounting packet from proxy to A, no
>>> accounting
>>> arrive to B, C, D. Herewith is the current <auth radius>.
>>>
>>> <AuthBy RADIUS>
>>> RetryTimeout 25
>>> NoForwardAuthentication
>>> Secret radius
>>> AcctPort 1813
>>> Host 10.12.1.2
>>> </AuthBy>
>>>
>>> <AuthBy RADIUS>
>>> IgnoreAccountingResponse
>>> RetryTimeout 25
>>> NoForwardAuthentication
>>> Secret radius
>>> AcctPort 1813
>>> Host 10.12.1.41
>>> </AuthBy>
>>>
>>> <AuthBy RADIUS>
>>> IgnoreAccountingResponse
>>> RetryTimeout 25
>>> NoForwardAuthentication
>>> Secret radius
>>> AcctPort 1813
>>> Host 10.12.1.201
>>> </AuthBy>
>>>
>>> <AuthBy RADIUS>
>>> IgnoreAccountingResponse
>>> RetryTimeout 25
>>> NoForwardAuthentication
>>> Secret radius
>>> AcctPort 1813
>>> Host 10.12.1.202
>>> </AuthBy>
>>>
>>> Regards,
>>> Donald
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Foo Donald (Products O2) [mailto:Donald.Foo at O2.com]
>>> Sent: Thursday, June 26, 2003 10:47 PM
>>> To: 'radiator at open.com.au'
>>> Subject: (RADIATOR) some question about the radiator
>>>
>>>
>>> Hi there,
>>> we found something strange after on production. can you help?
>>> we have a ggsn pointing to two radiator A and B, their configuration
>>> are the
>>> same.
>>>
>>> 1. we send the accounting packet to 4 accounting
>>> server(A1,A2,A3,A4),we only
>>> need A1 reply. But if A2 or A3 dead, the ggsn will fail to B
> radiator.
>>> herewith is the auth radius when we have this problem. with this
>>> configuration, we can see accounting send to A1, A2 and A3 but not
> A4,
>>> why??
>>> <AuthBy RADIUS>
>>> Synchronous
>>> RetryTimeout 25
>>> NoForwardAuthentication
>>> Secret radius
>>> AcctPort 1813
>>> Host 10.12.1.2
>>> </AuthBy>
>>>
>>> <AuthBy RADIUS>
>>> Synchronous
>>> RetryTimeout 25
>>> NoForwardAuthentication
>>> Secret radius
>>> AcctPort 1813
>>> Host 10.12.1.41
>>> </AuthBy>
>>>
>>> <AuthBy RADIUS>
>>> RetryTimeout 25
>>> NoForwardAuthentication
>>> Secret radius
>>> AcctPort 1813
>>> Host 10.12.1.201
>>> </AuthBy>
>>>
>>> <AuthBy RADIUS>
>>> RetryTimeout 25
>>> NoForwardAuthentication
>>> Secret radius
>>> AcctPort 1813
>>> Host 10.12.1.202
>>> </AuthBy>
>>>
>>>
>>> 2) When I put the IgnoreAccountingResponse in each of the tag, I can
>>> now
>>> only see accounting go A1 and don't see any accouning goto A2, A3,
A4
>>> (the
>>> current configuration is on below).
>>>
>>> 3) When I do a radiator/mysql process restart (we wrote a script to
> do
>>> start
>>> and stop) after change the configuration, it will not take effect
>>> until we
>>> reboot it, but the script works fine when test, is this relate to
>>> stack
>>> buffer or cache problem?
>>>
>>> 4) we found that the mysql database is growth fast. so it will take
>>> longer
>>> time to start it. is there anything in radiator which can detail the
>>> database ready before it can connect to it?
>>>
>>>
>>> The current configuration
>>>
>> #Foreground
>> #LogStdout
>> LogDir /var/radiator
>> LogFile %L/detail
>> DbDir /usr/local/radiator
>> DictionaryFile %D/dictionary,%D/goodies/dictionary.usr
>> PidFile %L/radiusd.pid
>> Trace 4
>>
>> AuthPort 1812
>> AcctPort 1813
>>
>> <Client DEFAULT>
>> Secret xxxxx
>> </Client>
>> <Client xxxxx>
>> Secret xxxxx
>> DupInterval 3
>> </Client>
>>
>> <Client xxxxx>
>> Secret xxxxx
>> DupInterval 3
>> </Client>
>>
>>
>> <Client xxxxx>
>> Secret xxxxx
>> DupInterval 3
>> </Client>
>>
>> <Client xxxxx>
>> Secret xxxxx
>> DupInterval 3
>> </Client>
>>
>> <Client xxxxx>
>> Secret xxxxx
>> DupInterval 3
>> </Client>
>>
>> <Client xxxxx>
>> Secret xxxxx
>> DupInterval 3
>> </Client>
>>
>> <Client xxxxx>
>> Secret xxxxx
>> DupInterval 3
>> </Client>
>>
>> <Client xxxxx>
>> Secret xxxxx
>> DupInterval 3
>> </Client>
>>
>> <Client xxxxx>
>> Secret xxxxx
>> DupInterval 3
>> </Client>
>>
>> <AuthBy SQL>
>> Identifier CheckSQLBlacklist
>> DBSource dbi:mysql:radius
>> DBUsername xxxxx
>> DBAuth xxxxx
>> AuthSelect select REJECT from CALLER_BLACKLIST where
>> Calling_Station='%{Calling-Station-Id}'
>> AuthColumnDef 0, GENERIC, check
>> AcceptIfMissing
>> NoDefaultIfFound
>> </AuthBy>
>>
>> <AuthBy SQL>
>> Identifier CheckSQLNormal
>> DBSource dbi:mysql:radius
>> DBUsername xxxxx
>> DBAuth xxxxx
>>
>> AccountingTable ACCOUNTING
>> AcctColumnDef USERNAME,User-Name
>> AcctColumnDef TIME_STAMP,Timestamp,integer
>> AcctColumnDef ACCTSTATUSTYPE,Acct-Status-Type
>> AcctColumnDef ACCTDELAYTIME,Acct-Delay-Time,integer
>> AcctColumnDef ACCTINPUTOCTETS,Acct-Input-Octets,integer
>> AcctColumnDef ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
>> AcctColumnDef ACCTSESSIONID,Acct-Session-Id
>> AcctColumnDef ACCTSESSIONTIME,Acct-Session-Time,integer
>> AcctColumnDef ACCTTERMINATECAUSE,Acct-Terminate-Cause
>> AcctColumnDef NASIDENTIFIER,NAS-Identifier
>> AcctColumnDef NASPORT,NAS-Port,integer
>> AcctColumnDef FRAMEDIPADDRESS,Framed-IP-Address
>> AcctColumnDef ACCTCALLINGSTATIONID,Calling-Station-Id
>> </AuthBy>
>>
>> # M1 Blacklist
>> <Handler Calling-Station-Id=/^123/>
>> RejectHasReason
>> <AuthBy INTERNAL>
>> DefaultResult REJECT
>> RejectReason You are not StarHub Customer
>> </AuthBy>
>>
>> <AuthLog SQL>
>> DBSource dbi:mysql:radius
>> DBUsername xxxxx
>> DBAuth xxxxx
>> LogFailure
>> FailureQuery insert into RADAUTHLOG (TIME_STAMP,
>> USERNAME,
>> TYPE, REASON, Calling_Station) values (%t, '%n', 0, %1,
>> '%{Calling-Station-Id}')
>> </AuthLog SQL>
>> </Handler>
>>
>> # SingTel Blacklist
>> <Handler Calling-Station-Id=/^123/>
>> RejectHasReason
>> <AuthBy INTERNAL>
>> DefaultResult RREJECT
>> RejectReason You are not StarHub Customer
>> </AuthBy>
>>
>> <AuthLog SQL>
>> DBSource dbi:mysql:radius
>> DBUsername xxxxx
>> DBAuth xxxxx
>> LogFailure
>> FailureQuery insert into RADAUTHLOG (TIME_STAMP,
>> USERNAME,
>> TYPE, REASON, Calling_Station) values (%t, '%n', 0, %1,
>> '%{Calling-Station-Id}')
>> </AuthLog SQL>
>> </Handler>
>>
>> <Handler>
>> RejectHasReason
>> AuthByPolicy ContinueWhileAccept
>> AuthBy CheckSQLBlacklist
>> AuthBy CheckSQLNormal
>> <AuthBy RADIUS>
>> RetryTimeout 5
>> NoForwardAuthentication
>> Secret xxxxx
>> AcctPort 1813
>> Host xxxxx
>> </AuthBy>
>>
>> <AuthBy RADIUS>
>> IgnoreAccountingResponse
>> RetryTimeout 5
>> NoForwardAuthentication
>> Secret xxxxx
>> AcctPort 1813
>> Host xxxxx
>> </AuthBy>
>>
>> <AuthBy RADIUS>
>> IgnoreAccountingResponse
>> RetryTimeout 25
>> NoForwardAuthentication
>> Secret xxxxx
>> AcctPort 1813
>> Host xxxxx
>> </AuthBy>
>>
>> <AuthBy RADIUS>
>> IgnoreAccountingResponse
>> RetryTimeout 25
>> NoForwardAuthentication
>> Secret xxxxx
>> AcctPort 1813
>> Host xxxxx
>> </AuthBy>
>>
>> <AuthLog SQL>
>> DBSource dbi:mysql:radius
>> DBUsername xxxxx
>> DBAuth xxxxx
>> LogSuccess
>> SuccessQuery insert into RADAUTHLOG (TIME_STAMP,
>> USERNAME,
>> TYPE, REASON, Calling_Station) values (%t, '%n', 1, 'Authorized',
>> '%{Calling-Station-Id}')
>> LogFailure
>> FailureQuery insert into RADAUTHLOG (TIME_STAMP,
>> USERNAME,
>> TYPE, REASON, Calling_Station) values (%t, '%n', 0, %1,
>> '%{Calling-Station-Id}')
>> </AuthLog>
>>
>> </Handler>
>>
>> <StatsLog SQL>
>> DBSource dbi:mysql:radius
>> DBUsername xxxxx
>> DBAuth xxxxx
>> Interval 3600
>> </StatsLog>
>>
>>
>>
>>> Regards,
>>> Donald
>>> ===
>>> 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.
>>> ===
>>> 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: have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>>
>> --
>> 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.
>>
>>
>
> NB: have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
>
> --
> 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.
> ===
> 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: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
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.
===
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