Captive Portal fails regularly after upgrading from 2.0.1 to 2.0.2
-
@ermal:
I put some more fixes in there so just gitsync again.
So far so good.
Something was horribly wrong after the update was applied. Responses to the web interface virtually stopped… so I rebooted.
Testing with a single device has been successful. Software, after a few minutes, appears stable according to the logs.
- David
Jan 4 07:51:11 apinger: rrdtool respawning too fast, waiting 300s.
Jan 4 07:50:39 login: login on ttyv0 as root
Jan 4 07:50:38 check_reload_status: Reloading filter
Jan 4 07:50:32 bandwidthd: Packet Encoding: Ethernet
Jan 4 07:50:32 php: : IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.
Jan 4 07:50:32 bandwidthd: Opening xl0
Jan 4 07:50:32 bandwidthd: Monitoring subnet 203.97.236.0 with netmask 203.97.236.0
Jan 4 07:50:32 bandwidthd: Monitoring subnet 192.168.250.0 with netmask 192.168.250.0
Jan 4 07:50:32 bandwidthd: Monitoring subnet 192.168.10.0 with netmask 192.168.10.0
Jan 4 07:50:32 bandwidthd: Monitoring subnet 192.168.10.0 with netmask 192.168.10.0
Jan 4 07:50:27 php: : The command '/usr/local/etc/rc.d/bandwidthd.sh stop' returned exit code '1', the output was 'No matching processes were found'
Jan 4 07:50:27 php: : The command '/usr/local/etc/rc.d/bandwidthd.sh stop' returned exit code '1', the output was 'No matching processes were found'
Jan 4 07:50:27 kernel: xl0: promiscuous mode enabled
Jan 4 07:50:25 php: : The command '/usr/local/etc/rc.d/darkstat.sh stop' returned exit code '1', the output was 'No matching processes were found'
Jan 4 07:50:21 php: : Restarting/Starting all packages.
Jan 4 07:50:11 apinger: Error while feeding rrdtool: Broken pipe
Jan 4 07:50:10 miniupnpd[1738]: Listening for NAT-PMP traffic on port 5351
Jan 4 07:50:10 miniupnpd[1738]: Listening for NAT-PMP traffic on port 5351
Jan 4 07:50:10 miniupnpd[1738]: HTTP listening on port 2189
Jan 4 07:50:10 miniupnpd[1738]: HTTP listening on port 2189
Jan 4 07:50:10 php: : miniupnpd: Starting service on interface: lan
Jan 4 07:50:08 php: : Creating rrd update script
Jan 4 07:50:02 check_reload_status: Restarting ipsec tunnels
Jan 4 07:49:59 lighttpd[51111]: (log.c.166) server started
Jan 4 07:49:59 lighttpd[51111]: (log.c.166) server started
Jan 4 07:49:39 kernel: ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to accept, logging disabled
Jan 4 07:49:26 ntpdate[37661]: step time server 209.167.68.100 offset 0.929602 sec
Jan 4 07:49:18 dnsmasq[40770]: read /etc/hosts - 60 addresses
Jan 4 07:49:18 dnsmasq[40770]: ignoring nameserver 127.0.0.1 - local interface
Jan 4 07:49:18 dnsmasq[40770]: ignoring nameserver 127.0.0.1 - local interface
Jan 4 07:49:18 dnsmasq[40770]: using nameserver 203.97.78.43#53
Jan 4 07:49:18 dnsmasq[40770]: using nameserver 203.97.78.44#53
Jan 4 07:49:18 dnsmasq[40770]: reading /etc/resolv.conf
Jan 4 07:49:18 dnsmasq[40770]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack
Jan 4 07:49:18 dnsmasq[40770]: started, version 2.63 cachesize 10000
Jan 4 07:49:18 check_reload_status: Updating all dyndns
Jan 4 07:49:17 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Jan 4 07:49:17 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Jan 4 07:49:17 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Jan 4 07:49:17 dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Jan 4 07:49:17 dhcpd: All rights reserved.
Jan 4 07:49:17 dhcpd: Copyright 2004-2012 Internet Systems Consortium.
Jan 4 07:49:17 dhcpd: Internet Systems Consortium DHCP Server 4.2.4-P1
Jan 4 07:49:17 dhcpleases: Could not deliver signal HUP to process because its pidfile does not exist, No such file or directory.
Jan 4 07:49:14 php: : ROUTING: setting default route to 203.97.236.1
Jan 4 07:49:14 lighttpd[29910]: (log.c.166) server started
Jan 4 07:49:14 lighttpd[29910]: (log.c.166) server started
Jan 4 07:49:11 apinger: Starting Alarm Pinger, apinger(17425)
Jan 4 07:49:10 sshlockout[16498]: sshlockout/webConfigurator v3.0 starting up
Jan 4 07:49:10 sshd[16201]: Server listening on 0.0.0.0 port 222.
Jan 4 07:49:10 sshd[16201]: Server listening on :: port 222. -
I havent gitsynced the latest updates since the early hours of this morning but so far so good, the original error of captive portal crashing seems to be fixed, as well as some other minor bugs, the redirected lighty error log also reports no problems.
Big thanks to the devs and pfsensers!
-
Hi I am having the same issue, upgraded from 2.0.1 (i386) to 2.0.2 in the services tap captive portal appears down. Interestingly I use radius and openldap for the username and passwords on a separate computer. When a user types in a username and password they get an error saying that page could not be reached, but then if they close the browser and open it they have been authenticated by captive portal and all is working. I am also using esx 4, I use squid (as transparent proxy) and squidguard and a wpad file to auto configure the browser. It all worked fine before the upgrade.
-
Please gitsync to latest changes i think the root cause of this has been fixed now.
-
yep did this and after a reboot everything works again, thanks for your help really appreciated.
-
@ermal:
Please gitsync to latest changes i think the root cause of this has been fixed now.
I updated (sync'd) again. Everything has remained stable over night.
- David
-
I did a gitsync the other day and that fixed the captive portal being stopped issue. What I've noticed since though is that clients have to either renew their IP or turn WiFi Off/On to be redirected to the captive portal after the 1 hour time out. DHCP default and maximum lease times are not set in the configuration so I'm presuming they are 720 seconds and 86400 seconds respectively, both definitely longer than the time out.
-
Same here >:(…upgraded and no more capitve po
-
Same here >:(…upgraded and no more capitve po
gitsync as described here and it will be fixed.
-
Hi everyone,
I confirm with the fix is working.
But i have some logs that i don't understand like :
lighttpd[34598]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'redirurl' (attacker '172.16.1.37', file '/usr/local/captiveportal/index.php')
lighttpd[34598]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'sessionkey' (attacker '172.16.1.141', file '/usr/local/captiveportal/index.php')
lighttpd[34598]: (connections.c.137) (warning) close: 73 Connection reset by peer
Best regards.
Myke. -
Using 2.02 in a production environment so I am reluctant to do a gitsync. I may come in this weekend and give it a try.
Interesting that although under service status the captiveportal service says Stopped captive portal is running and users are being asked to login.
-
Hello.
I have the "same issue" Since I upgrade my installation, captive portal don't works as expected. I have had to disable it.
My problem is that the ip roules stop working suddenly.
f.e. my rule "both any->10.2.0.0/16" stop working and the only way to work around was enable certains IPs on the captive portal (so they have access to internet too, and i don't want this).
Thanks!
Now i'm gitsyncing.. I'll try after
-
Hi after gitsyncing and going to 2.0.3 I had a number of other issues, such as under heavy load the firewall blocking everything with nothing entered into the syslog. we have 800 captive portal users and everything was working well in 2.0.1 . I have reverted back to 2.0.1 . The main reason was due to the crashing and the fact that the web gui became really slow, and crashed alot. I run 2 other pfsense devices and I have not gone back to 2.0.2 on them as they do not use captive portal. On all the devices that I have upgraded i have found the performance of the webgiu gets much worse after the upgrade with me having to remove the status widget from the dashboard to make some small improvements.
-
Web GUI seems very fast with 2.02. Have not gitsynced yet. Is there a 2.0.3 release? I have not seen it.
-
when you gitsync you will goto 2.0.3 pre release
-
he is right is there any workaround, a lot of error message coming out. Also Captive portal is not working.
when you gitsync you will goto 2.0.3 pre release
-
The latest 2.0.3 is stable from our testing.
Can you try because at the time there were some changes being done.
Now it is marked as stable on our side! -
heres the error i got
Jan 31 19:57:20 lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol Jan 31 19:57:20 lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
@ermal:
The latest 2.0.3 is stable from our testing.
Can you try because at the time there were some changes being done.
Now it is marked as stable on our side! -
yesterday i've deployed 2.0.3 with a ssl cert from startssl & Radius auth on a Win2K8r2
i've seen that too:
Jan 31 19:57:20 lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol Jan 31 19:57:20 lighttpd[21213]: (connections.c.305) SSL: 1 error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
doesn't seem to affect the portal … i've had +40 portal users all day without complaints
-
Running latest snapshot of PRERELEASE-2.0.3 (31/01/2013)
I can also confirm what the last 2 posters have reported, though it doesnt seem to affect the CP users.
I am also seeing a lot of the following.
Jan 31 20:23:57 lighttpd[18696]: (connections.c.137) (warning) close: 25 Connection reset by peer
Jan 31 20:23:57 lighttpd[18696]: (connections.c.137) (warning) close: 25 Connection reset by peerJan 31 20:02:55 lighttpd[18696]: (request.c.1133) GET/HEAD with content-length -> 400
Jan 31 20:02:55 lighttpd[18696]: (request.c.1133) GET/HEAD with content-length -> 400Jan 31 19:56:03 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'redirurl' (attacker '10.0.0.109', file '/usr/local/captiveportal/index.php')
Jan 31 19:56:03 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'redirurl' (attacker '10.0.0.109', file '/usr/local/captiveportal/index.php')Jan 31 17:55:50 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'info_hash' (attacker '10.0.0.78', file '/usr/local/captiveportal/index.php')
Jan 31 17:55:50 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'info_hash' (attacker '10.0.0.78', file '/usr/local/captiveportal/index.php')Jan 31 17:35:49 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'checklic' (attacker '10.0.0.74', file '/usr/local/captiveportal/index.php')
Jan 31 17:35:49 lighttpd[18696]: (mod_fastcgi.c.2676) FastCGI-stderr: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'checklic' (attacker '10.0.0.74', file '/usr/local/captiveportal/index.php')