pfSense

Applied in changeset b9276845369b186dd1226a20b7402b2e61b31faf.

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.

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

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.

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.

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?

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

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

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.

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.

Confirmed working.