Project

General

Profile

Bug #4131

CP RADIUS accounting not working

Added by Chris Buechler over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
Start date:
12/19/2014
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.2
Affected Architecture:

Description

Captive portal RADIUS accounting sends only 0 for Acct-Input and Output Packets, Octets, and Gigawords.

Associated revisions

Revision 553803f4 (diff)
Added by Ermal Luçi over 4 years ago

Correctly call function for retrieving stats from ipfw. Fixes #4131

Revision b9276845 (diff)
Added by Ermal Luçi over 4 years ago

Correctly call function for retrieving stats from ipfw. Fixes #4131

Revision f539af76 (diff)
Added by Ermal Luçi over 4 years ago

Ticket #4131 before formatting the mac extract the needed statistics from below

Revision 6a15be3f (diff)
Added by Ermal Luçi over 4 years ago

Ticket #4131 before formatting the mac extract the needed statistics from below

History

#1 Updated by Ermal Luçi over 4 years ago

  • Status changed from Confirmed to Feedback

#2 Updated by Ermal Luçi over 4 years ago

  • % Done changed from 0 to 100

#3 Updated by Ermal Luçi over 4 years ago

#4 Updated by Chris Buechler over 4 years ago

  • Status changed from Feedback to Resolved

fixed

#5 Updated by Mikael K over 4 years ago

Still having this issue on a machine updated from 2.1.5 to 2.2.
Prior to upgrading, the setup did work, although the reported values were higher than the real usage (https://redmine.pfsense.org/issues/1974#change-16421).

Information about my setup:
2.2-RELEASE (amd64)
This is a VM running on a Xenserver. /etc/fstab was converted to UFS labels. Interfaces were reassigned during first boot after upgrade.
Using MAC authentication with the "RADIUS MAC authentication" option enabled in CP.

#6 Updated by Hasan Zorlu over 4 years ago

Using 2.2-RELEASE (amd64) and this bug still exists, its not counting.

#7 Updated by Michael Newton over 4 years ago

This is still a problem in 2.2.2. Byte counts are all still zero!

I'm about to start digging through the code now, and will submit a pull request if I find anything.

#8 Updated by Michael Newton over 4 years ago

I put some debug code into /etc/inc/captiveportal.inc and got this result:

[01-May-2015 13:35:43 America/Toronto] Running pfSense_ipfw_getTablestats(2, 90, 1, 10.10.9.38, f0-24-75-36-78-47)
[01-May-2015 13:35:43 America/Toronto] Results: false
[01-May-2015 13:35:43 America/Toronto] Running pfSense_ipfw_getTablestats(2, 90, 1, 10.10.9.205, 1c-7b-21-e7-64-a6)
[01-May-2015 13:35:43 America/Toronto] Results: false
[01-May-2015 13:35:43 America/Toronto] Running pfSense_ipfw_getTablestats(2, 90, 1, 10.10.8.139, 38-0f-4a-0f-17-87)
[01-May-2015 13:35:43 America/Toronto] Results: false

Unfortunately I'm not a C programmer so I can't look into what the problem with pfSense_ipfw_getTablestats is.

#9 Updated by Ermal Luçi over 4 years ago

Can you run the same request but from CLI with ipsec -x 2 table 1 entrystats 10.10.8.139?

Tell me what do you see?

#10 Updated by Michael Newton over 4 years ago

  1. ipfw -x 2 table 1 entrystats 10.10.8.139
    10.10.8.139/32 0 1 1 0

#11 Updated by Ermal Luçi over 4 years ago

I think your problem is on the mac address format it should be specified by : rather than -

#12 Updated by Michael Newton over 4 years ago

Thanks, confirmed that is the issue.

[01-May-2015 15:03:56 America/Toronto] Running pfSense_ipfw_getTablestats(2, 90, 1, 10.10.8.141, d8:00:4d:dc:c0:d8)
[01-May-2015 15:03:56 America/Toronto] Results: array (
'packets' => 536306,
'bytes' => 24333460,
'timestamp' => 1430506934,
'dnpipe' => 2210,
)

We use the dropdown in captive portal settings to select IETF style MAC addresses, because that is what our RADIUS server expects. The C code should be separator agnostic, or the PHP code should sanitize it beforehand.

#13 Updated by Ermal Luçi over 4 years ago

Can you please try this change?

diff --git a/usr/local/captiveportal/radius_accounting.inc b/usr/local/captiveportal/radius_accounting.inc
index ed072cf..bb6ddc7 100644
--- a/usr/local/captiveportal/radius_accounting.inc
+++ b/usr/local/captiveportal/radius_accounting.inc
@@ -171,12 +171,12 @@ function RADIUS_ACCOUNTING_STOP($ruleno,$username,$sessionid,$start_time,$radius

     $retvalue = array();
     $nas_mac = mac_format(get_interface_mac("wan"));
+    $volume = getVolume($clientip, $clientmac);
     $clientmac = mac_format($clientmac);
     $nas_port = intval($ruleno);
     $radiusvendor = $config['captiveportal'][$cpzone]['radiusvendor'] ? $config['captiveportal'][$cpzone]['radiusvendor'] : null;
     $stop_time = (empty($stop_time)) ? time() : $stop_time;
     $session_time = $stop_time - $start_time;
-    $volume = getVolume($clientip, $clientmac);
     $volume['input_bytes_radius'] = remainder($volume['input_bytes']);
     $volume['input_gigawords'] = gigawords($volume['input_bytes']);
     $volume['output_bytes_radius'] = remainder($volume['output_bytes']);

It should fix the issue though you would have to clean up all your existing entries from CP and have them authenticate again.

UPDATE: With proper patch.
UPDATE2: Which fixes the root cause.

#14 Updated by Ermal Luçi over 4 years ago

  • Status changed from Resolved to Feedback
  • Target version changed from 2.2 to 2.2.3

Pushed the fix on pfSense as well.

#15 Updated by Michael Newton over 4 years ago

Confirmed working.

#16 Updated by Ermal Luçi over 4 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF