Captive portal "maximum concurrent connections" setting ignored

  • The "maximum concurrent connections" setting on the [Service -> Captive Portal] page appears to be ignored.

    The problem appears to be in /etc/inc/  The following functions are called from captiveportal_init_webgui():

    $cert, $key, $cacert, "", "8001", "/usr/local/captiveportal/",
    "cert-portal.pem", "ca-portal.pem", "1", $maxproc, $use_fastcgi, true);

    "", "", "", "", "8000", "/usr/local/captiveportal/",
    "cert-portal.pem", "ca-portal.pem", "1", $maxproc, $use_fastcgi, true);

    Note the order of the 10th and 11th parameters, "1" and $maxproc.  The function is defined in /etc/inc/

    function system_generate_lighty_config($filename,
    $port = 80,
    $document_root = "/usr/local/www/",
    $cert_location = "cert.pem",
    $ca_location = "ca.pem",
    $max_procs = 2,
    $max_requests = "2",
    $fast_cgi_enable = true,
    $captive_portal = false) {

    Note that the 10th parameter, $max_procs will always be set to "1" when called from captiveportal_init_webgui().  And the 11th parameter, $max_requests doesn't appear to even be used; this is how the lighty config file is written later in the function:

    "PHP_FCGI_CHILDREN" => "$max_procs",
    "PHP_FCGI_MAX_REQUESTS" => "500"

    and again here:

    fastcgi.server = ( ".php" =>
    ( "localhost" =>
    "socket" => "{$g['tmp_path']}/php-fastcgi.socket",
    "min-procs" => 0,
    "max-procs" => {$max_procs},

    So I'm thinking that those two parameters should be reversed either in the function definition or in the calls to the function.

    Was hoping this would fix the problem where Chrome and IE9 browsers hang out for 20+ seconds after logging into the portal, but unfortunately it doesn't.  I'm also hoping someone can verify that $max_requests applies to the maximum concurrent connection setting on the captive portal settings page.


  • Try latest snapshots it might help fixing this.

  • The 7/24/2011 snapshot did change the behavior, but it doesn't seem like it's completely fixed.  Now, PHP_FCGI_CHILDREN and max_procs seem to be based on how much memory you have, with a starting value of "1" and then modified upwards the more memory you have.  It still doesn't seem to pay attention to the "maximum concurrent connections" setting on the [Service -> Captive Portal] page.

    It also doesn't fix the IE9 and Chrome problem where the home page times out.  If you get a chance, can you clarify how the max connections per IP works and which settings control it?  I think the main cause of IE9/Chrome timing out is that they try to open more than 16 connections, but somewhere in pfsense there seems to be a hard limit of 16 – wondering if you can confirm that is correct, and if there is a way to adjust that?


  • I think I solved the problem; in /etc/inc/, there is a problem with the system_generate_lighty_config() function.  Shouldn't this block:

    if(!$maxprocperip and $maxprocperip > 0)
    $captive_portal_mod_evasive = "evasive.max-conns-per-ip = {$maxprocperip}";
    $captive_portal_mod_evasive = "";

    be changed to this:

    if($maxprocperip and $maxprocperip > 0)
    $captive_portal_mod_evasive = "evasive.max-conns-per-ip = {$maxprocperip}";
    $captive_portal_mod_evasive = "evasive.max-conns-per-ip = 4";

    I don't think there should be a ! in the if() statement above, should there?  I don't think there are any cases which would trigger the first branch of the "if" statement – so $captive_portal_mod_evasive will always be a blank string.  Shouldn't that default to 4?  In any case, changing the code to the above fixed my problem with Chrome and IE9.


  • Committed.
    For the default value i leave it as it is for now.