Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Captive portal seems stopped (can't bind port:8000 already in use) but working.

    Captive Portal
    3
    4
    2.7k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      abdurrahman
      last edited by

      Hello, I am using pfSense 2.0.2-RELEASE (amd64)

      when I tried to start captive portal, in System logs, I see the message below:

      php: /status_services.php: The command '/usr/local/sbin/lighttpd -f /var/etc/lighty-CaptivePortal.conf' returned exit code '255', the output was '2012-12-29 23:01:23: (network.c.385) can't bind to port: 8000 Address already in use'

      Interesting but, when I look Status->Services, captive portal seems stopped,
      bu users can login through the captive portal and successfullu authenticated and I can see the users
      who logged in in th Status-Captive Portal….

      My DHCP Server settings :
      Default lease time is 7776000
      Maximum lease time is 15552000

      In Captive Portal settings, I leaved Hard Time Out setting blank.... (no limit)
      my aim is this:  unless dhcp server gives different ip address to the clients (3 months after), the sessions of clients will not be closed.

      when I run the command,
      clog /var/log/lighttpd.error.log

      I see the error messages below...

      2013-04-19 08:42:16: (connections.c.137) (warning) close: 23 Connection reset by peer
      2013-04-19 08:44:28: (connections.c.137) (warning) close: 23 Connection reset by peer
      2013-04-19 08:46:58: (connections.c.137) (warning) close: 32 Connection reset by peer
      2013-04-19 08:48:28: (connections.c.137) (warning) close: 19 Connection reset by peer
      2013-04-19 08:49:58: (connections.c.137) (warning) close: 27 Connection reset by peer
      2013-04-19 08:52:27: (mod_fastcgi.c.1732) connect failed: Connection refused on unix:/tmp/php-fastcgi.socket-3
      2013-04-19 08:52:27: (mod_fastcgi.c.3002) backend died; we'll disable it for 1 seconds and send the request to another backend instead: reconnects: 0 load: 1
      2013-04-19 09:37:55: (connections.c.137) (warning) close: 11 Connection reset by peer
      2013-04-19 10:13:32: (mod_fastcgi.c.1732) connect failed: Connection refused on unix:/tmp/php-fastcgi.socket-3
      2013-04-19 10:13:32: (mod_fastcgi.c.3002) backend died; we'll disable it for 1 seconds and send the request to another backend instead: reconnects: 0 load: 1
      2013-04-19 14:45:49: (mod_fastcgi.c.1732) connect failed: Connection refused on unix:/tmp/php-fastcgi.socket-3
      2013-04-19 14:45:49: (mod_fastcgi.c.3002) backend died; we'll disable it for 1 seconds and send the request to another backend instead: reconnects: 0 load: 1
      2013-04-19 16:56:25: (connections.c.137) (warning) close: 11 Connection reset by peer
      2013-04-19 17:02:00: (connections.c.137) (warning) close: 14 Connection reset by peer
      2013-04-19 17:14:30: (connections.c.137) (warning) close: 12 Connection reset by peer
      2013-04-19 19:14:29: (mod_fastcgi.c.1732) connect failed: Connection refused on unix:/tmp/php-fastcgi.socket-1
      2013-04-19 19:14:29: (mod_fastcgi.c.3002) backend died; we'll disable it for 1 seconds and send the request to another backend instead: reconnects: 0 load: 1

      In spite of the fact that Captive portal seems stoped in (Status-Services) and the error log messages, mu clients can login throug captive portal and clients are authenticated succesfully...

      I will be glad, if you help me about this topic

      1 Reply Last reply Reply Quote 0
      • S
        Slam
        last edited by

        Upgrade to 2.0.3 as this solves this issue.

        1 Reply Last reply Reply Quote 0
        • A
          abdurrahman
          last edited by

          thanks for your offer, bu when I upgraded to pfSense 2.0.3 timezone problem occured…
          Although the time was shown true in webgui (Status-Dashboard), time information in all logs
          was 3 hours earlier.
          I have been living in Turkey. My time zone was correct. Europe/Istanbul...

          Any other ideas, or offers?

          1 Reply Last reply Reply Quote 0
          • T
            tripplex
            last edited by

            can anyone help me i want to limit the amount of user that can be logged in the captive portal at a time

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.