Project

General

Profile

Actions

Bug #2529

closed

Captive Portal does not function after update snap or restart system

Added by Allan Stanley over 9 years ago. Updated almost 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Ermal Luçi
Category:
Captive Portal
Target version:
Start date:
06/29/2012
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:

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.

Actions #1

Updated by Allan Stanley over 9 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.

Actions #2

Updated by Jim Pingle over 9 years ago

  • Status changed from New to Feedback

Fixed the bcmod error with 003436b and c199393 - see if that helps.

Actions #3

Updated by Allan Stanley over 9 years ago

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

Actions #4

Updated by Allan Stanley over 9 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.

Actions #5

Updated by Cyrill B over 9 years ago

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

Actions #6

Updated by Jim Pingle over 9 years ago

  • Status changed from Feedback to New
Actions #7

Updated by Yuri Keren over 9 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 ...

Actions #8

Updated by Ermal Luçi over 9 years ago

  • Status changed from New to Feedback
  • Assignee deleted (Allan Stanley)

Please try with next coming snapshots.

Actions #9

Updated by Yuri Keren over 9 years ago

Hi Ermal,

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

Actions #10

Updated by Life Form about 9 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.

Actions #11

Updated by Michael Mogren about 9 years ago

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

Actions #12

Updated by Chris Buechler about 9 years ago

  • Status changed from Feedback to New
  • Assignee set to Ermal Luçi
Actions #13

Updated by Michael Mogren about 9 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.

Actions #14

Updated by Ermal Luçi about 9 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #15

Updated by Chris Buechler about 9 years ago

  • Status changed from Feedback to Resolved
Actions #16

Updated by Fredrik Reuterswärd almost 9 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

Actions #17

Updated by Cyrill B almost 9 years ago

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.

Actions #18

Updated by Fredrik Reuterswärd almost 9 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

Actions #19

Updated by Cyrill B almost 9 years ago

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

Actions

Also available in: Atom PDF