PfSense 2.1 Captive Portal RADIUS Accouting records not sent to RADIUS Server

[communig8]

I have a number of pfSense Servers running pfSense 2.0.1, 2.0.3 and 2.1 all using an external RADIUS Server for authentication and accounting.
In fact, all using the same RADIUS Server.
The 2.0.x pfSense Servers are working fine and send RADIUS accounting data to the RADIUS Server.
However, I have 2 x pfSense 2.1 that are both suffering the same problem.
After a user completes has logged in an initial accounting record is sent to the RADIUS Server (radacct table) but that's it, no more are sent.
A packet capture on the pfSense server shows this. This leaves the users acctstoptime null in radacct.
If the user is timed out of disconnected via CP Status, still no accounting data.
But if I disable the CP service, all the records are updated but with the current date/time.
I have also found that data usage counts are not sent either.
I know pfSense 2.1 has had a lot of changes to CP but has something been broken along the way?
I also get this problem on a fresh install. I get this with interim and start/stop accounting.
Anyone else found this? Found a fix or even seen this reported before?
Thanks, Richard

[communig8]

Had a look through the code in /etc/inc/captiveportal.inc and in various places the code testes the $config array for 'radacct_enable'.
Even through "send RADIUS accounting packets" is checked 'radacct_enable' is empty so the code thinks RADIUS accounting is inactive.

[communig8]

On even more investigation, code in /etc/inc/cativeportal.inc is referring to the wrong columns in the array returned by captiveportal_read_db().
For example in captiveportal_disconnect_client() column 10 is being used to find the RADIUS server to use but its actually in column 9.
Changing the column reference to 9 causes the correct data to be sent to RADIUS in the event of a DISCONNECT.

[communig8]

Raised bug 3447 on Redmine.

[communig8]

Changing to code in captiveportal_disconnect_client() to use column 9 was a bit of a fluke as that column just happened to be null.
Looking at the code in captiveportal_opendb() which contains the CREATE for the table, there is no information on the RADIUS server to use.
So I don't know what's going on in captiveportal_disconnect_client() and other places in /etc/inc/cativeportal.inc to locate the correct RADIUS server.

[communig8]

I've created a local version of captiveportal.inc (attached as captiveportal.txt) to replace /etc/inc/captiveportal.inc (use at your own riaks!!).
This "fixed" the following functions that are using an incorrect RADIUS server lists.

captiveportal_prune_old()
captiveportal_disconnect()
captiveportal_radius_stop_all()
portal_allow()

This "fix" only supports a RADIUS Primary Authentication Source.
I needed this until the good people a pfSense do a proper fix.

Richard

captiveportal.txt

[eri--]

I fixed in for good on 2.1 repo.

[communig8]

I thought it was targeted for 2.1.1 ?

[fsantaana]

Hello,

I am having this same issue on the 2.2 Release version. The exact same is happening when only the first login is being sent to the radacct table.

[unixaccent]

Same problem here. Anyone who has fixed this? I am using 2.2.1. Thank you.

[vitord2]

Same problem on 2.2.2. Empty radacct table