[RADIATOR] radiator Timeout handling

[Michael]

Hi,

I'm having a couple issues with . Maybe it would be 
considered a bug i'm not sure.



1. the Timeout handling.

From my testing, it appears that radiator times out at this value, but 
seems to retry the sql query a second time, creating in another timeout 
count.


eg debug:
Tue Sep 14 12:48:21 2010: DEBUG: Handling accounting with Radius::AuthSQL
Tue Sep 14 12:48:21 2010: DEBUG: do query is: 'insert into `acct` 
Tue Sep 14 12:48:25 2010: ERR: do failed for 'insert into `acct`  
SQL Timeout
Tue Sep 14 12:48:29 2010: ERR: do failed for 'insert into `acct`  
SQL Timeout
Tue Sep 14 12:48:29 2010: DEBUG: AuthBy SQL result: IGNORE, Database 
failure


Timeout is set for 4 seconds...
so, query executed at 12:48:21, ERR timed out 4 seconds later, appeared 
to re-try but didn't say anything, and another ERR timeout 4 seconds 
after that.  That's 8 seconds of course.  It doubles the Timeout value.


This is no good, for me.  If I set my SQL timeout value for 4 seconds, 
and my NAS timeout for 5 seconds, I expect my radiator to timeout before 
my NAS re-transmits.  my NAS will retry after 5 seconds because radiator 
hasn't responded.  And, radiator hasn't obeyed the timeout so it's still 
waiting for 8 seconds.  This causes the same accounting packet to enter 
radiator again, and causing another 8 seconds delay, and of course 
duplicate entries in the accounting logging since I'm also using 
AcctFailedLogFileName so the packet will eventually end up in the SQL 
table.



2. SQL Timeout issue #2.

using the same debug example above, when the SQL query times out, it 
doesn't seem to use the FailureBackoffTime value. It only seems to use 
FailureBackoffTime when there is a connection failure, not a timeout.  
So, every query is still presented to the SQL server.  If the timeout is 
due to lets say a write lock, when the lock releases, all the queued 
insert statements are executed creating in sometimes up to 10 duplicate 
accounting entries.



3. AuthBy result after failure
--
an IGNORE occurs when the SQL query fails, but if AcctFailedLogFileName 
is used, and successfully wrote the accounting packet to the file, 
should radiator not then reply with an ACCEPT?  Dumping the accounting 
packet to a file, but replying with IGNORE will cause the NAS to go to 
the next radius server possibly accepting the entry, therefore the 
packet in the acct failed logfile, is a double.  Even if there's only 1 
radiator server in play, there will be an accounting packet entry in the 
failed log for each time the NAS retries.



Thanks in advanced for any advice,
Michael

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator Timeout handling

[Michael]

27;,'100','FED')':
 
SQL Timeout
Thu Sep 16 15:19:54 2010: DEBUG: AuthBy SQL result: IGNORE, Database failure

### timeout value 3 * 2 queries = 6 seconds and 2 possible accounting 
duplicates.
### omitted here is the exact same debug lines from another Start packet 
from the NAS since it timed out and retransmitted.


### here's the Stop packet coming through trying an insert again, not 
obeying FailureBackoffTime.

*** Received from 192.168.100.1 port 1646 
Code:   Accounting-Request
Identifier: 76
Authentic: <130><28><130><231>C<233><2><135><30><142><206><148><156>T~<160>
Attributes:
 Acct-Session-Id = "0620"
 Framed-Protocol = PPP
 Framed-IP-Address = 192.168.100.100
 User-Name = "dsltest"
 Acct-Authentic = RADIUS
 Acct-Session-Time = 4
 Acct-Input-Octets = 880
 Acct-Output-Octets = 116
 Acct-Input-Packets = 12
 Acct-Output-Packets = 7
 Acct-Terminate-Cause = User-Request
 Acct-Status-Type = Stop
 NAS-Port-Type = Ethernet
 NAS-Port = 100
 NAS-Port-Id = "0/0/0/431"
 Class = "FED,100,dsltest"
 Service-Type = Framed-User
 NAS-IP-Address = 192.168.100.1
 Ascend-Session-Svr-Key = "AA39FB66"
 NAS-Identifier = "TEST-LNS-1"
 Acct-Delay-Time = 0

Thu Sep 16 15:19:54 2010: DEBUG: hook.service-label: finding 
service-label for NAS-Port=(100)
Thu Sep 16 15:19:54 2010: DEBUG: hook.service-label: service-label=(testing)
Thu Sep 16 15:19:54 2010: DEBUG: hook.service-label: 
add_attr(service=testing)
Thu Sep 16 15:19:54 2010: DEBUG: Handling request with Handler 
'Request-Type = "Accounting-Request", Acct-Status-Type = Start|Stop', 
Identifier 'accounting'
Thu Sep 16 15:19:54 2010: DEBUG: hook.PreProcessingHook: executing.
Thu Sep 16 15:19:54 2010: DEBUG: hook.PreProcessingHook: changed 
Acct-Status-Type Stop to logout.
Thu Sep 16 15:19:54 2010: DEBUG: hook.PreProcessingHook: loading attrs 
from Class.
Thu Sep 16 15:19:54 2010: DEBUG: hook.PreProcessingHook: calculating 
total-output-octets and total-input-octets.
Thu Sep 16 15:19:54 2010: DEBUG: Handling with Radius::AuthSQL: 
SQL-1-Accounting
Thu Sep 16 15:19:54 2010: DEBUG: Handling accounting with Radius::AuthSQL
Thu Sep 16 15:19:54 2010: DEBUG: do query is: 'insert into `acct` 
(`acct_delay_time`,`auth_un`,`download`,`ip_address`,`nas_ip_address`,`service`,`sess_id`,`sess_time`,`submitted_un`,`term_cause`,`timestamp`,`type`,`uid`,`upload`,`zone`)
 
values 
('0','dsltest','116','192.168.100.100','192.168.100.1','testing','0620','4','dsltest','User-Request','1284664794','logout','100','880','FED')':
 

Thu Sep 16 15:19:57 2010: ERR: do failed for 'insert into `acct` 
(`acct_delay_time`,`auth_un`,`download`,`ip_address`,`nas_ip_address`,`service`,`sess_id`,`sess_time`,`submitted_un`,`term_cause`,`timestamp`,`type`,`uid`,`upload`,`zone`)
 
values 
('0','dsltest','116','192.168.100.100','192.168.100.1','testing','0620','4','dsltest','User-Request','1284664794','logout','100','880','FED')':
 
SQL Timeout
Thu Sep 16 15:20:00 2010: ERR: do failed for 'insert into `acct` 
(`acct_delay_time`,`auth_un`,`download`,`ip_address`,`nas_ip_address`,`service`,`sess_id`,`sess_time`,`submitted_un`,`term_cause`,`timestamp`,`type`,`uid`,`upload`,`zone`)
 
values 
('0','dsltest','116','192.168.100.100','192.168.100.1','testing','0620','4','dsltest','User-Request','1284664794','logout','100','880','FED')':
 
SQL Timeout
Thu Sep 16 15:20:00 2010: DEBUG: AuthBy SQL result: IGNORE, Database failure

### omitted here is the exact same debug lines from another Stop packet 
from the NAS since it timed out and retransmitted.




On 10-09-16 03:00 PM, Hugh Irvine wrote:
>
> Hello Michael -
>
> We'll need to see a copy of the configuration file (no secrets), together 
> with a more complete trace 4 debug showing what is happening.
>
> We will also need to know what hardware/software platform you are running on, 
> what version of Perl, what version of DBI/DBD, what SQL database, and 
> anything else that might be useful.
>
> regards
>
> Hugh
>
>
> On 16 Sep 2010, at 13:33, Michael wrote:
>
>> Hi,
>>
>> I'm having a couple issues with. Maybe it would be considered a 
>> bug i'm not sure.
>>
>>
>> 1. the Timeout handlin

Re: [RADIATOR] radiator Timeout handling

[Michael]

ok, thanks.  Can I suggest an option to disable this behavior? In my 
case, I would prefer radiator to only allow one timeout, when a timeout 
occurs, respect the FailureBackoffTime. If it doesn't, radiator creates 
a very undesirable situation when it continues to try for every packet, 
the sql server that timed out. It basically bottlenecks my whole radius 
system since all radiator servers connect to the same accounting mysql 
server, and all nas's eventually mark each radius server "RADIUS_DEAD" 
and then all authentication seems to stop.

Mike



On 10-09-16 08:27 PM, Hugh Irvine wrote:
> Hello Michael -
>
> The behaviour you observe is in fact what the code does - the manual does not 
> correctly describe this behaviour.
>
> The manual has been amended for the next release.
>
> Thanks for letting us know.
>
> regards
>
> Hugh
>
>
> On 16 Sep 2010, at 15:31, Hugh Irvine wrote:
>
>
>> Hello Michael -
>>
>> We'll investigate this a bit further.
>>
>> BTW - some people put a unique index on the accounting table using something 
>> like Acct-Session-Id + Timestamp to avoid duplicates.
>>
>> Otherwise you can use a stored procedure in the database to do whatever you 
>> need (or not).
>>
>> regards
>>
>> Hugh
>>
>>
>>
>> On 16 Sep 2010, at 14:43, Michael wrote:
>>
>>  
>>> Debian 4.0
>>> Perl, v5.8.8 built for x86_64-linux-gnu-thread-multi
>>> DBI v1.53
>>> mysqld Ver 5.0.32-Debian_7etch12-log for pc-linux-gnu on x86_64 (Debian 
>>> etch distribution)
>>>
>>>
>>> since my radiator config is quite lengthy, i'll just post what i think is 
>>> the relevant parts.  if you would like to know more, let me know.  There 
>>> are also a few very custom things I do to identify what type of service the 
>>> connection is coming from, handling of Acct Gigawords and Acct Octets, 
>>> etc...  so, there's going to be a few things in the debug/config that you 
>>> wont recognize.
>>>
>>>   section allows specific NAS's
>>>
>>> #All accounting packets for all NAS'S handled here:
>>> >>Acct-Status-Type = Start|Stop>
>>>Identifier accounting
>>>
>>>SessionDatabase sessdb
>>>
>>>PreProcessingHook file:"%D/conf/hook.PreProcessingHook"
>>>
>>>AuthByPolicy
>>>AuthBy SQL-1-Accounting
>>> 
>>> 
>>>
>>>Identifier  SQL-1-Accounting
>>>
>>>DBSourcedbi:mysql:yyy:yyy
>>>DBUsername  yyy
>>>DBAuth  yyy
>>>
>>>
>>>Timeout   3
>>>FailureBackoffTime300
>>>
>>>
>>># a few attributes added to radius packet via previous Hook file.
>>>AccountingTable `acct`
>>>AcctColumnDef   `submitted_un`,%u,formatted
>>>AcctColumnDef   `auth_un`,auth-un
>>>AcctColumnDef   `zone`,zone
>>>AcctColumnDef   `uid`,uid
>>>AcctColumnDef   `timestamp`,Timestamp
>>>AcctColumnDef   `type`,Acct-Status-Type
>>>AcctColumnDef   `acct_delay_time`,Acct-Delay-Time
>>>AcctColumnDef   `upload`,total-input-octets
>>>AcctColumnDef   `download`,total-output-octets
>>>AcctColumnDef   `sess_id`,Acct-Session-Id
>>>AcctColumnDef   `sess_time`,Acct-Session-Time
>>>AcctColumnDef   `term_cause`,Acct-Terminate-Cause
>>>AcctColumnDef   `nas_ip_address`,NAS-IP-Address
>>>AcctColumnDef   `ip_address`,Framed-IP-Address
>>>AcctColumnDef   `service`,service
>>>
>>>AcctFailedLogFileName 
>>> %L/accounting-missed/logfile.sql-failed.acct.%Y%m%d
>>> 
>>>
>>>
>>>
>>>
>>> Thu Sep 16 15:19:48 2010: DEBUG: Packet dump:
>>> *** Received from 192.168.100.1 port 1646 
>>> Code:   Accounting-Request
>>> Identifier: 75
>>> Authentic:<133><139><188><253><225><157><240>[Lo<175><236><127><144><161><31>
>>> Attributes:
>>>Acct-Session-Id = "0620"
>>>Framed-Protocol = PPP
>>>Framed-IP-Address = 192.168.100.100
>>>User-Name = "dsltest"
>>>Acct-Authentic = RADIUS
>>>Acct-Status-Type = Start
>>>

Re: [RADIATOR] Basic question about AuthBy and Handlers.

[Michael]

Ricardo,

I don't think the AuthBy clauses are checked at all on their own.  The 
AuthBy's are strictly a configuration, referenced by the Handler's via 
"AuthBy (Identifier)".  Therefore, the Handler is checked first, and if 
the AuthBy's are not referenced in any Handler, they will not be used at 
all.


Referenced AuthBy's need to be configured above the Handler for which 
references it.


So, I don't see your AuthBy's being referenced at all in the 2 Handlers 
you have, therefore not used.


Michael
P.S. correct me if i'm wrong.



On 10-11-17 08:19 AM, Ricardo Martinez wrote:


Hello.

I have a basic question about the AuthBy clause.  I’m in the process 
of understand the configuration file create by another person. So.


If I have  clauses before anything else in the 
configuration file, this means all the request are going to be 
authenticated for each one of this clauses??  Or just they define the 
way to connect to the other server to forward the request, and the 
Reaquest are processed with the Handler clauses before ??


This is the beginning of the configuration file :



Secret nokia

DupInterval 0





Identifier WAPGW

IgnoreAccountingResponse

Host xx.xx.xx.xx

Secret nokia

AuthPort 1812

AcctPort 1813

Retries 0

MaxFailedRequests 50

FailureBackoffTime 0



# En este AuthBy se definen los parametros para reenviar los 
requerimientos hacia Subscriber Manager




Identifier CiscoSuscriberManager

IgnoreAccountingResponse

IgnoreAuthentication

Host xxx.xxx.xxx.xxx

Secret scesm

AuthPort 1812

AcctPort 1813

Retries 0

MaxFailedRequests 50

FailureBackoffTime 0

AddToRequest Class = %{3GPP-User-Location-Info}, 3GPP-SGSN-Roaming 
= %{3GPP-SGSN-Address}






   Identifier MobiProf

   RequestHook file:"/etc/radiator/mobiprof_connector.pl 
<http://mobiprof_connector.pl>"






Identifier SqlStart

DBSource
dbi:mysql:database=radius;host=xxx.xxx.xxx.xxx;timeout=1


DBUsername  radius

DBAuth

FailureBackoffTime 10

Timeout 1

AcctSQLStatement replace into ONLINE 
(MSISDN,APN,3GPP_Charging_Id,Username,Acct_Session_Id,Timestamp,NAS_Identifier,Framed_IP_A$






Identifier SqlAlive

DBSource
dbi:mysql:database=radius;host=xxx.xxx.xxx.xxx;timeout=1


DBUsername  radius

DBAuth

FailureBackoffTime 10

Timeout 1

AcctSQLStatement update ONLINE set Timestamp = "%{Timestamp}", 
3GPP_RAT_Type = if("%{3GPP-RAT-Type}"="", NULL , "%{3GPP-RAT-Typ$






Identifier SqlStop

DBSource
dbi:mysql:database=radius;host=xxx.xxx.xxx.xx;timeout=1


DBUsername  radius

DBAuth

FailureBackoffTime 10

Timeout 1

AcctSQLStatement delete from ONLINE where 
NAS_Identifier="%{NAS-Identifier}" and 
3GPP_Charging_Id="%{3GPP-Charging-Id}";




/(1400|1600)/>






DefaultReply Called-Station-Id = "isp.domain.pp"



. . .

Called-Station-Id=/imovil.domain\.cl/>








So, if a request is coming to my server, the first thing to try is the 
Handlers??.. or the AuthBy clause defined at the beginning of the 
configuration file?


Hope someone can help me here.

Thanks in advance.

Regards,

Ricardo.-


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Upgrading - Handlers

[Michael]

I recently upgraded from a really old version.  1.8 or something like 
that.  I was able to use the exact same Auth config without any 
modification except for things I wanted to change for improvement.  I 
suspect you shouldn't have any problems.  But, it's always good to test 
first.  That's my disclaimer.  :)


Michael


On 10-12-07 06:33 AM, Ricardo Freitas wrote:

Hello to all.

I currently have a really old version of Radiator installed (2.19) and 
I'm going to upgrade it now to the latest release.


Does this handlers work pretty much the same way?


User-Name=/(username-with-calledNumber)\...@quiz$/>

*Identifier  Identifier1 (example)*


{ configuration info }





User-Name=/(username-with-calledNumber)\...@quiz$/>

* Identifier  Identifier2 (another example)*
AccountingHandled
AcctLogFileName  %L/%Y%m%d_log


{ configuration info }





Thank you!

Ricardo


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Ignore Accounting packets from certain hosts

[Michael]

Yes, but i wouldn't recommend it.  If your NAS is ignored, it may mark 
your radius server as RADIUS_DEAD, if cisco.  Depends on your NAS i guess.

If you just don't want to do anything with the accounting, it's probably 
better to just ACCEPT and do nothing with it, but if you truley want to 
ignore, you can.  If ignored, your NAS would probably move to the next 
radius server in its config and try the accounting on that radius server. 
again, depends on NAS config.

...for Accounting only:



 DefaultResult IGNORE <- use this to ignore
 DefaultResult ACCEPT <- use this to accpet





But, if you want to use the realm option, and have authentication to:


...


...


# this will reply ACCEPT to the NAS,
# but do nothing with it.
AccountingHandled




Michael




On Fri, 10 Dec 2010, Zaeem Arshad wrote:

> Hi List,
>
> We are testing a scenario where we require our radiator radius server
> to ignore accounting packets from certain NAS hosts if the user
> belongs  to realm xyz.com. Is that possible?
>
>
> Regards
>
> Zaeem
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] radpwtst - sending multiple packets

[Michael]

hi,

I'm trying to figure out the best way to send multiple radius packets to 
a server.  It seems that executing radpwtst once for each individual 
packet is pretty slow.  I assume it is slow since it has to compile, 
parse the dictionary, and do whatever else radpwtst has to do each time 
it is run.  I'm wondering if there is a way to have radpwtst run once, 
and send/receive multiple packets.

I see there is a -rawfileseq option that appears to do this, but i don't 
see this as being a documented option in the manual.  How do you 
generate raw packets to build a raw file?

Is there any other ways of sending/receiving radius packets to a server?


Mike

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radpwtst - sending multiple packets

[Michael]

Sounds good.  i'll check out that module.  What I was trying to do is 
log what I call a 'checkpoint' for all online sessions for the purpose 
of calculating monthly bandwidth usage.  if a session starts in one 
month, but logs out in a different month, you can't calculate the 
monthly usage accurately.  I wanted to log a checkpoint entry containing 
the usage on the 1st of every month for each session.  with that, usage 
can be subtracted to find the usage of that month.

So, i ended up using 'Alive' packets to accomplish this. Seems like kind 
of a hack, but it works pretty good.


...
# for a 40 minute windows on the 1st of every month, set 
Acct-Status-Type = checkpoint
ClientHook sub { my $req = ${$_[0]}; \
 my $dHM = &Radius::Util::format_special("%d,%H,%M");
 my( $d, $H, $M ) = ( split(/,/,$dHM) )[0,1,2];
 if( $d == 1 && $H == 0 && $M <= 40 && 
$req->get_attr('Acct-Status-Type') eq 'Alive' ) {
&main::log($main::LOG_WARNING, "ClientHook: 1st of the month. 
configuring Alive packet as a checkpoint.");
   $req->change_attr('Acct-Status-Type','checkpoint');
 }
...


And then later, in an AuthBy:


...
# for Acct-Status-Type = checkpoint
 HandleAcctStatusTypes   checkpoint
 AcctSQLStatement INSERT INTO some_table ( sess_id, timestamp, 
upload, download, . ) \
     VALUES ( '%{Acct-Session-Id}', %b, ... ) \
 ON DUPLICATE KEY UPDATE (x=y,xx=yy, )

...



Michael

On 11-01-05 08:43 PM, Kiernan McColl wrote:
> You could use radiator's Radius::Radius perl module from within your own perl 
> script. That way you could fork if a single thread isn't sending them fast 
> enough for your needs.
> I believe there's an example in the goodies directory.
>
> -Original Message-
> From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On 
> Behalf Of Bjoern A. Zeeb
> Sent: Thursday, January 06, 2011 5:37 AM
> To: Michael
> Cc: radiator@open.com.au list
> Subject: Re: [RADIATOR] radpwtst - sending multiple packets
>
> On Wed, 5 Jan 2011, Michael wrote:
>
> Hi,
>
>> I'm trying to figure out the best way to send multiple radius packets to
>> a server.  It seems that executing radpwtst once for each individual
>> packet is pretty slow.  I assume it is slow since it has to compile,
>> parse the dictionary, and do whatever else radpwtst has to do each time
>> it is run.  I'm wondering if there is a way to have radpwtst run once,
>> and send/receive multiple packets.
>>
>> I see there is a -rawfileseq option that appears to do this, but i don't
>> see this as being a documented option in the manual.  How do you
>> generate raw packets to build a raw file?
>>
>> Is there any other ways of sending/receiving radius packets to a server?
>
> Depends on what you really want to accomplish.  Shell loops of
> radpwtst have often been suggested in the past; I found them painful
> to script though.  There is a problem of deltaT (rtt) as well, so you need
> parallel radpwtst to actually get to speed and with that you need to
> make sure to not send duplicates, yadda yadda yadda.  It's ok if you
> want to check a couple of hundred requests.
>
> For benchmarking and pushing servers in the multiple thousands of
> reqs/s you probably want something more sophisticated but perl and
> Radiator have proven to be able to do that fairly well, even on a
> desktop machine;)
>
> /bz
>

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] CoA / Change-of-Authorization / Change-Filter-Request

[Michael]

I give up.  I've searched for hours for a hint at what this CoA / 
Change-of-Authorization / Change-Filter-Request is.  I think it is what 
i'm looking for.

I have the usual problem of too much info on the internet, and not 
enough of it makes sense to me.  For radiator specific, i can only find 
1 mention for Change-Filter-Request in the manual and it only says 
radpwtst can send this code.  The website says in the changelog there's 
a fix for a bug.

i've run across a couple examples for radpwtst:
-code Change-Filter-Request User-Name=whatever Message-Authenticator=x

and

-code Change-Filter-Request Account-Info="Sx.x.x.x" Command-Code="04 20"


I'm just looking to know if you can change the rate limit of a current 
session on a cisco device.

I was kinda hoping something like this would work:
-code Change-Filter-Request User-Name="test" cisco-Policy-Down="rate1M"
or:
code Change-Filter-Request Acct-Session-Id="0012" 
cisco-Policy-Down="rate1M"

if also tried with the cisco-avpair attr.


all I ever get in the cisco debug is:

...
++ CoA Attribute List ++
84F09FA4 0 0009 string-session-id(339) 8 0005
...
COA: No matching entry found
COA: Added Reply Message: No Matching Session
...


why nothing matches, i don't know. the session-id is correct. but since 
i don't know anything about the COA, i'm not even sure if i'm barking up 
the right tree.

My Disconnect-Request process works fine which uses a similar process.


Michael

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] CoA / Change-of-Authorization / Change-Filter-Request

[Michael]

On Fri, 28 Jan 2011, Steve Lalonde wrote:

> On 28 Jan 2011, at 02:30, Michael wrote:
>
>>
>> I give up.  I've searched for hours for a hint at what this CoA /
>> Change-of-Authorization / Change-Filter-Request is.  I think it is what
>> i'm looking for.
>>
>> I was kinda hoping something like this would work:
>> -code Change-Filter-Request User-Name="test" cisco-Policy-Down="rate1M"
>> or:
>> code Change-Filter-Request Acct-Session-Id="0012"
>> cisco-Policy-Down="rate1M"
>>
>> My Disconnect-Request process works fine which uses a similar process.
>>
>>
>> Michael
>
> Hi
>
> I had the same problem and eventually got it working using the following
>
> /usr/local/bin/radpwtst -noauth -noacct -code Change-Filter-Request -secret 
>  -s $nas-ip -auth_port 1700 Framed-IP-Address=$ip 
> cisco-avpair="ip:sub-qos-policy-out=$policy"
>
> that worked but i had scaling issues, only solved when i moved the traffic 
> management to Cisco SCE devices.
>
> -- 
> Steve Lalonde RTFM
> Chief Technical Officer
> Entanet International Ltd
> http://www.enta.net/
>
>


Thanks for the suggestion.  I never thought to try to match by IP alone, 
but it didn't seem to work. The router shows the attributes i enter with 
radpwtst, it just refuses to match anything.

COA: x.x.x.x request queued
++ CoA Attribute List ++
86124E38 0 0001 addr(7) 4 x.x.x.x
857EA738 0 0009 sub-qos-policy-out(348) 6 RATE1M
COA: No matching entry found
COA: Added Reply Message: No Matching Session
COA: Added NACK Error Cause: Session Context Not Found
COA: Sending NAK from port 1700 to x.x.x.x

There must be more strict limitations/requirments in order to match a 
session for CoA? maybe something else has to be used as matching 
attributes?

I do have the match policy set for ANY for now during testing:
aaa server radius dynamic-author
  ...
  auth-type any

This to me is suppose to tell the router to match a session if ANY 
attribute at all match.

There must me something more that's required that most people 
unknowingly adhere to?



___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] CoA / Change-of-Authorization / Change-Filter-Request

[Michael]

On Fri, 28 Jan 2011, Michael wrote:

>
>
> On Fri, 28 Jan 2011, Steve Lalonde wrote:
>
>> On 28 Jan 2011, at 02:30, Michael wrote:
>>
>>>
>>> I give up.  I've searched for hours for a hint at what this CoA /
>>> Change-of-Authorization / Change-Filter-Request is.  I think it is what
>>> i'm looking for.
>>>
>>> I was kinda hoping something like this would work:
>>> -code Change-Filter-Request User-Name="test" cisco-Policy-Down="rate1M"
>>> or:
>>> code Change-Filter-Request Acct-Session-Id="0012"
>>> cisco-Policy-Down="rate1M"
>>>
>>> My Disconnect-Request process works fine which uses a similar process.
>>>
>>>
>>> Michael
>>
>> Hi
>>
>> I had the same problem and eventually got it working using the following
>>
>> /usr/local/bin/radpwtst -noauth -noacct -code Change-Filter-Request -secret 
>>  -s $nas-ip -auth_port 1700 Framed-IP-Address=$ip 
>> cisco-avpair="ip:sub-qos-policy-out=$policy"
>>
>> that worked but i had scaling issues, only solved when i moved the traffic 
>> management to Cisco SCE devices.
>>
>> --
>> Steve Lalonde RTFM
>> Chief Technical Officer
>> Entanet International Ltd
>> http://www.enta.net/
>>
>>
>
>
> Thanks for the suggestion.  I never thought to try to match by IP alone,
> but it didn't seem to work. The router shows the attributes i enter with
> radpwtst, it just refuses to match anything.
>
> COA: x.x.x.x request queued
> ++ CoA Attribute List ++
> 86124E38 0 0001 addr(7) 4 x.x.x.x
> 857EA738 0 0009 sub-qos-policy-out(348) 6 RATE1M
> COA: No matching entry found
> COA: Added Reply Message: No Matching Session
> COA: Added NACK Error Cause: Session Context Not Found
> COA: Sending NAK from port 1700 to x.x.x.x
>
> There must be more strict limitations/requirments in order to match a
> session for CoA? maybe something else has to be used as matching
> attributes?
>
> I do have the match policy set for ANY for now during testing:
> aaa server radius dynamic-author
>  ...
>  auth-type any
>
> This to me is suppose to tell the router to match a session if ANY
> attribute at all match.
>
> There must me something more that's required that most people
> unknowingly adhere to?
>
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>


I tried this on a production router, getting frustrated!!  A little 
risky I know.  Last time I tried this for Disconnect-Request, a bug 
matched ALL SESSIONS and kicked everyone offline. DAMN CISCO

Anyways, the CoA matched the session and appears to have accepted 
the CoA. gonna have to test this later to see if the rate limit was 
applied.  the show aaa user  showed the rate limit before i tried it, 
and now shows nothing so i'm not sure if it broke the policy, or applied 
what i wanted and it just doesn't show me.

Looks like another IOS bug with my test lns.  DAMN YOU cisco.  I'm not 
even a network person.  I'm a systems person that has to learn 
cisco because it seems the cisco people don't know how to do what I want 
to do.  But, i don't blame them now that i've started to learn it. Stick 
that in your mailing list archive!!! ;)

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] CoA / Change-of-Authorization / Change-Filter-Request

[Michael]

On Fri, 28 Jan 2011, Michael wrote:

>
>
> On Fri, 28 Jan 2011, Michael wrote:
>
>>
>>
>> On Fri, 28 Jan 2011, Steve Lalonde wrote:
>>
>>> On 28 Jan 2011, at 02:30, Michael wrote:
>>>
>>>>
>>>> I give up.  I've searched for hours for a hint at what this CoA /
>>>> Change-of-Authorization / Change-Filter-Request is.  I think it is what
>>>> i'm looking for.
>>>>
>>>> I was kinda hoping something like this would work:
>>>> -code Change-Filter-Request User-Name="test" cisco-Policy-Down="rate1M"
>>>> or:
>>>> code Change-Filter-Request Acct-Session-Id="0012"
>>>> cisco-Policy-Down="rate1M"
>>>>
>>>> My Disconnect-Request process works fine which uses a similar process.
>>>>
>>>>
>>>> Michael
>>>
>>> Hi
>>>
>>> I had the same problem and eventually got it working using the following
>>>
>>> /usr/local/bin/radpwtst -noauth -noacct -code Change-Filter-Request -secret 
>>>  -s $nas-ip -auth_port 1700 Framed-IP-Address=$ip 
>>> cisco-avpair="ip:sub-qos-policy-out=$policy"
>>>
>>> that worked but i had scaling issues, only solved when i moved the traffic 
>>> management to Cisco SCE devices.
>>>
>>> --
>>> Steve Lalonde RTFM
>>> Chief Technical Officer
>>> Entanet International Ltd
>>> http://www.enta.net/
>>>
>>>
>>
>>
>> Thanks for the suggestion.  I never thought to try to match by IP alone,
>> but it didn't seem to work. The router shows the attributes i enter with
>> radpwtst, it just refuses to match anything.
>>
>> COA: x.x.x.x request queued
>> ++ CoA Attribute List ++
>> 86124E38 0 0001 addr(7) 4 x.x.x.x
>> 857EA738 0 0009 sub-qos-policy-out(348) 6 RATE1M
>> COA: No matching entry found
>> COA: Added Reply Message: No Matching Session
>> COA: Added NACK Error Cause: Session Context Not Found
>> COA: Sending NAK from port 1700 to x.x.x.x
>>
>> There must be more strict limitations/requirments in order to match a
>> session for CoA? maybe something else has to be used as matching
>> attributes?
>>
>> I do have the match policy set for ANY for now during testing:
>> aaa server radius dynamic-author
>>  ...
>>  auth-type any
>>
>> This to me is suppose to tell the router to match a session if ANY
>> attribute at all match.
>>
>> There must me something more that's required that most people
>> unknowingly adhere to?
>>
>>
>>
>> ___
>> radiator mailing list
>> radiator@open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>>
>
>
> I tried this on a production router, getting frustrated!!  A little
> risky I know.  Last time I tried this for Disconnect-Request, a bug
> matched ALL SESSIONS and kicked everyone offline. DAMN CISCO
>
> Anyways, the CoA matched the session and appears to have accepted
> the CoA. gonna have to test this later to see if the rate limit was
> applied.  the show aaa user  showed the rate limit before i tried it,
> and now shows nothing so i'm not sure if it broke the policy, or applied
> what i wanted and it just doesn't show me.
>
> Looks like another IOS bug with my test lns.  DAMN YOU cisco.  I'm not
> even a network person.  I'm a systems person that has to learn
> cisco because it seems the cisco people don't know how to do what I want
> to do.  But, i don't blame them now that i've started to learn it. Stick
> that in your mailing list archive!!! ;)
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>



CONFIRMED. i just noticed now, it changed the order of the 
attributes.  I didn't see notice at first.  It did apply the new 
policy.  looks like it worked fine with my production router.  must be a 
bug in my test lns. damn you cisco.  there's hours of my life i'll never 
get back.

Are we allowed to swear in this mailing list? :D

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Assigning IP's directly from the Radius server

[Michael]

I've been working on this to.  Got it working, but haven't put it into 
production yet.  May be a bit messy, but I just haven't got to the 
cleansing stage yet.

So, here's how i understand it works:

 used to build the sql table rows on startup and 
configures the (de)allocating of the IPs.
 passes the request to AddressAllocator from a 
Handler. The DYNADDRESS needs to be call by your auth/start/and stop 
Handler.

NOTE: i used a separate AddressAllocator to build the table rows, and 
KEEP IT DISABLED at all times since my ip table is used by multiple 
radiator servers so I never really want it to rebuild.

# adds the proper rows for each available IP on startup.

 Identifier init
...
 
 Subnetmask  255.255.255.255
 Range   192.168.1.100 192.168.1.200
 
 
 Subnetmask  255.255.255.255
 Range   192.168.2.100 192.168.2.200
 

CheckPoolQuery select STATE from RADPOOL where YIADDR=?
CheckPoolQueryBindVar %0

AddAddressQuery insert into RADPOOL (STATE, TIME_STAMP, POOL, \
YIADDR, SUBNETMASK, DNSSERVER) values (0, ?, ?, ?, ?, ?)
AddAddressQueryBindVar %t
AddAddressQueryBindVar %0
AddAddressQueryBindVar %1
AddAddressQueryBindVar %2
AddAddressQueryBindVar %3



# configure allocate/deallocate sql statements.

 Identifier address-allocator.1
...
 # sql select statement seems to need the ip address in the
 # 2nd slot in the results to satisfy '%3' for 'AllocateQuery'.
 # this seems to be an undocumented requirement.
 FindQuery select NULL, ip, netmask from ip_pools where pool=? \
and state=0 order by timestamp limit 1
 FindQueryBindVar %0

 # allocate during 'Access-Request' after sucessful 'FindQuery'
 AllocateQuery update ip_pools set state=1,timestamp=?, \
  auth_un=? where ip=?
 AllocateQueryBindVar %0
 AllocateQueryBindVar %2
 AllocateQueryBindVar %3

 # deallocate with accounting Stop packets
 DeallocateQuery update ip_pools set state=0, auth_un=NULL, \
  timestamp=? where ip=?
 DeallocateQueryBindVar %t
 DeallocateQueryBindVar %0

 # ReclaimQuery = (blank) ...to disable lease expiring.
 ReclaimQuery
 # defaults to:
 #ReclaimQuery update RADPOOL set STATE=0 where STATE!=0 and \
   EXPIRY < ?
 #ReclaimQueryBindVar %0




# middle-man DYNADDRESS used to pass to AddressAllocator

 # specific ip pool for nas defined by 'NAS-IP-Address'
 Identifier nas_specific
 AddressAllocator address-allocator.1
 PoolHint %{Request:NAS-IP-Address}
 MapAttributeip, Framed-IP-Address
 MapAttributenetmask, Framed-IP-Netmask
 #StripFromReply PoolHint





...
AuthByPolicyContinueWhileAccept
 AuthBy  auth.sql
# send to DYNADDRESS after Accept to get it's ip.
 AuthBy nas_specific
...




# AuthByPolicy (blank): process all AuthBy's
 AuthByPolicy

 # acct details logging
 AuthBy acct.sql
 AuthBy another-if-you-want-to

# start/stops need to go to DYNADDRESS to allocate/deallocate
 AuthBy nas_specific
...




Michael


On 11-01-31 04:46 AM, Gerard Alcorlo Bofill wrote:
> Hello,
>
> I'm using Radiator with 4 CISCO AP 1100 to offer Eduroam access.
> Nowadays we are giving IP address from a DHCP server without visibility
> with the Radius.
> I'd like to query the Radius using radwho.cgi script giving all the
> assignated IP addresses at that specific moment.
>
> To do that, I thought that the solution would be to use
>   and then use the Framed-Route attribute to assign
> the gateway to the clients.
>
> Am I right?
>
> I also have problems understanding the  clause.
> In what situation is useful that Radiator asks the IP to a real DHCP
> server? Is something related to the performance or there are situations
> that need a DHCP mandatorily?
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Assigning IP's directly from the Radius server

[Michael]

I think the AddressPool only populates the sql table with the available ips in 
that pool.  I guess you're missing a FindQuery definition of an sql query that 
returns an available ip from the sql db.

my example had this:

 # sql select statement seems to need the ip address in the 2nd 
returned column in the results to satisfy '%3' for 'AllocateQuery'.
 # this seems to be an undocumented requirement.
 #FindQuery select TIME_STAMP, YIADDR, SUBNETMASK, DNSSERVER from 
RADPOOL where POOL=? and STATE=0 order by TIME_STAMP limit 1
 FindQuery select NULL, ip, netmask from ip_pools where pool=? and 
state=0 order by timestamp limit 1
 FindQueryBindVar %0

which selects the ip/netmask and the reply IP/netmask must be the 2nd/3rd 
returned column in the results, and adds this result into Framed-IP-Address and 
Framed-IP-Netmask to the reply radius packet needed for the nas.

And of course, you need an AllocateQuery to mark that IP as used, and 
DeallocateQuery to mark available again after the stop packet.

Michael


On 11-02-03 09:47 AM, Gerard Alcorlo Bofill wrote:
> Hello,
>
> thanks Michael for your good explanation. I checked your configuration
> with mine and it was similar. Well, I only have one Radius so I don't
> use two AddressAllocators like you.
>
> Heikki, thank you too. Now I understand a little more the difference
> between the two different AddressAllocators. I've been experimenting,
> but I'm not able to get an ip address from the Radius server and I
> allways get the address from the DHCP server. I've based my
> configuration with goodies/addressallocator.cfg
>
>
> 
> Identifier myallocator
> DBSource dbi:mysql:database_name:127.0.0.1
> DBUsername  user
> DBAuth  password
> FailureBackoffTime  30
>
> DefaultLeasePeriod  86400
> LeaseReclaimInterval300
>
> 
>Subnetmask   255.255.255.128
>Range10.0.0.2 10.0.0.127
>DNSServer8.8.8.8
> 
> 
>
>
> 
> AuthByPolicy ContinueWhileAccept
> 
>DBSource dbi:mysql:database_name:127.0.0.1
>DBUsername  user
>DBAuth  password
>FailureBackoffTime  30
>
>AuthSelect  select PASSWORD from SUBSCRIBERS where BINARY
> USERNAME=%0
>AuthColumnDef   0, User-Password, check
>AuthColumnDef   1, GENERIC, check
>EAPType MSCHAP-V2, PAP
> 
>
> 
>AddressAllocator myallocator
>PoolHint pool-eduroam
>AddToReply Framed-Route="10.0.0.0/25  10.0.0.1 1"
>AddToReply MS-Primary-DNS-Server=84.88.0.3,
> MS-Secondary-DNS-Server=84.88.0.5
>StripFromReply PoolHint
> 
> 
>
>
>
> This is the error I'm getting from de AP:
> 16:27:29.234 GMT: RADIUS/DECODE: EAP-Message fragments, 6, total 6 bytes
> 16:27:29.241 GMT: RADIUS/ENCODE(002A):Orig. component type = DOT11
> 16:27:29.241 GMT: RADIUS/ENCODE: No idb found! Framed IP Addr might not
> be included
>
> I thought that my NAS (my AP) would send all the attributes to the wifi
> client but that's not happening.
>
> Are this attributes only for PPP connections or is it possible to use
> them using a wifi AP?
>
> Thanks
>
> --
> Gerard
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Assigning IP's directly from the Radius server

[Michael]

oh and keep in mind, when you restart radiator, or even maybe reload radiator, 
the AddressPool may re-mark all ips as available, therefore it may hand out an 
IP that is already in use.  Maybe someone else can confirm that is correct?


On 11-02-03 11:53 AM, Michael wrote:
> I think the AddressPool only populates the sql table with the available ips 
> in that pool.  I guess you're missing a FindQuery definition of an sql query 
> that returns an available ip from the sql db.
>
> my example had this:
>
>   # sql select statement seems to need the ip address in the 2nd 
> returned column in the results to satisfy '%3' for 'AllocateQuery'.
>   # this seems to be an undocumented requirement.
>   #FindQuery select TIME_STAMP, YIADDR, SUBNETMASK, DNSSERVER from 
> RADPOOL where POOL=? and STATE=0 order by TIME_STAMP limit 1
>   FindQuery select NULL, ip, netmask from ip_pools where pool=? and 
> state=0 order by timestamp limit 1
>   FindQueryBindVar %0
>
> which selects the ip/netmask and the reply IP/netmask must be the 2nd/3rd 
> returned column in the results, and adds this result into Framed-IP-Address 
> and Framed-IP-Netmask to the reply radius packet needed for the nas.
>
> And of course, you need an AllocateQuery to mark that IP as used, and 
> DeallocateQuery to mark available again after the stop packet.
>
> Michael
>
>
> On 11-02-03 09:47 AM, Gerard Alcorlo Bofill wrote:
>> Hello,
>>
>> thanks Michael for your good explanation. I checked your configuration
>> with mine and it was similar. Well, I only have one Radius so I don't
>> use two AddressAllocators like you.
>>
>> Heikki, thank you too. Now I understand a little more the difference
>> between the two different AddressAllocators. I've been experimenting,
>> but I'm not able to get an ip address from the Radius server and I
>> allways get the address from the DHCP server. I've based my
>> configuration with goodies/addressallocator.cfg
>>
>>
>> 
>>  Identifier myallocator
>>  DBSource dbi:mysql:database_name:127.0.0.1
>>  DBUsername  user
>>  DBAuth  password
>>  FailureBackoffTime  30
>>
>>  DefaultLeasePeriod  86400
>>  LeaseReclaimInterval300
>>
>>  
>> Subnetmask   255.255.255.128
>> Range10.0.0.2 10.0.0.127
>> DNSServer8.8.8.8
>>  
>> 
>>
>>
>> 
>>  AuthByPolicy ContinueWhileAccept
>>  
>> DBSource dbi:mysql:database_name:127.0.0.1
>> DBUsername  user
>> DBAuth  password
>> FailureBackoffTime  30
>>
>> AuthSelect  select PASSWORD from SUBSCRIBERS where BINARY
>> USERNAME=%0
>> AuthColumnDef   0, User-Password, check
>> AuthColumnDef   1, GENERIC, check
>> EAPType MSCHAP-V2, PAP
>>  
>>
>>  
>> AddressAllocator myallocator
>> PoolHint pool-eduroam
>> AddToReply Framed-Route="10.0.0.0/25  10.0.0.1 1"
>> AddToReply MS-Primary-DNS-Server=84.88.0.3,
>> MS-Secondary-DNS-Server=84.88.0.5
>> StripFromReply PoolHint
>>  
>> 
>>
>>
>>
>> This is the error I'm getting from de AP:
>> 16:27:29.234 GMT: RADIUS/DECODE: EAP-Message fragments, 6, total 6 bytes
>> 16:27:29.241 GMT: RADIUS/ENCODE(002A):Orig. component type = DOT11
>> 16:27:29.241 GMT: RADIUS/ENCODE: No idb found! Framed IP Addr might not
>> be included
>>
>> I thought that my NAS (my AP) would send all the attributes to the wifi
>> client but that's not happening.
>>
>> Are this attributes only for PPP connections or is it possible to use
>> them using a wifi AP?
>>
>> Thanks
>>
>> --
>> Gerard
>>
>>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] check-items in chained authby queries

[Michael]

your "AuthBy GROUP AuthSQL" will not flow down into  the "AuthBy GROUP 
AuthHOTP".  I don't think the AuthHOTP will be used at all in this config.

Look like you need an "AuthBy AuthHOTP" in the AuthSQL config, like this:
> 
>  Identifier  AuthSQL
>  AuthByPolicyContinueWhileAccept
>  
>  GroupMembershipQuerySELECT groupname FROM v_usergroups 
> WHERE username=%0 AND groupname=%1
>  AuthSelect  select PASSWORD, 'Auth-Type=AuthHOTP', 
> 'GroupList="Group1 Group2 Group3"' from SUBSCRIBERS where USERNAME=%0
>  AuthColumnDef   0, Class, request
>  AuthColumnDef   1, GENERIC, check
>  AuthColumnDef   2, GENERIC, check
>  

# now call the AuthHOTP
AuthBy AuthHOTP

> 


Michael


On 11-02-03 02:34 PM, Linuxchuck wrote:
> Hello again,
>
> I am attempting to validate both the username and appropriate group 
> membership via MySQL on an incoming access-request before bothering to 
> process the HOTP password provided.  If the username doesn't exist, or the 
> user is not a member of the group in the list provided, send a reject and 
> stop processing.
>
> The problem I run into is that the grouplist check appears to be performed by 
> the 2nd AuthBy clause, which fails because HOTP is not capable of checking 
> groups.  I would like for the group check to occur prior to the HOTP check.
>
> Here is my config layout so far:
>
> FYI:  The user entry in MySQL provides a check-item of "Auth-Type=AuthHOTP"
>
> 
>  Identifier  AuthSQL
>  AuthByPolicyContinueWhileAccept
>  
>  GroupMembershipQuerySELECT groupname FROM v_usergroups 
> WHERE username=%0 AND groupname=%1
>  AuthSelect  select PASSWORD, 'Auth-Type=AuthHOTP', 
> 'GroupList="Group1 Group2 Group3"' from SUBSCRIBERS where USERNAME=%0
>  AuthColumnDef   0, Class, request
>  AuthColumnDef   1, GENERIC, check
>  AuthColumnDef   2, GENERIC, check
>  
> 
>
> 
>  Identifier  AuthHOTP
>  
>  ...
>  
> 
>
> 
>  AuthBy AuthSQL
> 
>
> I don't see any evidence that the Authby SQL is performing the group check, 
> and the log tells me "WARNING: This AuthBy does not know how to get user 
> Groups" under the HOTP section.
>
> Is there a way to accomplish what I'm after?
>
> Thanks!
>
> Chuck
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] check-items in chained authby queries

[Michael]

Actually, probably nicer to understand, and easier to look at if you clean it 
up like this:


# configure AuthSQL
  
Identifier  AuthSQL

GroupMembershipQuerySELECT groupname FROM v_usergroups 
WHERE username=%0 AND groupname=%1
AuthSelect  select PASSWORD, 'Auth-Type=AuthHOTP', 
'GroupList="Group1 Group2 Group3"' from SUBSCRIBERS where USERNAME=%0
AuthColumnDef   0, Class, request
AuthColumnDef   1, GENERIC, check
AuthColumnDef   2, GENERIC, check

  

# configure AuthHOTP
  
Identifier  AuthHOTP

...

  

# configure authentication process
  
AuthByPolicyContinueWhileAccept
AuthBy AuthSQL
AuthBy AuthHOTP
  







On 11-02-03 02:43 PM, Michael wrote:
>
> your "AuthBy GROUP AuthSQL" will not flow down into  the "AuthBy GROUP 
> AuthHOTP".  I don't think the AuthHOTP will be used at all in this config.
>
> Look like you need an "AuthBy AuthHOTP" in the AuthSQL config, like this:
>> 
>>   Identifier  AuthSQL
>>   AuthByPolicyContinueWhileAccept
>>   
>>   GroupMembershipQuerySELECT groupname FROM v_usergroups 
>> WHERE username=%0 AND groupname=%1
>>   AuthSelect  select PASSWORD, 'Auth-Type=AuthHOTP', 
>> 'GroupList="Group1 Group2 Group3"' from SUBSCRIBERS where USERNAME=%0
>>   AuthColumnDef   0, Class, request
>>   AuthColumnDef   1, GENERIC, check
>>   AuthColumnDef   2, GENERIC, check
>>   
>
> # now call the AuthHOTP
>   AuthBy AuthHOTP
>
>> 
>
>
> Michael
>
>
> On 11-02-03 02:34 PM, Linuxchuck wrote:
>> Hello again,
>>
>> I am attempting to validate both the username and appropriate group 
>> membership via MySQL on an incoming access-request before bothering to 
>> process the HOTP password provided.  If the username doesn't exist, or the 
>> user is not a member of the group in the list provided, send a reject and 
>> stop processing.
>>
>> The problem I run into is that the grouplist check appears to be performed 
>> by the 2nd AuthBy clause, which fails because HOTP is not capable of 
>> checking groups.  I would like for the group check to occur prior to the 
>> HOTP check.
>>
>> Here is my config layout so far:
>>
>> FYI:  The user entry in MySQL provides a check-item of "Auth-Type=AuthHOTP"
>>
>> 
>>   Identifier  AuthSQL
>>   AuthByPolicyContinueWhileAccept
>>   
>>   GroupMembershipQuerySELECT groupname FROM v_usergroups 
>> WHERE username=%0 AND groupname=%1
>>   AuthSelect  select PASSWORD, 'Auth-Type=AuthHOTP', 
>> 'GroupList="Group1 Group2 Group3"' from SUBSCRIBERS where USERNAME=%0
>>   AuthColumnDef   0, Class, request
>>   AuthColumnDef   1, GENERIC, check
>>   AuthColumnDef   2, GENERIC, check
>>   
>> 
>>
>> 
>>   Identifier  AuthHOTP
>>   
>>   ...
>>   
>> 
>>
>> 
>>   AuthBy AuthSQL
>> 
>>
>> I don't see any evidence that the Authby SQL is performing the group check, 
>> and the log tells me "WARNING: This AuthBy does not know how to get user 
>> Groups" under the HOTP section.
>>
>> Is there a way to accomplish what I'm after?
>>
>> Thanks!
>>
>> Chuck
>> ___
>> radiator mailing list
>> radiator@open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>>
>>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] check-items in chained authby queries

[Michael]

ah ok, i see.  the  AuthSQL specifies "Auth-Type=AuthHOTP". Never done this 
type of setup before, but maybe the 'Auth-Type=AuthHOTP' in the sql query 
should be after the 'GroupList="Group1 Group2 Group3"??  Again, not sure, but I 
would think the 'check' is done in order.  it sounds like you want to do the 
group list check first before checking the AuthHOTP. I don't see any config in 
the AuthHOTP section though.

Sorry, I'm reaching/guessing a little.


Michael


On 11-02-03 03:11 PM, Linuxchuck wrote:
> Hi Michael, Thanks for the response.
>
> Actually, it does hit the AuthHOTP section.  I should have put a little more 
> emphasis on the fact that there is an "AuthType=AuthHOTP" for the user when 
> it is looked up in the database.  I did mention that, but it was kind of 
> jammed into the beginning, and was probably easy to miss.
>
> Here is the "slightly sanitized" debug output indicating AuthHOTP was indeed 
> used:
>
> Thu Feb  3 13:54:57 2011: DEBUG: Handling request with Handler 
> 'Realm=DEFAULT', Identifier ''
> Thu Feb  3 13:54:57 2011: DEBUG:  Deleting session for testuser, 
> 192.168.xxx.xxx, 1
> Thu Feb  3 13:54:57 2011: DEBUG: Handling with Radius::AuthGROUP: AuthSQL
> Thu Feb  3 13:54:57 2011: DEBUG: Handling with Radius::AuthSQL:
> Thu Feb  3 13:54:57 2011: DEBUG: Handling with Radius::AuthSQL:
> Thu Feb  3 13:54:57 2011: DEBUG: Query is: 'select PASSWORD, CHECKATTR, 
> 'GroupList="group1 group2 group3 group4 group5"' from SUBSCRIBERS where 
> USERNAME='testuser'':
> Thu Feb  3 13:54:57 2011: DEBUG: Radius::AuthSQL looks for match with 
> testuser [testuser]
> Thu Feb  3 13:54:57 2011: DEBUG: Handling with Radius::AuthGROUP: AuthHOTP
> Thu Feb  3 13:54:57 2011: DEBUG: Handling with Radius::AuthSQLHOTP:
> Thu Feb  3 13:54:57 2011: DEBUG: Radius::AuthSQLHOTP looks for match with 
> testuser [testuser]
> Thu Feb  3 13:54:57 2011: WARNING: This AuthBy does not know how to get user 
> Groups
> Thu Feb  3 13:54:57 2011: WARNING: This AuthBy does not know how to get user 
> Groups
> Thu Feb  3 13:54:57 2011: WARNING: This AuthBy does not know how to get user 
> Groups
> Thu Feb  3 13:54:57 2011: WARNING: This AuthBy does not know how to get user 
> Groups
> Thu Feb  3 13:54:57 2011: WARNING: This AuthBy does not know how to get user 
> Groups
> Thu Feb  3 13:54:57 2011: DEBUG: Radius::AuthSQLHOTP REJECT: User testuser is 
> not in any group in GroupList: testuser [testuser]
> Thu Feb  3 13:54:57 2011: DEBUG: Radius::AuthGROUP:AuthHOTP  result: REJECT, 
> User testuser is not in any group in GroupList
> Thu Feb  3 13:54:57 2011: DEBUG: Radius::AuthSQL REJECT: User testuser is not 
> in any group in GroupList: testuser [testuser]
> Thu Feb  3 13:54:57 2011: DEBUG: Query is: 'select PASSWORD, CHECKATTR, 
> 'GroupList="group1 group2 group3 group4 group5"' from SUBSCRIBERS where 
> USERNAME='DEFAULT'':
> Thu Feb  3 13:54:57 2011: DEBUG: Radius::AuthGROUP:AuthSQLUSR  result: 
> REJECT, User testuser is not in any group in GroupList
> Thu Feb  3 13:54:57 2011: DEBUG: AuthBy GROUP result: REJECT, User testuser 
> is not in any group in GroupList
> Thu Feb  3 13:54:57 2011: INFO: Access rejected for testuser: User testuser 
> is not in any group in GroupList
>
> Thanks!
>
> On 02/03/2011 01:43 PM, Michael wrote:
>>
>> your "AuthBy GROUP AuthSQL" will not flow down into  the "AuthBy GROUP 
>> AuthHOTP".  I don't think the AuthHOTP will be used at all in this config.
>>
>> Look like you need an "AuthBy AuthHOTP" in the AuthSQL config, like this:
>>> 
>>>   Identifier  AuthSQL
>>>   AuthByPolicyContinueWhileAccept
>>>   
>>>   GroupMembershipQuerySELECT groupname FROM 
>>> v_usergroups WHERE username=%0 AND groupname=%1
>>>   AuthSelect  select PASSWORD, 'Auth-Type=AuthHOTP', 
>>> 'GroupList="Group1 Group2 Group3"' from SUBSCRIBERS where USERNAME=%0
>>>   AuthColumnDef   0, Class, request
>>>   AuthColumnDef   1, GENERIC, check
>>>   AuthColumnDef   2, GENERIC, check
>>>   
>>
>> # now call the AuthHOTP
>>  AuthBy AuthHOTP
>>
>>> 
>>
>>
>> Michael
>>
>>
>> On 11-02-03 02:34 PM, Linuxchuck wrote:
>>> Hello again,
>>>
>>> I am attempting to validate both the username and appropriate group 
>>> membership via MySQL on an 

Re: [RADIATOR] check-items in chained authby queries

[Michael]

instead of:
roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=%0 AND 
groupname=%1

try:
roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=? AND 
groupname=?


On Thu, 3 Feb 2011, Linuxchuck wrote:

> Michael,
>
> Ok, I gave it a shot, and got some completely different results.  Thanks for 
> the suggestion.  The order of check items is certainly taken into account, 
> which I should have thought of.  However, the error I am receiving is a 
> little strange.  All I have done is changed the order of the two check items. 
>  Now I am getting an error that looks to be more of a Perl error than a 
> Radiator error.
>
> Here is the debug log:
>
> Thu Feb  3 17:45:45 2011: DEBUG: Packet dump:
> *** Received from 192.168.xxx.xxx port 1645 
> Code:   Access-Request
> Identifier: 47
> Authentic:  
> Attributes:
>User-Name = "testuser"
>User-Password = **
>NAS-Port = 1
>NAS-Port-Id = "tty1"
>NAS-Port-Type = Virtual
>Calling-Station-Id = "192.168.yyy.yyy"
>NAS-IP-Address = 192.168.xxx.xxx
>
> Thu Feb  3 17:45:45 2011: DEBUG: Handling request with Handler 
> 'Realm=DEFAULT', Identifier ''
> Thu Feb  3 17:45:45 2011: DEBUG:  Deleting session for testuser, 
> 192.168.xxx.xxx, 1
> Thu Feb  3 17:45:45 2011: DEBUG: Handling with Radius::AuthGROUP: AuthSQLUSR
> Thu Feb  3 17:45:45 2011: DEBUG: Handling with Radius::AuthSQL:
> Thu Feb  3 17:45:45 2011: DEBUG: Handling with Radius::AuthSQL:
> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'select PASSWORD, 
> 'GroupList="group1 group2 group3 group4 group5"', 'AuthType=AuthHOTP' from 
> SUBSCRIBERS where USERNAME='testuser'':
> Thu Feb  3 17:45:45 2011: DEBUG: Radius::AuthSQL looks for match with 
> testuser [testuser]
> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group1'': testuser 
> group1
> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group1'': called with 2 
> bind variables when 0 are needed
> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group1'': called with 2 
> bind variables when 0 are needed
> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group2'': testuser 
> group2
> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group2'': called with 2 
> bind variables when 0 are needed
> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group2'': called with 2 
> bind variables when 0 are needed
> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group3'': testuser 
> group3
> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group3'': called with 2 
> bind variables when 0 are needed
> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group3'': called with 2 
> bind variables when 0 are needed
> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group4'': testuser 
> group4
> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group4'': called with 2 
> bind variables when 0 are needed
> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group4'': called with 2 
> bind variables when 0 are needed
> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'SELECT groupname FROM 
> v_usergroups WHERE username='testuser' AND groupname='group5'': testuser 
> group5
> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
> v_usergroups WHERE u

Re: [RADIATOR] check-items in chained authby queries

[Michael]

the version, 4.7, that i have, it looks like the GroupMembershipQuery should 
honor %0 and %1 and replace them with the 'sql quoted user name' and 'sql 
quoted 
group name' as per the manual as well.

But, as per your debug, it looks like it's using 'bind variables', so i think 
sql would replace the question marks (?) with these bind variables.

What version do you have?

let me know how using 2 '?' instead of %0 and %1 goes.

Michael


formats the query in AuthSQL.pm, and passes the user/group as @extras:
--
my $q = &Radius::Util::format_special($self->{GroupMembershipQuery}, $p,
   $self, $qusername, $qgroupname);

format routine:
---
sub format_special
{
 my ($s, $p, $self, @extras) = @_;
...

and formats here, replacing all %(digits) with values from @extras:
---
$s =~ s/%([%aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTUuvVwWxXyYzZ]|\d+)/$1 =~ 
m@(^\d+)@ ? $extras[$1] : &{$conversions{$1}}($p)/egs;





On Thu, 3 Feb 2011, Michael wrote:

>
> instead of:
> roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=%0 
> AND
> groupname=%1
>
> try:
> roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=? AND
> groupname=?
>
>
> On Thu, 3 Feb 2011, Linuxchuck wrote:
>
>> Michael,
>>
>> Ok, I gave it a shot, and got some completely different results.  Thanks for 
>> the suggestion.  The order of check items is certainly taken into account, 
>> which I should have thought of.  However, the error I am receiving is a 
>> little strange.  All I have done is changed the order of the two check 
>> items.  Now I am getting an error that looks to be more of a Perl error than 
>> a Radiator error.
>>
>> Here is the debug log:
>>
>> Thu Feb  3 17:45:45 2011: DEBUG: Packet dump:
>> *** Received from 192.168.xxx.xxx port 1645 
>> Code:   Access-Request
>> Identifier: 47
>> Authentic:  
>> Attributes:
>>User-Name = "testuser"
>>User-Password = **
>>NAS-Port = 1
>>NAS-Port-Id = "tty1"
>>NAS-Port-Type = Virtual
>>Calling-Station-Id = "192.168.yyy.yyy"
>>NAS-IP-Address = 192.168.xxx.xxx
>>
>> Thu Feb  3 17:45:45 2011: DEBUG: Handling request with Handler 
>> 'Realm=DEFAULT', Identifier ''
>> Thu Feb  3 17:45:45 2011: DEBUG:  Deleting session for testuser, 
>> 192.168.xxx.xxx, 1
>> Thu Feb  3 17:45:45 2011: DEBUG: Handling with Radius::AuthGROUP: AuthSQLUSR
>> Thu Feb  3 17:45:45 2011: DEBUG: Handling with Radius::AuthSQL:
>> Thu Feb  3 17:45:45 2011: DEBUG: Handling with Radius::AuthSQL:
>> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'select PASSWORD, 
>> 'GroupList="group1 group2 group3 group4 group5"', 'AuthType=AuthHOTP' from 
>> SUBSCRIBERS where USERNAME='testuser'':
>> Thu Feb  3 17:45:45 2011: DEBUG: Radius::AuthSQL looks for match with 
>> testuser [testuser]
>> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'SELECT groupname FROM 
>> v_usergroups WHERE username='testuser' AND groupname='group1'': testuser 
>> group1
>> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
>> v_usergroups WHERE username='testuser' AND groupname='group1'': called with 
>> 2 bind variables when 0 are needed
>> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
>> v_usergroups WHERE username='testuser' AND groupname='group1'': called with 
>> 2 bind variables when 0 are needed
>> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'SELECT groupname FROM 
>> v_usergroups WHERE username='testuser' AND groupname='group2'': testuser 
>> group2
>> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
>> v_usergroups WHERE username='testuser' AND groupname='group2'': called with 
>> 2 bind variables when 0 are needed
>> Thu Feb  3 17:45:45 2011: ERR: Execute failed for 'SELECT groupname FROM 
>> v_usergroups WHERE username='testuser' AND groupname='group2'': called with 
>> 2 bind variables when 0 are needed
>> Thu Feb  3 17:45:45 2011: DEBUG: Query is: 'SELECT groupname FROM 
>> v_usergroups WHERE username='testuser' AND groupname='group3

Re: [RADIATOR] check-items in chained authby queries

[Michael]

Perfect.  But it looks like you're just using a default setup.  there are other 
things that should be considered. very fine details, like one i run into is the 
nas wait times, and failover when problems arise. failing over to multiple sql 
servers for authentication is great. with accounting, if sql, fail over your 
logging to disk.

And, one of the most important things i've found, is if problems arise with the 
radius server, even with failover, if your nas isn't configured to wait long 
enough for the failover process to happen, it can mark the radius server as 
RADIUS_DEAD if cisco.  this was one of the more teadious things i worked on. 
for example, if your radiator server takes a total of 13 seconds to timeout and 
failover to other means, but your nas's are only configured to wait 8 seconds, 
then your nas will mark your radius server as DEAD.  where if it waited the 
full 
13 seconds, and finally the radius server responds after failing over, it will 
continue to function fine.

But of course, i'm not sure what kind of setup you're working with, mine for 
example, is so important, it can't fail.



On Thu, 3 Feb 2011, Linuxchuck wrote:

> Michael,
>
> I have version 4.7 based on the log output during startup.
>
> Your solution works!  I really appreciate your assistance on all this.  Now 
> to finish working out a way to add the proper reply type based on group 
> membership, and I can call my eval "done", and push the move to production.  
> I'm so ready to get rid of our windows-based RADIUS server, and this one is 
> looking like it is exactly what we need.
>
> You've been a great help.
>
> Respectfully,
> Chuck
>
>
> On 02/03/2011 08:17 PM, Michael wrote:
>>
>> the version, 4.7, that i have, it looks like the GroupMembershipQuery should 
>> honor %0 and %1 and replace them with the 'sql quoted user name' and 'sql 
>> quoted group name' as per the manual as well.
>>
>> But, as per your debug, it looks like it's using 'bind variables', so i 
>> think sql would replace the question marks (?) with these bind variables.
>>
>> What version do you have?
>>
>> let me know how using 2 '?' instead of %0 and %1 goes.
>>
>> Michael
>>
>>
>> formats the query in AuthSQL.pm, and passes the user/group as @extras:
>> --
>> my $q = &Radius::Util::format_special($self->{GroupMembershipQuery}, $p,
>>   $self, $qusername, $qgroupname);
>>
>> format routine:
>> ---
>> sub format_special
>> {
>> my ($s, $p, $self, @extras) = @_;
>> ...
>>
>> and formats here, replacing all %(digits) with values from @extras:
>> ---
>> $s =~ s/%([%aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTUuvVwWxXyYzZ]|\d+)/$1 =~ 
>> m@(^\d+)@ ? $extras[$1] : &{$conversions{$1}}($p)/egs;
>>
>>
>>
>>
>>
>> On Thu, 3 Feb 2011, Michael wrote:
>>
>>>
>>> instead of:
>>> roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=%0 
>>> AND
>>> groupname=%1
>>>
>>> try:
>>> roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=? 
>>> AND
>>> groupname=?
>>>
>>>
>>> On Thu, 3 Feb 2011, Linuxchuck wrote:
>>>
>>>> Michael,
>>>>
>>>> Ok, I gave it a shot, and got some completely different results.  Thanks 
>>>> for the suggestion.  The order of check items is certainly taken into 
>>>> account, which I should have thought of.  However, the error I am 
>>>> receiving is a little strange.  All I have done is changed the order of 
>>>> the two check items.  Now I am getting an error that looks to be more of a 
>>>> Perl error than a Radiator error.
>>>>
>>>> Here is the debug log:
>>>>
>>>> Thu Feb  3 17:45:45 2011: DEBUG: Packet dump:
>>>> *** Received from 192.168.xxx.xxx port 1645 
>>>> Code:   Access-Request
>>>> Identifier: 47
>>>> Authentic:  
>>>> Attributes:
>>>>User-Name = "testuser"
>>>>User-Password = **
>>>>NAS-Port = 1
>>>>NAS-Port-Id = "tty1"
>>>>NAS-Port-Type = Virtual
>>>>Calling-Station-Id = "192.168.yyy.yyy"
>>>&

Re: [RADIATOR] check-items in chained authby queries

[Michael]

oh, and, you may not want to stop there.  you may want to find out why %0 and 
%1 
don't work.  I think it should as per source code and manual.  Since you are 
using the 2 '?' the order is very important.  You can't change the order of:

WHERE username=? AND groupname=?

to this:
WHERE groupname=? AND username=?

..cause it will not work and will break your setup.

Maybe the radiator coders can check out the source. i'm sure they'll see these 
emails. To me, the source looks fine.


Michael




On Thu, 3 Feb 2011, Linuxchuck wrote:

> Michael,
>
> I have version 4.7 based on the log output during startup.
>
> Your solution works!  I really appreciate your assistance on all this.  Now 
> to finish working out a way to add the proper reply type based on group 
> membership, and I can call my eval "done", and push the move to production.  
> I'm so ready to get rid of our windows-based RADIUS server, and this one is 
> looking like it is exactly what we need.
>
> You've been a great help.
>
> Respectfully,
> Chuck
>
>
> On 02/03/2011 08:17 PM, Michael wrote:
>>
>> the version, 4.7, that i have, it looks like the GroupMembershipQuery should 
>> honor %0 and %1 and replace them with the 'sql quoted user name' and 'sql 
>> quoted group name' as per the manual as well.
>>
>> But, as per your debug, it looks like it's using 'bind variables', so i 
>> think sql would replace the question marks (?) with these bind variables.
>>
>> What version do you have?
>>
>> let me know how using 2 '?' instead of %0 and %1 goes.
>>
>> Michael
>>
>>
>> formats the query in AuthSQL.pm, and passes the user/group as @extras:
>> --
>> my $q = &Radius::Util::format_special($self->{GroupMembershipQuery}, $p,
>>   $self, $qusername, $qgroupname);
>>
>> format routine:
>> ---
>> sub format_special
>> {
>> my ($s, $p, $self, @extras) = @_;
>> ...
>>
>> and formats here, replacing all %(digits) with values from @extras:
>> ---
>> $s =~ s/%([%aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTUuvVwWxXyYzZ]|\d+)/$1 =~ 
>> m@(^\d+)@ ? $extras[$1] : &{$conversions{$1}}($p)/egs;
>>
>>
>>
>>
>>
>> On Thu, 3 Feb 2011, Michael wrote:
>>
>>>
>>> instead of:
>>> roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=%0 
>>> AND
>>> groupname=%1
>>>
>>> try:
>>> roupMembershipQuerySELECT groupname FROM v_usergroups WHERE username=? 
>>> AND
>>> groupname=?
>>>
>>>
>>> On Thu, 3 Feb 2011, Linuxchuck wrote:
>>>
>>>> Michael,
>>>>
>>>> Ok, I gave it a shot, and got some completely different results.  Thanks 
>>>> for the suggestion.  The order of check items is certainly taken into 
>>>> account, which I should have thought of.  However, the error I am 
>>>> receiving is a little strange.  All I have done is changed the order of 
>>>> the two check items.  Now I am getting an error that looks to be more of a 
>>>> Perl error than a Radiator error.
>>>>
>>>> Here is the debug log:
>>>>
>>>> Thu Feb  3 17:45:45 2011: DEBUG: Packet dump:
>>>> *** Received from 192.168.xxx.xxx port 1645 
>>>> Code:   Access-Request
>>>> Identifier: 47
>>>> Authentic:  
>>>> Attributes:
>>>>User-Name = "testuser"
>>>>User-Password = **
>>>>NAS-Port = 1
>>>>NAS-Port-Id = "tty1"
>>>>NAS-Port-Type = Virtual
>>>>Calling-Station-Id = "192.168.yyy.yyy"
>>>>NAS-IP-Address = 192.168.xxx.xxx
>>>>
>>>> Thu Feb  3 17:45:45 2011: DEBUG: Handling request with Handler 
>>>> 'Realm=DEFAULT', Identifier ''
>>>> Thu Feb  3 17:45:45 2011: DEBUG:  Deleting session for testuser, 
>>>> 192.168.xxx.xxx, 1
>>>> Thu Feb  3 17:45:45 2011: DEBUG: Handling with Radius::AuthGROUP: 
>>>> AuthSQLUSR
>>>> Thu Feb  3 17:45:45 2011: DEBUG: Handling with Radius::AuthSQL:
>>>> Thu Feb  3 17:45:45 2011: DEBUG: Handling with Radius::AuthSQL:
>>>> Thu 

Re: [RADIATOR] AcctInsertQuery for Authby RADIUS

[Michael]

AcctInsertQuery is for the  section.  it sounds like your trying to 
use it inside or around an .  It doesn't work that way. You need 
to setup an  section where the AcctInsertQuery will be inside your 
 or i prefer configuring it outside and calling it inside via 
AuthBy (Identifier).

Without a config sample though, ...can only speculate.

Michael


On 11-02-15 07:35 PM, Jeffrey Lee wrote:
> How do I log all accounting records locally (to a SQL DB) before
> proxy-forwarding to the respective RADIUS server?
> I know that I can log the accounting records locally but what I want
> is to insert the accounting record into a SQL database.
>
> I've tried adding AcctInsertQuery between  tags, but
> I'm getting this error when I started radiusd.
> "Wed Feb 16 10:24:07 2011: ERR: Unknown keyword 'AcctInsertQuery' in
> C:\Program Files\Radiator\radius.cfg line 268"
>
> Really need help with this! Thanks
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AcctInsertQuery for Authby RADIUS

[Michael]

You mentioned you wanted to '... log the RADIUS accounting records locally ... 
for realms that need to be authenticated by another RADIUS server'.  I don't 
think you can actually Authenticate your accounting start/stops as the password 
is not included in the packet.  If accounting is coming into your radius 
server, the authentication has already happened by this point.  You need to 
ether accept it, or don't.

But, I assume you mean authenticate the Realm, and except ALL accounting that 
may shows up for that Realm.  Keep in mind, that if authentication happens 
elsewhere, and accounting shows up here, it will be logged regardless of your 
.

I like to configure all clauses separately, and call them with identifiers. I 
find it makes the config easier to look at, and later you can call the same 
AuthBy if you want. but that's personal preference.

So, modifying Remo's example a bit:

Identifier SQL-acct-logging
DBSource...
DBUsername  ...
DBAuth  ...

AcctInsertQuery ...
AcctColumnDef ...



Identifier RADIUS-auth-proxy

...




Then call them in the Handler. again, i like to separate so you can see exactly 
what would happen when a packet is processed:

...

AuthByPolicyContinueUntilAccept
AuthBy RADIUS-auth-proxy

# you may want some sort of AuthLog here to.
AuthLog ...

...


...

# AuthByPolicy (blank) means process all AuthBy's
AuthByPolicy
AuthBy SQL-acct-logging
AuthBy you-could-have-another-log-aswell

...



Michael


On 11-02-16 02:53 AM, Ryter Remo wrote:
> Hi Jeff,
>
> What you can do is to combine both AuthBy clauses into an  and 
> simply put one after the other.
>
> It would be something like this:
>
> 
>   Identifier My_Group
>
>   # carefully with this, ensure that
>   # your AuthBy SQL will return ACCEPT
>   AuthByPolicy ContinueWhileAccept
>
>   
>   DBSource...
>   DBUsername  ...
>   DBAuth  ...
>
>   # This select has to succeed in order
>   # to return an ACCEPT (which is needed
>   # to continue to the AuthBy RADIUS)
>   # TIP: when there is no PASSWORD (NULL)
>   # in the selected record, then it's accepted
>   # no matter which password is provided
>   # in the request
>   AuthSelect select PASSWORD from ...
>
>   # now simply define your stuff
>   AcctColumnDef ...
>   
>
>   
>   
>   ...
>   
>   
> 
>
> Now you can use this AuthBy GROUP inside your handlers:
>
> 
>   ...
>   
>   AuthBy My_Group
>
>   ...
> 
>
> Hope that helped!
>
> Cheers,
> --Remo
>
> -Original Message-
> From: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] On 
> Behalf Of Jeffrey Lee
> Sent: Mittwoch, 16. Februar 2011 08:33
> To: Michael
> Cc: radiator@open.com.au
> Subject: Re: [RADIATOR] AcctInsertQuery for Authby RADIUS
>
> I tried adding  after  but as soon as
>   is executed,  will not be executed.
>
> Can you actually place  within a?
>
> What I'm trying to achieve is to log the RADIUS accounting records
> locally (start, stop&  alive) for realms that need to be authenticated
> by another RADIUS server. How can I achieve that?
>
>
> On Wed, Feb 16, 2011 at 11:26 AM, Michael  wrote:
>> AcctInsertQuery is for the  section.  it sounds like your trying
>> to use it inside or around an.  It doesn't work that way.
>> You need to setup an  section where the AcctInsertQuery will be
>> inside your  or i prefer configuring it outside and calling
>> it inside via AuthBy (Identifier).
>>
>> Without a config sample though, ...can only speculate.
>>
>> Michael
>>
>>
>> On 11-02-15 07:35 PM, Jeffrey Lee wrote:
>>>
>>> How do I log all accounting records locally (to a SQL DB) before
>>> proxy-forwarding to the respective RADIUS server?
>>> I know that I can log the accounting records locally but what I want
>>> is to insert the accounting record into a SQL database.
>>>
>>> I've tried adding AcctInsertQuery betweentags, but
>>> I'm getting this error when I started radiusd.
>>> "Wed Feb 16 10:24:07 2011: ERR: Unknown keyword 'AcctInsertQuery' in
>>> C:\Program Files\Radiator\radius.cfg line 268"
>>>
>>> Really need he

Re: [RADIATOR] AcctInsertQuery for Authby RADIUS

[Michael]

was there even an accounting record sent?  there's not enough debug here to 
show what type of request this was, and it's only one, if there was an auth 
request and a accounting request, there should be at least two requests in your 
debug.

I think you'd need to show the list more debug.

Michael


On 11-02-17 08:25 PM, Jeffrey Lee wrote:
> see below for the  config
>
> i have 2 RADIUS server setup here RADIUS A is this radiator,
> RADIUS B is another RADIUS for testing proxy-realms.
> On RADIUS A, here's the output on screen:
>
> Fri Feb 18 12:18:18 2011: DEBUG: Handling request with Handler
> 'Realm=ABC', Identifier ''
> Fri Feb 18 12:18:18 2011: DEBUG: Rewrote user name to jeff
> Fri Feb 18 12:18:18 2011: DEBUG:  Adding session for jeff@ABC, 
> 203.63.154.1,1234
> Fri Feb 18 12:18:18 2011: DEBUG: Handling with Radius::AuthSQL:
> Fri Feb 18 12:18:18 2011: DEBUG: Handling accounting with Radius::AuthSQL
> Fri Feb 18 12:18:18 2011: DEBUG: AuthBy SQL result: ACCEPT,
> Fri Feb 18 12:18:18 2011: DEBUG: Accounting accepted
>
>   >>  it seems as though the AcctInsertQuery was called but there's
> no accounting record captured. if the stored procedure generated an
> error, will radiator capture and display the error message on screen?
>
>
> On RADIUS B, it seems that the proxy-forwarded authentication requests
> is received but not the accounting requests.
>
>
> On the database (configured for radiator), there are no accounting
> records captured, and the sessiondatabase is not triggered.
>
>
> ... what is wrong with the config?
>
>
>
> #
>
> 
>   AcctLogFileName %D/detail
>   AuthByPolicy ContinueWhileIgnore
>   RewriteUsername s/^([^@]+).*/$1/
>   MaxSessions 1
>
>   
>   IgnoreAuthentication
>   HandleAcctStatusTypes Start,Stop,Alive
>   
>   # i've created a database called radiator with username and 
> password
> as radiator
>   DBAuth radiator
>   DBSource dbi:ODBC:radiator
>   DBUsername radiator
>
>   # i'm using a sql server stored procedure to capture the 
> accounting records
>   AcctInsertQuery exec radiator_insert_accounting '%{User-Name}',
> '%{Acct-Session-Id}', '%{Acct-Session-Time}', '%{Acct-Input-Octets}',
> '%{Acct-Output-Octets}', '%{Framed-IP-Address}',
> '%{Calling-Station-Id}', '%{Called-Station-Id}', '%{NAS-Identifier}',
> '%{NAS-IP-Address}', '%{NAS-Port}', '', '%{Acct-Status-Type}',
> '%{Acct-Terminate-Cause}', '%R'
>   
>
>   
>   AcctPort 1813
>   AuthPort 1812
>   CacheOnNoReply 1
>   CachePasswordExpiry 86400
>   LocalAddress 0.0.0.0
>   MaxFailedGraceTime 0
>   MaxFailedRequests 1
>   OutPort 0
>   PasswordPrompt password
>   Retries 3
>   RetryTimeout 5
>   Secret mysecret
>
>   
>   AcctPort 1813
>   AuthPort 1812
>   BogoMips 1
>   LocalAddress 0.0.0.0
>   MaxFailedGraceTime 0
>   MaxFailedRequests 1
>   OutPort 0
>   Retries 3
>   RetryTimeout 15
>   Secret mysecret
>   
>   
>   
>  # all success/failed requests logs are captured
>  
>   DBAuth radiator
>   DBSource dbi:ODBC:radiator
>   DBUsername radiator
>
>   LogSuccess 1
>   SuccessQuery insert into radpostauth (user,pass,reply)
> values(%2,%3,'Access-Accept')
>
>   LogFailure 1
>   FailureQuery insert into radpostauth (user,pass,reply)
> values(%2,%3,'Access-Reject')
>  
> 
>
> #
>
>
>
>
>
>
> On Thu, Feb 17, 2011 at 10:49 AM, Hugh Irvine  wrote:
>>
>> Hello Jeff -
>>
>> You should not mix Handlers and Realms in the same configuration file, as 
>> Realms are always evaluated before Handlers.
>>
>> If you are going to change from Realms to Handlers, I suggest you use 
>> separate Handlers fo

Re: [RADIATOR] AcctInsertQuery for Authby RADIUS

[Michael]

hmm.. ya, it looks like the AuthBy SQL is being called, but not executing the 
insert statment.


i seem to remember running into this before. I remember something about how 
radiator didn't execute the insert statement unless a AccountingTable value was 
configured, or maybe AcctColumnDef.


So, try adding this even though it's not needed since your sql insert statment 
has the table name:


AccountingTable radiator_insert_accounting

..and also try configuring an AcctColumnDef:
AcctColumnDef   invalid,invalid

This AcctColumnDef of course wont work, but just see what it does in your debug.


Michael




On Sat, 19 Feb 2011, Jeffrey Lee wrote:


here's the debug log...  i execute radpwtst -user jeff@abc -password 



Sat Feb 19 11:09:47 2011: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 56818 
Code:   Access-Request
Identifier: 2
Authentic:  <149>G<148><203>z<228>]<232><150><158><219><252><31><128>WP
Attributes:
   User-Name = "jeff@abc"
   Service-Type = Framed-User
   NAS-IP-Address = 203.63.154.1
   NAS-Identifier = "203.63.154.1"
   NAS-Port = 1234
   Called-Station-Id = "123456789"
   Calling-Station-Id = "987654321"
   NAS-Port-Type = Async
   User-Password = <22>]<179><134><136><216><235>Y<253><238>+<30><161><249>
a<235>

Sat Feb 19 11:09:47 2011: DEBUG: Handling request with Handler 'Realm=abc', Iden
tifier ''
Sat Feb 19 11:09:47 2011: DEBUG: Rewrote user name to jeff
Sat Feb 19 11:09:47 2011: DEBUG:  Deleting session for jeff@abc, 203.63.154.1, 1
234
Sat Feb 19 11:09:47 2011: DEBUG: Handling with Radius::AuthSQL:
Sat Feb 19 11:09:47 2011: DEBUG: AuthBy SQL result: IGNORE, Ignored due to Ignor
eAuthentication
Sat Feb 19 11:09:47 2011: DEBUG: Handling with Radius::AuthRADIUS
Sat Feb 19 11:09:47 2011: DEBUG: AuthBy RADIUS creates new local socket '0.0.0.0
:0' for sending requests
Sat Feb 19 11:09:47 2011: DEBUG: Packet dump:
*** Sending to 192.168.10.103 port 1812 
Code:   Access-Request
Identifier: 1
Authentic:  <149>G<148><203>z<228>]<232><150><158><219><252><31><128>WP
Attributes:
   User-Name = "jeff"
   Service-Type = Framed-User
   NAS-IP-Address = 203.63.154.1
   NAS-Identifier = "203.63.154.1"
   NAS-Port = 1234
   Called-Station-Id = "123456789"
   Calling-Station-Id = "987654321"
   NAS-Port-Type = Async
   User-Password = <22>]<179><134><136><216><235>Y<253><238>+<30><161><249>
a<235>

Sat Feb 19 11:09:47 2011: DEBUG: AuthBy RADIUS result: IGNORE,
Sat Feb 19 11:09:47 2011: DEBUG: Received reply in AuthRADIUS for req 1 from 192
.168.10.103:1812
Sat Feb 19 11:09:47 2011: DEBUG: Packet dump:
*** Received from 192.168.10.103 port 1812 
Code:   Access-Accept
Identifier: 1
Authentic:  1<234><130><212>=p<140><200><128><199><228><139>c<1><<148>
Attributes:
   Class = "<233><183>d=9<191><185>]<23><236>"Gl<249>"Z"

Sat Feb 19 11:09:47 2011: DEBUG: Access accepted for jeff
Sat Feb 19 11:09:47 2011: DEBUG: do query is: 'INSERT INTO SuccessfulRequests(Re
alm, UserName, Password, NASIPAddress, ReplyMessage, CallerID) values('', 'jeff'
, 'meyf', '203.63.154.1', '', '987654321')':
Sat Feb 19 11:09:48 2011: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 56818 
Code:   Access-Accept
Identifier: 2
Authentic:  "R<245><11><194>%<230><147>T<153><171><31><251><175>K<200>
Attributes:
   Class = "<233><183>d=9<191><185>]<23><236>"Gl<249>"Z"

Sat Feb 19 11:09:48 2011: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 56818 
Code:   Accounting-Request
Identifier: 3
Authentic:  <194><140><153><14>v<154><210> <227><204>;v7<148>(<172>
Attributes:
   User-Name = "jeff@abc"
   Service-Type = Framed-User
   NAS-IP-Address = 203.63.154.1
   NAS-Identifier = "203.63.154.1"
   NAS-Port = 1234
   NAS-Port-Type = Async
   Acct-Session-Id = "1234"
   Acct-Status-Type = Start
   Called-Station-Id = "123456789"
   Calling-Station-Id = "987654321"
   Acct-Delay-Time = 0
   Class = "<233><183>d=9<191><185>]<23><236>"Gl<249>"Z"

Sat Feb 19 

Re: [RADIATOR] AcctInsertQuery for Authby RADIUS

[Michael]

also, you should be able to use radpwtst -user jeff@abc -noauth -nostop so that 
it only sends a start packet into your radius server just to lesson the debug 
output and narrow things down.

Maybe remove the HandleAcctStatusTypes configuration since maybe it's 
wrongly determining the accounting type.

As per the radiator docs:
"If HandleAcctStatusTypes is specified and an Accounting request has an 
Acct-Status-Type not mentioned in HandleAcctStatusTypes, then the request will 
be ACCEPTed but not inserted or handled with AcctSQLStatement. The default is 
to 
handle all Acct-Status-Types."

so, if wrongly determining the type, it will ACCEPT but do nothing.  default is 
handle all accounting, so just take out the config option for now.


Michael







On Sat, 19 Feb 2011, Jeffrey Lee wrote:

> here's the debug log...  i execute radpwtst -user jeff@abc -password 
>
>
>
> Sat Feb 19 11:09:47 2011: DEBUG: Packet dump:
> *** Received from 127.0.0.1 port 56818 
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AcctInsertQuery for Authby RADIUS

[Michael]

your handler has a policy of:
AuthByPolicy ContinueWhileIgnore

so, when authentication comes through, your  replies with a 
Ignore since you have:

IgnoreAuthentication
and it continues

But, when an accounting packet comes in, your  replies with a ACCEPT 
since it excepted the accounting packet, and since the policy is 
ContinueWhileIgnore, it doesn't continue.


Your Policy is very important here because you use 1 handler for both 
authentication and accounting.  This is why i choose to use 2 handlers.  1 for 
each authentication, and one for accounting.


But, up to you i guess.



On Sun, 20 Feb 2011, Jeffrey Lee wrote:


Michael, you're right... the accounting insert query executed after i included

AccountingTable accounting #accounting table name
AcctColumnDef invalid,invalid

... but i did not comment out "HandleAcctStatusTypes Start,Stop,Alive"

but there's a problem... the accounting info does not get
proxy-forwarded to the RADIUS server i specified how do i enable local
RADIUS accounting logging (using SQL, which works now) and
proxy-forward all accounting info?



On Sat, Feb 19, 2011 at 3:13 PM, Michael  wrote:


also, you should be able to use radpwtst -user jeff@abc -noauth -nostop so
that it only sends a start packet into your radius server just to lesson the
debug output and narrow things down.

Maybe remove the HandleAcctStatusTypes configuration since maybe it's
wrongly determining the accounting type.

As per the radiator docs:
"If HandleAcctStatusTypes is specified and an Accounting request has an
Acct-Status-Type not mentioned in HandleAcctStatusTypes, then the request
will be ACCEPTed but not inserted or handled with AcctSQLStatement. The
default is to handle all Acct-Status-Types."

so, if wrongly determining the type, it will ACCEPT but do nothing.  default
is handle all accounting, so just take out the config option for now.


Michael







On Sat, 19 Feb 2011, Jeffrey Lee wrote:


here's the debug log...  i execute radpwtst -user jeff@abc -password 



Sat Feb 19 11:09:47 2011: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 56818 


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SessionDatabase SQL

[Michael]

copy and paste from the manual:
If DeleteQuery is defined as an empty string,
then the query will not be executed.

The manual is quite informative, and organised quite well.  I know manuals suck 
to read sometimes, but the radiator manual is one of the best organized manuals 
i've seen.  Of course, that's a personal opinion.


Michael

On Wed, 13 Apr 2011, Eddie Stassen wrote:

> Hi,
>
> Could someone please explain the rationale behind calling DeleteQuery
> on the session database when an authentication packet is received?  It
> makes no sense to me since the mere reception of an
> Authentication-Request is no indication that a session has ended.  It
> also means it is potentially very easy for users to bypass
> simultaneous login limitations by simply making a faking a second PPP
> session with a bad password (or spoofing an Authentication-Request),
> which will cause their existing radonline entry to be deleted and
> allow the account to be used from anywhere else.
>
> Is there any way to disable this behaviour without hacking the code?
>
> Eddie
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator Version 4.8 released

[Michael]

Can't seem to download the patches.  after accepting the license agreement, it 
just keeps returning to the license agreement.




On Thu, 28 Apr 2011, Mike McCauley wrote:

> We are pleased to announce the release of Radiator version 4.8
>
> This version contains some new features and minor bug fixes.
>
> As usual, the new version is available to current licensees from:
> http://www.open.com.au/radiator/downloads/
>
> and to current evaluators from:
> http://www.open.com.au/radiator/demo-downloads
>
> Licensees with expired access contracts can renew at:
> http://www.open.com.au/renewal.php
>
> An extract from the history file
> http://www.open.com.au/radiator/history.html is below:
>
> -
> Revision 4.8 (2011-04-28) New features and some bug fixes.
>
> Fixed a problem in AuthBy EAPBALANCE where no reply from a
> proxied request from the middle of an EAP stream would result in
> unlimited retransmissions of the request. Reported by Keith Ma.
>
> Testing on OpenWRT. OK, with caveats as discussed in the updated FAQ.
>
> Added Meru-AP-Id and Meru-AP-Name to dictionary. Provided by Neil Johnson.
>
> RPM packages were built by default on OpenSuSE with LZMA
> compression, which is not available for all platforms. This new
> Radiator.spec disables LZMA and uses BZ2 instead. In future all
> RPMS will be built with BZ2 comppression. New versions of
> Radiator-4.7-2.noarch.rpm and Radiator-Locked-4.7-2.noarch.rpm
> with BZ2 uploaded.
>
> Fixed a problem with AuthBy SQLTOTP and AuthBy SQLHOTP where
> MaxBadLogins, BadLoginWindow, DelayWindow, TimeStep and
> TimeStepOrigin parameters were not correctly read, resulting in
> errors like "Unknown keyword 'MaxBadLogins'". Reported by Matthew
> Reeves-Hairs.
>
> GetClientQuery was incorrectly using field 25 instead of 27 for
> flags. Documentation for GetClientQuery incorrectly decribed
> field 25 as being flags instead of ClientHook.
>
> Added SQLRetries parameter to all SQL type clauses. When
> executing a query, Radiator will try up to SQLRetries attempts to
> execute the query, retrying if certain types of SQL error are
> seen. Defaults to 2. Requested by Michael.
>
> Fixed some problems with Radius paths in the RPM on some
> platforms. Rebuilt and uploaded new RPMs.
>
> Improved Client CIDR address searches so a more specific cidr
> would have priority over a less specific cidr. Contributed by
> Nicholas Waples.
>
> Improved ClientListLDAP, added oscRadiusIdentifier &
> oscRadiusDefaultRealm into the default list of
> ClientAttrDef's. were the only attributes missing from
> oscRadiusClient ldap schema provided (in goodies). Contributed by
> Nicholas Waples.
>
> In Server TACACSPLUS, the call AuthenticationStartHook now
> includes the priv_lvl and service values from the TACACSPLUS
> request passed as arguments to the hook.
>
> In Server TACACSPLUS, during authetication, we now add
> cisco-avpair attributes to the RADIUS request for action,
> authen_type, priv-lvl and service from the incoming TACACSPLUS
> request.
>
> Improvements to AuthBy URL. Improved HTTP and HTML standards
> compliance by using the LWP::UserAgent methods post() and
> get(). Can now handle CHAP, MSCHAP and MSCHAPV2 authentication,
> as well as the previously supported PAP. *CHAP challenges and
> responses are encoded as HEX and sent as configurable web
> parameters. Updated the sample config file goodies/url.cfg, and
> improved documentation. Fixed inconsistant password in sample
> test_url_md5.cgi. Cleaned up some of the code to be compliant
> with in-house standards.
>
> Added support for BindAddress in all Ldap derived clauses,
> allowing you to specify a local address for the client side of
> the LDAP connection with BindAddress, in the form
> hostname[:port]. Defaults to 0.0.0.0. Updated sample config
> file. Suggested by Roel Hoek.
>
> Updated AuthBy NTLM so that if an authentication fails, the
> Warning log message records the user name along with the
> Authentication-Error. Suggested by David Zych.
>
> Further improvements to AuthBy URL. Now suports CopyReplyItem
> parameter. If a successful HTTP reply contains a string like
> 'xxx=hexencodedvalue' the value will be copied to the RADIUS
> reply as attribute yyy=value the value is expected to be HEX
> encoded and will be HEX decoded before adding to the reply.
>
> Fixed a problem where some SQL modules were not being correctly
> initialised, which was revealed when the new SQLRetries was
> added. Reported by Steffen Weinreich.
>
> Further improvements to AuthBy URL. Now supports CopyRequestItem
> parameter. Adds a tagged item to the HTTP request. Format is
> Cop

[RADIATOR] linux-radiator.init suggestion

[Michael]

suggest using these processes for Debian in the linux-radiator.init control 
script.  currently, i don't see anything.

RELOADPROC="/sbin/start-stop-daemon --stop --signal HUP --pidfile 
${RADIUSD_PIDFILE}"
TRACEUPPROC="/sbin/start-stop-daemon --stop --signal USR1 --pidfile 
${RADIUSD_PIDFILE}"
TRACEDOWNPROC="/sbin/start-stop-daemon --stop --signal USR2 --pidfile 
${RADIUSD_PIDFILE}"

The "start-stop-daemon" requires a --start or --stop, but when the --signal is 
specified for the --stop process, it does not send a TERM, so process is not 
stopped.


For the status option, i guess something is better than nothing?
CHECKPROC="ps -fp `cat ${RADIUSD_PIDFILE}`"


Michael
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] radiator shutdown on reload

[Michael]

I just had an issue with radiator shutting down.  I added another Handler to my 
config.  I keep them in separate files, and use an include to include that 
given file.  I typo'd the file location, and when I reloaded the config, the 
service shut down.  I have an HA environment where I sync the config to 4 
redundant radiator systems and they all reload upon new config.  So, all 4 
services shut down.  Boy was I sweating.

Does radiator not use the current running configuration if a reload fails to 
process the config files?


Michael

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator shutdown on reload

[Michael]

On Fri, 3 Jun 2011, Heikki Vatiainen wrote:

> On 06/02/2011 11:56 PM, Michael wrote:
>
>> I just had an issue with radiator shutting down.  I added another
>> Handler to my config.  I keep them in separate files, and use an
>> include to include that given file.  I typo'd the file location, and
>> when I reloaded the config, the service shut down.  I have an HA
>> environment where I sync the config to 4 redundant radiator systems
>> and they all reload upon new config.  So, all 4 services shut down.
>> Boy was I sweating.
>>
>> Does radiator not use the current running configuration if a reload
>> fails to process the config files?
>
> It does not. Fortunately this problem is also logged during startup. In
> other words, what you experienced is how Radiator works.
>
> You also need to be careful to close each ,  and other
> clauses. Not closing these with a matching  etc. can cause the
> parser to incorrectly interpret the configuration file without noticing
> any errors.

The error i created was only a typo in an include statement filename.  so, 
the only error is really a 'file not found' type error.  i wouldn't think 
this would be reason enough to shut down.

Also, there is nothing in my log about the error.  The only time i seen 
the error was on the cli when trying to start radiator back up again.  It 
would be nice if radiator didn't shut down on error, but if it must, i 
would think the last line in the log would be why it shut down.

I guess since it can't parse the config during the startup, it doesn't 
know where/how to log, so the best time to log such an error is before it 
shuts down, while it still has config of where the log file is.

>
> Heikki
>
> -- 
> Heikki Vatiainen 
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
> NetWare etc.
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] radiator shutdown on reload

[Michael]

I setup an identical radiator instance.  i'll do what you suggest. thanks.


On 11-06-03 03:04 PM, Martin Burton wrote:
> Just my 2p worth :-)
>
>>
>> The error i created was only a typo in an include statement filename.  so,
>> the only error is really a 'file not found' type error.  i wouldn't think
>> this would be reason enough to shut down.
>>
>
> Unless someone is willing to go through every possible failure scenario
> and identify whether such a failure should warrant a shutdown or not
> then there's no way that Radiator can decide.  The safest thing is to
> shutdown on *any* error, otherwise you could end up with a configuration
> that doesn't work the way you expect it to.  I know it's possible to end
> up with the same result even with a "correct" config, but shutting down
> if Radiator can actually detect an error seems by far the safest option
> to me.
>
> If your environment is mission-critical then the answer is to always
> pre-stage your configuration changes in a test environment that matches
> your live environment.  At least that way you can be sure that a simple
> typo isn't going to screw you over.  With the plethora of virtualisation
> solutions that are available these days there isn't really an excuse for
> not building a replica and testing stuff before you try it out.  I'm
> sure that Mike and Hugh etc wouldn't begrudge you using an extra copy of
> radiator beyond your license agreement for this kind of purpose? (we're
> lucky in that we haven't used up our licensed instance allocation)
>
>
>> Also, there is nothing in my log about the error.  The only time i seen
>> the error was on the cli when trying to start radiator back up again.  It
>> would be nice if radiator didn't shut down on error, but if it must, i
>> would think the last line in the log would be why it shut down.
>>
>> I guess since it can't parse the config during the startup, it doesn't
>> know where/how to log, so the best time to log such an error is before it
>> shuts down, while it still has config of where the log file is.
>>
>
> I've generally found that Radiator is exceptional at telling me exactly
> where I've stuffed up a configuration.  Having said that however, I
> generally tend to bump up the log level to max and SIGHUP the server
> before I make any further changes.  Perhaps doing the same might help
> for you?
>
> Cheers,
>
> Martin
>
>
>
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Stopping Radiator: problem with killproc

[Michael]

maybe change your killproc line:
KILLPROC="killproc -p ${RADIUSD_PIDFILE}"

to something like this for debug:
KILLPROC="echo -p ${RADIUSD_PIDFILE}"

then try to kill it, and see what it says for the output for this 
variable.  one thing i can think of is that your pid file location may 
have spaces in it.  or, the pidfile location is wrong.


reply with the output.


Michael



On Fri, 10 Jun 2011, Aeneas Jaißle wrote:


Hi,

I just tried the patched script, no change at all.

# /etc/init.d/radiator stop
Shutting down Radiator: killproc: Usage:
killproc [-v] [-q] [-L] [-g|-G] [-N] [-p pid_file] [I ignore_file] \
[-c root] [-t] [-SIG] /full/path/to/executable
killproc -l

#


OS is openSUSE 11.4, Radiator was installed through RPM.

- Aeneas



-Ursprüngliche Nachricht-
Von: Heikki Vatiainen [mailto:h...@open.com.au]
Gesendet: Freitag, 10. Juni 2011 22:34
An: Aeneas Jaißle
Cc: radiator@open.com.au
Betreff: Re: [RADIATOR] Stopping Radiator: problem with killproc

On 06/10/2011 04:30 PM, Aeneas Jaißle wrote:

Hello Aeneas,


there were some issues while installing and running the radius server
for the first time on an openSUSE server (system was looking for the
scripts in /usr/lib/perl5/site_perl/5.12.3/ instead of
/usr/lib/perl5/site_perl/5.10.0/) and there are still issues with
restarting and stopping the service (handing over arguments to
killproc doesn't work; instead of killing the process it displays the
usage of killproc).


There have been a couple of patches for the init.d script 
goodies/linux-radiator.init. You could try downloading the patches and trying 
the patched init.d script too see if it solves your problem.

Thanks!

--
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server anywhere. 
SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, 
TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, 
RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, 
Windows, MacOSX, Solaris, VMS, NetWare etc.
.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Accessing a reply attribute from one authby in a subsequent authby

[Michael]

you can choose from where to get the attribute value via:
%{Reply:Class}
%{Request:Class}

if you know the value will be in the Reply packet, use %{Reply:Class}.  I 
think the default (if using %Class) is the request packet and may appear 
blank.



On Wed, 29 Jun 2011, Heikki Vatiainen wrote:

> On 06/29/2011 05:49 PM, Bob Shafer wrote:
>
> Hello Bob,
>
>> I would like to do something like this:
>>
>> 
>> AuthByPolicy ContinueWhileAccept
>> 
>> Filename %D/access-users
>> 
>> 
>>  Command %D/scripts/otherauth %T
>>  
>>  
>>
>> where the file access-users contains entries like this:
>>
>>
>> fredClass = Vendor
>> Callback-Number = 1234567890
>> janeClass = User
>>
>> I'd like to pass the reply attributes from the AuthBy File to the AuthBy
>> EXTERNAL script.
>>
>> I'm pretty sure there must be a way to do that, but I haven't figured it
>> out yet.
>
> Here's a quick (ugly?) way to do it:
> Add  between the two AuthBys. The INTERNAL would have a
> small inline RequestHook that adds Callback-Number from the reply to the
> request.
>
> Thanks!
>
> -- 
> Heikki Vatiainen 
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
> NetWare etc.
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] failover SqlDB destinations

[Michael]

Has anyone found any solutions/patches for the sql timeout failover issue with 
radiator?  When radiator executes an sql statement on an sql server that times 
out not on connecting, but the statement itself, radiator disconnects and 
reconnects to the same sql server to try again.  It never seems to failover to 
the next sql destination.  So, having multiple sql sources seems to be 
irrelevant with the issue of statement time outs.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] failover SqlDB destinations

[Michael]

I patched my version of radiator to failover to the next sql source when an sql 
time out error occurs. What I did was:

In 'sub initialize' i added an offset value:
$self->{DBOffset}= 0;

In 'sub reconnect' i add this value to $i of the 'for' for cycling through the 
DBSources:
for ($i = 0 + $self->{DBOffset}; $i < @{$self->{DBSource}}; $i++)

In 'sub prepareAndExecute' right before the 'while' statement which loops the 
number of times the current sql statement will be attempted, I reset this 
offset value to 0.
$self->{DBOffset}=0;

Also in 'sub prepareAndExecute' I changed the timeout detection 'if' statement 
to increment the DBOffset value
if( $@ && $@ =~ /timeout/ ) {
  $reason = "SQL Timeout";
  $self->{DBOffset}++;
}



So the result is, when an sql statement timeout occurs, the DBSource start 
point when re-connecting ($i) is incremented so that the next DBSource is used, 
and hopefully no timeout.  It seems to be working better so far, but an obvious 
undesirable situation arises when the 2nd DBSource is in use, and a timeout 
occurs, DBOffset will be 1, and the $i start point to re-connect, will be the 
same sql server that timed out, and it will have to time out again in order to 
move to the next sql server.

It's not perfect, but this is better for me at this point.






On 11-08-02 10:00 AM, Michael wrote:
>
>
> Has anyone found any solutions/patches for the sql timeout failover issue 
> with radiator?  When radiator executes an sql statement on an sql server that 
> times out not on connecting, but the statement itself, radiator disconnects 
> and reconnects to the same sql server to try again.  It never seems to 
> failover to the next sql destination.  So, having multiple sql sources seems 
> to be irrelevant with the issue of statement time outs.
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] failover SqlDB destinations

[Michael]

On 11-08-09 04:54 AM, Heikki Vatiainen wrote:
> On 08/05/2011 10:19 AM, Heikki Vatiainen wrote:
>
>>> Has anyone found any solutions/patches for the sql timeout failover
>>> issue with radiator?  When radiator executes an sql statement on an
>>> sql server that times out not on connecting, but the statement
>>> itself, radiator disconnects and reconnects to the same sql server to
>>> try again.  It never seems to failover to the next sql destination.
>>
>> Thanks for the problem description and the example code in your other
>> message. I will get back to this once I get the comments from the
>> development team.
>
> Can you provide a patch for this? That would make sure we have your
> version of the fix corretly understood.

I'm still testing/monitoring it to. So far, it will just alternate between the 
first 2 sql sources.  I have 4. I wanted to keep the 1st sql source preferred. 
My patch may not be a desired solution, but here it is:


--- Radiator-4.8+patches/Radius/SqlDb.pm2011-04-27 17:21:51.0 
-0400
+++ Radiator-4.8+patches+custom/Radius/SqlDb.pm 2011-08-11 09:10:50.0 
-0400
@@ -121,6 +121,16 @@ sub initialize
  $self->{SQLRetries} = 2;
  $self->{FailureBackoffTime} = 600; # Seconds
  $self->{DateFormat} = '%b %e, %Y %H:%M'; # eg 'Sep 3, 1995 13:37'
+$self->{DBCur}  = '-'; # keep track of the current (or if 
disconnected, previous) source.
+
+$self->set("ConnectionHook",
+   'sub {
+  my $self = shift;
+  my $dbsource = ( split(/;/,$self->{dbname}) )[0];
+
+ # If an sql connection occurs, log it so we can see it. 
Could use this to find out what sql server was in use, when a failure occurs.
+ $self->log($main::LOG_WARNING, "SQL connected to 
DBSource: ($dbsource) [$self->{Identifier}]");
+ }');
  
  $self->set("ConnectionAttemptFailedHook",
 'sub {
@@ -170,6 +180,12 @@ sub reconnect
$dbsource = &Radius::Util::format_special($dbsource, undef, $self);
$dbusername = &Radius::Util::format_special($dbusername, undef, 
$self);
$dbauth = &Radius::Util::format_special($dbauth, undef, $self);
+
+# since reconnect always starts from the 1st DBSource, never 
reconnect to the 1st DBSource if the current/previous sql server (DBCur) 
matches.
+# this should prevent always retrying the same server if an SQL 
timeout occurs, but the connection to the failing server succeeds.
+next if $self->{DBCur} eq $dbsource;
+$self->{DBCur} = $dbsource;
+
$self->{dbname} = "$dbsource;$dbusername;$dbauth";
return 1
if $Radius::SqlDb::handles{$self->{dbname}};


> There is also the question of possible problems with backwards
> compatibility. Currently Radiator does not advance to the next server if
> there's a timeout with the query. This change would extend the timeout
> behaviour from connections to queries too.
>
> Does anyone see problems with this? Should be made optional? Comments
> would be appreciated.
>
>> Can you tell why the problem occurred? Was the DB server having IO
>> problems? I'm just curious to know how this happens and how frequent the
>> problem might be.

Yes, I think it was I/O problems.  Not always, but a lot of times at 6:25am  
(Debian Lenny), when the daily cron runs.  The timeout issue is not a Radiator 
problem.  It's an os/system/sql problem.  Only thing i was asking about, is if 
radiator should have a different response to an SQL timeout error.  Happens 2-3 
times a day, but sometimes 0.



>
> Michael, do you have any comments on this?
>
>>> So, having multiple sql sources seems to be irrelevant with the issue
>>> of statement time outs.
>>
>> That is currently true.
>
yes, multiple sql sources is an irrelevance for sql timeout issues.  It will 
just constantly re-connect to the first sql source.

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] failover SqlDB destinations

[Michael]

my patch idea has been working for me.  when an sql timeout occurs on the 1st 
dbsource it will skip to the 2nd dbsource.  But, if the sql timeout occurs on 
the 2nd source, rather than try the 3rd source, it starts again with the 1st.  
So, a reoccurring timeout issue will bounce between the 1st source and 2nd 
sources only.

This is good enough for me, but there's probably a better way.  Maybe rotate 
the dbsources instead of trying starting from the 1st source.  But, on the 
other hand, it's also nice to have radiator prefer the 1st db source instead of 
rotating.  I'd rather have radiator prefer the 1st source as I have it 
configured always as 'localhost'.





On 11-08-19 03:46 AM, Heikki Vatiainen wrote:
> On 08/18/2011 03:50 AM, Michael wrote:
>
>> >  I'm still testing/monitoring it to. So far, it will just alternate
>> >  between the first 2 sql sources.  I have 4. I wanted to keep the 1st sql
>> >  source preferred. My patch may not be a desired solution, but here it is:
> Thanks for the patch. If you need to change something or notice
> something that might be of interest, please let us know. We are
> interested to hear how your approach works.
>
> We are considering changes to the error behaviour and as I wrote, also
> thinking about how to do it so that the changes will not negatively
> change existing configurations.
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Memory leak with Radiator?

[Michael]

I noticed an increase of memory usage over time as well on radiusd. Quite a 
long time though, but an increase non-the-less. 10% right now for example. When 
I stop/start the service, it drops and remains at about 0.5% again.  I have 4 
identically synced config servers, where 2 are constantly used, and 2 are not 
(backups). The 2 constantly used are the ones that have the increase of memory. 
The increase of memory is noticeable, but radiator does continue to work very 
well.  Since this doesn't cause issues, it's not really important to me at this 
time, but i just thought i would mention it.

Using MySQL for user authentication data, and auth/accounting logs.

The one thing i would think could cause this is the session db, which i do not 
use.  I have:

 Identifier NULL

And then reference it by "SessionDatabase NULL" in all my Handler's.

My config is quite long as I handle several different services, and multiple 
ways of authenticating so I can't paste my config here.



On 11-09-30 06:44 AM, Heikki Vatiainen wrote:
> On 09/30/2011 10:35 AM, Elias wrote:
>
> Hello Elias,
>
>> We're running RADIATOR with Farms and have noticed that the RADIATOR
>> processes eat up huge chunks of memory. Has anybody else experienced this?
>
> Memory leaks are very rare but certainly possible. Can you reply with
> your configuration (no secrets or passwords needed).
>
> The growing heap size hints this is a problem with dynamically allocated
> memory. Seeing the configuration, the possible hooks and learning more
> about what kind of traffic Radiator handles, would help diagnosing the
> problem.
>
> The pmap output also indicates you are using DBD::Oracle. You may want to
>
> check http://search.cpan.org/~pythian/DBD-Oracle-1.30/
>
> and see if the memory leaks listed in the change log are relevant to
> your configuration.
>
> Thanks!
> Heikki
>
>
>> last pid: 27248;  load avg:  3.88,  3.97,  3.98;   up
>> 196+02:04:57
>> 15:09:23
>> 51 processes: 45 sleeping, 1 zombie, 5 on cpu
>> CPU states: 73.9% idle, 24.1% user,  2.0% kernel,  0.0% iowait,  0.0% swap
>> Memory: 8184M phys mem, 128M free mem, 10G swap, 4851M free swap
>>
>> PID USERNAME LWP PRI NICE  SIZE   RES STATETIMECPU COMMAND
>>   16445 root   1  100 2410M *1393M* sleep  308.1H 84.69% radiusd
>>   16447 root   1  100 2410M *1281M* cpu307.4H 81.52% radiusd
>>   16443 root   1  100 2414M *1312M* cpu308.4H 80.92% radiusd
>>   16446 root   1  100 2398M *1236M* cpu306.9H 79.59% radiusd
>>   16444 root   1  100 2394M *1305M* cpu306.7H 75.31% radiusd
>>
>> The RADIUS services do not crash or anything, but its just that our low
>> memory alert keeps on appearing every week or so. Restarting the
>> RADIATOR daemon gets memory released again.
>>
>>
>>
>>
>> root@radauth01 # pmap 16444
>> 16444:  /usr/bin/perl /opt/radiator/radiusd -config_file
>> /usr/local/etc/radius
>> 0001 960K r-x--  /usr/local/bin/perl
>> 0010E000  48K rwx--  /usr/local/bin/perl
>> 0011A000  24K rwx--[ heap ]
>> 00122944K rwx--[ heap ]
>> *0040 2428928K rwx--[ heap ]*
>> FDA01728K r-x--  /opt/oracle/lib32/libnnz10.so
>> FDBB  56K r-x--  /opt/oracle/lib32/libnnz10.so
>> FDBCC000  16K rwx--  /opt/oracle/lib32/libnnz10.so
>> FDBD 128K rwx--  dev:32,13 ino:1539
>> FDBF   8K rwx--  /opt/oracle/lib32/libnnz10.so
>> FDC0   12288K r-x--  /opt/oracle/lib32/libclntsh.so.10.1
>> FE802752K r-x--  dev:32,13 ino:1627
>> FEAB  56K r-x--  /opt/oracle/lib32/libclntsh.so.10.1
>> FEACC000  16K rwx--  /opt/oracle/lib32/libclntsh.so.10.1
>> FEAD 448K rwx--  dev:32,13 ino:1627
>> FEB4  16K rwx--  dev:32,13 ino:1627
>> FEB44000  56K rwx--  /opt/oracle/lib32/libclntsh.so.10.1
>> FEBF   8K rwx--[ anon ]
>> FEC0  40K r-x--  /usr/local/lib/libgcc_s.so.1
>> FEC18000   8K rwx--  /usr/local/lib/libgcc_s.so.1
>> FEC2  48K r-x--  /usr/lib/libz.so.1
>> FEC3A000  16K rwx--  /usr/lib/libz.so.1
>> FEC5 192K r-x--  /usr/local/lib/mysql/libmysqlclient.so.14.0.0
>> FEC8  32K r-x--  /usr/local/lib/mysql/libmysqlclient.so.14.0.0
>> FEC96000  40K rwx--  /usr/local/lib/mysql/libmysqlclient.so.14.0.0
>> FECA  64K rwx--  dev:32,11 ino:152615
>> FECB  56K rwx--  /usr/local/lib/mysql/libmysqlclient.so.14.0.0
>> FECD  64K r-x--
>> /usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/mysql/mysql.so
>> FECE  32K r-x--
>> /usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/mysql/mysql.so
>> FECF6000  24K rwx--
>> /usr/local/lib/perl5/site_perl/5.8.7/sun4-solaris/auto/DBD/mysql/mysql.so
>> FED1 376K r---R  dev:32,13 ino:1490
>> FED8   8K r-x--  /lib/libmd5.so.1
>> FED92000   8K rwx--  /lib/libmd5.so.1
>> FEDA   8K rwx--[ anon ]
>> FEDB  24K r-x--  /lib/librt.so.1
>> FEDC6000   8K rwx--  /lib/librt.so.1
>> 

Re: [RADIATOR] NoSQL databases support

[Michael]

I use monthly tables for sql accounting.  works good for me.

ie. AccountingTable `acct_%f%g` for the AuthSQL

So, as the month changes, radiator starts to insert into a different table.  Of 
course, you have to have these tables created before the month starts.  A quick 
script and a cron job handles this to make sure the tables are created a few 
months ahead of time.  Also makes it easy to rotate out and archive old data 
(ie. old sql tables).


Michael




On 11-10-17 05:43 AM, Leigh Porter wrote:
> I agree that any SQL solution for storing accounting and logs is somewhat 
> crazy when you get a little busy. We store up to one weeks accounting logs in 
> an SQL database for billing and customer care but all other logs (i.e. data 
> retention for law enforcement) are stored as gzip text files in a 
> hierarchical directory tree on a NFS mount. It makes searching a bit time 
> consuming, but scripts do all the work for us.
>
> I’ll have a look at Mongo though as it would be handy to be able to index say 
> the IP addresses..
>
> --
>
> Leigh Porter
>
> *From:*radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] *On 
> Behalf Of *Mike Puchol
> *Sent:* 17 October 2011 10:17
> *To:* radiator@open.com.au
> *Subject:* [RADIATOR] NoSQL databases support
>
> Greetings,
>
> I have started looking into NoSQL solutions (mentioned in a recent thread) 
> for storage of accounting data & other logging details, as storing them in 
> SQL is wasting space and ending up with huge tables that take eons to sift 
> through.
>
> My choice so far is MongoDB, and here is some info on Perl driver & tools to 
> support it:
>
> http://www.mongodb.org/display/DOCS/Perl+Language+Center
>
> I'd like to share experiences with anyone trying to go this route too.
>
> Cheers,
>
> Mike
>
>
> __
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> __
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] NoSQL databases support

[Michael]

Hi Jim,

I log my accounting directly into MySQL systems.  radiator supports failover 
sql hosts, so you can fail over to multiple sql systems and have these systems 
configured to slave to each other.

But besides that redundancy, radiator also supports the option to fail to a 
file on the local disk if sql activity fails, and that can be imported if the 
time comes.  so, you still don't loose data.

Essentially 2 levels of redundancy. You could use just one, or both.


Michael


On 11-10-18 11:25 AM, Jim Tyrrell wrote:
> I  use MySQL for monthly accounting with approx 100 million rows per
> month and 12 months retention and its very usable, less than 1 second to
> pull back a users records for the month.  I don't have Radiator log
> directly to the MySQL though, I have it log the accounting to a file and
> have a script continually running and importing that file into the
> database which means we don't lose data if the server is offline, or
> impact Radiator performance if the DB has performance issues.
>
> The MySQL log server hardware isn't anything special, so I'm sure you
> could scale to far bigger databases than ours with some decent CPU, RAM
> and storage.
>
> Jim.
>
>
>
> On 17/10/2011 18:35, Michael wrote:
>> I use monthly tables for sql accounting.  works good for me.
>>
>> ie. AccountingTable `acct_%f%g` for the AuthSQL
>>
>> So, as the month changes, radiator starts to insert into a different table.  
>> Of course, you have to have these tables created before the month starts.  A 
>> quick script and a cron job handles this to make sure the tables are created 
>> a few months ahead of time.  Also makes it easy to rotate out and archive 
>> old data (ie. old sql tables).
>>
>>
>> Michael
>>
>>
>>
>>
>> On 11-10-17 05:43 AM, Leigh Porter wrote:
>>> I agree that any SQL solution for storing accounting and logs is somewhat 
>>> crazy when you get a little busy. We store up to one weeks accounting logs 
>>> in an SQL database for billing and customer care but all other logs (i.e. 
>>> data retention for law enforcement) are stored as gzip text files in a 
>>> hierarchical directory tree on a NFS mount. It makes searching a bit time 
>>> consuming, but scripts do all the work for us.
>>>
>>> I’ll have a look at Mongo though as it would be handy to be able to index 
>>> say the IP addresses..
>>>
>>> --
>>>
>>> Leigh Porter
>>>
>>> *From:*radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] 
>>> *On Behalf Of *Mike Puchol
>>> *Sent:* 17 October 2011 10:17
>>> *To:* radiator@open.com.au
>>> *Subject:* [RADIATOR] NoSQL databases support
>>>
>>> Greetings,
>>>
>>> I have started looking into NoSQL solutions (mentioned in a recent thread) 
>>> for storage of accounting data&   other logging details, as storing them in 
>>> SQL is wasting space and ending up with huge tables that take eons to sift 
>>> through.
>>>
>>> My choice so far is MongoDB, and here is some info on Perl driver&   tools 
>>> to support it:
>>>
>>> http://www.mongodb.org/display/DOCS/Perl+Language+Center
>>>
>>> I'd like to share experiences with anyone trying to go this route too.
>>>
>>> Cheers,
>>>
>>> Mike
>>>
>>>
>>> __
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> __
>>>
>>>
>>> ___
>>> radiator mailing list
>>> radiator@open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>> ___
>> radiator mailing list
>> radiator@open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] NoSQL databases support

[Michael]

I think it is being deprecated.  I use it though. If the code gets removed, 
i'll just patch it myself for my purpose.  it's a good idea. it saves the exact 
sql query that failed, rather than the accounting data that would need to be 
parsed separately. one issue I found with it, is that the code uses the sql 
service itself to quote the sql string, so if the sql service is down, it will 
fail to quote the string, therefore fail with the dump to file process.  I 
patched it to still dump the sql string even if the quote query fails. so you 
can simply dump this file into the sql server (mysql db -u user -ppass  I thought that the option to fail to a local file was being deprecated, but 
> looks like I was thinking of SQLRecoveryFile but AcctFailedLogFileName does 
> the job.
>
> The MySQL accounting can add quite a bit of processing to Radiator I believe, 
> so I prefer Radius focus on authentication and accounting for optimal 
> performance. The DB logging can be done as and when. An LNS with 100,000 
> users crashing seems to put quite a bit of load on the Radius servers. :)
>
> Jim.
>
> On 18/10/2011 18:37, Michael wrote:
>>
>> Hi Jim,
>>
>> I log my accounting directly into MySQL systems. radiator supports failover 
>> sql hosts, so you can fail over to multiple sql systems and have these 
>> systems configured to slave to each other.
>>
>> But besides that redundancy, radiator also supports the option to fail to a 
>> file on the local disk if sql activity fails, and that can be imported if 
>> the time comes. so, you still don't loose data.
>>
>> Essentially 2 levels of redundancy. You could use just one, or both.
>>
>>
>> Michael
>>
>>
>> On 11-10-18 11:25 AM, Jim Tyrrell wrote:
>>> I use MySQL for monthly accounting with approx 100 million rows per
>>> month and 12 months retention and its very usable, less than 1 second to
>>> pull back a users records for the month. I don't have Radiator log
>>> directly to the MySQL though, I have it log the accounting to a file and
>>> have a script continually running and importing that file into the
>>> database which means we don't lose data if the server is offline, or
>>> impact Radiator performance if the DB has performance issues.
>>>
>>> The MySQL log server hardware isn't anything special, so I'm sure you
>>> could scale to far bigger databases than ours with some decent CPU, RAM
>>> and storage.
>>>
>>> Jim.
>>>
>>>
>>>
>>> On 17/10/2011 18:35, Michael wrote:
>>>> I use monthly tables for sql accounting. works good for me.
>>>>
>>>> ie. AccountingTable `acct_%f%g` for the AuthSQL
>>>>
>>>> So, as the month changes, radiator starts to insert into a different 
>>>> table. Of course, you have to have these tables created before the month 
>>>> starts. A quick script and a cron job handles this to make sure the tables 
>>>> are created a few months ahead of time. Also makes it easy to rotate out 
>>>> and archive old data (ie. old sql tables).
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>>
>>>> On 11-10-17 05:43 AM, Leigh Porter wrote:
>>>>> I agree that any SQL solution for storing accounting and logs is somewhat 
>>>>> crazy when you get a little busy. We store up to one weeks accounting 
>>>>> logs in an SQL database for billing and customer care but all other logs 
>>>>> (i.e. data retention for law enforcement) are stored as gzip text files 
>>>>> in a hierarchical directory tree on a NFS mount. It makes searching a bit 
>>>>> time consuming, but scripts do all the work for us.
>>>>>
>>>>> I’ll have a look at Mongo though as it would be handy to be able to index 
>>>>> say the IP addresses..
>>>>>
>>>>> --
>>>>>
>>>>> Leigh Porter
>>>>>
>>>>> *From:*radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] 
>>>>> *On Behalf Of *Mike Puchol
>>>>> *Sent:* 17 October 2011 10:17
>>>>> *To:* radiator@open.com.au
>>>>> *Subject:* [RADIATOR] NoSQL databases support
>>>>>
>>>>> Greetings,
>>>>>
>>>>> I have started looking into NoSQL solutions (mentioned in a recent 
>>>>> thread) for storage of accounting data& other logging details, as sto

[RADIATOR] and AuthColumnDef

[Michael]

For , does anyone know if sql returned values from AuthSelect and 
configured as 'request' with AuthColumnDef are suppose to be added to the 
request packet if the authentication fails?  It does add if success, but 
doesn't seem to add values to the request packet if it fails.  I don't see the 
answer to that question in the docs section bellow.


Michael



5.29.9

AuthColumnDef

This optional parameter allows you to change the way Radiator interprets the 
result of
the AuthSelect statement. If you don’t specify any AuthColumnDef parameters, 
Radia-
tor will assume that the first column returned is the password; the second is 
the check
items (if any) and the third is the reply items (if any). If you specify any 
AuthColumn-
Def parameters, Radiator will use the column definitions you provide.

You can specify any number of AuthColumnDef parameters, one for each interesting
field returned by AuthSelect. The general format is:

AuthColumnDef n, attributename, type

• n is the index of the field in the result of AuthSelect. 0 is the first field.

• attributename is the name of the attribute to be checked or replied. The 
value of the
attribute is in the nth field of the result. The special attributename 
‘GENERIC’ indi-
cates that it is a list of comma separated attribute=value pairs.

• type indicates whether it is a check or reply item. A type of ‘request’ sets 
the named
attribute in the incoming request, from where it can be retrieved later in the 
authenti-
cation process with special formatting characters.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] SqlDb.pm - sql server failover.

[Michael]

In SqlDb.pm sub do{} should a mysql syntax error also be reason NOT to 
disconnect/reconnect from/to the mysql server?

 # Primary key violation is not a cause for disconnection.
 # Also SQL syntax error.
 return $rc if defined $rc
   || $reason =~ /error in your SQL syntax/i
   || $reason =~ /violation/i
   || $reason =~ /duplicate key/im
   || $reason =~ /Duplicate entry/im
   || $reason =~ /^ORA-1/;


Michael
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SqlDb.pm - sql server failover.

[Michael]

It happened for me when a customer logged in with a ' in their username.  the 
mysql insert for the AuthLog of course didn't like that. i didn't originally 
use the the sql quoted special characters in my insert statement.  I am using 
those special characters now though.  Not too crucial of an issue, i just 
thought i'd mention it.



On 11-11-10 05:31 PM, Heikki Vatiainen wrote:
> On 11/10/2011 08:15 PM, Michael wrote:
>> In SqlDb.pm sub do{} should a mysql syntax error also be reason NOT to 
>> disconnect/reconnect from/to the mysql server?
>
> Hmm, good question. If it does not mask a real problem, then probably yes.
>
> Isn't this something that happens with an incorrect configuration or can
> these errors happen during the normal operation. If so, what would be
> the reason for this?
>
> It would be useful to know why this happens before adding it.
>
> Thanks!
>
>>   # Primary key violation is not a cause for disconnection.
>>   # Also SQL syntax error.
>>   return $rc if defined $rc
>> || $reason =~ /error in your SQL syntax/i
>> || $reason =~ /violation/i
>> || $reason =~ /duplicate key/im
>> || $reason =~ /Duplicate entry/im
>> || $reason =~ /^ORA-1/;
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Could not connect to SQL database

[Michael]

The incoming request is coming from a 10. network, and your mysql server is on 
an 192 network.  is your network configuration setup properly for this to work? 
ie. your system/router knows how to get to the 192 network?  Do you use a 
firewall/iptables?

try ronald.higgins suggestion first. can you connect manually to the sql server:
mysql DB -u username -p[password] -h dbhostname


On 11-11-15 09:45 AM, Nuno Marques wrote:
> Hello,
>
> I’m trying to store accounting into a SQL daba-base and I’m getting this 
> error:
>
> **
>
> *Tue Nov 15 14:19:32 2011: ERR: Could not connect to SQL database with 
> DBI->connect dbi:mysql:Accounting:192.168.69.222, , :*
>
> *Tue Nov 15 14:19:32 2011: ERR: Could not connect to any SQL database. 
> Request is ignored. Backing off for 600 seconds*
>
> **
>
> Radiator doesn’t even try to reach the data-base IP address (sniffed the 
> traffic to confirm this).
>
> I’ve no idea what’s wrong, all looks fine. Any help is greatly appreciated.
>
> Thanks in advance,
>
> Nuno Marques
>
> **
>
> *radius.cfg:***
>
> LogDir /var/log/radius
>
> DbDir /etc/radiator/
>
> Trace 4
>
> AuthPort 1812
>
> AcctPort 1813
>
> 
>
> Secret 
>
> 
>
> 
>
> Identifier PEAP_IAS
>
> Secret xxx
>
> AuthPort 1812
>
> AcctPort 1813
>
> Retries 3
>
> SSLeayTrace 4
>
> Host ubidc1.ubi.pt
>
> 
>
> 
>
> Identifier SQLAccounting
>
> DBSource dbi:mysql:Accounting:192.168.69.222
>
> DBUsername 
>
> DBAuth x
>
> IgnoreAuthentication
>
> AuthSelect
>
> AccountingTable Accounting-table
>
> HandleAcctStatusTypes Start,Stop
>
> #Just putting something into the DB
>
> AcctColumnDef Nome, User-Name
>
> 
>
> 
>
> AuthByPolicy ContinueAlways
>
> AuthBy SQLAccounting
>
> AuthBy PEAP_IAS
>
> 
>
> *_Logfile:_**__*
>
> Tue Nov 15 14:19:32 2011: ERR: Attribute number 1 (vendor 52) is not defined 
> in your dictionary
>
> Tue Nov 15 14:19:32 2011: DEBUG: Packet dump:
>
> *** Received from 10.240.1.1 port 20009 
>
> Code: Accounting-Request
>
> Identifier: 15
>
> Authentic: <<235><173>x<164><226>d<193><171><168>0<239>)<240>g&
>
> Attributes:
>
> Acct-Status-Type = Stop
>
> Acct-Authentic = RADIUS
>
> Acct-Multi-Session-Id = "SESS-63907-d2d8d0-365628-402"
>
> Acct-Session-Id = "SESS-63907-d2d8d0-365628-402"
>
> User-Name = "xxx...@ubi.pt"
>
> Event-Timestamp = 1321366775
>
> Calling-Station-Id = "00-1C-BF-72-63-92"
>
> NAS-Port-Id = "AP7/1"
>
> Called-Station-Id = "00-11-88-D2-D9-62:RAD-Test"
>
> NAS-Port = 185
>
> Framed-IP-Address = 192.168.228.121
>
> Class = 
> "l<127><6>F<0><0><1>7<0><1><2><0><192><168>d<1><0><0><0><0><0><0><0><0><0><0><0><0><1><204><159><178><6>2n<159><0><0><0><0><0><18><155>-"
>
> Acct-Session-Time = 1146
>
> Acct-Output-Octets = 1349445
>
> Acct-Input-Octets = 1925391
>
> Acct-Output-Packets = 3538
>
> Acct-Input-Packets = 13777
>
> NAS-Port-Type = Wireless-IEEE-802-11
>
> NAS-IP-Address = 10.240.1.1
>
> NAS-Identifier = "enterasys"
>
> Acct-Delay-Time = 0
>
> Tue Nov 15 14:19:32 2011: DEBUG: Handling request with Handler 
> 'Realm=/ubi.pt/i', Identifier ''
>
> Tue Nov 15 14:19:32 2011: DEBUG: Deleting session for nmarq...@ubi.pt, 
> 10.240.1.1, 185
>
> Tue Nov 15 14:19:32 2011: DEBUG: Handling with Radius::AuthSQL: SQLAccounting
>
> Tue Nov 15 14:19:32 2011: DEBUG: Handling accounting with Radius::AuthSQL
>
> *Tue Nov 15 14:19:32 2011: ERR: Could not connect to SQL database with 
> DBI->connect dbi:mysql:Accounting:192.168.69.222, , :*
>
> *Tue Nov 15 14:19:32 2011: ERR: Could not connect to any SQL database. 
> Request is ignored. Backing off for 600 seconds*
>
> Tue Nov 15 14:19:32 2011: DEBUG: do query is: 'insert into Accounting-table 
> (Nome) values ()':
>
> Tue Nov 15 14:19:32 2011: DEBUG: AuthBy SQL result: IGNORE, Database failure
>
> Tue Nov 15 14:19:32 2011: DEBUG: Handling with Radius::AuthRADIUS
>
> Tue Nov 15 14:19:32 2011: DEBUG: Packet dump:
>
>
> 
--
>
> UBI amiga do ambiente: Antes de imprimir este e-mail pense bem se tem mesmo 
> que o fazer. As árvores sã

[RADIATOR] Timestamp attribute

[Michael]

The Timestamp attribute as per radiator docs is the system time when packet is 
received, adjusted by ACCT_DELAY_TIME to give a more accurate time for which 
the event happened.  Radiator seems to add this attribute in the Handler.pm:


 if ($p->code eq 'Accounting-Request')
 {
 # Add a pseudo attribute for the Timestamp
 # (adjusted by Delay-Time)
 # Some modules (AuthSQL) and logfile scripts rely on it
 $p->change_attr('Timestamp',
  $p->{RecvTime}
  - int $p->getAttrByNum($Radius::Radius::ACCT_DELAY_TIME));

Two issues I had were:
1. Since this Timestamp attr is added in the Handler processing, special 
characters such as %f and %g which reference the timestamp are not available 
with any processing that happens before the Handler.
2. Since it is only added to 'Accounting-Request', special characters such as 
%f and %g are not available at all for the AuthLog processing since it is a 
time when an 'Authentication-Request' is being processed.

These issues for me were easily resolved by adding the Timestamp with a 
ClientHook for all packets, but I thought i would mention it for consideration 
of adding the Timestamp sooner, and possibly for auth and acct packets.



Michael
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] PreClientHook

[Michael]

Radiator docs seem to suggest a PreClientHook is a global parameter that will 
apply to all connections to radiator but when I add this as a global option i 
get:

Thu Dec  1 15:31:49 2011: ERR: Unknown keyword 'PreClientHook' in 
/etc/radius.cfg line 10

I this suppose to be added as a global option?
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] PreClientHook

[Michael]

I tried a copy and paste of that and it worked.  I retried the hook i wanted to 
apply originally, which was still in my clipboard history and that worked.  
Can't be a typo since it's clipboard history.  I can't make it fail.  But 
looking in my console history it looks like i had first tried to put a 
PreClientHook in a  clause and forgot it was there.  So, radiator was 
complaining about that one.

My mistake, sorry.



On 11-12-01 05:29 PM, Heikki Vatiainen wrote:
> On 12/01/2011 09:27 PM, Michael wrote:
>
>> Radiator docs seem to suggest a PreClientHook is a global parameter that 
>> will apply to all connections to radiator but when I add this as a global 
>> option i get:
>>
>> Thu Dec  1 15:31:49 2011: ERR: Unknown keyword 'PreClientHook' in 
>> /etc/radius.cfg line 10
>>
>> I this suppose to be added as a global option?
>
> Hmm, I just tried with a config that had this as the first line:
>
> PreClientHook  sub { print "Here I am in PreClientHook\n"; }
>
> This is an example from Radiator radius.cfg in the distribution directory.
>
> It worked and I think it's been available for a long time.
>
> Heikki
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Missing attributes

[Michael]

Isn't AuthSelect used for authentication queries in ?  not 
accounting inserts?  Aren't you suppose to be using a combination of 
AccountingTable and AcctColumnDef or use AcctSQLStatement?

I use both ways, for different purposes. be aware i use some of my own custom 
attributes, ie %{uid} and %{zone}, but you get the idea.
eg1:
 AccountingTable `acct_%f%g`
 AcctColumnDef   `submitted_un`,%u,formatted
 AcctColumnDef   `timestamp`,%b,formatted
 AcctColumnDef   `sess_id`,Acct-Session-Id
 AcctColumnDef   `sess_time`,Acct-Session-Time
 AcctColumnDef   `term_cause`,Acct-Terminate-Cause
 AcctColumnDef   `nas_ip_address`,NAS-IP-Address
 AcctColumnDef   `nas_id`,NAS-Identifier
 AcctColumnDef   `ip_address`,Framed-IP-Address


eg2:
 AcctSQLStatement INSERT INTO whoison (timestamp, submitted_un, 
auth_un, uid, zone, ip_address, sess_id, \
 extended_sess_id, sess_svr_key, service, nas_ip_address, \
 upload, up_octets, up_giga, download, down_octets, \
 down_giga, last_updated, sess_time, nas_id, nas_port, device, 
card, port, vlan) \
 VALUES (%b-%{Acct-Session-Time}, 
'%u','%{auth-un}','%{uid}','%{zone}','%{Framed-IP-Address}','%{Acct-Session-Id}',
 \
 '%{extended-sess-id}', 
'%{Ascend-Session-Svr-Key}','%{service}','%{NAS-IP-Address}', \
 '%{total-input-octets}', '%{Acct-Input-Octets}', 
'%{Acct-Input-Gigawords}', '%{total-output-octets}', '%{Acct-Output-Octets}', \
 

Michael




On 11-12-07 06:47 AM, Heinrich Mislik wrote:
> On 7 Dec 2011 at 9:15, Hugh Irvine wrote:
>
>>>>> Hi, most of our NAS devices include Acct-Output-Gigawords in
>> their accounting requests, so we store it in our SQL database using
>> an AuthSelect parameter with the
>> %{IntegerValue:Acct-Output-Gigawords} syntax. But, we have a few
>> devices that do not include it. So every time the AuthSelect is run
>> in that case, we get this error in the log:
>>>>>
>>>>> ERR: There is no value named  for attribute
>> Acct-Input-Gigawords. Using 0.
>>>>>
>>>>> I would request that either this be reduced in severity from
>> error, or provide the opportunity to specify a default setting (e.g.
>> %{IntegerValue:Acct-Input-Gigawords|0} where 0 is the default in
>> case it's not present.) We did the former in our installation
>> because it was easy, but the latter would probably be more useful.
>>>>>
>>>>> Or, if there's already a way to deal with this I'd love to hear
>> it. Thanks.
>
> I would try:
>
> AddToRequestIfNotExist Acct-Input-Gigawords=0
>
> Cheers
>
> Heinrich
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Missing attributes

[Michael]

Maybe i wasn't clear ether.  I was suggesting that there's something else 
wrong. I use Gigawords and have a nas with old IOS and doesn't send the 
attribute. But if the attribute isn't there, radiator is fine with it.  It 
doesn't show an error.  You shouldn't have to use AddToRequestIfNotExist.

Did the original email for this thread not show using AuthSelect for inserting 
accounting records?  as far as i was aware, that is wrong.


Michael



On 11-12-07 08:42 AM, Heinrich Mislik wrote:
> Hi,
>
> Maybe I was not clear enough. The line
>
>  AddToRequestIfNotExist Acct-Input-Gigawords=0
>
> should be added to the  section and is processed long before
> any. It just makes sure, that "Acct-Input-Gigawords" exists
> in any request (either with it's original value or 0). This should
> not do no harm with Access-Reqests and avoid error messages when
> using %{Acct-Input-Gigawords} during accounting.
>
> Hope this helps.
>
> Heinrich
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AuthBy SQL Reject or Accept in the SQL results

[Michael]

I use a reject column in my user database, and SELECT it like this:
SELECT username, crypt, CONCAT('Reject:',reject), 

and:
AuthColumnDef   2, Auth-Type, check

so, if the reject column is NULL, CONCAT returns NULL and it passed, but if the 
reject column has text in it, CONCAT returns 'Reject:reject reason', and the 
user is rejected.




On 12-02-08 12:40 PM, Lee Solway wrote:
> Is there a way I can set an access Accept or Reject in the MySQL results
> generated by AuthBy SQL?
>
> Currently I have a stored procedure that I call in the following.. I
> would like the SP to be able to reject the Access-Request with an error
> message also if possible..
>
>  AuthSelectCALL get_reply_attr('%U')
>  AuthColumnDef 0, GENERIC, reply
>  AuthColumnDef 1, User-Password, check
>
> Thanks,
> Lee
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator's database handle

[Michael]

I hate to answer a question with another question, but what, why and/or when 
are you writing data to the sql?  I write data to sql but I do it through any 
combination of  , and sometimes an AuthBy SessionDB.  
Works much better for me.  I try to avoid custom hooks if at all possible.  The 
ability for hooks is great to have, but if Radiator can already do a task just 
through config, i try to do it that way instead of a hook.

So, if you want to write something to a table for example ever time a user 
authenticates, use an , a SuccessQuery, and "LogSuccess  1".
if you want to write something when stop packets come in, use , 
with "HandleAcctStatusTypes   Stop", and a AcctSQLStatement.

depends on what you need to do.


On 12-02-16 09:17 AM, Alby wrote:
> Hi all,
> I'm using radiator with a SQL database that stores the users' data. I've also 
> a PostAuthHook that writes some data on the SQL database. Up to now my Hook 
> connects to the database, writes the data and then disconnects. I suspect 
> that connecting and disconnecting each time I write to the database is not a 
> really good idea (expecially for the performance). I've noticed that Radiator 
> opens the connection to the database only the first time, then reuses it 
> (this is of course a better way than mine). Since the database that I write 
> is the same that I use on Radiator (same name, same user and same password), 
> is there a way to reuse the Radiator's DB handle instead of creating a new 
> one and destroying it each time?
> At at first glance, my idea was to open the database connection with a 
> StartUpHook and then close with a ShutdownHook, but there is the problem on 
> how to share the DB handle between the three Hooks. This should be made 
> securely, because if an attacker is able to obtain the handler, it will be 
> able to read and write the database without performing authentication first, 
> I think. In my opinion reusing the Radiator DB handle is the best solution if 
> it can be implemented.
> Thank you very much in advance for your help and for your attention
> Alberto
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator's database handle

[Michael]

sounds like you may be trying to do something that is pretty complex.  maybe 
you should be thinking about creating your own custom Auth Clause. section 17.0 
in the Radiator manual. For example, i've created my own Auth Clause 
(AuthUNIX_UID) to support the UID value from unix password files as it was 
required for my purpose.  The normal AuthUNIX doesn't do anything with UIDs.



On 12-02-16 09:55 AM, Alby wrote:
> Hi Michael,
> thank you for your answer!
> I agree with you, if you can do what you need with Radiator's configuration, 
> of course it is a better way to operate. But I need to implement a sort of 
> Self-Provisioning  procedure. When a new user tries to authenticate, I first 
> let Radiator rejects the request (because the user does not have an account 
> on the system). But then I check if the user satisfies with some 
> prerequisites (e.g. a special password used and some more). If so, I create 
> an account for the new user (and write the SQL database from my PostAuthHook) 
> and then notify it of the account creation, for example by mail. Up to now, I 
> use a PostAuthHook script to do that. It works very well, the only matter is 
> about the performance when writing to the database because I connect and 
> disconnect each time. I've tried to do it in other ways, but without any 
> success, since up to now this seems to be the best solution.
> Cheers,
> Alberto
>
> Il giorno 16 febbraio 2012 15:32, Michael  <mailto:ri...@vianet.ca>> ha scritto:
>
> I hate to answer a question with another question, but what, why and/or 
> when are you writing data to the sql?  I write data to sql but I do it 
> through any combination of  , and sometimes an 
> AuthBy SessionDB.  Works much better for me.  I try to avoid custom hooks if 
> at all possible.  The ability for hooks is great to have, but if Radiator can 
> already do a task just through config, i try to do it that way instead of a 
> hook.
>
> So, if you want to write something to a table for example ever time a 
> user authenticates, use an , a SuccessQuery, and "LogSuccess  
> 1".
> if you want to write something when stop packets come in, use  SQL>, with "HandleAcctStatusTypes   Stop", and a AcctSQLStatement.
>
> depends on what you need to do.
>
>
>
> On 12-02-16 09:17 AM, Alby wrote:
>
> Hi all,
> I'm using radiator with a SQL database that stores the users' data. 
> I've also a PostAuthHook that writes some data on the SQL database. Up to now 
> my Hook connects to the database, writes the data and then disconnects. I 
> suspect that connecting and disconnecting each time I write to the database 
> is not a really good idea (expecially for the performance). I've noticed that 
> Radiator opens the connection to the database only the first time, then 
> reuses it (this is of course a better way than mine). Since the database that 
> I write is the same that I use on Radiator (same name, same user and same 
> password), is there a way to reuse the Radiator's DB handle instead of 
> creating a new one and destroying it each time?
> At at first glance, my idea was to open the database connection with 
> a StartUpHook and then close with a ShutdownHook, but there is the problem on 
> how to share the DB handle between the three Hooks. This should be made 
> securely, because if an attacker is able to obtain the handler, it will be 
> able to read and write the database without performing authentication first, 
> I think. In my opinion reusing the Radiator DB handle is the best solution if 
> it can be implemented.
> Thank you very much in advance for your help and for your attention
> Alberto
>
>
> _
> radiator mailing list
> radiator@open.com.au <mailto:radiator@open.com.au>
> http://www.open.com.au/__mailman/listinfo/radiator 
> <http://www.open.com.au/mailman/listinfo/radiator>
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator's database handle

[Michael]

maybe this may help spark some ideas:
- check normal auth.
- if pass, done and accept.
- if fail, continue to a second auth that checks only a password.
- if fail, done and reject.
- but if password only passes, send to another handler which does something.



 # auth policy set to continue only if the auth fails.
 AuthByPolicyContinueWhileReject

 AuthLog NORMAL_ATUH_LOG

 # a normal username/password test
 
 ...
 

 # due to policy, this is only done if previous failed.
 
 # policy changed
 AuthByPolicyContinueWhileAccept

 # authby to check a DEFAULT account and check password only.
 
 ...

AuthSelect  SELECT username, crypt, ... FROM table 
WHERE BINARY username='DEFAULT'

 AuthColumnDef   1, Encrypted-Password, check
 AuthColumnDef   2, ...
 ...
 

 # due to AuthByPolicy only pass to another handler if previous 
auth passes.
 
 HandlerId "call another handler"
 
 








On 12-02-16 02:38 PM, Michael wrote:
> sounds like you may be trying to do something that is pretty complex.  maybe 
> you should be thinking about creating your own custom Auth Clause. section 
> 17.0 in the Radiator manual. For example, i've created my own Auth Clause 
> (AuthUNIX_UID) to support the UID value from unix password files as it was 
> required for my purpose.  The normal AuthUNIX doesn't do anything with UIDs.
>
>
>
> On 12-02-16 09:55 AM, Alby wrote:
>> Hi Michael,
>> thank you for your answer!
>> I agree with you, if you can do what you need with Radiator's configuration, 
>> of course it is a better way to operate. But I need to implement a sort of 
>> Self-Provisioning  procedure. When a new user tries to authenticate, I first 
>> let Radiator rejects the request (because the user does not have an account 
>> on the system). But then I check if the user satisfies with some 
>> prerequisites (e.g. a special password used and some more). If so, I create 
>> an account for the new user (and write the SQL database from my 
>> PostAuthHook) and then notify it of the account creation, for example by 
>> mail. Up to now, I use a PostAuthHook script to do that. It works very well, 
>> the only matter is about the performance when writing to the database 
>> because I connect and disconnect each time. I've tried to do it in other 
>> ways, but without any success, since up to now this seems to be the best 
>> solution.
>> Cheers,
>> Alberto
>>
>> Il giorno 16 febbraio 2012 15:32, 
>> Michaelmailto:ri...@vianet.ca>>  ha scritto:
>>
>>  I hate to answer a question with another question, but what, why and/or 
>> when are you writing data to the sql?  I write data to sql but I do it 
>> through any combination of  , and sometimes an 
>> AuthBy SessionDB.  Works much better for me.  I try to avoid custom hooks if 
>> at all possible.  The ability for hooks is great to have, but if Radiator 
>> can already do a task just through config, i try to do it that way instead 
>> of a hook.
>>
>>  So, if you want to write something to a table for example ever time a 
>> user authenticates, use an, a SuccessQuery, and "LogSuccess  
>> 1".
>>  if you want to write something when stop packets come in, use> SQL>, with "HandleAcctStatusTypes   Stop", and a AcctSQLStatement.
>>
>>  depends on what you need to do.
>>
>>
>>
>>  On 12-02-16 09:17 AM, Alby wrote:
>>
>>  Hi all,
>>  I'm using radiator with a SQL database that stores the users' data. 
>> I've also a PostAuthHook that writes some data on the SQL database. Up to 
>> now my Hook connects to the database, writes the data and then disconnects. 
>> I suspect that connecting and disconnecting each time I write to the 
>> database is not a really good idea (expecially for the performance). I've 
>> noticed that Radiator opens the connection to the database only the first 
>> time, then reuses it (this is of course a better way than mine). Since the 
>> database that I write is the same that I use on Radiator (same name, same 
>> user and same password), is there a way to reuse the Radiator's DB handle 
>> instead of creating a new one and destroying it each time?
>>  At at first glance, my idea was to open the database connection 
>> with a StartUpHook and then clos

Re: [RADIATOR] PreClientHook not behaving as expected

[Michael]

The PreClientHook is a hook that is run before the packet is unpacked.


Caution: At the time this hook is run, integer attributes have not yet been 
unpacked and
decoded, and encrypted attributes have not yet been decrypted. If you need 
unpacked,
decrypted versions of these attributes, consider using a per-client ClientHook 
instead.



On 12-02-27 01:45 PM, Bruno Tiago Rodrigues wrote:
> This looks like a basic question, but I haven't been able to sort it out.
>
> Basically I have a structure of Radiator AuthBy and Handlers set for
> Accounting and needed to filter out some "special" packets being sent
> to the server.
>
> I've done this with a specific hook, pointed it to a ClientHook clause
> and had it running as expected. Then I moved it to a PreClientHook
> clause and it didn't work properly.
>
> This is happening when I peek at the Acct-Status-Type for the request
> packet, I managed to narrow it down to a specific bit of code, but I
> found out by dumping the packet structure that there are other fields
> showing up garbled.
>
> When called from a PreClientHook, Data::Dumper on the request packet
> shows a bunch of entries like this
>   'Attributes' =>  [
> [
>   'Acct-Status-Type',
>   '^@^@^@^C'
> ],
> [
>   'NAS-IP-Address',
>   'S3'
> ],
> [
>   'User-Name',
>   '00:14:7f:eb:36:4b'
> ],
> [
>   'Framed-IP-Address',
>   'S5'
> ],
> [
>   'Framed-IP-Netmask',
>   '<80>'
> ],
> [
>   'NAS-Identifier',
>   'test01nas'
> ],
> [
>   'Acct-Session-Id',
>
> '23@2/1/1:2999@10.0.0.234@00:14:7f:eb:36:4b@0_2012/02/27 17:05:23'
> ],
> [
>   'Acct-Session-Time',
>   '^@^@^U<89>'
> ],
>
>
> There are some entries that show up as expected (ie, not garbled).
> When called from a ClientHook, the Data::Dumper show the expected
> (plaintext ASCII) value for all fields of the same packet.
>
> Is this normal?
>
> The code is fairly simple, I narrowed it down to something like
>
> sub {
>  my $r = ${$_[0]};
>  return unless $r->code() eq 'Accounting-Request';
>
>  my $acct_type=$r->get_attr('Acct-Status-Type');
>
>  &main::log($main::LOG_INFO,"Caught Accounting $acct_type packet");
>  return;
> }
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Idle timeout issue

[Michael]

maybe need Idle-Timeout = 0 in your authentication accept reply packet?

eg. AddToReplyIfNotExist Idle-Timeout = 0


On 12-04-18 09:24 PM, Jennings Tuala wrote:
> Hi Mike,
>
> I have tried again this time with laptop on continuously, not going to sleep 
> and it still cuts out the connection. I have pasted my radius.cfg for your 
> perusal.
>
> LogDir   /var/log/radius
>
> DbDir /etc/radiator
>
> # Use a low trace level in production systems. Increase
>
> # it to 4 or 5 for debugging, or use the -trace flag to radiusd
>
> Trace 4
>
> AuthPort 1812
>
> AcctPort 1813
>
> # You will probably want to add other Clients to suit your site,
>
> # one for each NAS you want to work with
>
> 
>
>  Secret   xxx
>
>  DupInterval 0
>
> 
>
> 
>
>  Secret  xxx
>
>  AuthPort 1182
>
>  AcctPort 1183
>
>  DupInterval 0
>
> 
>
> 
>
>  DBSource dbi:mysql:bluezone
>
>  DBUsername root
>
>  DBAuth xxxyyyzzz
>
> AddQuery insert into SUBSCRIBERS (USERNAME, \
>
> NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP, \
>
> FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE, DNIS)
>
> values ('%n', '%N', \
>
> %{NAS-Port}, �%{Acct-Session-Id}�, %{Timestamp},\
>
> �%{Framed-IP-Address}�, �%{NAS-Port-Type}�, \
>
> �%{Service-Type}�, �%{Called-Station-Id}�)
>
> 
>
> 
>
> 
>
>  DBSource dbi:mysql:bluezone
>
>  DBUsername root
>
>  DBAuth  xxxyyyzzz
>
>  # Only one Session per user at a time
>
>  DefaultSimultaneousUse 1
>
>  # Let the user IN if they have any time 
> left, set
>
>  # the Session-Timeout to the time left
>
>  AuthSelect select PASSWORD, SESSIONTIMEOUT 
> from SUBSCRIBERS where USERNAME=%0 and SESSIONTIMEOUT > 0
>
>  AuthColumnDef 0, User-Password, check
>
>  AuthColumnDef 1, Session-Timeout, reply
>
>  # Adjust the time left when they log out
>
>  AccountingStopsOnly
>
>  AcctSQLStatement update SUBSCRIBERS set 
> SESSIONTIMEOUT=SESSIONTIMEOUT-0%{Acct-Session-Time} where USERNAME='%n'
>
>  AccountingTable SUBSCRIBERS
>
> 
>
> 
>
> Thanks and look forward to your response.
>
> Cheers,
>
> Jennings
>
> *From:*Mike Puchol [mailto:puc...@me.com ]
> *Sent:* Saturday, 14 April 2012 2:42 AM
> *To:* Jennings Tuala
> *Cc:* radiator@open.com.au 
> *Subject:* Re: [RADIATOR] Idle timeout issue
>
> Acct terminate cause is User-Request, meaning the hotspot received a session 
> end instruction from the device, eg. logoff URL, or a disassociation which 
> the hotspot translates as User-Request (eg. laptop going to sleep). There is 
> no Session-Timeout or Idle-Timeout in the logs that would correspond to what 
> you describe.
>
>
> On Apr 13, 2012, at 3:26 PM, Jennings Tuala  > wrote:
>
> Hi there,
>
> I’m having some issues with idle timeouts in radiator. Users are suddenly 
> being disconnected after say 25 minutes of inactivity. This never used to 
> happen before so I attached a trace 4 debug for you to have a look at. Would 
> greatly appreciate your assistance please.
>
> Thanks,
>
> Jay
>
> Tue Apr 10 15:48:32 2012: DEBUG: Packet dump:
>
> *** Received from 110.5.112.85 port 32817 
>
> Code:   Access-Request
>
> Identifier: 29
>
> Authentic: <137><202><239><165><163>W<22><229>Xfg<168>&<144><174><216>
>
> Attributes:
>
>  User-Name = "6100510"
>
>  User-Password = 
> @[<4>=<161><221><154>u<141><0><143><5><1><165>_<250>
>
>  NAS-IP-Address = 110.5.112.85
>
>  Service-Type = Login-User
>
>  Framed-IP-Address = 10.17.4.212
>
>  Called-Station-Id = "00:90:0B:05:6B:14"
>
>  Calling-Station-Id = "38:59:f9:80:c8:5d"
>
>  NAS-Identifier = "110.5.112.85"
>
>  Acct-Session-Id = "00:90:0B:05:6B:14:13341172017"
>
>  NAS-Port-Type = Wireless-IEEE-802-11
>
> Tue Apr 10 15:48:32 2012: DEBUG: Handling request with Handler '', 
> Identifier ''
>
> Tue Apr 10 15:48:32 2012: DEBUG:  Deleting session for 6100510, 
> 110.5.112.85,
>
> Tue Apr 10 15:48:32 2012: DEBUG: do query is: 'delete from RADONLINE 
> where NASIDENTIFIER='110.5.112.85' and NASPORT=0':
>
> Tue Apr 10 15:48:32 2012: DEBUG: Handling with Radius::AuthSQL:
>
> Tue Apr 10 15:48:32 2012: DEBUG: Handling with Radius::AuthSQL:
>
> Tue Apr 10 15:48:32 2012: DEBUG: Query is: 'select PASSWORD, 
> SESSIONTIMEOUT from SUBSCR

Re: [RADIATOR] AuthBy SQL - multiple rows/attributes

[Michael]

I seem to remember reading somewhere in the Radiator manual that it will only 
process the first sql row received therefore I don't think it will process 
multiple row results.  I can't seem to find in the manual where i read that 
though. On the other hand, you could have all reply values on the same row in 
the table, or create an sql statement that returns them all on one row.

What is your sql table structure?  multiple tables?

mike


On 12-06-25 08:52 AM, Jim Tyrrell wrote:
> Hi,
>
> Is it possible for AuthBy SQL to return multiple attributes if the query
> returns multiple rows?
>
> I am currently using AuthBy SQL to return a Tunnel-Endpoint to a LAC
> with the following simplified config:
>
> 
>   DBSourcedbi:mysql:databasename:192.168.10.3
>   DBUsername  DBuser
>   DBAuth  DBPass
>   AuthSelect SELECT Endpoint, Password FROM endpoints
>   AuthColumnDef   0,Tunnel-Server-Endpoint,reply
>   AuthColumnDef   1,Tunnel-Password,reply
> 
>
> This works fine at the moment as I only have 1 row in the table which
> represents 1 endpoint.  But I now want to return multiple endpoints so
> the Access-Accept would be something along the lines of:
>
> Code:   Access-Accept
> Attributes:
>   Tunnel-Server-Endpoint = 172.16.1.1
>   Tunnel-Password = "tunnelpass"
>   Tunnel-Server-Endpoint = 172.16.1.2
>   Tunnel-Password = "tunnelpass2"
>
> I had hoped to just add a 2nd row to the table, but the handler just
> returns the values from the 1st row of the result.  I'd like to be able
> to return additional attributes for each row returned so I can easily
> add/remove more endpoints to the table as and when I need to.
>
> Thanks.
>
> Jim.
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AuthBy SQL - multiple rows/attributes

[Michael]

you could use GENERIC like how Heikki suggested but still have separate rows in 
your sql and use SQL to join all the results, and apply the attribute names.  
For MySQL, group_concat:



mysql> select * from temp;
+++-+
| id | Server | Password|
+++-+
|  5 | 172.16.1.1 | tunnelpass1 |
|  6 | 172.16.1.2 | tunnelpass2 |
|  7 | 172.16.1.3 | tunnelpass3 |
+++-+
3 rows in set (0.00 sec)

mysql> select GROUP_CONCAT( CONCAT('Tunnel-Server-Endpoint=',Server )) AS 
Servers, GROUP_CONCAT( CONCAT('Tunnel-Server-Endpoint=', Password)) AS 
Passwords from temp order by id;
+---+--+
| Servers   
| Passwords 
   |
+---+--+
| 
Tunnel-Server-Endpoint=172.16.1.1,Tunnel-Server-Endpoint=172.16.1.2,Tunnel-Server-Endpoint=172.16.1.3
 | 
Tunnel-Server-Endpoint=tunnelpass1,Tunnel-Server-Endpoint=tunnelpass2,Tunnel-Server-Endpoint=tunnelpass3
 |
+---+--+
1 row in set (0.00 sec)


Michael





On 12-06-26 07:33 AM, Heikki Vatiainen wrote:
> On 06/26/2012 12:28 PM, Jim Tyrrell wrote:
>> At the moment I just have a single very simple table that I am testing
>> with, 2 columns 'Endpoint'&  'Password' with 2 rows in the table for 2
>> different Tunnel endpoints.
>
> How about changing the config to use GENERIC:
>
> AuthColumnDef   0,GENERIC,reply
> AuthColumnDef   1,GENERIC,reply
>
> The DB would then have Endpoint and Password columns with values like these:
>
> Endpoint column for row n:
> Tunnel-Server-Endpoint=172.16.1.1,Tunnel-Server-Endpoint=172.16.1.2
> Password column for row n:
> Tunnel-Password="tunnelpass1",Tunnel-Password="tunnelpass2"
>
> With GENERIC you could actually put all reply attributes into the same
> column but that would likely make maintaining the values harder.
>
> With Hugh's solution you could get rid of repeating the attribute names
> and storing just the values.
>
> Heikki
>
>
>> I could have multiple columns for the multiple tunnels, but then if I
>> wanted to add or remove tunnels I would need to update the Radiator
>> query each time to add/remove the extra AuthAttrDefs, but I'd like the
>> flexibility to just add/remove entries to the SQL table without having
>> to change the Radiator config.
>>
>> ie - if I have one tunnel in the table then the handler needs to return:
>>
>> Code:   Access-Accept
>> Tunnel-Server-Endpoint = 172.16.1.1
>> Tunnel-Password = "tunnelpass"
>>
>> And if an extra entry is added to the table then return the following
>> format:
>>
>> Code:   Access-Accept
>> Tunnel-Server-Endpoint = 172.16.1.1
>> Tunnel-Password = "tunnelpass"
>> Tunnel-Server-Endpoint = 172.16.1.2
>> Tunnel-Password = "tunnelpass2"
>>
>>
>> If I was able to use LDAP I could just have an object such as:
>>
>> uid=TunnelEndPoints
>> tunnelip=172.16.0.1
>> tunnelip=172.16.0.2
>> tunnelpass=blah1
>> tunnelpass=blah2
>>
>> And then use an AuthBy LDAP including the following:
>>
>>   AuthAttrDef tunnelip,Tunnel-Server-Endpoint,reply
>>   AuthAttrDef tunnelpass,Tunnel-Password,reply
>>
>>
>> Is there not an equivalent of this for MySQL authentication?  How do
>> people store multiple attributes such as Framed-Route in MySQL and then
>> return multiple instances of this when they exist? (The examples above
>> would actually be returned as tagged attributes but I can worry about
>> that later).
>>
>> Thanks.
>>
>> Jim.
>>
>>
>> On 25/06/2012 18:05, Michael wrote:
>>>
>>> I seem to remember reading somewhere in the Radiator manual that it
>>> will only process the first sql row received therefore I do

Re: [RADIATOR] Multi-Line Handler issues with 4.10

[Michael]

I also have really complex config files and Handlers and putting things on 
multiple lines does help to keep things neat.  Hopefully this can be fixed, 
although i guess it's not a pressing issue to upgrade so no need to rush.


On 12-07-02 05:22 PM, Heikki Vatiainen wrote:
> On 07/02/2012 09:47 PM, Aaron Holtz wrote:
>
>> Hello - I've noticed with 4.10 that you can no longer have multi-line
>> Handler statements.
>
> Thanks for reporting this. There were changes between 4.9 and 4.10
> related to parsing hooks and I think this may be what caused the problem
> you are seeing.
>
>> Under 4.9 something like this loads properly:
>>
>> > 563974|4445690321|3335774198)/, CHAP-Password=/[\w]+/>
>>
>> Under 4.10 I'm getting:
>>
>> Sun Jul  1 13:27:43 2012: ERR: Unknown keyword '> /etc/raddb/test.cfg line 6
>
> Yes, I can reproduce this took.
>
>> Is this a bug?  We have a fairly complex config file with several
>> multi-line handlers and upgrading to 4.10 isn't going to be possible
>> without having some seriously long Handler statements.
>
> If you can wait a little with upgrading I will get back to this later
> this week.
>
> Thanks,
> Heikki
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Multi-Line Handler issues with 4.10

[Michael]

i found some time to try the 4.10 upgrade with patches, but i have this 
Multi-Line config issue.  Seems to be related to the fact that I have a blank 
line and comments in the middle of the multi line Handler.



Fri Aug 10 10:51:18 2012: ERR: Unknown keyword '

 Identifier handler_null
 SessionDatabase NULL
 AuthBy AuthBy_REJECT





On 12-07-06 05:57 AM, Heikki Vatiainen wrote:
> On 07/03/2012 12:22 AM, Heikki Vatiainen wrote:
>
>> If you can wait a little with upgrading I will get back to this later
>> this week.
>
> Patches for 4.10 now restore the functionality while keeping the
> originally planned multiline change working. Please let us know if there
> are still problems.
>
> Thanks,
> Heikki
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Multi-Line Handler issues with 4.10

[Michael]

i had to make a couple changes for my config to parse properly.
1. move the "ignore blank lines and lines beginning with a hash" process before 
appending to the $line variable.
2. ignore blank lines including lines with whitespace (next if $_ =~ /^\s*$/;)




--- 
/usr/src/radiator/4.10/Radiator-4.10+patches+vianet_custom/Radius/Configurable.pm
   2012-08-09 10:59:18.0 -0400
+++ 
/etc/radiator/src/radiator-v4.10+patches+vianet_custom/share/perl/5.8.8/Radius/Configurable.pm
  2012-08-10 12:23:11.0 -0400
@@ -162,16 +162,17 @@ sub parse
  {
  #  print "parsing for $self: $_\n"; # test
  
+   # Ignore blank lines and lines beginning with hash
+   next if $_ =~ /^\s*$/;
+   next if $_ =~ /^\s*#/;
+
 $line .= $_;
 next if ($line =~ s/\\$//); # Line continuation
+
 # Strip leading and trailing white space
 $line =~ s/^\s*//;
 $line =~ s/\s*$//;
  
-   # Ignore blank lines and lines beginning with hash
-   next if $line eq '';
-   $line = '', next if $line =~ /^#/;
-
 # Look for  to end the object definition
 last if ($line =~ /^<\/([^>]*)>/);
  






On 12-08-10 11:07 AM, Michael wrote:
> i found some time to try the 4.10 upgrade with patches, but i have this 
> Multi-Line config issue.  Seems to be related to the fact that I have a blank 
> line and comments in the middle of the multi line Handler.
>
>
>
> Fri Aug 10 10:51:18 2012: ERR: Unknown keyword ' /etc/radiator/conf/handler.pre-defined line 3
> Fri Aug 10 10:51:18 2012: ERR: Unknown keyword 'Request-Type' in 
> /etc/radiator/conf/handler.pre-defined line 6
>
>
>
># failed auth attempts many times a day. used to reject a username.
>
>   Request-Type = Access-Request, \
>   User-Name = DISABLED>
>
>   Identifier handler_null
>   SessionDatabase NULL
>   AuthBy AuthBy_REJECT
> 
>
>
>
>
> On 12-07-06 05:57 AM, Heikki Vatiainen wrote:
>> On 07/03/2012 12:22 AM, Heikki Vatiainen wrote:
>>
>>> If you can wait a little with upgrading I will get back to this later
>>> this week.
>>
>> Patches for 4.10 now restore the functionality while keeping the
>> originally planned multiline change working. Please let us know if there
>> are still problems.
>>
>> Thanks,
>> Heikki
>>
>>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Multi-Line Handler issues with 4.10

[Michael]

abused? the last version said multiple lines was fine.  Hasn't been a problem 
until 4.10.  It more has to do with the vast configuration that I have (452K so 
far) and i organize my config like this a lot and don't feel like rearranging 
it all right now.

I patched the code myself.  works fine now and i can use 4.10 without changing 
my current config. My request can be ignored.


Michael


On 12-08-11 09:05 AM, alan buxey wrote:
> Hi,
>
>> i found some time to try the 4.10 upgrade with patches, but i have this 
>> Multi-Line config issue.  Seems to be related to the fact that I have a 
>> blank line and comments in the middle of the multi line Handler.
>>
>>
>>
>> Fri Aug 10 10:51:18 2012: ERR: Unknown keyword '> /etc/radiator/conf/handler.pre-defined line 3
>> Fri Aug 10 10:51:18 2012: ERR: Unknown keyword 'Request-Type' in 
>> /etc/radiator/conf/handler.pre-defined line 6
>>
>>
>>
>> >  # failed auth attempts many times a day. used to reject a username.
>>
>>   Request-Type = Access-Request, \
>>   User-Name = DISABLED>
>>
>>   Identifier handler_null
>>   SessionDatabase NULL
>>   AuthBy AuthBy_REJECT
>> 
>
> there comes a point when a configuration parser is being abusedwhy dont 
> you simply have
>
>
> # failed auth attempts many times a day. used to reject a username.
> 
>Identifier handler_null
>SessionDatabase NULL
>AuthBy AuthBy_REJECT
> 
>
> ??
>
> this is how the docs say you write handlers - and its the way that any 
> auto-export config
> generator tool could output the config (I generate my RADIATOR configuration 
> from an SQL
> database).  instead, you have devised a rather wierd local requirement - and 
> then suggest
> some code changes to allow this to be read that could mess up peoples 
> legitimate configurations.
>
> alan
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Multi-Line Handler issues with 4.10

[Michael]

why i want to is besides the point.  Because, I don't actually want to really.  
it's a matter of it already being done.   It must be within the standard specs 
of the parser i guess, since it's always worked before and the docs probably 
said you could do it.  But don't worry about it.  i patched it myself. I will 
maintain this patch for myself and for future versions.

Thanks.


On 12-08-13 05:02 AM, alan buxey wrote:
> Hi,
>> abused? the last version said multiple lines was fine.  Hasn't been a 
>> problem until 4.10.  It more has to do with the vast configuration that I 
>> have (452K so far) and i organize my config like this a lot and don't feel 
>> like rearranging it all right now.
>
> my config is 708K - its when it reached 300k that I decided that I'd keep the 
> format
> tight and within the standard specs of the parser.  I can see what your patch 
> does...but I still
> cannot see why you'd want to break the handler line up like that...should 
> anyone take over your role
> I'm sure they wouldnt like to inherit that.
>
> (and every line you read in is an extra bit of work for the config parser to 
> do)
>
> alan
>
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Multi-Line Handler issues with 4.10

[Michael]

yep, correct.  The multi-line config support was broken in 4.10 then partially 
fixed with then patch-set.


A couple points of interest for the fix though, that i have changed for myself. 
 This is my own personal opinion and may not be agreed with anyone else:

Ignoring commented lines in config should probably include leading white space 
so people can indent their comments if they want.
-   next if $line =~ /^#/;
+   next if $line =~ /^\s*#/;

Blank lines should be ignored, and should also include whitespace for blank 
lines that actually have spaces, or tabs on them because you can't see them.  
best to just ignore.
-   next if $line eq '';
+   next if $line =~ /^\s*$/;



Also, the ($line eq '') will never equal a blank line because a blank line has 
a carriage return and line feed values on it that you don't actually see.  a 
blank line has an 0x0A and 0x0D hex characters i think at the end of the line.
So this line:
next if $line eq '';
wont work, but this line:
next if $line =~ m/^$/;
will.


The order of these i also changed.  Ignore blank and commented lines i would 
think should be first before anything.


On 12-08-13 11:30 AM, alan buxey wrote:
> Hi,
>
>> why i want to is besides the point.  Because, I don't actually want to 
>> really.  it's a matter of it already being done.   It must be within the 
>> standard specs of the parser i guess, since it's always worked before and 
>> the docs probably said you could do it.  But don't worry about it.  i 
>> patched it myself. I will maintain this patch for myself and for future 
>> versions.
>
> I seem to recall that there was a change which also broke
> multi-line configs (ie those with just the \ at the end...) which
> was then fixed as part of the patch-set.  Obviously this also
> affected the way your configuration was also read in.
>
> alan
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Change of Authorization

[Michael]

This was the hardest thing to get working and automated for me 
personally.  I don't know if there is an easy way of doing it.  I didn't 
find one.  I accomplished it with a complicated process.  It could be as 
simple as a script to execute "./radpwtst -s IP -code 
Change-Filter-Request etc."


My complicated process goes something like the following, but I would 
suggest making sure the above simple method works for you as I do have a 
couple nas's where CoA just doesn't work with the IOS that it has.

- a script process that injects Change-Filter-Request packets into the 
radiator service, using radpwtst:
  push( @change_args, (
 '-s', 'local radiator ip',
 '-code', 'Change-Filter-Request',
 "Timestamp=$timestamp",
 "NAS-IP-Address=$nas_ip",
 "NAS-Port=$nas_port",
 "Acct-Session-Id=$sess_id",
 "Framed-IP-Address=$ip",
 "Class=$class",
 "cisco-Policy-Up=$rate_up",
 "cisco-Policy-Down=$rate_down"
 )

- a Handler with custom Hook configured to read the cisco-Policy rate 
values from the injected packet, and look up the proper policy command 
from a radiator global variable depending on the nas-ip-address since I 
have multiple nas's that require different commands.
eg. global variable:
DefineFormattedGlobalVar 1.2.3.4-RATE100M-up
ip:sub-qos-policy-in=RATE100M
DefineFormattedGlobalVar 1.2.3.4-RATE100M-down 
ip:sub-qos-policy-out=RATE100M

- add 2 "cisco-avpair" attributes to the packet with the up rate and 
down rate commands.  These are the actual commands the NAS needs to 
change the rate limit.  The policy must already be setup on your nas.
ie:
cisco-avpair="ip:sub-qos-policy-in=RATE100M"
cisco-avpair="ip:sub-qos-policy-out=RATE100M"

- then a custom authby that required patching to determine what nas to 
forward the packet to, since i have multiple nas's. Also another authby 
that logs this request which is not required but i wanted to log it.


There's much more to it, but I don't want to get too deep here.  it all 
pretty much revolves around building the Change-Filter-Request packet 
with "./radpwtst -code Change-Filter-Request" and ether send that to the 
nas, or inject it into radiator so you can do other things with it.


Michael


On 15/10/12 12:47 PM, rohan.he...@cwjamaica.com wrote:
> Hello all,
>
> I do not see any info on the captioned in the Radiator documentation. Where 
> do I go to see details on implementing COA?
>
> Thanks.
>
> Rohan
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] verifying online sessions with SNMP

[Michael]

I'm having some issues with verifying online session with the 
DefaultSimultaneousUse option.  I keep seeing that sessions are "gone 
away".  Messages in the log such as:
Thu Nov  1 04:45:41 2012: INFO: Session 0196B6A4 for username at 
0.0.0.0: has gone away

But, the sessions where NOT "gone away" and should have been counted, 
and this login request should have been rejected.  I found out by 
manually running the snmp query that the snmp query is not working:
# /usr/bin/snmpget -c "x" 0.0.0.0 
iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905
iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905: 
Unknown Object Identifier 
(org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905)

I see in the snmpget routine in Radius/SNMP.pm, the error checking 
doesn't seem to include this error.  Should it be added:

 my $result = `$command`;
 if ($result =~ /error/i || $result =~ /no response/i || $result =~ 
/timeout/i || $result =~ /Unknown Object Identifier/ )
 {



After changing this myself, i can now see the problem in the logs:
Thu Nov  1 12:08:06 2012: ERR: The command '/usr/bin/snmpget -c "" 
0.0.0.0 
iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905 
2>&1' failed with an error: 
iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905: 
Unknown Object Identifier 
(org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905)

Now i see i have an snmpget problem.



Michael
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Accounting records are not written to database

[Michael]

Looks like your "AuthBy xDSL" is accepting, therefore since the default 
AuthByPolicy is ContinueWhileIgnore, it will stop at the xDSL authby and 
the "AuthBy SQLAccounting" is not processed.


I personally handle accounting in a separate handler.  To me, handling 
accounting and authorization in the same handler is tricky.




Michael




On 01/11/12 05:07 PM, rohan.he...@cwjamaica.com wrote:

Hugh,

Config and logs attached.


And the application crashed when testing Simultaneous-Use for both 
configurations below.

In my AuthBy config:
"DefaultSimultaneousUse 1" With "AuthAttrDef 
Simultaneous-Use,Simultaneous-Use,check"

Or

In my Handler:
MaxSessions 1



On Fri, 2 Nov 2012 07:19:09 +1100
  Hugh Irvine  wrote:

Hello Rohan -

We will need to see the configuration file (no secrets) together with a trace 4 
debug showing what is happening.

regards

Hugh


On 2 Nov 2012, at 05:53,  wrote:


Hello,

Why doesn't the following work?


Identifier SQLAccounting
DBSource dbi:mysql:inetdb_test
DBUsername inet
DBAuth inet@inetdb
#Disable SQL authentication
AuthSelect
HandleAcctStatusTypes Start,Stop
AccountingTable ARCH_ACCOUNTING
AcctColumnDef USER_NAME,User-Name
AcctColumnDef ACCT_START_TIME,Timestamp,integer
AcctColumnDef ACCT_STOP_TIME,Timestamp,integer
AcctColumnDef ACCT_STATUS_TYPE,Acct-Status-Type,integer
AcctColumnDef ACCT_DELAY_TIME,Acct-Delay-Time,integer
AcctColumnDef ACCT_INPUT_OCTETS,Acct-Input-Octets,integer
AcctColumnDef ACCT_OUTPUT_OCTETS,Acct-Output-Octets,integer
AcctColumnDef ACCT_SESSION_ID,Acct-Session-Id
AcctColumnDef ACCT_SESSION_TIME,Acct-Session-Time,integer
AcctColumnDef ACCT_TERMINATE_CAUSE,Acct-Terminate-Cause,integer
AcctColumnDef FRAMED_IP_ADDRESS,Framed-IP-Address
AcctColumnDef NAS_IDENTIFIER,NAS-Identifier
AcctColumnDef NAS_PORT,NAS-Port,integer
AcctColumnDef CALLED_STATION_ID,Called-Station-Id
AcctColumnDef CALLING_STATION_ID,Calling-Station-Id
SQLRecoveryFile %L/sqlaccounting.sql


Specifying the following in my Handler does not work. I don't even see any 
trace in my logs set at level 4 or 5.
AuthBy SQLAccounting

However my sessions database work with the following.
SessionDatabase SQLSDB

Thanks much.

Regards,
Rohan
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc.
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.


Rohan Henry
Server Administrator
LIME
Phone (876) 936-4819
Mobile (876) 997-0729


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] verifying online sessions with SNMP

[Michael]

I see my snmp problem is due to missing MIBs, and Radiator has switched 
to numerical snmp queries in the latest version/patch set:

2012-09-25 :
 Updated all Nas/*.pm modules to use numeric OIDs instead of 
sysmbolic, since some recent versions of snmp tools install without MIBs.

Guess someone may still want to add the error detection though.



On 01/11/12 02:07 PM, Michael wrote:
> I'm having some issues with verifying online session with the
> DefaultSimultaneousUse option.  I keep seeing that sessions are "gone
> away".  Messages in the log such as:
> Thu Nov  1 04:45:41 2012: INFO: Session 0196B6A4 for username at
> 0.0.0.0: has gone away
>
> But, the sessions where NOT "gone away" and should have been counted,
> and this login request should have been rejected.  I found out by
> manually running the snmp query that the snmp query is not working:
> # /usr/bin/snmpget -c "x" 0.0.0.0
> iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905
> iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905:
> Unknown Object Identifier
> (org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905)
>
> I see in the snmpget routine in Radius/SNMP.pm, the error checking
> doesn't seem to include this error.  Should it be added:
> 
>   my $result = `$command`;
>   if ($result =~ /error/i || $result =~ /no response/i || $result =~
> /timeout/i || $result =~ /Unknown Object Identifier/ )
>   {
> 
>
>
> After changing this myself, i can now see the problem in the logs:
> Thu Nov  1 12:08:06 2012: ERR: The command '/usr/bin/snmpget -c ""
> 0.0.0.0
> iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905
> 2>&1' failed with an error:
> iso.org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905:
> Unknown Object Identifier
> (org.dod.internet.private.enterprises.9.9.150.1.1.3.1.2.26740905)
>
> Now i see i have an snmpget problem.
>
>
>
> Michael
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator does not wait for RADIUS requests

[Michael]

and if the secret is wrong, i'm pretty sure it will show the connection 
in the debug logs.


On 06/11/12 02:38 PM, alan buxey wrote:
> Hi,
>> I entered the correct password.
> did you? All I have seen you say so far is that you used
>
>
> perl radpwtst -user mikem -password fred -auth_port 1812 -trace 4
>
>
> wheres the shared secret for the client to talk to the RADIUS server?
> radpwst emulates a NAS rather than a real client edge device - so it needs
> to have a shared secret
>
> radpwtst -h
>
>
>
> alan
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SessionDB::RADONLINE::Deletion Failing

[Michael]

5.10.4
DeleteQuery
This SQL statement is executed whenever a user session finishes (i.e. 
when an Account-
ing-Request Stop message is received). It is expected to remove the 
details of the ses-
sion from the SQL database. Special formatting characters may be used. 
%0 is replaced
by the quoted user name to be deleted, %1 by the NAS IP address, %2 by 
the NAS-Port,
%3 by the SQL quoted Acct-Session-Id. If DeleteQuery is defined as an 
empty string,

then the query will not be executed.


On 13/11/12 02:15 PM, ronald higgins wrote:


Hi User List,

I need a bit of an assist. I'm having an issue with sessions being 
deleted from RADONLINE when a stop record comes in.


This is the pertinent bit in the conf:

##


Identifier SessionDB

DBSourcedbi:mysql:radius:XXX.XXX.XXX.XXX:3306
DBUsername  radius
DBAuth  DB_PASSWORD

Timeout 5



Pretty basic and standard now.

##

This is the Trace 4 in the log file for the Start and the Stop:

##
Start:

Tue Nov 13 18:51:25 2012: DEBUG: do query is: 'delete from RADONLINE 
where NASIDENTIFIER='196.X.X.X' and NASPORT=01929707729':
Tue Nov 13 18:51:25 2012: DEBUG: do query is: 'insert into RADONLINE 
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP, 
FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE) values ('ADSL_USERNAME', 
'196.X.X.X', 1929707729, '7/0/3/5.209_16FBD22C', 1352825485, 
'ADSL_IP', 'Virtual', 'Framed-User')':


It's quite happily inserting the record.

##
Stop:

Tue Nov 13 20:46:27 2012: DEBUG: do query to 'DB_CONNECTION_STRING': 
'delete from RADONLINE where NASIDENTIFIER='196.X.X.X' and 
NASPORT=01929707729':
Tue Nov 13 20:46:27 2012: ERR: do failed for 'delete from RADONLINE 
where NASIDENTIFIER='196.X.X.X' and NASPORT=01929707729': MySQL server 
has gone away


Not so happy on the Stop record, Stops always seem to produce the 
"MySQL server has gone away".


##


If i log into mysql and delete the query as it's posted in the logs it 
deletes just fine...


mysql> delete from RADONLINE where NASIDENTIFIER='196.X.X.X' and 
NASPORT=01929707729;

Query OK, 1 row affected (0.00 sec)


It's Radiator 4.10, running on Centos 5.3 and Perl version 5.8.8



Any thoughts?

Regards

Ronald


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SessionDB::RADONLINE::Deletion Failing

[Michael]

I don't think that delete statement you are seeing is actually a delete 
statement to delete the session from your sql table.  It is a delete 
statement to help make sure duplicates don't happen in the table.  So, 
you should probably specify the proper delete statement as per the 
manual section 5.10.4



On 13/11/12 02:34 PM, Michael wrote:

5.10.4
DeleteQuery
This SQL statement is executed whenever a user session finishes (i.e. 
when an Account-
ing-Request Stop message is received). It is expected to remove the 
details of the ses-
sion from the SQL database. Special formatting characters may be used. 
%0 is replaced
by the quoted user name to be deleted, %1 by the NAS IP address, %2 by 
the NAS-Port,
%3 by the SQL quoted Acct-Session-Id. If DeleteQuery is defined as an 
empty string,

then the query will not be executed.


On 13/11/12 02:15 PM, ronald higgins wrote:


Hi User List,

I need a bit of an assist. I'm having an issue with sessions being 
deleted from RADONLINE when a stop record comes in.


This is the pertinent bit in the conf:

##


Identifier SessionDB

DBSourcedbi:mysql:radius:XXX.XXX.XXX.XXX:3306
DBUsername  radius
DBAuth  DB_PASSWORD

Timeout 5



Pretty basic and standard now.

##

This is the Trace 4 in the log file for the Start and the Stop:

##
Start:

Tue Nov 13 18:51:25 2012: DEBUG: do query is: 'delete from RADONLINE 
where NASIDENTIFIER='196.X.X.X' and NASPORT=01929707729':
Tue Nov 13 18:51:25 2012: DEBUG: do query is: 'insert into RADONLINE 
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP, 
FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE) values ('ADSL_USERNAME', 
'196.X.X.X', 1929707729, '7/0/3/5.209_16FBD22C', 1352825485, 
'ADSL_IP', 'Virtual', 'Framed-User')':


It's quite happily inserting the record.

##
Stop:

Tue Nov 13 20:46:27 2012: DEBUG: do query to 'DB_CONNECTION_STRING': 
'delete from RADONLINE where NASIDENTIFIER='196.X.X.X' and 
NASPORT=01929707729':
Tue Nov 13 20:46:27 2012: ERR: do failed for 'delete from RADONLINE 
where NASIDENTIFIER='196.X.X.X' and NASPORT=01929707729': MySQL 
server has gone away


Not so happy on the Stop record, Stops always seem to produce the 
"MySQL server has gone away".


##


If i log into mysql and delete the query as it's posted in the logs 
it deletes just fine...


mysql> delete from RADONLINE where NASIDENTIFIER='196.X.X.X' and 
NASPORT=01929707729;

Query OK, 1 row affected (0.00 sec)


It's Radiator 4.10, running on Centos 5.3 and Perl version 5.8.8



Any thoughts?

Regards

Ronald


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator



___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Michael]

looks like your first AuthBy SQL is answering accept.  is this maybe 
because you don't have any 'check' options at all?  Then if accept, 
never process the AuthBy FILE because of ContunueWhileIgnore.


For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:


Hello,

I'm trying to Backoff an SQL query to my database whenever a timeout 
happened.  I have the next configuration in my radius_auth.cfg :




RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSource
dbi:mysql:prueba:127.0.0.1:3306 


DBUsername  radius

DBAuth  radiator

Timeout 2

FailureBackoffTime  60

SQLRetries  2

NoDefault

AuthSelect call DELAYREQ;

AuthColumnDef 0, SIP-AVP, reply





Filename /usr/src/Radiator-4.9/users_tranum







The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return 
a column.


This is the log for a Request to this Handler:

Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

User-Name = "sip:557100050994@10.0.0.86 
"


Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82 
"


Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86 
"


NAS-Port = 0

NAS-IP-Address = 10.0.0.82

Mon Nov 19 16:03:33 2012: DEBUG: Handling request with Handler 
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', 
Identifier ''


Mon Nov 19 16:03:33 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:03:33 2012: DEBUG:  Deleting session for 
sip:557100050994@10.0.0.86 , 
10.0.0.82, 0


Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthGROUP:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Query is: 'call DELAYREQ;':

(2 seconds delay)

Mon Nov 19 16:03:35 2012: ERR: getOneRow timed out

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL looks for match with 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL ACCEPT: : 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthGROUP:  result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: AuthBy GROUP result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:03:35 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 36336 

Code:   Access-Accept

Identifier: 96

Authentic:  M,<1><152><137><23>?<135><233>IA<137>-<14><30><11>

Attributes:

SIP-AVP = "avion"

I was expecting if the DB take too much time to answer it failover to 
the second AuthBy.  Maybe I'm doing something wrong?


Can someone help me here?

Regards,

Ricardo.-



___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Michael]

I think you would have to query a 2nd time within 60 seconds in order to 
see the BackOff in the log.



On 19/11/12 02:44 PM, Ricardo Martinez wrote:


Hello Michael.

I have modified the AuthByPolicy fro mContinueWhileIgnore for

And now it jumps to the second AuthBy, but is not marking the DB as 
fail (and therefor doing the Backooff Time), this is the log.


What I’m doing wrong?

Mon Nov 19 16:41:05 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 34896 

Code:   Access-Request

Identifier: 112

Authentic: <31><23>t<202><197><247>5<185><138><147><198>*<22><184><216>x

Attributes:

User-Name = "sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>"


Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82 
<mailto:sip%3A0212345678@10.0.0.82>"


Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>"


NAS-Port = 0

NAS-IP-Address = 10.0.0.82

Mon Nov 19 16:41:05 2012: DEBUG: Handling request with Handler 
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', 
Identifier 'AuthFailover'


Mon Nov 19 16:41:05 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:41:05 2012: DEBUG:  Deleting session for 
sip:557100050994@10.0.0.86 <mailto:sip%3A557100050994@10.0.0.86>, 
10.0.0.82, 0


Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:07 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:09 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL looks for match with 
sip:557100050994 [sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>]


Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL REJECT: No such user: 
sip:557100050994 [sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>]


Mon Nov 19 16:41:09 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:11 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:13 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:13 2012: DEBUG: AuthBy SQL result: REJECT, No such user

Mon Nov 19 16:41:13 2012: DEBUG: Handling with Radius::AuthFILE:

Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE looks for match with 
sip:557100050994 [sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>]


Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE ACCEPT: : 
sip:557100050994 [sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>]


Mon Nov 19 16:41:13 2012: DEBUG: AuthBy FILE result: ACCEPT,

Mon Nov 19 16:41:13 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:41:13 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 34896 

Code:   Access-Accept

Identifier: 112

Authentic:  @<165><188><181>;<242>-<251><184><200>q<174>`<239><24>k

Attributes:

SIP-AVP = "tranum:sip:0212345678@10.0.0.82 
<mailto:tranum%3Asip%3A0212345678@10.0.0.82>"


SIP-AVP = "channels:1"

Thanks,
Ricardo.-

*De:*Michael [mailto:ri...@vianet.ca <mailto:ri...@vianet.ca>]
*Enviado el:* lunes, 19 de noviembre de 2012 16:28
*Para:* Ricardo Martinez
*CC:* radiator@open.com.au <mailto:radiator@open.com.au>
*Asunto:* Re: [RADIATOR] SQL Timeout

looks like your first AuthBy SQL is answering accept.  is this maybe 
because you don't have any 'check' options at all?  Then if accept, 
never process the AuthBy FILE because of ContunueWhileIgnore.


For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:

Hello,

I’m trying to Backoff an SQL query to my database whenever a timeout 
happened.  I have the next configuration in my radius_auth.cfg :




RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSource
dbi:mysql:prueba:127.0.0.1:3306 <http://127.0.0.1:3306>


DBUsername  radius

DBAuth  radiator

Timeout 2

FailureBackoffTime  60

SQLRetries  2

NoDefault

AuthSelect call DELAYREQ;

AuthColumnDef 0, SIP-AVP, reply





Filename /usr/src/Radiator-4.9/us

Re: [RADIATOR] SQL Timeout

[Michael]

I see this query timeout issue quite often.  I have a 4 system sql 
replication ring though, so it just moves onto the next one and keeps 
humming.  not sure what's causing the timeout though.

On 20/11/12 04:33 PM, Heikki Vatiainen wrote:
> On 11/20/2012 02:27 PM, Ricardo Martinez wrote:
>> Is there a way to mark the DB SQL as down in the configuration file, maybe
>> with a PostHook? Or something like that?
> Currently DB query timeout can not be trapped with a hook. Have you had
> problems with the DB timing out queries while still allowing connections?
>
> I'd like to know how common this problem is.
>
> Thanks,
> Heikki
>
>
>> Regards,
>> Ricardo.-
>>
>> -Mensaje original-
>> De: Ricardo Martinez [mailto:rmarti...@redvoiss.net]
>> Enviado el: lunes, 19 de noviembre de 2012 18:50
>> Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
>> Asunto: RE: [RADIATOR] SQL Timeout
>>
>> There is also other post about the same issue :
>>
>> http://www.open.com.au/pipermail/radiator/2011-April/017237.html
>>
>>
>>
>> -Mensaje original-
>> De: Ricardo Martinez [mailto:rmarti...@redvoiss.net] Enviado el: lunes, 19
>> de noviembre de 2012 18:36
>> Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
>> Asunto: RE: [RADIATOR] SQL Timeout
>>
>> Is there another more safe way to do the BackOff.  What I'm trying to do
>> is when a SQLquery is Timeout by Radiator mark the server as "down" and do
>> the next AuthBy Clause.
>> I saw a pair of question about the same issue near 2002 :
>> http://www.open.com.au/pipermail/radiator/2002-October/005289.html
>>
>> Please help me here.
>>
>> I'm using :
>> Radiator 4.9
>> perl, v5.10.1 (*) built for x86_64-linux-thread-multi DBI : 1 .622
>> DBD:mysql  4.022
>>
>> Regards,
>> Ricardo.-
>>
>>
>> -Mensaje original-
>> De: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] En
>> nombre de Heikki Vatiainen Enviado el: lunes, 19 de noviembre de 2012
>> 18:21
>> Para: radiator@open.com.au
>> Asunto: Re: [RADIATOR] SQL Timeout
>>
>> On 11/19/2012 10:47 PM, Ricardo Martinez wrote:
>>
>>> Question : When it says ".Radiator will wait for when trying to
>>> contact the SQL server." this means that a */select/* is a CONTACT???
>> Hello Ricardo,
>>
>> there is a contact before the select. The contact succeeds but the
>> subsequent query (DELYREQ) times out. Since it was the query that returned
>> error and not the contact just before it, FailureBackoffTime is not
>> triggered.
>>
>>> So, I don't understand why the Radiator is not doing the Backoff.
>> If you make the DB contact to block, for example using iptables to drop
>> traffic destined to the DB, it will then time out the connection attempt.
>> When this happens you will see it start the backoff timer.
>>
>> Thanks,
>> Heikki
>>
>> --
>> Heikki Vatiainen
>>
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER
>> etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
>> ___
>> radiator mailing list
>> radiator@open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] A few tips on performance and high availabilty

[Michael]

This memcache sounds pretty nice.  I do experience many pppoe logins 
where a router will constantly attempt to login which is fine at a slow 
rate.  Some router (usually Dlink) must be defective as they sometimes 
attempt to login WAY TOO often.  My personal record i've seen  is about 
12 times a second.  This means a little over 1 million rows in a failure 
sql table per day.  I have so far combated this issue by instead of 
logging every failure, i use an sql table with a unique index key 
between the username, a month/day value, and message, then use an 
"INSERT INTO table .  ON DUPLICATE KEY UPDATE hits=hits+1.  It works 
quite nicely.  This reduces these 1 million rows PER DAY down to just 1 
row per day and counts the number of times it happens in a given day.  
28/30/31 rows for the month.  Very effective.

I also have routers that seems to login, logout, login, logout 
successfully all day long.  This must be defective routers, but i'm not 
interested in a REACTIVE solution of calling these people and telling 
them they need to trash that router. I'm more interested in PROACTIVE 
solutions to battle this.

Just a quick glance right now in my success log, i've got 2 people, 12 
thousand, and 16 thousand logins so far for just today.  And this will 
be every day.  These are SUCCESS.  so these routers are logging in, 
logging out constantly. And i'm only 11 hours into this day.

Failures, 127 thousand for 1 user again just for today.  And i'm only 11 
hours into this day.


The login attempts though, still of course cause many unneeded sql 
queries for the authentication.  This memcache sounds interesting.  Do 
you have a quick description of usage, or a link describing how to 
implement it into radiator?


Thanks



On 03/12/12 11:17 AM, Anders Bandholm wrote:
> Hi list!
>
> We have been running Radiator for several purposes for around 5 years,
> and I would like to share a few tricks that we have learned...
>
>
> Memcached
> -
>
> Memcached is distributed cache, with a simple Perl-api. We run an instance
> of memcached on each Radius-server. We use it for several things:
>
>* We use it in a PostAuthHook for rejecting users with too many login
>  failures (to prevent brute-force password guessing)
>
>* We cache certain SOAP-calls. Since Radiator is single-threaded, fast
>  answers from backends is imperative as you probably know. We use
>  memcached in a "defensive" way: We always make the SOAP-call first,
>  but with a low timeout (0.1 sec) If the call times out, we use the
>  cache - if not we save the result to the cache.
>
>* we have started a service for our customers (Danish schools) where
>  they get alerts by email when user up- or download exceeds certain
>  thresholds. This is handled by summing up bytes from accounting
>  records in a PostProcessingHook. The counters for each user is kept
>  in memcached.
>
> It seems to me that memcached is a perfect companion for Radiator!
>
> Memcached is of course not a database, and if you shut down one of
> the memcached instances you will lose part of your cache. But for the
> purposes above it works very well.
>
> The Perl module is Cache::Memcached.
>
> If you run Linux memcached is probably packaged for you - on Debian/Ubuntu
> you need packages like these:
>
>  memcached
>  libcache-memcached-perl
>  libmemcached-tools
>
>
> Two other tricks
> 
>
>   1) We have started using Gearman to make it possible for the main radii
>  to offload certain slow things to other servers. As explained above
>  our radii keep track of user up/downloads through acct-records, and
>  when a certain limit is reached we send email alerts to the relevant
>  admin. But we don't want Radiator itself to send the email - we submit
>  a job through Gearman (Perl: Gearman::Client and Gearman::Worker)
>  This is a very promising technology and I expect we will use it more
>  in the future.
>
>   2) Simple trick - probably used by many of you: We have the client list
>  in an Oracle database, but since the database is sometimes down
>  for maintenance, we generate static file-based client-lists every
>  10 minutes instead, and reload Radiator when they change. If Oracle
>  is down, Radiator does not suffer. (The 10 minutes interval is
>  overkill for most installations ;-)
>
>
> Cheers,
> Anders
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] format_special for GENERIC attributes.

[Michael]

Suggestion...

I just noticed that when using GENERIC attribute name for AuthColumnDef 
in  which allows for a comma separated attribute list, the 
result from the select query is not passed through format_special 
therefore I can't use global variables.



--- old/Radius/AuthSQL.pm 2013-01-07 17:21:33.0 -0500
+++ new/Radius/AuthSQL.pm   2013-01-25 15:08:55.0 -0500
@@ -472,6 +472,7 @@ sub getAuthColumns
 if ($attrib eq "GENERIC")
 {
 # Column is a list of attr=value pairs
+   $cols[$colnr] = &Radius::Util::format_special( 
$cols[$colnr], $p );
 if ($type eq 'check')
 {
 $user->get_check->parse($cols[$colnr]);

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

(RADIATOR) PreClientHook

[Michael]

Hi all,

I am trying to work out how to use the PreClientHook to check that the
customer
is dialling the correct number, the idea being to prevent them accidentally
dialling
the wrong number and incurring hefty call charges.

here is what I am thinking of (I know bugger all about Perl).


#Perl Script
my $dialled = ${$_[0]}->get_attr(`Called-Station-Id');
my $callfrom = ${$_[0]}->get_attr(`Calling-Station-Id');
#Compare numbers to list and allow or deny logon

The way I was thinking to do this would be to have a file that is named as
the dial
up number for the region.
So we would have a buch of files named the number the customer should
call. So the script could simply go and check in a file called $dialled for
a
partial number $callfrom (first 4 digits) if it is not there deny logon and
log it. This
should make it easy to add more dial up locations later. If we go into a new
area
we simply need more files named for $dialled.

Would this work? What does the script need to return to prevent or allow
logon?

Michael



===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: [RADIATOR] Bandwidth switch COA advice

[Michael]

I do this, but it's done by sending the "cisco-avpair" attribute to the 
nas, with a value such as: "ip:sub-qos-policy-out=RATE10M".  "RATE10M" 
is a rate policy that MUST be already setup in the NAS.  And of course 
you usually have 2 of these values.  1 being ip:sub-qos-policy-in= and 
the other ip:sub-qos-policy-out= to cover both the upload and the download.


On a wider view of the process i myself use, i inject the request using 
radpwtst into NOT the nas, but into the radiator system which is 
configured to proxy the request itself to the nas, and then you have the 
ability to log that action.  The nas needs to be setup with the POD 
server to accept these requests.



Michael


On 27/03/13 05:16 AM, Thomas Kurian wrote:

Hello Friends,
I want to do a COA ,to switch the bandwidth profile of the users after 
they exceed maximum their allocated quota. Which are the attributes  
to be  included in the COA script to achieve this( (with respect to 
the following  Accounting request capture from the NAS[cisco ISG]) , 
is it cisco-Policy-Up/Down or some other?
what additional script lines might be required to achieve this 
bandwidth switch COA?

Is there some configuration to be changed on the NAS end?

To make myself clear ,my requirement is for example,  to switch the 
bandwidth of this user from 8Mbps to 1Mbps after this user exceeds 
allocated quota ( quota check is to done by comparing 2 values like 
this, if monthlycounter>=maxquota  ,perform the COA bandwidth 
switching). Note:[totalcounter and maxquota are column names in my 
odbc database named quotasubscribers].


_Hook_
sub { \
  my $p = ${$_[0]}; \
  return unless $p->code eq 'Accounting-Request'; \
  main::log($main::LOG_DEBUG, 'Handling Accounting-Request'); \
  my $user_name = $p->get_attr('User-Name'); \
  my $sess_id = $p->get_attr('Acct-Session-Id'); \
  my $framed_ipaddress = $p->get_attr('Framed-IP-Address'); \
  my @coa_attrs = ("User-Name=$user_name", 
"Acct-Session-Id=$sess_id", "Framed-IP-Address=$framed_ipaddress");\
  my @cmd_args = ("-noacct", "-noauth", "-time","-code", 
"Change-Filter-Request"); \
 push @cmd_args, ("-trace", "4", "-bind_address", 
"0.0.0.0", "-auth_port", "3799", "-secret", "xxx", "-s", "x.x.x.x"); \

  my @cmd = ("perl", "radpwtst"); \
  main::log($main::LOG_DEBUG, "Running command: @cmd @cmd_args 
@coa_attrs"); \

  system (@cmd, @cmd_args, @coa_attrs); \
}
_Accounting request sent from ISG_
Wed Mar 27 10:19:32 2013: DEBUG: Packet dump:
*** Received from 10.50.1.4 port 1646 
Code:   Accounting-Request
Identifier: 165
Authentic:  .<25>5]<191><175>+<218>#<237><182><22><220><229>|<214>
Attributes:
Acct-Session-Id = "002D98E3"
cisco-Policy-Up = "8Mbps"
cisco-Policy-Down = "8Mbps"
Framed-Protocol = PPP
Framed-IP-Address = 94.187.159.88
User-Name = "99759991"
cisco-avpair = "connect-progress=LAN Ses Up"
cisco-avpair = "nas-tx-speed=10"
cisco-avpair = "nas-rx-speed=10"
Acct-Session-Time = 40503
Acct-Input-Octets = 81218503
Acct-Output-Octets = 2504979160
Acct-Input-Packets = 1032810
Acct-Output-Packets = 1829162
Acct-Authentic = RADIUS
Acct-Status-Type = Alive
NAS-Port-Type = Virtual
NAS-Port = 0
NAS-Port-Id = "0/0/0/666"
cisco-avpair = "client-mac-address=7073.cbb3.66c8"
Class = 
"<153>3<1><8>99759991<21><4><4>$<221><0>3<4><3><0><0><0>   3<4><12><0><0><0>3<4><6><0><0><0>1<16>c1dfaedfabcffee7"

Service-Type = Framed-User
NAS-IP-Address = 10.50.1.4
Event-Timestamp = 1364368772
NAS-Identifier = "DC-ISG2-Flash.wimd.kw"
Acct-Delay-Time = 0
--
Requesting your kind help and advice,

Thomas Kurian
IT Security Engineer (B.Tech. -- Electrical)
Kuwaiti Canadian Consulting Group (www.kccg.com)
T: +965 22435566
F: +965 22415149
E:tho...@kccg.com


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Handler type Stop/Alive distinguished processing

[Michael]

AuthByPolicy has to do with the processing of the AuthBy's in Handlers, 
not the handlers themselves.  Radiator will process the Handlers in 
order they are in the config file, and will only process the first 
match. that's it.  If you want to do multiple things with the same 
packet, you would have to configure only 1 Handler, and multiple 
AuthBy's to do more than one thing with a packet.


Michael



On 27/03/13 12:41 PM, Michael Newton wrote:
On 27 March 2013 09:29, <mailto:radiator-requ...@open.com.au>> wrote:



My requirement is to process and handle ,Alive and Stop packet
separately  and the configuration must be called/processed
separately ,each time the radiator receives it based on the Acct
Status type as described above. Please help me out , i could not
find an explanation for this anywhere and i am confused. Please
let me know, if you need any more specifics to help me out.


There shouldn't be any problem with using Acct-Status-Type=Start>, , or Acct-Status-Type=Stop>, it is how we do accounting on our server. 
Maybe make sure you you are using "AuthByPolicy ContinueWhileIgnore" 
if you have problems with subsequent handlers not getting called?


If that doesn't help, I'd suggest posting the config that doesn't work 
instead of the one that does; other people may be able to provide more 
suggestions.


Mike



___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Bandwidth switch COA advice

[Michael]

This is not really a cut-and-paste sort of configuration.  different 
cisco devices can have different config.  Sometimes this is all done on 
1 line, but generally this is what it looks like:



aaa server radius dynamic-author
 client 1.1.1.1
 client 1.1.1.2
 client 1.1.1.3
 client 1.1.1.4
 server-key 7 12464C5F030316
 auth-type any
!

The clients being the ip address from where you need to accept 
connections ie. from radpwtst.


Also keep in mind, this enables the POD server on the nas, but it 
doesn't necessarily listen on the ip address that you use for radius or 
to connect to the device.  I work on devices that have many ips and the 
POD service seems to only sit on some, possible just one of the nas's ips.





On 27/03/13 03:13 PM, Thomas Kurian wrote:

Hello Michael,
Many thanks for your email. I am just handling the radiator side of 
our company project . ISG (NAS) is handled by my colleague. so Can you 
please give me the necessary steps that i should ask him to do on the NAS?
Additionally can you also please elaborate the steps or provide me 
with an example on what is  to done on the radiator in a sequence. I 
positively believe that your  previous experience with this subject  
,can certainly help me out.


Requesting your kind help&  cooperation,

Thomas Kurian
IT Security Engineer (B.Tech. -- Electrical)
Kuwaiti Canadian Consulting Group (www.kccg.com)
T: +965 22435566
F: +965 22415149
E:tho...@kccg.com
On 3/27/2013 8:18 PM, Michael wrote:


I do this, but it's done by sending the "cisco-avpair" attribute to 
the nas, with a value such as: "ip:sub-qos-policy-out=RATE10M".  
"RATE10M" is a rate policy that MUST be already setup in the NAS.  
And of course you usually have 2 of these values.  1 being 
ip:sub-qos-policy-in= and the other ip:sub-qos-policy-out= to cover 
both the upload and the download.


On a wider view of the process i myself use, i inject the request 
using radpwtst into NOT the nas, but into the radiator system which 
is configured to proxy the request itself to the nas, and then you 
have the ability to log that action.  The nas needs to be setup with 
the POD server to accept these requests.



Michael


On 27/03/13 05:16 AM, Thomas Kurian wrote:

Hello Friends,
I want to do a COA ,to switch the bandwidth profile of the users 
after they exceed maximum their allocated quota. Which are the 
attributes  to be  included in the COA script to achieve this( (with 
respect to the following  Accounting request capture from the 
NAS[cisco ISG]) , is it cisco-Policy-Up/Down or some other?
what additional script lines might be required to achieve this 
bandwidth switch COA?

Is there some configuration to be changed on the NAS end?

To make myself clear ,my requirement is for example,  to switch the 
bandwidth of this user from 8Mbps to 1Mbps after this user exceeds 
allocated quota ( quota check is to done by comparing 2 values like 
this, if monthlycounter>=maxquota  ,perform the COA bandwidth 
switching). Note:[totalcounter and maxquota are column names in my 
odbc database named quotasubscribers].


_Hook_
sub { \
  my $p = ${$_[0]}; \
  return unless $p->code eq 'Accounting-Request'; \
  main::log($main::LOG_DEBUG, 'Handling Accounting-Request'); \
  my $user_name = $p->get_attr('User-Name'); \
  my $sess_id = $p->get_attr('Acct-Session-Id'); \
  my $framed_ipaddress = $p->get_attr('Framed-IP-Address'); \
  my @coa_attrs = ("User-Name=$user_name", 
"Acct-Session-Id=$sess_id", "Framed-IP-Address=$framed_ipaddress");\
  my @cmd_args = ("-noacct", "-noauth", "-time","-code", 
"Change-Filter-Request"); \
 push @cmd_args, ("-trace", "4", "-bind_address", 
"0.0.0.0", "-auth_port", "3799", "-secret", "xxx", "-s", 
"x.x.x.x"); \

  my @cmd = ("perl", "radpwtst"); \
  main::log($main::LOG_DEBUG, "Running command: @cmd 
@cmd_args @coa_attrs"); \

  system (@cmd, @cmd_args, @coa_attrs); \
}
_Accounting request sent from ISG_
Wed Mar 27 10:19:32 2013: DEBUG: Packet dump:
*** Received from 10.50.1.4 port 1646 
Code:   Accounting-Request
Identifier: 165
Authentic:  .<25>5]<191><175>+<218>#<237><182><22><220><229>|<214>
Attributes:
Acct-Session-Id = "002D98E3"
cisco-Policy-Up = "8Mbps"
cisco-Policy-Down = "8Mbps"
Framed-Protocol = PPP
Framed-IP-Address = 94.187.159.88
User-Name = "99759991"
cisco-avpair = "connect-progress=LAN Ses Up"
cisco-avpair = "nas-tx-speed=100

Re: [RADIATOR] Handler type Stop/Alive distinguished processing

[Michael]

AuthByPolicy is only for what to do when you have multiple authby's.  
you only have 1 per handler here so it's irrelevant.


Best to show some debug log of this in action with a start packet to 
figure out what's going on.  the config looks like it should at least 
handle the start packet.




On 27/03/13 03:32 PM, Thomas Kurian wrote:

Hi Mike,
Thanks for your email. Can you please tell me where exactly i have to 
add "AuthByPolicy ContinueWhileIgnore"? Should it go under each 
handler clause inside Authby sql?


_My old config (which didnt work ,Start packets were never getting 
processed) (this was the config i had problem a long time ago.. which 
lead me to ask this question)_


AcctPort 1813

AuthPort 1812




BindAddress 0.0.0.0


LogDir /var/log/radius

DbDir /etc/radiator

# Use a low trace level in production systems. Increase

# it to 4 or 5 for debugging, or use the -trace flag to radiusd

Trace 4

# You will probably want to add other Clients to suit your work site,

# one for each NAS you want to work with







Secret 

DupInterval 0














Secret xxx

DupInterval 0

NasType Cisco

IgnoreAcctSignature






#For strictly processing with Accounting Stop packets











Identifier Block-Quota-SQL




DBSource dbi:mysql:radius

DBUsername 

DBAuth x




AccountingStopsOnly

AccountingTable quotacouunter

AuthColumnDef username,User-Name,check







AuthSelect select monthlycounter from quotacounter \

where username='%n' \

And type = 'Q'

#AuthColumnDef 0, Session-Timeout, reply




AcctSQLStatement update quotacounter set \

monthlycounter=monthlycounter+%{Acct-Input-Octets} \

where username='%n' \

And Type = 'Q'




AuthSelect select totalcounter from quotacounter \

where username='%n' \

And Type = 'Q'




AcctSQLStatement update quotacounter set \

totalcounter=totalcounter+%{Acct-Input-Octets} \

where username='%n' \

And Type = 'Q'




PostAuthHook file:"%D/thomas.pl";




















# Accept processing of other accounting requests of the genre start 
and interim
















DBSource dbi:mysql:radius

DBUsername 

DBAuth 










AccountingTable ACCOUNTING

AcctColumnDef USERNAME, User-Name

AcctColumnDef ACCTSTATUSTYPE,Acct-Status-Type

AcctColumnDef FRAMEDIPADDRESS,Framed-IP-Address

AcctColumnDef ACCTINPUTOCTETS,Acct-Input-Octets

AcctColumnDef ACCTOUTPUTOCTETS,Acct-Output-Octets

AcctColumnDef TIME_STAMP,Event-Timestamp

AcctColumnDef ACCTSESSIONTIME,Acct-Session-Time

AcctColumnDef ACCTDELAYTIME,Acct-Delay-Time

AcctColumnDef ACCTSESSIONID,Acct-Session-Id

AcctColumnDef ACCTTERMINATECAUSE,Acct-Terminate-Cause

AcctColumnDef NASIDENTIFIER,NAS-Identifier

AcctColumnDef NASPORT,NAS-Port

AcctColumnDef ACCTSESSIONID,Acct-Session-Id






# Log accounting to a detail file

AcctLogFileName %L/detail















Requesting your kind help, Thomas Kurian IT Security Engineer (B.Tech. 
-- Electrical) Kuwaiti Canadian Consulting Group (www.kccg.com) T: 
+965 22435566 F: +965 22415149 E: tho...@kccg.com

On 3/27/2013 8:00 PM, radiator-requ...@open.com.au wrote:
Send radiator mailing list submissions to radiator@open.com.au To 
subscribe or unsubscribe via the World Wide Web, visit 
http://www.open.com.au/mailman/listinfo/radiator or, via email, send 
a message with subject or body 'help' to radiator-requ...@open.com.au 
You can reach the person managing the list at 
radiator-ow...@open.com.au When replying, please edit your Subject 
line so it is more specific than "Re: Contents of radiator digest..." 
Today's Topics: 1. Re: Handler type Stop/Alive distinguished 
processing (Michael Newton) 
-- Message: 
1 Date: Wed, 27 Mar 2013 09:41:40 -0700 From: Michael Newton 
 Subject: Re: [RADIATOR] Handler type Stop/Alive 
distinguished processing To: radiator@open.com.au Message-ID: 
 
Content-Type: text/plain; charset="utf-8" On 27 March 2013 09:29, 
 wrote:
My requirement is to process and handle ,Alive and Stop packet 
separately and the configuration must be called/processed separately 
,each time the radiator receives it based on the Acct Status type as 
described above. Please help me out , i could not find an 
explanation for this anywhere and i am confused. Please let me know, 
if you need any more specifics to help me out. 
There shouldn't be any problem with using Acct-Status-Type=Start>, , or 
, it is how we do accounting on our 
server. Maybe make sure you you are using "AuthByPolicy 
ContinueWhileIgnore" if you have problems with subsequent handlers 
not getting called? If that doesn't help, I'd suggest posting the 
config that doesn't work instead of the one that does; other people 
may be able to provide more suggestio

Re: [RADIATOR] Handler type Stop/Alive distinguished processing

[Michael]

quot;disc-cause-ext=TCP Foreign Host Close"
Acct-Status-Type = Stop
NAS-Port-Type = Virtual
NAS-Port = 0
NAS-Port-Id = "0/0/0/666"
cisco-avpair = "client-mac-address=e046.9a3b.c135"
Class = 
"<153>3<1><8>65002914<21><4><171><144><212><0>3<4><6><0><0><0>3<4><16><0><0><0>3<4><3><0><0><0>1<16>8f9c5c39dc74286f"

Service-Type = Framed-User
NAS-IP-Address = 10.50.1.4
Event-Timestamp = 1365068251
NAS-Identifier = "DC-ISG2-Flash.wimd.kw"
Acct-Delay-Time = 0

Thu Apr  4 12:37:31 2013: DEBUG: Handling request with Handler 
'Request-Type = Accounting-Request', Identifier ''
Thu Apr  4 12:37:31 2013: DEBUG: tamesql Deleting session for 
65002914, 10.50.1.4, 0
Thu Apr  4 12:37:31 2013: DEBUG: do query to 'dbi:ODBC:IRONMAN': 
'delete from RADONLINE where NASIDENTIFIER='10.50.1.4' and NASPORT=00':

Thu Apr  4 12:37:31 2013: DEBUG: Handling with Radius::AuthSQL: thomas
Thu Apr  4 12:37:31 2013: DEBUG: Handling accounting with Radius::AuthSQL
Thu Apr  4 12:37:31 2013: DEBUG: do query to 'dbi:ODBC:IRONMAN': 
'update quotasubscribers set monthlycounter = 160823960, totalcounter 
= 160823960, timestamp = 13650682

51  where username='65002914' And Type = 'Q'':
Thu Apr  4 12:37:31 2013: DEBUG: AuthBy SQL result: ACCEPT,
Thu Apr  4 12:37:31 2013: DEBUG: Running PostAuthHook: Using Identifier

Thu Apr  4 12:37:31 2013: DEBUG: Running PostAuthHook sql query check 
for :

65002914
Thu Apr  4 12:37:31 2013: DEBUG: Query to 'dbi:ODBC:IRONMAN': 'select 
username from quotasubscribers where switched = 0 and type = 'Q' and 
monthlycounter >= maxquota ':
Thu Apr  4 12:37:31 2013: DEBUG: The user 65002914 either has not yet 
exceeded allocated quota or isnt a quota based user

Thu Apr  4 12:37:31 2013: DEBUG: Accounting accepted
Thu Apr  4 12:37:31 2013: DEBUG: Packet dump:
*** Sending to 10.50.1.4 port 1646 
Code:   Accounting-Response
Identifier: 29
Authentic:  (e<12>Z<183>bS<24>*-_<150><4>'<130><238>
Attributes:

*_Radiator Config file_*
LogDir  /var/log/radius
DbDir   /etc/radiator
# Use a low trace level in production systems. Increase
# it to 4 or 5 for debugging, or use the -trace flag to radiusd
Trace   4

# You will probably want to add other Clients to suit your work site,


Secret  XX
DupInterval 0




Secret XX
DupInterval 0
NasType Cisco
IgnoreAcctSignature


# Accept processing of other accounting requests of the genre Stop



Identifier thomas
DBSource dbi:ODBC:IRONMAN
DBUsername 
DBAuth WX


AccountingStopsOnly
AccountingTable ACCOUNTING
AcctColumnDef   USERNAME, User-Name
AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
AcctColumnDef   
ACCTOUTPUTOCTETS,Acct-Output-Octets,integer

AcctColumnDef   TIME_STAMP,Event-Timestamp,integer-date
AcctColumnDef   ACCTSESSIONTIME,Acct-Session-Time,integer
AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
AcctColumnDef   NASIDENTIFIER,NAS-Identifier
AcctColumnDef   NASPORT,NAS-Port,integer



# This SessionDatabase clause can be used to insert value of extra 
desired field for future development


Identifier  tamesql
DBSourcedbi:ODBC:IRONMAN
DBUsername  XXX
DBAuth  X




# Accept processing of other accounting requests of the genre Alive 
interim updates



Identifier thomas
DBSource dbi:ODBC:IRONMAN
DBUsername XXX
DBAuth XX


AcctSQLStatement update quotasubscribers set 
monthlycounter = %{Acct-Output-Octets}, totalcounter = 
%{Acct-Output-Octets}, timestamp = %{Event-Timestamp}  \

where username='%n' \
And Type = 'Q'




PostAuthHook file:"/etc/radiator/rocky.pl"
#Log accounting to a detail file
AcctLogFileName %L/detail



Requesting your kind help&  cooperation,

Thomas Kurian
IT Security Engineer (B.Tech. -- Electrical)
Kuwaiti Canadian Consulting Group (

Re: [RADIATOR] Radiator & Debian Wheezy = memory problem?

[Michael]

  
  
I have this problem too.  Radiator slowly consumes more and more
memory as the weeks go by.  Restarting it brings it back down.  I
have asked this question to, but also got the same answers you did. 
Not a radiator problem.


On 19/06/13 05:04 AM, Kurt Bauer wrote:

  
  Hi,
  
  since upgrading one of our radius-servers to Debain 7 (Wheezy) we
  expierence serious memory problems, namely Radiator eating up all
  the available memory over time (see attached graph). We have a few
  Radiator installations running and the ones on Debian Squeeze
  behave fine.
  Radiator 4.11 plus latest patches
  Perl v5.14.2 (as packaged in Wheezy)
  
  Any similar experiences or hints why this could be? Restarting
  Radiator every few days rectifies the situation but is not the way
  we want to run the service ;-)
  
  Thanks for your help,
  best regards,
  Kurt
  
  
  
  
  
  
  -- 
Kurt Bauer 
Vienna University Computer Center - ACOnet - VIX
Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe
Tel: ++43 1 4277 - 14070 (Fax: - 814070)  KB1970-RIPE

  
  
  
  
  ___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

  

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator & Debian Wheezy = memory problem?

[Michael]

  
  

4 radius servers. identical config.  the last in the list is not
used as much.  lower usage seems to mean lower memory usage.


since May 7, up to 22% memory usage.  restarting it, drops down to
4%.  It will sit there for a while and slowly creep up over a couple
months.
-apr25 16.1%, 2.7 after restart
-may7 18.4%, 4.7 after restart
-may17 8.5%, 3.0 after restart

===
root@:/l# ps u |grep radiusd
root  9404  4.6 22.1 263120 112584 pts/0   S    May07 2859:09
/usr/bin/perl radiusd
root@:/# radiator stop
Shutting down Radiator: 
root@:/# radiator start
Starting Radiator: 
root@:/var/lib/mysql# ps u |grep radiusd
root  3490  2.5  4.1  91124 21224 pts/0    S    11:20   0:00
/usr/bin/perl radiusd
===
root@:/# ps u |grep radiusd
root 25157  2.5 16.1 274228 123864 pts/3   S    Apr25 1994:48
/usr/bin/perl radiusd
root@:/# radiator stop
Shutting down Radiator: 
root@:/# radiator start
Starting Radiator: 
root@:/# ps u |grep radiusd
root 21310  6.0  2.7  92972 20744 pts/0    S    11:24   0:00
/usr/bin/perl radiusd
===
root@:# ps u |grep radiusd
root 20050  2.1 18.4 242708 93992 pts/1    S    May07 1354:18
/usr/bin/perl radiusd
root@:# radiator stop
Shutting down Radiator: 
root@:# radiator start
Starting Radiator: 
root@:# ps u |grep radiusd
root  3133  5.1  4.7  93896 24116 pts/1    S    11:27   0:00
/usr/bin/perl radiusd
===
root@:# ps u |grep radiusd
root 14703  0.6  8.5 211892 65432 pts/0    S    May17 306:39
/usr/bin/perl radiusd
root@:# radiator stop
Shutting down Radiator: 
root@:# radiator start
Starting Radiator: 
root 22218  0.7  3.0  93524 23488 pts/0    S    11:30   0:00
/usr/bin/perl radiusd
===

On 19/06/13 11:10 AM, Michael wrote:

  
  I have this problem too.  Radiator slowly consumes more and more
  memory as the weeks go by.  Restarting it brings it back down.  I
  have asked this question to, but also got the same answers you
  did.  Not a radiator problem.
  
  
  On 19/06/13 05:04 AM, Kurt Bauer wrote:
  

Hi,

since upgrading one of our radius-servers to Debain 7 (Wheezy)
we expierence serious memory problems, namely Radiator eating up
all the available memory over time (see attached graph). We have
a few Radiator installations running and the ones on Debian
Squeeze behave fine.
Radiator 4.11 plus latest patches
Perl v5.14.2 (as packaged in Wheezy)

Any similar experiences or hints why this could be? Restarting
Radiator every few days rectifies the situation but is not the
way we want to run the service ;-)

Thanks for your help,
best regards,
Kurt






-- 
  Kurt Bauer 
  Vienna University Computer Center - ACOnet - VIX
  Universitaetsstrasse 7, A-1010 Vienna, Austria, Europe
  Tel: ++43 1 4277 - 14070 (Fax: - 814070)  KB1970-RIPE
  




___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
  
  
  
  
  ___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

  

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radiator & Debian Wheezy = memory problem?

[Michael]

- i use SessionDatabase NULL to disable this feature.
- my radiator service handles many different authentication methods and 
my config is quite large.  i'm up to 6,043 lines of config.  I don't 
wish to send the config to anyone.
- not sure what the logs are going to show for this mater not to mention 
what part of the logs would anyone want to look at.
- i didn't say it was a memory leak.  I just responded to Kurt Bauer 
saying that I experience the same problem ie. Debian Wheezy and 
increased memory usage over time.
- i'm not actually looking for help though.  I do realize how hard it 
would be for someone to help via email on such a matter.  thanks anyways 
though.

Michael


On 19/06/13 02:19 PM, Christian Kratzer wrote:
> Hi,
>
> On Wed, 19 Jun 2013, Michael wrote:
>
>>
>> 4 radius servers. identical config.  the last in the list is not used 
>> as much.  lower usage seems to mean lower memory usage.
>
> even without any additional modules in use radiator will of course use
> some memory. Features like the session database will gradually build up
> memory usage until a level that matches your workload is reached.
>
> Restarting radiator will of course free up all of the memory.
>
> This would not be a memory leak but legitimate usage that you have to
> account for to match your workload or number of concurrent sessions in 
> the case of session db.
>
> If you have a memory leak the process size would grow without ever
> reaching a saturation point.  To find out if it is so you need to watch
> memory consuption with a graphing tool mrtg/cacti/observium/
>
> If you see a graph that slowly saturates alls fine. If you see steady
> growth investigate further.
>
> Greetings
> Christian
>
>>
>> since May 7, up to 22% memory usage.  restarting it, drops down to 
>> 4%.  It will sit there for a while and slowly creep up over a couple 
>> months.
>> -apr25 16.1%, 2.7 after restart
>> -may7 18.4%, 4.7 after restart
>> -may17 8.5%, 3.0 after restart
>>
>> ===
>> root@:/l# ps u |grep radiusd
>> root  9404  4.6 22.1 263120 112584 pts/0   SMay07 2859:09 
>> /usr/bin/perl radiusd
>> root@:/# radiator stop
>> Shutting down Radiator:
>> root@:/# radiator start
>> Starting Radiator:
>> root@:/var/lib/mysql# ps u |grep radiusd
>> root  3490  2.5  4.1  91124 21224 pts/0S11:20   0:00 
>> /usr/bin/perl radiusd
>> ===
>> root@:/# ps u |grep radiusd
>> root 25157  2.5 16.1 274228 123864 pts/3   SApr25 1994:48 
>> /usr/bin/perl radiusd
>> root@:/# radiator stop
>> Shutting down Radiator:
>> root@:/# radiator start
>> Starting Radiator:
>> root@:/# ps u |grep radiusd
>> root 21310  6.0  2.7  92972 20744 pts/0S11:24   0:00 
>> /usr/bin/perl radiusd
>> ===
>> root@:# ps u |grep radiusd
>> root 20050  2.1 18.4 242708 93992 pts/1SMay07 1354:18 
>> /usr/bin/perl radiusd
>> root@:# radiator stop
>> Shutting down Radiator:
>> root@:# radiator start
>> Starting Radiator:
>> root@:# ps u |grep radiusd
>> root  3133  5.1  4.7  93896 24116 pts/1S11:27   0:00 
>> /usr/bin/perl radiusd
>> ===
>> root@:# ps u |grep radiusd
>> root 14703  0.6  8.5 211892 65432 pts/0SMay17 306:39 
>> /usr/bin/perl radiusd
>> root@:# radiator stop
>> Shutting down Radiator:
>> root@:# radiator start
>> Starting Radiator:
>> root 22218  0.7  3.0  93524 23488 pts/0S11:30   0:00 
>> /usr/bin/perl radiusd
>> ===
>>
>> On 19/06/13 11:10 AM, Michael wrote:
>>> I have this problem too.  Radiator slowly consumes more and more 
>>> memory as the weeks go by.  Restarting it brings it back down.  I 
>>> have asked this question to, but also got the same answers you did.  
>>> Not a radiator problem.
>>>
>>>
>>> On 19/06/13 05:04 AM, Kurt Bauer wrote:
>>>> Hi,
>>>>
>>>> since upgrading one of our radius-servers to Debain 7 (Wheezy) we 
>>>> expierence serious memory problems, namely Radiator eating up all 
>>>> the available memory over time (see attached graph). We have a few 
>>>> Radiator installations running and the ones on Debian Squeeze 

Re: [RADIATOR] AccountingTable Database Very big

[Michael]

I use monthly tables.  that really helped. Then use the year-month 
attributes in your insert statements.  And of course anything that reads 
this data will have to be altered to support year-month tables. Also an 
external process that runs monthly to make sure that the tables get 
created ahead of time.



On 28/06/13 10:08 PM, sergio wrote:
> Hello list
>
> I use mysql database and my AccountingTable has more than 40 million records 
> per month. Does anyone here have any policy purge? I have an extract of CGI 
> access for my users and is very slow because the bank is getting too big. 
> Does anyone have any recommendation what I should do to have a page extract 
> access working well with a huge amount of data like this?
>
> Regards!
>
> 
> GET FREE SMILEYS FOR YOUR IM&  EMAIL - Learn more at 
> http://www.inbox.com/smileys
> Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™ and 
> most webmails
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AccountingTable Database Very big

[Michael]

i use mysql. no i don't have anything that reads the data with a 
browser. sorry.


On 30/06/13 11:33 PM, sergio wrote:
> I use mysql database, elterei from MyISAM to InnoDB but I wonder if another 
> database would not help.
>
> Very good idea to use your tables YEAR-MES. What database do you use?
>
> you have some script to extract such data in the Browser?
>
> Thanks
>
>> -Original Message-
>> From: ri...@vianet.ca
>> Sent: Sat, 29 Jun 2013 14:02:27 -0400
>> To: ser...@inbox.com
>> Subject: Re: [RADIATOR] AccountingTable Database Very big
>>
>> I use monthly tables.  that really helped. Then use the year-month
>> attributes in your insert statements.  And of course anything that reads
>> this data will have to be altered to support year-month tables. Also an
>> external process that runs monthly to make sure that the tables get
>> created ahead of time.
>>
>>
>>
>> On 28/06/13 10:08 PM, sergio wrote:
>>> Hello list
>>>
>>> I use mysql database and my AccountingTable has more than 40 million
>>> records per month. Does anyone here have any policy purge? I have an
>>> extract of CGI access for my users and is very slow because the bank is
>>> getting too big. Does anyone have any recommendation what I should do to
>>> have a page extract access working well with a huge amount of data like
>>> this?
>>>
>>> Regards!
>>>
>>> 
>>> GET FREE SMILEYS FOR YOUR IM&   EMAIL - Learn more at
>>> http://www.inbox.com/smileys
>>> Works with AIM®, MSN® Messenger, Yahoo!® Messenger, ICQ®, Google Talk™
>>> and most webmails
>>>
>>>
>>> ___
>>> radiator mailing list
>>> radiator@open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
> 
> FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
> Check it out at http://www.inbox.com/earth
>
>
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] AccountingTable Database Very big

[Michael]

are you saying postgresql is really that much better with regards to 
performance, and worth switching to?


On 01/07/13 03:29 AM, a.l.m.bu...@lboro.ac.uk wrote:
> Hi,
>
>> I use mysql database and my AccountingTable has more than 40 million records 
>> per month. Does anyone here have any policy purge? I have an extract of CGI 
>> access for my users and is very slow because the bank is getting too big. 
>> Does anyone have any recommendation what I should do to have a page extract 
>> access working well with a huge amount of data like this?
> firstly use InnoDB rather than MyISAM (InnoDB has been in MySQL for ages 
> now...no default
> installs should not have InnoDB support...and no tools should want to slap 
> MyISAM tables
> into the DB..should be InnoDB by default)
>
> secondly, edit the my.cnf to fully utilise your hostthere are plenty of 
> docs
> for each InnoDB option...but..like MyISAM.there are also quite a few tools 
> that will
> give you a fairly good start on the way down the path eg 
> http://mysqltuner.com/
>
> thirdly, look at what your tool is doing (in this case RADIATOR) with the DB 
> to find
> out if there are any local query bottlenecks eg use the EXPLAIN command to 
> find out
> what the queries are doing and where it cannot find quick answers. then look 
> at adding
> required INDEXes to the tables
>
> finally, move from MySQL to PostgreSQL - psql doesnt have so many nasty 
> locking events
> on each row/column - MySQL will cause limits whenever an update/insert is 
> occuring
> (from experience, default install speed of psql is similar to that of MySQL 
> after
> you've spent some time optimising the MySQL environment! - and THEN you can 
> tweak
> psql even further )
>
> alan
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] proxying POD reply packets

[Michael]

Does anyone know of any issues with receiving reply packets from a 
packet-of-disconnect request which is proxied through radiator?  For my 
POD requests, i inject them into radiator using radpwtst and have them 
configured to proxy to the proper device.  The POD does work.  When a 
session is matched and a user is disconnected, the AKed reply comes back 
to radiator and proxies back to radpwtst and radpwtst will exit with "OK".

But, when the device respondes with NOT acknowledged (ie. no matching 
session found), that reply is NOT proxied back to radpwtst and therefore 
produces a no response timeout issue for radpwtst.




This is an example of the NAKed request coming back with "No Matching 
Session" which is correct, but it just stops and doesn't appear to 
forward that reply back to the waiting radpwtst.


*** Received from 1.1.1.1 port 1700 
Code:   Disconnect-Request-NAKed
Identifier: 22
Authentic:
Attributes:
 Reply-Message = "No Matching Session"
 Error-Cause = Session-Context-Not-Found

Fri Jul  5 09:50:26 2013: DEBUG: Accounting rejected: Proxied

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] proxying POD reply packets

[Michael]

In AuthRADIUS.pm, routine sub handleReply, should 
"Disconnect-Request-NAKed" also be listed in the code bellow?

Works for me now.  The NAKed request now gets forwarded to the original 
requester (radpwtst).




 # RadiusResult tells Synchronous mode that we have
 # finished with this packet and what the result was
 # ReplyHook above could set op->{RadiusResult} to force a
 # required reponse type
 if (!defined $op->{RadiusResult})
 {
 if ($p->code eq 'Access-Accept'
 || $p->code eq 'Accounting-Response'
 || $p->code eq 'Disconnect-Request-ACKed'
 || $p->code eq 'Disconnect-Request-NAKed'
 || $p->code eq 'Change-Filter-Request-ACKed')
 {
 $op->{RadiusResult} = $main::ACCEPT;






On 05/07/13 10:02 AM, Michael wrote:
> Does anyone know of any issues with receiving reply packets from a
> packet-of-disconnect request which is proxied through radiator?  For my
> POD requests, i inject them into radiator using radpwtst and have them
> configured to proxy to the proper device.  The POD does work.  When a
> session is matched and a user is disconnected, the AKed reply comes back
> to radiator and proxies back to radpwtst and radpwtst will exit with "OK".
>
> But, when the device respondes with NOT acknowledged (ie. no matching
> session found), that reply is NOT proxied back to radpwtst and therefore
> produces a no response timeout issue for radpwtst.
>
>
>
>
> This is an example of the NAKed request coming back with "No Matching
> Session" which is correct, but it just stops and doesn't appear to
> forward that reply back to the waiting radpwtst.
>
>
> *** Received from 1.1.1.1 port 1700 
> Code:   Disconnect-Request-NAKed
> Identifier: 22
> Authentic:
> Attributes:
>   Reply-Message = "No Matching Session"
>   Error-Cause = Session-Context-Not-Found
>
> Fri Jul  5 09:50:26 2013: DEBUG: Accounting rejected: Proxied
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] proxying POD reply packets

[Michael]

also, Change-Filter-Request-NAKed would also need to be in that list.


On 09/07/13 07:00 AM, Heikki Vatiainen wrote:
> On 07/05/2013 09:17 PM, Michael wrote:
>
>> In AuthRADIUS.pm, routine sub handleReply, should
>> "Disconnect-Request-NAKed" also be listed in the code bellow?
> I think all types can be proxied back. Good news or bad news, the
> requestor will surely like to know abou them.
>
>> Works for me now.  The NAKed request now gets forwarded to the original
>> requester (radpwtst).
> Thanks for reporting the results. If nothing special comes up the
> additional messages types will be in patches soon.
>
> Thanks,
> Heikki
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] proxying POD reply packets

[Michael]

Heikki, to answer your questions at bottom


I wonder if you have a (very) old Radiator or more likely, a
configuration that causes NAKed messages to be rejected.


I'm using v4.10 so it's not old.  I do however have a quite complicated 
radiator configuration.  Mainly, i inject POD's and COA's into radiator rather 
than sending directly to devices because i have many different cisco devices, 
some using different commands to accomplish the POD and COA.  radiator applies 
the necessary commands for the given device before proxying.  Also, i wanted 
these requests to be logged.  So, my complicated config determines what device 
the request needs to go to and sends, and then it converts the POD and COA 
packets to accounting packets using scripting, then sends to my accounting 
handler and that POD/COA request is logged.  So yes, i will have to review my 
config.

For now though, adding the NAKed requests to the list in the code i described 
does make sure the reply packets coming back from the nas's are proxied to the 
radpwtst client.

There's probably a better way of accomplishing this for sure.  I'll look into 
this further
Thanks.


Michael





On 13/07/13 03:25 AM, Heikki Vatiainen wrote:
> On 07/12/2013 06:46 PM, Michael wrote:
>
>> also, Change-Filter-Request-NAKed would also need to be in that list.
> Hello Michael,
>
> I tested with this setup:
> radpwtst ->  R1 ->  R2
>
> where R1 is a simple proxy Radiator and R2 is Radiator that replies with
> Change-Filter-NAKed or Disconnect-Request-NAKed. It also adds
> Error-Cause and Reply-Message to the responses. This is done with AuthBy
> INTERNAL.
>
> R1 config is simply this:
>
> 
>  Secret  mysecret
> 
>
> 
>
>  Secret mysecret
>  Host 127.0.0.1
>  AuthPort 1812
>  AcctPort 1813
>
> 
>
> With the above setup the NAKed responses were proxied back to radpwtst
> correctly. Also the ACKed responses were proxied fine. R1 logs the
> message from R2 like this:
>
>
> DEBUG: Packet dump:
> *** Received from 127.0.0.1 port 1812 
> Code:   Disconnect-Request-NAKed
> Identifier: 1
> Authentic:  C<235><235>T<17><153>RG<130><221><213><213><27><223>"<184>
> Attributes:
>  Reply-Message = "No Matching Session"
>  Error-Cause = Session-Context-Not-Found
>
> INFO: Disconnect-Request rejected: No Matching Session
> DEBUG: Packet dump:
> *** Sending to 127.0.0.1 port 44624 
> Code:   Disconnect-Request-NAKed
> Identifier: 90
> Authentic:   ZNg<23>3<165>a<23>'<222><235><201><189><155><14>
> Attributes:
>  Reply-Message = "No Matching Session"
>  Error-Cause = Session-Context-Not-Found
>
> The INFO line is logged by Handler which forwards the request back to
> radpwtst even if the request type was not added the the ACCEPTed request
> types.
>
> I wonder if you have a (very) old Radiator or more likely, a
> configuration that causes NAKed messages to be rejected.
>
> Thanks,
> Heikki
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] proxying POD reply packets

[Michael]

On 16/07/13 04:24 PM, Heikki Vatiainen wrote:
> On 07/13/2013 08:20 PM, Michael wrote:
>
>> So, my complicated config determines what device the request needs to
>> go to and sends, and then it converts the POD and COA packets to
>> accounting packets using scripting, then sends to my accounting
>> handler and that POD/COA request is logged.
> Ok, so that's where the 'Accounting rejected' log entry in your first
> message came from.
>
> The default processing in Radiator will proxy back both ACKed and NAKed
> messages. The latter will be logged as a failed message with
> 'Change-Filter-Request rejected: thereason', but it will be proxied back
> just like an ACKed reply.
>
> However, rejected accounting messages are dropped. The RADIUS spec does
> not specify how to reject accounting messages, so there's no
> Accounting-Rejected message type to send back. You get drops instead.
>
> Thanks,
> Heikki
>

hmm so, are you saying radiator after proxying out my POD/COA requests, 
and after i then convert the packet to an accounting packet and log it, 
radiator is actually expecting that the POD/COA reply coming back is 
actually an accounting reply and does not relay it to the radpwtst?

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] Radius domain only auth, with password='cisco'

[Michael]

Has anyone ever seen a situation where, for every authentication attempt 
to a radiator system from a cisco device, there is an authentication 
attempt right before it that appears to be:

- a domain (the username with the 'username@' part stripped off).
- plain text password is always 'cisco'.
- Service-Type = Outbound-User

if I remove this line from the cisco lns:
aaa authorization network TEST group TEST
...the extra auth attempts stop, but then my radius network static 
profiles don't work, so it's not a solution but it narrows down the problem.

my auth requests for the radiator system are essentially doubled due to 
this.  This only started happening recently.  Network guys sometimes are 
like a ticking time bomb and asking them can cause an explosion so i 
thought i would ask here.


Mike
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Radius domain only auth, with password='cisco'

[Michael]

i'm looking to stop it. not set it up.  i'm not sure what had 
enabled/configured it to start happening.  I guess this is probably the 
wrong place to ask.

On 06/11/13 04:56 PM, Hugh Irvine wrote:
> Hello Michael -
>
> This sounds like Cisco VPDN tunnelling.
>
> This example is from the standard “users” file in the Radiator distribution:
>
>
> # This example shows how to configure a Cisco VPDN circuit:
> open.com.au User-Password=cisco, Service-Type=Outbound-User
>  cisco-avpair = "vpdn:tunnel-id=cca-gw",
>  cisco-avpair = "vpdn:ip-addresses=1.2.3.4",
>  cisco-avpair = "vpdn:nas-password=pw",
>  cisco-avpair = "vpdn:gw-password=pw”
>
>
> regards
>
> Hugh
>
>
> On 7 Nov 2013, at 04:56, Michael  wrote:
>
>> Has anyone ever seen a situation where, for every authentication attempt
>> to a radiator system from a cisco device, there is an authentication
>> attempt right before it that appears to be:
>>
>> - a domain (the username with the 'username@' part stripped off).
>> - plain text password is always 'cisco'.
>> - Service-Type = Outbound-User
>>
>> if I remove this line from the cisco lns:
>> aaa authorization network TEST group TEST
>> ...the extra auth attempts stop, but then my radius network static
>> profiles don't work, so it's not a solution but it narrows down the problem.
>>
>> my auth requests for the radiator system are essentially doubled due to
>> this.  This only started happening recently.  Network guys sometimes are
>> like a ticking time bomb and asking them can cause an explosion so i
>> thought i would ask here.
>>
>>
>> Mike
>> ___
>> radiator mailing list
>> radiator@open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>
> --
>
> Hugh Irvine
> h...@open.com.au
>
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
> DIAMETER etc.
> Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
>
>

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Variables

[Michael]

to save other values, you have to place it in the Class attribute in the 
Reply packet going back to your device.  The Class should get saved in 
the device, and will be there when the Stop packet comes in.  I 
personally save a few values in the Class as coma separated values.  
When it comes back in, I have a PreHandlerHook to pull the Class 
attribute out, separate the values, and place them into their own 
attributes for later use and logging.  But if you just want to save 1 
value in the Class, and later log the Class value, no Hook should be needed.



Mike

On 26/11/13 02:20 PM, rohan.henry @cwjamaica.com wrote:

Thanks Hugh.

I am already seeing the attributes using trace 4. Just exploring other 
possible ways to obtain and store the Start time of a session without 
having to calculate using session time (Acct-Session-Time).


Rohan


On Mon, Nov 25, 2013 at 10:21 PM, Hugh Irvine > wrote:



Hello Rohan -

Most if not all of these attributes should be included in the
RADIUS accounting stop request, assuming RADIUS accounting is
turned on in the NAS device.

Note that there is a difference between "Event-Timestamp" as shown
below which may be sent by the NAS, and "Timestamp" which is
internal to Radiator.

Have a look at a trace 4 debug to see exactly what you are
receiving in the RADIUS accounting requests.

regards

Hugh


On 26 Nov 2013, at 08:26, rohan.henry @cwjamaica.com
 mailto:rohan.he...@cwjamaica.com>> wrote:

> Hello,
>
> Are values for any of the foll. attributes automatically stored
somewhere in Radiator where they can be fetched anytime during or
at the end of the session? For example the Timestamp attribute.
>
> If not, how can I store values for use later in or at the end of
the session?
>
> Attributes:
> Acct-Status-Type = Start
> User-Name =
> Event-Timestamp =
> Acct-Delay-Time =
> NAS-Identifier =
> Acct-Session-Id =
> NAS-IP-Address =
> Class =
> Service-Type =
> Framed-Protocol =
> Framed-Compression =
> Unisphere-Pppoe-Description =
> Framed-IP-Address =
> Framed-IP-Netmask =
> Calling-Station-Id =
> Connect-Info =
> NAS-Port-Type =
> NAS-Port =
> NAS-Port-Id =
> Acct-Authentic =
>
> Thanks.
>
> Regards,
> Rohan
> ___
> radiator mailing list
> radiator@open.com.au 
> http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP,
TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc.
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.




___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator


___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Variables

[Michael]

sample of the perl Hook?  Well, if you're going to just need 1 value, 
and you are ok with using the Class attribute directly, then you don't 
need a hook.  You would just need to configure:

AddToReply Class = "somevalue"
then, when the Stop comes back, the same Class value should be there.


but, here's a sample of what i do for multiple saved values in the 
Class. Notice how i load the values into new attributes.  Then i use/log 
those attributes:


sub {
  my $req = ${$_[0]};
  my $script_name = "hook.PreHandlerHook.pl";
  &main::log($main::LOG_DEBUG, "$script_name: executing.");

  if( $req->code eq 'Accounting-Request' ) {
if( my $class = $req->get_attr('Class') ) {
my( $zone, $uid, $authed_un, $old_zone, $un_only ) = ( 
split(',', $class) )[0,1,2,3,4];

$req->change_attr('zone', $zone) if $zone;
$req->change_attr('uid', $uid) if $uid;
$req->change_attr('auth-un', $authed_un) if $authed_un;

&main::log($main::LOG_DEBUG, "$script_name: loading csv values 
from Class into their own attributes: 
[zone=$zone,uid=$uid,auth-un=$authed_un,old_zone=$old_zone,un_only=$un_only]");

}
  }

# end sub
}




On 26/11/13 02:59 PM, rohan.henry @cwjamaica.com wrote:


Thanks Michael.

Would you be able to share a sample?


On Tue, Nov 26, 2013 at 2:39 PM, Michael <mailto:ri...@vianet.ca>> wrote:


to save other values, you have to place it in the Class attribute
in the Reply packet going back to your device.  The Class should
get saved in the device, and will be there when the Stop packet
comes in.  I personally save a few values in the Class as coma
separated values.  When it comes back in, I have a PreHandlerHook
to pull the Class attribute out, separate the values, and place
them into their own attributes for later use and logging.  But if
you just want to save 1 value in the Class, and later log the
Class value, no Hook should be needed.


Mike


On 26/11/13 02:20 PM, rohan.henry @cwjamaica.com
<http://cwjamaica.com> wrote:

Thanks Hugh.

I am already seeing the attributes using trace 4. Just exploring
other possible ways to obtain and store the Start time of a
session without having to calculate using session time
(Acct-Session-Time).

Rohan


On Mon, Nov 25, 2013 at 10:21 PM, Hugh Irvine mailto:h...@open.com.au>> wrote:


Hello Rohan -

Most if not all of these attributes should be included in the
RADIUS accounting stop request, assuming RADIUS accounting is
turned on in the NAS device.

Note that there is a difference between "Event-Timestamp" as
shown below which may be sent by the NAS, and "Timestamp"
which is internal to Radiator.

Have a look at a trace 4 debug to see exactly what you are
receiving in the RADIUS accounting requests.

regards

Hugh


On 26 Nov 2013, at 08:26, rohan.henry @cwjamaica.com
<http://cwjamaica.com> mailto:rohan.he...@cwjamaica.com>> wrote:

> Hello,
>
> Are values for any of the foll. attributes automatically
stored somewhere in Radiator where they can be fetched
anytime during or at the end of the session? For example the
Timestamp attribute.
>
> If not, how can I store values for use later in or at the
end of the session?
>
> Attributes:
> Acct-Status-Type = Start
> User-Name =
> Event-Timestamp =
> Acct-Delay-Time =
> NAS-Identifier =
> Acct-Session-Id =
> NAS-IP-Address =
> Class =
> Service-Type =
> Framed-Protocol =
> Framed-Compression =
> Unisphere-Pppoe-Description =
> Framed-IP-Address =
> Framed-IP-Netmask =
> Calling-Station-Id =
> Connect-Info =
> NAS-Port-Type =
> NAS-Port =
> NAS-Port-Id =
> Acct-Authentic =
>
> Thanks.
>
> Regards,
> Rohan
> ___
> radiator mailing list
> radiator@open.com.au <mailto:radiator@open.com.au>
> http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
h...@open.com.au <mailto:h...@open.com.au>

Radiator: the most portable, flexible and configurable RADIUS
server
anywhere. SQL, pro