pfSense

I've also noticed If I kick a user they can still get full access through the portal.
When disconnecting a client I get this error page.

Fatal error: Call to undefined function bcmod() in /usr/local/captiveportal/radius_accounting.inc on line 337

I then have to click save on the main portal config page to get it working again.

Seems to be fine now I can disconnect a user with out errors and CP remains running

The start up bug still exists. After a snap upgrade or a system reboot I still have to save the main CP page before it will run properly.

Running "ipfw_context -l" after a reboot shows that no contexts are defined.

A temporal work-around to this problem is restarting the Captive Portal for the 2nd time, at the end of the boot-up process.
In /etc/rc.bootup, at the end of the file, just before the /* done */ comment I added the following two lines:

/* re-start the captive portal to work around bug 2529 */
captiveportal_configure();

I guess it's the timing of when starting the captive portal upon reboot that got messed up ...

Hi Ermal,

Could you please write the exact revision where it was fixed?

Not yet fixed only work around can do the trick. The start up bug still exists. After a snap upgrade or a system reboot I still have to save the main CP page before it will run properly.

The "fix" for this also gets wiped out when you update... need a real fix ASAP!

Anything I can do to help move this along? I'm fairly new to pfsense but competent and would love to see this fixed ASAP.

I'm sorry but I still have a problem with this one.
After upgrading to snapshot built on Wed Dec 12 10:59:14 EST 2012 Captile portal is not working at all.
It claimes to be active but no traffic on that interface is stopped.

At boot I get this message:

Starting captive portal(login)...
Warning: pfSense_interface_flags() expects parameter 2 to be long, string given in /etc/inc/captiveportal.inc on line 503

Fredrik lae

Your problems are not directly related to this former issue. Instead there was a parsing problem in ipfw with symbolic names that has since been fixed in commit d0288824f3719138a53d01ff6e4fa49fde18972d. And the second issue was addressed in 78fdb3b9bc64d3502bb93a552370b1c2e9e2212d.

You will have to wait a few have hours until a new snapshot that includes those changes is built.

Hi.

Thankyou for the quick responce.
Something else now seams broken.

The user is now redericted to the login page.
But the login does not work. In the captive portal status the MAC-adress is shown as "Array"

I also get these messages when the login page is shown:

Warning: explode() expects parameter 2 to be string, array given in /etc/inc/uti
l.inc on line 1244

Warning: explode() expects parameter 2 to be string, array given in /etc/inc/uti
l.inc on line 1244

Warning: radius_put_attr() expects parameter 3 to be string, array given in /etc
/inc/radius.inc on line 214

Warning: radius_put_attr() expects parameter 3 to be string, array given in /etc
/inc/radius.inc on line 214

Warning: strlen() expects parameter 1 to be string, array given in /etc/inc/radi
us.inc on line 667

Warning: htmlspecialchars() expects parameter 1 to be string, array given in /et
c/inc/captiveportal.inc on line 1639

Warning: htmlspecialchars() expects parameter 1 to be string, array given in /et
c/inc/captiveportal.inc on line 1648

Fredrik lae

Since those problems are not related to the original bug report you should not report them here but instead create a new bug report or preferably post in the "2.1 Snapshot Feedback and Problems" forum board.

Btw. It should be fixed in 0d20a0409939738984e42256c7983bcc8f46d445