FreeRADIUS 3 - discard certain accounting types
Clash Royale CLAN TAG#URR8PPP
up vote
0
down vote
favorite
I am using FreeRADIUS 3.0.13 on a CentOS 7 server for accounting data from a telephony device, and we want to simply drop certain record types - specifically, for this application, I want to only record Stop messages.
We're specifically writing to a detail log, and then using the bufferedsql module to read from that log, and write to the database server. Everything is working normally, until I get a record such as an Accounting-On, or Start. I've worked around some of this by writing the unwanted records to a database that simply gets purged, but I'd prefer a more elegant solution.
One of the things I saw in the documentation was to replace the query with a SELECT TRUE;
, but since this doesn't update records, FreeRADIUS seems to choke on it. It reports "No response to request" and keeps the record in the detail file, attempting to re-process it every 30 seconds.
When I run radiusd -X
, I see output similar the following. This output is from a received Accounting-On packet, and I just want to discard the message:
(22) accounting
(22) sql: EXPAND %tolower:type.%Acct-Status-Type.query
(22) sql: --> type.accounting-on.query
(22) sql: Using query template 'query'
rlm_sql (sql): Reserved connection (0)
(22) sql: EXPAND %User-Name
(22) sql: -->
(22) sql: SQL-User-Name set to ''
(22) sql: EXPAND SELECT TRUE;
(22) sql: --> SELECT TRUE;
(22) sql: Executing query: SELECT TRUE;
(22) sql: SQL query returned: success
(22) sql: -1 record(s) updated
(22) sql: No additional queries configured
rlm_sql (sql): Released connection (0)
(22) [sql] = noop
(22) # accounting = noop
(22) detail (/var/log/radius/radacct/detail-ca-fallback/detail-ca-fallback-log): No response to request. Will retry in 30 seconds
(22) Finished request
(22) Cleaning up request packet ID 0 with timestamp +660
Ready to process requests
How can I configure my dialup.conf to simply drop these types of accounting records? The device generating the accounting data does not support any kind of configuration to only send specific accounting messages.
This is the relevant section of my custom dialup.conf file:
accounting
reference = "%tolower:type.%Acct-Status-Type.query"
type
accounting-on
# This is a no-op. We don't log this anywhere.
query = "SELECT TRUE;"
accounting-off
# This is a no-op. We don't log this anywhere.
query = "SELECT TRUE;"
start
# This is a no-op. We don't log this anywhere.
query = "INSERT INTO blackhole
(<snip - fields>)
VALUES (<snip - values>)"
interim-update
# This is a no-op. We don't log this anywhere.
uery = "INSERT INTO blackhole
(<snip - fields>)
VALUES (<snip - values>)"
stop
query = "INSERT INTO $....acct_table1
(<fields>)
VALUES (<values>)"
#
# No Acct-Status-Type == ignore the packet
#
none
query = "SELECT true"
radius freeradius
add a comment |Â
up vote
0
down vote
favorite
I am using FreeRADIUS 3.0.13 on a CentOS 7 server for accounting data from a telephony device, and we want to simply drop certain record types - specifically, for this application, I want to only record Stop messages.
We're specifically writing to a detail log, and then using the bufferedsql module to read from that log, and write to the database server. Everything is working normally, until I get a record such as an Accounting-On, or Start. I've worked around some of this by writing the unwanted records to a database that simply gets purged, but I'd prefer a more elegant solution.
One of the things I saw in the documentation was to replace the query with a SELECT TRUE;
, but since this doesn't update records, FreeRADIUS seems to choke on it. It reports "No response to request" and keeps the record in the detail file, attempting to re-process it every 30 seconds.
When I run radiusd -X
, I see output similar the following. This output is from a received Accounting-On packet, and I just want to discard the message:
(22) accounting
(22) sql: EXPAND %tolower:type.%Acct-Status-Type.query
(22) sql: --> type.accounting-on.query
(22) sql: Using query template 'query'
rlm_sql (sql): Reserved connection (0)
(22) sql: EXPAND %User-Name
(22) sql: -->
(22) sql: SQL-User-Name set to ''
(22) sql: EXPAND SELECT TRUE;
(22) sql: --> SELECT TRUE;
(22) sql: Executing query: SELECT TRUE;
(22) sql: SQL query returned: success
(22) sql: -1 record(s) updated
(22) sql: No additional queries configured
rlm_sql (sql): Released connection (0)
(22) [sql] = noop
(22) # accounting = noop
(22) detail (/var/log/radius/radacct/detail-ca-fallback/detail-ca-fallback-log): No response to request. Will retry in 30 seconds
(22) Finished request
(22) Cleaning up request packet ID 0 with timestamp +660
Ready to process requests
How can I configure my dialup.conf to simply drop these types of accounting records? The device generating the accounting data does not support any kind of configuration to only send specific accounting messages.
This is the relevant section of my custom dialup.conf file:
accounting
reference = "%tolower:type.%Acct-Status-Type.query"
type
accounting-on
# This is a no-op. We don't log this anywhere.
query = "SELECT TRUE;"
accounting-off
# This is a no-op. We don't log this anywhere.
query = "SELECT TRUE;"
start
# This is a no-op. We don't log this anywhere.
query = "INSERT INTO blackhole
(<snip - fields>)
VALUES (<snip - values>)"
interim-update
# This is a no-op. We don't log this anywhere.
uery = "INSERT INTO blackhole
(<snip - fields>)
VALUES (<snip - values>)"
stop
query = "INSERT INTO $....acct_table1
(<fields>)
VALUES (<values>)"
#
# No Acct-Status-Type == ignore the packet
#
none
query = "SELECT true"
radius freeradius
If you want to ignore certain messages, then do not build SQL queries for that.
â Rui F Ribeiro
May 7 at 20:42
When I commented out those queries, I continued to get warnings in the output saying that there was no query defined for that message type. Additionally, there were still accounting-on messages in the detail.work file which were blocking new data from being processed (in the detail) file.
â csyria
May 7 at 21:10
add a comment |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am using FreeRADIUS 3.0.13 on a CentOS 7 server for accounting data from a telephony device, and we want to simply drop certain record types - specifically, for this application, I want to only record Stop messages.
We're specifically writing to a detail log, and then using the bufferedsql module to read from that log, and write to the database server. Everything is working normally, until I get a record such as an Accounting-On, or Start. I've worked around some of this by writing the unwanted records to a database that simply gets purged, but I'd prefer a more elegant solution.
One of the things I saw in the documentation was to replace the query with a SELECT TRUE;
, but since this doesn't update records, FreeRADIUS seems to choke on it. It reports "No response to request" and keeps the record in the detail file, attempting to re-process it every 30 seconds.
When I run radiusd -X
, I see output similar the following. This output is from a received Accounting-On packet, and I just want to discard the message:
(22) accounting
(22) sql: EXPAND %tolower:type.%Acct-Status-Type.query
(22) sql: --> type.accounting-on.query
(22) sql: Using query template 'query'
rlm_sql (sql): Reserved connection (0)
(22) sql: EXPAND %User-Name
(22) sql: -->
(22) sql: SQL-User-Name set to ''
(22) sql: EXPAND SELECT TRUE;
(22) sql: --> SELECT TRUE;
(22) sql: Executing query: SELECT TRUE;
(22) sql: SQL query returned: success
(22) sql: -1 record(s) updated
(22) sql: No additional queries configured
rlm_sql (sql): Released connection (0)
(22) [sql] = noop
(22) # accounting = noop
(22) detail (/var/log/radius/radacct/detail-ca-fallback/detail-ca-fallback-log): No response to request. Will retry in 30 seconds
(22) Finished request
(22) Cleaning up request packet ID 0 with timestamp +660
Ready to process requests
How can I configure my dialup.conf to simply drop these types of accounting records? The device generating the accounting data does not support any kind of configuration to only send specific accounting messages.
This is the relevant section of my custom dialup.conf file:
accounting
reference = "%tolower:type.%Acct-Status-Type.query"
type
accounting-on
# This is a no-op. We don't log this anywhere.
query = "SELECT TRUE;"
accounting-off
# This is a no-op. We don't log this anywhere.
query = "SELECT TRUE;"
start
# This is a no-op. We don't log this anywhere.
query = "INSERT INTO blackhole
(<snip - fields>)
VALUES (<snip - values>)"
interim-update
# This is a no-op. We don't log this anywhere.
uery = "INSERT INTO blackhole
(<snip - fields>)
VALUES (<snip - values>)"
stop
query = "INSERT INTO $....acct_table1
(<fields>)
VALUES (<values>)"
#
# No Acct-Status-Type == ignore the packet
#
none
query = "SELECT true"
radius freeradius
I am using FreeRADIUS 3.0.13 on a CentOS 7 server for accounting data from a telephony device, and we want to simply drop certain record types - specifically, for this application, I want to only record Stop messages.
We're specifically writing to a detail log, and then using the bufferedsql module to read from that log, and write to the database server. Everything is working normally, until I get a record such as an Accounting-On, or Start. I've worked around some of this by writing the unwanted records to a database that simply gets purged, but I'd prefer a more elegant solution.
One of the things I saw in the documentation was to replace the query with a SELECT TRUE;
, but since this doesn't update records, FreeRADIUS seems to choke on it. It reports "No response to request" and keeps the record in the detail file, attempting to re-process it every 30 seconds.
When I run radiusd -X
, I see output similar the following. This output is from a received Accounting-On packet, and I just want to discard the message:
(22) accounting
(22) sql: EXPAND %tolower:type.%Acct-Status-Type.query
(22) sql: --> type.accounting-on.query
(22) sql: Using query template 'query'
rlm_sql (sql): Reserved connection (0)
(22) sql: EXPAND %User-Name
(22) sql: -->
(22) sql: SQL-User-Name set to ''
(22) sql: EXPAND SELECT TRUE;
(22) sql: --> SELECT TRUE;
(22) sql: Executing query: SELECT TRUE;
(22) sql: SQL query returned: success
(22) sql: -1 record(s) updated
(22) sql: No additional queries configured
rlm_sql (sql): Released connection (0)
(22) [sql] = noop
(22) # accounting = noop
(22) detail (/var/log/radius/radacct/detail-ca-fallback/detail-ca-fallback-log): No response to request. Will retry in 30 seconds
(22) Finished request
(22) Cleaning up request packet ID 0 with timestamp +660
Ready to process requests
How can I configure my dialup.conf to simply drop these types of accounting records? The device generating the accounting data does not support any kind of configuration to only send specific accounting messages.
This is the relevant section of my custom dialup.conf file:
accounting
reference = "%tolower:type.%Acct-Status-Type.query"
type
accounting-on
# This is a no-op. We don't log this anywhere.
query = "SELECT TRUE;"
accounting-off
# This is a no-op. We don't log this anywhere.
query = "SELECT TRUE;"
start
# This is a no-op. We don't log this anywhere.
query = "INSERT INTO blackhole
(<snip - fields>)
VALUES (<snip - values>)"
interim-update
# This is a no-op. We don't log this anywhere.
uery = "INSERT INTO blackhole
(<snip - fields>)
VALUES (<snip - values>)"
stop
query = "INSERT INTO $....acct_table1
(<fields>)
VALUES (<values>)"
#
# No Acct-Status-Type == ignore the packet
#
none
query = "SELECT true"
radius freeradius
asked May 7 at 20:30
csyria
80117
80117
If you want to ignore certain messages, then do not build SQL queries for that.
â Rui F Ribeiro
May 7 at 20:42
When I commented out those queries, I continued to get warnings in the output saying that there was no query defined for that message type. Additionally, there were still accounting-on messages in the detail.work file which were blocking new data from being processed (in the detail) file.
â csyria
May 7 at 21:10
add a comment |Â
If you want to ignore certain messages, then do not build SQL queries for that.
â Rui F Ribeiro
May 7 at 20:42
When I commented out those queries, I continued to get warnings in the output saying that there was no query defined for that message type. Additionally, there were still accounting-on messages in the detail.work file which were blocking new data from being processed (in the detail) file.
â csyria
May 7 at 21:10
If you want to ignore certain messages, then do not build SQL queries for that.
â Rui F Ribeiro
May 7 at 20:42
If you want to ignore certain messages, then do not build SQL queries for that.
â Rui F Ribeiro
May 7 at 20:42
When I commented out those queries, I continued to get warnings in the output saying that there was no query defined for that message type. Additionally, there were still accounting-on messages in the detail.work file which were blocking new data from being processed (in the detail) file.
â csyria
May 7 at 21:10
When I commented out those queries, I continued to get warnings in the output saying that there was no query defined for that message type. Additionally, there were still accounting-on messages in the detail.work file which were blocking new data from being processed (in the detail) file.
â csyria
May 7 at 21:10
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Comment out (or remove) the sections to make it clear to others maintaining your config that you're not processing these message types. Then in the accounting section only call the SQL module if the Acct-Status-Type value matches one of the types you want to process.
In your example, you seem to be ignoring all types which isn't terribly useful. Here's an example with only processing starts and stops.
accounting
switch "%Acct-Status-Type"
case 'Start'
sql
case 'Stop'
sql
# Do nothing for other types
See man unlang
for policy language documentation.
This is more or less what I ended up doing (handled this before the detail log instead of in the SQL module). I did have to add an if (noop) ok block to keep the ignored messages types (like Accounting-On) from being retransmitted.
â csyria
May 18 at 9:48
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Comment out (or remove) the sections to make it clear to others maintaining your config that you're not processing these message types. Then in the accounting section only call the SQL module if the Acct-Status-Type value matches one of the types you want to process.
In your example, you seem to be ignoring all types which isn't terribly useful. Here's an example with only processing starts and stops.
accounting
switch "%Acct-Status-Type"
case 'Start'
sql
case 'Stop'
sql
# Do nothing for other types
See man unlang
for policy language documentation.
This is more or less what I ended up doing (handled this before the detail log instead of in the SQL module). I did have to add an if (noop) ok block to keep the ignored messages types (like Accounting-On) from being retransmitted.
â csyria
May 18 at 9:48
add a comment |Â
up vote
1
down vote
accepted
Comment out (or remove) the sections to make it clear to others maintaining your config that you're not processing these message types. Then in the accounting section only call the SQL module if the Acct-Status-Type value matches one of the types you want to process.
In your example, you seem to be ignoring all types which isn't terribly useful. Here's an example with only processing starts and stops.
accounting
switch "%Acct-Status-Type"
case 'Start'
sql
case 'Stop'
sql
# Do nothing for other types
See man unlang
for policy language documentation.
This is more or less what I ended up doing (handled this before the detail log instead of in the SQL module). I did have to add an if (noop) ok block to keep the ignored messages types (like Accounting-On) from being retransmitted.
â csyria
May 18 at 9:48
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Comment out (or remove) the sections to make it clear to others maintaining your config that you're not processing these message types. Then in the accounting section only call the SQL module if the Acct-Status-Type value matches one of the types you want to process.
In your example, you seem to be ignoring all types which isn't terribly useful. Here's an example with only processing starts and stops.
accounting
switch "%Acct-Status-Type"
case 'Start'
sql
case 'Stop'
sql
# Do nothing for other types
See man unlang
for policy language documentation.
Comment out (or remove) the sections to make it clear to others maintaining your config that you're not processing these message types. Then in the accounting section only call the SQL module if the Acct-Status-Type value matches one of the types you want to process.
In your example, you seem to be ignoring all types which isn't terribly useful. Here's an example with only processing starts and stops.
accounting
switch "%Acct-Status-Type"
case 'Start'
sql
case 'Stop'
sql
# Do nothing for other types
See man unlang
for policy language documentation.
answered May 10 at 7:35
Arran Cudbard-Bell
1864
1864
This is more or less what I ended up doing (handled this before the detail log instead of in the SQL module). I did have to add an if (noop) ok block to keep the ignored messages types (like Accounting-On) from being retransmitted.
â csyria
May 18 at 9:48
add a comment |Â
This is more or less what I ended up doing (handled this before the detail log instead of in the SQL module). I did have to add an if (noop) ok block to keep the ignored messages types (like Accounting-On) from being retransmitted.
â csyria
May 18 at 9:48
This is more or less what I ended up doing (handled this before the detail log instead of in the SQL module). I did have to add an if (noop) ok block to keep the ignored messages types (like Accounting-On) from being retransmitted.
â csyria
May 18 at 9:48
This is more or less what I ended up doing (handled this before the detail log instead of in the SQL module). I did have to add an if (noop) ok block to keep the ignored messages types (like Accounting-On) from being retransmitted.
â csyria
May 18 at 9:48
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f442403%2ffreeradius-3-discard-certain-accounting-types%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
If you want to ignore certain messages, then do not build SQL queries for that.
â Rui F Ribeiro
May 7 at 20:42
When I commented out those queries, I continued to get warnings in the output saying that there was no query defined for that message type. Additionally, there were still accounting-on messages in the detail.work file which were blocking new data from being processed (in the detail) file.
â csyria
May 7 at 21:10