rlm_acct_unique Issue
Hi,
We're using FreeRADIUS 2.1.6, and have rlm_acct_unique configured as per
the below:
acct_unique {
key = User-Name, Framed-IP-Address, Acct-Session-Id
}
Over the past couple of days we've noticed that the unique session ID
calculated by the module during interim updates is changing mid session
for some users, although none of the attributes defined in the
configuration are changing between requests.
Here's an example for a session that had started on 2009-09-06 at 00:31:28:
Mon Sep 7 05:00:23 2009
Acct-Session-Id = 01BCBC45
Framed-Protocol = PPP
Framed-IP-Address = xxx.xxx.xxx.xxx
User-Name = u...@realm
Cisco-AVPair = connect-progress=LAN Ses Up
Cisco-AVPair = nas-tx-speed=7349000
Cisco-AVPair = nas-rx-speed=1000
Acct-Session-Time = 102534
Acct-Input-Octets = 5792373
Acct-Output-Octets = 8666851
Acct-Input-Packets = 79786
Acct-Output-Packets = 54731
Acct-Authentic = RADIUS
Acct-Status-Type = Interim-Update
NAS-Port-Type = Virtual
Cisco-NAS-Port = Uniq-Sess-ID40
NAS-Port = 40
Service-Type = Framed-User
NAS-IP-Address = xxx.xxx.xxx.xxx
Acct-Delay-Time = 45
Acct-Unique-Session-Id = 3c17c916d8e9ff20
Timestamp = 1252296023
Request-Authenticator = Verified
Mon Sep 7 05:28:24 2009
Acct-Session-Id = 01BCBC45
Framed-Protocol = PPP
Framed-IP-Address = xxx.xxx.xxx.xxx
User-Name = u...@realm
Cisco-AVPair = connect-progress=LAN Ses Up
Cisco-AVPair = nas-tx-speed=7349000
Cisco-AVPair = nas-rx-speed=1000
Acct-Session-Time = 104260
Acct-Input-Octets = 5895021
Acct-Output-Octets = 8838223
Acct-Input-Packets = 81164
Acct-Output-Packets = 55643
Acct-Authentic = RADIUS
Acct-Status-Type = Interim-Update
NAS-Port-Type = Virtual
Cisco-NAS-Port = Uniq-Sess-ID40
NAS-Port = 40
Service-Type = Framed-User
NAS-IP-Address = xxx.xxx.xxx.xxx
Acct-Delay-Time = 0
Acct-Unique-Session-Id = fb0d91180bc7523e
Timestamp = 1252297704
Request-Authenticator = Verified
I've hidden the Framed-IP-Address and User-Name attributes, but they
were identical in both requests.
Prior to 05:28:2 today, the unique session ID was always returned as
3c17c916d8e9ff20, and since 05:28:24, it has been returned as
fb0d91180bc7523e.
The only common factor with the sessions where this has happened is the
Acct-Delay-Time attribute being set to 45 in the last logged request
before the ID had changed, but I can't see any evidence on the server of
a delay, or any issues that may have caused a delay, around this time.
Does anyone know what might be causing this?
Thanks,
Tim
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: rlm_acct_unique Issue
Does anyone know what might be causing this?
The acct_unique configuration is being overridden by the defaults in
/etc/freeradius/modules/acct_unique...
acct_unique {
key = User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address,
NAS-Port
}
And the Client-IP-Address is changing mid session.
Now we have to update a few thousand running sessions, shortly after
removing the defaults and restarting freeradius.
Does anyone have any equivalent Perl/Python code to the add_unique_id
function in rlm_acct_unique.c?
Thanks,
Tim
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
MySQL 5.1 Partitions FreeRADIUS
Hi, Has anyone had any success in implementing MySQL 5.1's partitions to increase backend performance for FreeRADIUS? Thanks, Tim - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Peculiar Input/Output Octet Data In Alive/Stop Packets
Hi, The data transfer figures sent in these accounting packets are important to us because we have capped services as well as unmetered. Without being able to accurately keep track of the data transferred during sessions, it is impossible to tell if users are exceeding the caps. This in turn means that they can receive the same service as the unmetered users at a much cheaper rate. I have written an application to analyse the incoming alive and stop packets to gather the input and output octet values and to produce daily transfer statistics. When it determines that a transfer value is of a timestamp type, it ignores the data. But as some user's sessions only ever receive this type their transfer stats are never updated. Kind regards, Tim O'Donovan Seferovic Edvin wrote: Hello, is the timestamp in the Accounting packet really important for your monitoring puroposes? Regards, Edvin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] g] On Behalf Of Tim O'Donovan Sent: Dienstag, 13. Juni 2006 21:19 To: freeradius-users@lists.freeradius.org Subject: Peculiar Input/Output Octet Data In Alive/Stop Packets Hi, The majority of alive and stop packets received by our FreeRadius server contain correct input and output octet data, but there are a number of users that receive a UNIX time formatted integer translating to midnight of the day the packet was received instead of the correct data. Here's an example of such a packet, note the output octets: Tue Jun 13 16:05:30 2006 User-Name = [EMAIL PROTECTED] NAS-IP-Address = xxx.xxx.xxx.xxx NAS-Port = 29 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = xxx.xxx.xxx.xxx Proxy-State = 0x42543030326436336366643134 Acct-Status-Type = Alive Acct-Delay-Time = 0 Acct-Input-Octets = 899858807 Acct-Output-Octets = 1150153200 Acct-Session-Id = 0002576E Acct-Authentic = RADIUS Acct-Session-Time = 1583103 Acct-Input-Packets = 7437599 Acct-Output-Packets = 8973389 NAS-Port-Type = Virtual Client-IP-Address = xxx.xxx.xxx.xxx Acct-Unique-Session-Id = 372fc40c32b2b500 Timestamp = 1150211130 The output octets figure 1150153200 translates to Tue Jun 13 00:00:00 2006 GMT. We currently do not have direct access to the NAS servers that are sending across this data, but we have worked together with our provider towards replicating this through testing. In each case the expected data is reported and we have yet to reproduce the error manually. As the data transfer has only recently become an area we wish to monitor and log, it is impossible to tell whether this has always been occurring. Has anyone experienced this before? Any help or advice would be greatly appreciated. Kind regards, Tim O'Donovan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Peculiar Input/Output Octet Data In Alive/Stop Packets
Resolved - turned out to be a problem at the NAS provider's end. Kind regards, Tim O'Donovan Tim O'Donovan wrote: Hi, The majority of alive and stop packets received by our FreeRadius server contain correct input and output octet data, but there are a number of users that receive a UNIX time formatted integer translating to midnight of the day the packet was received instead of the correct data. Here's an example of such a packet, note the output octets: Tue Jun 13 16:05:30 2006 User-Name = [EMAIL PROTECTED] NAS-IP-Address = xxx.xxx.xxx.xxx NAS-Port = 29 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = xxx.xxx.xxx.xxx Proxy-State = 0x42543030326436336366643134 Acct-Status-Type = Alive Acct-Delay-Time = 0 Acct-Input-Octets = 899858807 Acct-Output-Octets = 1150153200 Acct-Session-Id = 0002576E Acct-Authentic = RADIUS Acct-Session-Time = 1583103 Acct-Input-Packets = 7437599 Acct-Output-Packets = 8973389 NAS-Port-Type = Virtual Client-IP-Address = xxx.xxx.xxx.xxx Acct-Unique-Session-Id = 372fc40c32b2b500 Timestamp = 1150211130 The output octets figure 1150153200 translates to Tue Jun 13 00:00:00 2006 GMT. We currently do not have direct access to the NAS servers that are sending across this data, but we have worked together with our provider towards replicating this through testing. In each case the expected data is reported and we have yet to reproduce the error manually. As the data transfer has only recently become an area we wish to monitor and log, it is impossible to tell whether this has always been occurring. Has anyone experienced this before? Any help or advice would be greatly appreciated. Kind regards, Tim O'Donovan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Peculiar Input/Output Octet Data In Alive/Stop Packets
Hi, The majority of alive and stop packets received by our FreeRadius server contain correct input and output octet data, but there are a number of users that receive a UNIX time formatted integer translating to midnight of the day the packet was received instead of the correct data. Here's an example of such a packet, note the output octets: Tue Jun 13 16:05:30 2006 User-Name = [EMAIL PROTECTED] NAS-IP-Address = xxx.xxx.xxx.xxx NAS-Port = 29 Service-Type = Framed-User Framed-Protocol = PPP Framed-IP-Address = xxx.xxx.xxx.xxx Proxy-State = 0x42543030326436336366643134 Acct-Status-Type = Alive Acct-Delay-Time = 0 Acct-Input-Octets = 899858807 Acct-Output-Octets = 1150153200 Acct-Session-Id = 0002576E Acct-Authentic = RADIUS Acct-Session-Time = 1583103 Acct-Input-Packets = 7437599 Acct-Output-Packets = 8973389 NAS-Port-Type = Virtual Client-IP-Address = xxx.xxx.xxx.xxx Acct-Unique-Session-Id = 372fc40c32b2b500 Timestamp = 1150211130 The output octets figure 1150153200 translates to Tue Jun 13 00:00:00 2006 GMT. We currently do not have direct access to the NAS servers that are sending across this data, but we have worked together with our provider towards replicating this through testing. In each case the expected data is reported and we have yet to reproduce the error manually. As the data transfer has only recently become an area we wish to monitor and log, it is impossible to tell whether this has always been occurring. Has anyone experienced this before? Any help or advice would be greatly appreciated. Kind regards, Tim O'Donovan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Is rlm_perl a viable solution for production environments yet?
Hi, I'm considering writing some Perl for use with the rlm_perl module, but before I do I need to know whether the module is ready for use in a production environment. Has anyone had any experience (both positive and negative) with rlm_perl, performance wise, that they could share with me to help my decision? Thanks. Kind regards, Tim O'Donovan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Rejecting auth requests
Hi, But wouldn't that require using the users file instead of MySQL? Can the radcheck table be used in the same way? What I mean is, can a user have multiple entries within the table? At the moment we just have a single entry for each user: ++---+---++---+ | id | UserName | Attribute | op | Value | ++---+---++---+ | 1 | [EMAIL PROTECTED] | Password | == | test | ++---+---++---+ But would this accomplish the same as using the users file: ++---+---++---+ | id | UserName | Attribute | op | Value | ++---+---++---+ | 1 | [EMAIL PROTECTED] | Password | == | test | | 2 | [EMAIL PROTECTED] | Auth-Type | := | Reject| ++---+---++---+ I'm not going to be able to actually try this for myself until Monday, but any advice in advance would be greatly appreciated. Kind regards, Tim O'Donovan Joe Maimon wrote: Tim O'Donovan wrote: Hi, Does anyone know of a simple way to invoke an Access-Reject for a user at the authenticate stage? Without changing the stored password. I have tried altering the 'op' to != and all manner of other combinations from within the rad_check table without success. We would just like to be able to ban/unban a user with a single SQL update statement. in the users file, setting a check item like this userAuth-Type := Reject Seems to do the job. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Rejecting auth requests
Hi, Does anyone know of a simple way to invoke an Access-Reject for a user at the authenticate stage? Without changing the stored password. I have tried altering the 'op' to != and all manner of other combinations from within the rad_check table without success. We would just like to be able to ban/unban a user with a single SQL update statement. Kind regards, Tim O'Donovan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: i want to add new attributs
Thanks Alan. That's why radrelay sets Acct-Delay-Time, so that the timestamp of the original request can be calculated as received packet time - Acct-Delay-Time I didn't know radrelay could do that. This may sound strange, but does it do this automatically without any intervention, or does it need to be set manually? The reason I ask is that the logged AcctStartTime and AcctStopTime differs (by up to 2mins) on the secondary radius server. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: i want to add new attributs
I have tried altering the insert/update strings within sql.conf,
specifically by changing the %S variable to %{Timestamp} (and altering
the table definition to except an integer) but to no avail. It just
inserts a 0. I have searched the dictionary files for an attribute named
Timestamp but the only equivalent is Event-Timestamp.
Here's an example from the detail file:
Mon Oct 10 22:25:37 2005
User-Name = [EMAIL PROTECTED]
NAS-IP-Address = *
NAS-Port = 328
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Address = *
Proxy-State = 0x42543030326436336366643134
Acct-Status-Type = Start
Acct-Delay-Time = 0
Acct-Session-Id = 000151A7
Acct-Authentic = RADIUS
NAS-Port-Type = Virtual
Client-IP-Address = *
Acct-Unique-Session-Id = e74e5806dc266e0d
Timestamp = 1128979537
So it is recognising the Timestamp attribute, as you suggested. Where am
I going wrong?
Kind regards,
Tim O'Donovan
Joe Maimon wrote:
Tim O'Donovan wrote:
Hi Harish,
I am trying to accomplish almost exactly the same thing on our
freeradius setup. Our NAS servers send us an additional attribute,
'Timestamp', in UNIX time, but at the moment our radius server is
ignoring it altogether.
We are using MySQL for accounting etc and the default setup logs
entries using the current time of insertion, not the time sent by the
NAS. We have a secondary radius server that is replicated by using
radrelay on the primary server which runs every minute or so. This is
the main problem as the time logged to the secondary server is
different to the primary.
You can do anything you would like with the SQL logging by editing the
sql.conf file, which contains the sql query strings the radius server uses.
I believe the solution involves editing the dictionary file (found in
raddb dir) to add the new attribute.
You would only need to do that if the server did not recognize the
attribute (translating it from a numerical id to a string name). If the
server logs the attribute into the detail file with the proper name or
the server prints its name in debugging mode, there is no need for that.
Although I am not 100% if that is
enough for it to come into effect. The standard attributes can be
found here: http://www.iana.org/assignments/radius-types.
When I find a complete solution I will let you know. :-)
Let me know how you get on.
Kind regards,
Tim O'Donovan
Harish Gupta wrote:
Hello All,
I m Harish Gupta from india, i m working in a Telecom ISP company
as system Administator and I m using freeradius application on linux
platform(CentOS4.0) for my dialup users . its working fine, but i
want to add a new attribute like caller-id and calling-id how can
add these attributs plz. help me .
Thanx Regards
Harish Gupta
System Aministrator
India
+919828032258
This email message is personal statement of the sender and shall not
be construed as statement of Shyam Telelink Limited. The contents of
this email and attached documents (if any) may contain confidential
and privileged material for the sole use of the intended recipient.
Any unauthorized review, dissemination, use or distribution by others
is strictly prohibited. If you have received the message in error,
please advise the sender by reply email and delete the message. The
recipient is also advised to get the statement confirmed in writing
from the company before acting on the contents of this email.
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
