Re: [RADIATOR] verifying online sessions with SNMP
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] Accounting records are not written to database
Hugh, re: server crash see config and log files attached. Rohan On Sat, 3 Nov 2012 09:06:44 +1100 Hugh Irvine wrote: > >Hello Rohan - > >The easiest way to do this is to store only the Stop records, and calculate >the start time from the attributes present in the accounting stop request. > >Something like this (the value is in epoch seconds): > > Timestamp - Acct-Session-Time - Acct-Delay-Time > >For the crash I will need to see the logfile that immediately precedes it >together with the configuration file you are using. > >regards > >Hugh > > >On 3 Nov 2012, at 02:24, wrote: > >> Hugh, >> >> Now that records are being written to the database, I want a single record >> per session that includes both Stop and Start times like below. >> >> User_Name, NAS_IP_Address, NAS_Port, Framed_IP_Address, Acct_Start_Time, >> Acct_Stop_Time, Acct_Session_ID >> jwilliams12 208.138.43.123 805306450 72.27.33.224 Nov 2, 2012 12:21:04 AM >> Nov 2, 2012 1:21:16 AM, erx TenGigabitEthernet 3/0/0.37:123-82:1830880926 >> >> So the record is added to the accounting database at the end of a session >> and includes both Stop and Start times. >> >> Added to that is the issue I have where Radiator crashes when I try to use >> the Simultaneous-Use features. >> >> Thanks. >> >> On Fri, 2 Nov 2012 17:46:58 +1100 >> Hugh Irvine wrote: >>> >>> Hello Rohan - >>> >>> Can you please explain exactly what you are trying to do? >>> >>> It is normal for you to get two records in your accounting table, as that >>> is what you have configured. >>> >>> If you can tell us what you are trying to achieve we will be able to make >>> sensible suggestions. >>> >>> regards >>> >>> Hugh >>> >>> >>> On 2 Nov 2012, at 09:38, wrote: >>> Thanks Michael, I was able to go further with the advice using the AuthByPolicy and AuthBy GROUP under the existing Handler. Only that two records are added to my accounting database for a single session - one at Start and one at Stop. AddToRequest SERVICESTATUS = ACTIVE SessionDatabase SQLSDB # MaxSessions 1 RejectHasReason AuthByPolicy ContinueAlways AuthBy SQLAccounting AuthByPolicy ContinueWhileIgnore AuthBy xDSL Regards, Rohan On Thu, 01 Nov 2012 17:45:18 -0400 Michael wrote: > 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,A
Re: [RADIATOR] Accounting records are not written to database
Hi, On Mon, 5 Nov 2012, rohan.he...@cwjamaica.com wrote: > Hugh, > > re: server crash see config and log files attached. What exactly do you mean when you say the server crashes ? I cannot find any perl exceptions in the logs and nothing at first sight in the config that would cause anything like that. The only time the radiator process had died on me is when I have a syntax error in a hook or module. Greetings Christian > > Rohan > > On Sat, 3 Nov 2012 09:06:44 +1100 > Hugh Irvine wrote: >> >> Hello Rohan - >> >> The easiest way to do this is to store only the Stop records, and calculate >> the start time from the attributes present in the accounting stop request. >> >> Something like this (the value is in epoch seconds): >> >> Timestamp - Acct-Session-Time - Acct-Delay-Time >> >> For the crash I will need to see the logfile that immediately precedes it >> together with the configuration file you are using. >> >> regards >> >> Hugh >> >> >> On 3 Nov 2012, at 02:24, wrote: >> >>> Hugh, >>> >>> Now that records are being written to the database, I want a single record >>> per session that includes both Stop and Start times like below. >>> >>> User_Name, NAS_IP_Address, NAS_Port, Framed_IP_Address, Acct_Start_Time, >>> Acct_Stop_Time, Acct_Session_ID >>> jwilliams12 208.138.43.123 805306450 72.27.33.224 Nov 2, 2012 12:21:04 AM >>> Nov 2, 2012 1:21:16 AM, erx TenGigabitEthernet 3/0/0.37:123-82:1830880926 >>> >>> So the record is added to the accounting database at the end of a session >>> and includes both Stop and Start times. >>> >>> Added to that is the issue I have where Radiator crashes when I try to use >>> the Simultaneous-Use features. >>> >>> Thanks. >>> >>> On Fri, 2 Nov 2012 17:46:58 +1100 >>> Hugh Irvine wrote: Hello Rohan - Can you please explain exactly what you are trying to do? It is normal for you to get two records in your accounting table, as that is what you have configured. If you can tell us what you are trying to achieve we will be able to make sensible suggestions. regards Hugh On 2 Nov 2012, at 09:38, wrote: > Thanks Michael, > > > > I was able to go further with the advice using the AuthByPolicy and > AuthBy GROUP under the existing Handler. Only that two records are added > to my accounting database for a single session - one at Start and one at > Stop. > > > AddToRequest SERVICESTATUS = ACTIVE > SessionDatabase SQLSDB > # MaxSessions 1 > RejectHasReason > > AuthByPolicy ContinueAlways > AuthBy SQLAccounting > > AuthByPolicy ContinueWhileIgnore > AuthBy xDSL > > > > Regards, > > Rohan > > > > On Thu, 01 Nov 2012 17:45:18 -0400 > > Michael wrote: > >> 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 > > AcctColumnDe
Re: [RADIATOR] Accounting records are not written to database
Hello Rohan - To see what is happening with the crash you should run radiusd from the command line so you can see the relevant Perl messages. Something like this (with your local pathnames): /usr/bin/perl /usr/local/bin/radiusd -foreground -log_stdout -trace 4 -config_file /etc/radiator/radius.cfg BTW - I don't think your CountQuery is correct as it will never find all existing sessions for that particular user. regards Hugh On 6 Nov 2012, at 09:30, wrote: > Hugh, > > re: server crash see config and log files attached. > > Rohan > > On Sat, 3 Nov 2012 09:06:44 +1100 > Hugh Irvine wrote: >> >> Hello Rohan - >> >> The easiest way to do this is to store only the Stop records, and calculate >> the start time from the attributes present in the accounting stop request. >> >> Something like this (the value is in epoch seconds): >> >> Timestamp - Acct-Session-Time - Acct-Delay-Time >> >> For the crash I will need to see the logfile that immediately precedes it >> together with the configuration file you are using. >> >> regards >> >> Hugh >> >> >> On 3 Nov 2012, at 02:24, wrote: >> >>> Hugh, >>> >>> Now that records are being written to the database, I want a single record >>> per session that includes both Stop and Start times like below. >>> >>> User_Name, NAS_IP_Address, NAS_Port, Framed_IP_Address, Acct_Start_Time, >>> Acct_Stop_Time, Acct_Session_ID >>> jwilliams12 208.138.43.123 805306450 72.27.33.224 Nov 2, 2012 12:21:04 AM >>> Nov 2, 2012 1:21:16 AM, erx TenGigabitEthernet 3/0/0.37:123-82:1830880926 >>> >>> So the record is added to the accounting database at the end of a session >>> and includes both Stop and Start times. >>> >>> Added to that is the issue I have where Radiator crashes when I try to use >>> the Simultaneous-Use features. >>> >>> Thanks. >>> >>> On Fri, 2 Nov 2012 17:46:58 +1100 >>> Hugh Irvine wrote: Hello Rohan - Can you please explain exactly what you are trying to do? It is normal for you to get two records in your accounting table, as that is what you have configured. If you can tell us what you are trying to achieve we will be able to make sensible suggestions. regards Hugh On 2 Nov 2012, at 09:38, wrote: > Thanks Michael, > > > > I was able to go further with the advice using the AuthByPolicy and > AuthBy GROUP under the existing Handler. Only that two records are added > to my accounting database for a single session - one at Start and one at > Stop. > > > AddToRequest SERVICESTATUS = ACTIVE > SessionDatabase SQLSDB > # MaxSessions 1 > RejectHasReason > > AuthByPolicy ContinueAlways > AuthBy SQLAccounting > > AuthByPolicy ContinueWhileIgnore > AuthBy xDSL > > > > Regards, > > Rohan > > > > On Thu, 01 Nov 2012 17:45:18 -0400 > > Michael wrote: > >> 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 > > #Dis
