PfSense 2.1 Captive Portal RADIUS Accouting records not sent to RADIUS Server
-
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. -
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. -
Raised bug 3447 on Redmine.
-
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. -
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
-
I fixed in for good on 2.1 repo.
-
I thought it was targeted for 2.1.1 ?
-
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.
-
Same problem here. Anyone who has fixed this? I am using 2.2.1. Thank you.
-
Same problem on 2.2.2. Empty radacct table