Bug #2529
closed
Captive Portal does not function after update snap or restart system
Added by Allan Stanley over 12 years ago. Updated almost 12 years ago.
100%
Description
Each time the system is rebooted either manually or because of a new snapshot upgrade Captive portal using freeradius2 shows running in services but does not block or show a portal page too non users.
Restarting the service does not fix the issue. Opening the CP main page and clicking save resolves the issue.
Updated by Allan Stanley over 12 years ago
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.
Updated by Jim Pingle over 12 years ago
- Status changed from New to Feedback
Updated by Allan Stanley over 12 years ago
Seems to be fine now I can disconnect a user with out errors and CP remains running
Updated by Allan Stanley over 12 years ago
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.
Updated by Cyrill B over 12 years ago
Running "ipfw_context -l" after a reboot shows that no contexts are defined.
Updated by Yuri Keren over 12 years ago
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 ...
Updated by Ermal Luçi over 12 years ago
- Status changed from New to Feedback
- Assignee deleted (
Allan Stanley)
Please try with next coming snapshots.
Updated by Yuri Keren over 12 years ago
Hi Ermal,
Could you please write the exact revision where it was fixed?
Updated by Life Form about 12 years ago
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.
Updated by Michael Mogren about 12 years ago
The "fix" for this also gets wiped out when you update... need a real fix ASAP!
Updated by Chris Buechler about 12 years ago
- Status changed from Feedback to New
- Assignee set to Ermal Luçi
Updated by Michael Mogren about 12 years ago
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.
Updated by Ermal Luçi almost 12 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 3a4b01476620d33b6d6200849231398f82e593c7.
Updated by Chris Buechler almost 12 years ago
- Status changed from Feedback to Resolved
Updated by Fredrik Reuterswärd almost 12 years ago
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
Updated by Cyrill B almost 12 years ago
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.
Updated by Fredrik Reuterswärd almost 12 years ago
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
Updated by Cyrill B almost 12 years ago
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