FreeRADIUS 3 - discard certain accounting types

The name of the pictureThe name of the pictureThe name of the pictureClash 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"









share|improve this question



















  • 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














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"









share|improve this question



















  • 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












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"









share|improve this question











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"











share|improve this question










share|improve this question




share|improve this question









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
















  • 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










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.






share|improve this answer





















  • 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










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















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






























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.






share|improve this answer





















  • 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














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.






share|improve this answer





















  • 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












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.






share|improve this answer













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.







share|improve this answer













share|improve this answer



share|improve this answer











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
















  • 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












 

draft saved


draft discarded


























 


draft saved


draft discarded














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













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?