Shouldn't expired sessions be removed?
-
I've set up captive portal for the purpose of telling people what wifi network they're accessing.
The SSID has no password, when they connect Captive Portal jumps in, welcomes them, shows the weekly special etc.
But no accounts of vouchers are required or used. So just a button "To the internet".These sessions are set to expire after 15 minutes (Hard timeout). Shouldn't expired sessions be removed after X time?
It's now well over 4 hours after the user has left and his session still shows as active in the CP status pages. Does that go away the next time someone logs in? Or when that guy comes back? If ever?Please advise. Thanks!
-
Same problem, hard timeout doesn't seem to do his job for me.
-
I've noticed that the session eventually did go away, but I've also changed a bunch of things in the overall setup so I'm not sure if a daemon restarted which caused the sessions to be cleared up that one time or if CP actually cleaned up after itself.
Any input/feedback welcome :(
-
The idle and hard timeout don't seem to work at all.
-
Hi,
I have the same problems on pfsense 2.0.1 and 2.0.3. In many cases it does not work, in some it does. Did not find out when this happens.
HINT:
HardTimeout disconnects the user no matter if he is idle or not. So setting this to 15min will disconnect every user 4 times an hour. So better use idle timeout of 15min.
I know this is not your problem/solution. -
I currently have "expired" sessions open from October 12, 13 and 14… I have to manuall restart or resave CP for them to go away (or close them one by one, manually)
-
The idle and hard timeout don't seem to work at all.
I can confirm this behaviour, doesn't work for me either i'm on 2.1-RELEASE (i386)
built on Wed Sep 11 18:16:50 EDT 2013 -
Hi there …
Just a wild shot: goto Diagnostics: Execute command and execute this command:
ps ax | grep minicronThe results shoss several lines.
One of them must be:xxxxx ?? Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone
(which, of course is wrong: when accessing be SSH, I have the more complete:
xxxxx ?? Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone.pid /etc/rc.prunecaptiveportal cpzone ```) which means that this task /usr/local/bin/minicron runs every 60 secondes - using the script it fins here: /etc/rc.prunecaptiveportal using 'cpzone' (the name of my captive portal zone). Its running on your box ? (if doubts: in file /etc/rc.prunecaptiveportal copy line 50 to line 42 - and change the text: "Skipping CP prunning process because previous/another instance is already running" to something more useful. This line should show up every 60 secondes in the log - like this:
Nov 4 11:01:14 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 11:00:14 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 10:59:14 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 10:58:13 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 10:57:13 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 10:56:13 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already runningYou have the same logs ? **edit**: Ok, I admit, I didn't change the text for something more usefull … ;) These tests just to check if the prunnig process is running.
-
I've since disabled the proxy server and timeouts seem to work more often now… Perhaps a relation? Incompatibility?
-
I disabled squid, had no effect.
Well sometimes time-out works,
and i see time-out messages in the captive portal logs.
Yesterday i issued the command ps ax | grep minicron
And i could see the cron command:
0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone.pid /etc/rc.prunecaptiveportal cpzoneThis morning i did ps ax | grep minicron and the cron command is gone ??????
Hi there …
Just a wild shot: goto Diagnostics: Execute command and execute this command:
ps ax | grep minicronThe results shoss several lines.
One of them must be:xxxxx ?? Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone
(which, of course is wrong: when accessing be SSH, I have the more complete:
xxxxx ?? Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone.pid /etc/rc.prunecaptiveportal cpzone ```) which means that this task /usr/local/bin/minicron runs every 60 secondes - using the script it fins here: /etc/rc.prunecaptiveportal using 'cpzone' (the name of my captive portal zone). Its running on your box ? (if doubts: in file /etc/rc.prunecaptiveportal copy line 50 to line 42 - and change the text: "Skipping CP prunning process because previous/another instance is already running" to something more useful. This line should show up every 60 secondes in the log - like this:
Nov 4 11:01:14 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 11:00:14 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 10:59:14 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 10:58:13 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 10:57:13 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already running
Nov 4 10:56:13 php: rc.prunecaptiveportal: Skipping CP prunning process because previous/another instance is already runningYou have the same logs ? **edit**: Ok, I admit, I didn't change the text for something more usefull … ;) These tests just to check if the prunnig process is running.
-
I get this:
$ ps ax | grep minicron 42603 ?? Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_free_n 43080 ?? I 0:07.85 minicron: helper /etc/rc.prunecaptiveportal free_net 82992 ?? Is 0:00.00 /usr/local/bin/minicron 240 /var/run/ping_hosts.pid / 83235 ?? I 0:01.86 minicron: helper /usr/local/bin/ping_hosts.sh (minic 83543 ?? Is 0:00.00 /usr/local/bin/minicron 3600 /var/run/expire_accounts 83678 ?? I 0:00.13 minicron: helper /etc/rc.expireaccounts (minicron) 84070 ?? Is 0:00.00 /usr/local/bin/minicron 86400 /var/run/update_alias_u 84393 ?? I 0:00.01 minicron: helper /etc/rc.update_alias_url_data (mini 98388 ?? S 0:00.00 sh -c ps ax | grep minicron 2>&1 98810 ?? S 0:00.00 grep minicron
-
As adegans stated, several minicron tasks should be running.
One of them 'prunes' the 'portal firewall' and portal-user-active database. This is what disconnects portal users.The minicron
xxxxx ?? Is 0:00.00 /usr/local/bin/minicron 60 /var/run/cp_prunedb_cpzone.pid /etc/rc.prunecaptiveportal cpzone
that takes care of the portal interface(s) should never stop running as long as the portal service is up.
Actually, this minicron and the portal web server is the 'portal webservice'.
Note: a minicron exists for every portal zone, more then one can exist.If all minicrons are stopped (what I understood from mikenl), then the problem isn't related to the portal interface.
Users not getting disconnected is just a side effect.These are for other maintenance tasks:
82992 ?? Is 0:00.00 /usr/local/bin/minicron 240 /var/run/ping_hosts.pid / 83543 ?? Is 0:00.00 /usr/local/bin/minicron 3600 /var/run/expire_accounts 84070 ?? Is 0:00.00 /usr/local/bin/minicron 86400 /var/run/update_alias_u
My edit of the file "/etc/rc.prunecaptiveportal" mentioned above will not indicate why our minicron is killed but it will show when.
The log files should be examined to see what happens on your systems. -
Perhaps the issue isn't minicron or the calling of the script, but the script itself.
Or perhaps even the thing that should add the cronjobs/governs them. -
The (portal) minicron is stand alone.
It's activated when the portal interface is activated.
Here: /etc/inc/captiveportal.inc - see for yourself on line 334 - or killed if the captive portal is deactivated (line 350).This means that 'something' is playing with the pfSense config interface or someone has root level access and killing by hand the minicron (and thus portal users have indefinite access).
The question persists: first: when is your minincron is killed. Then: why ? it blows up by itself ?? (and/or by who ?).
The why part might be system related: mine is working for weeks, months … (I have a nearly bare pfSEnse setup - no plugins - no packages). -
My knowledge of the system doesn't go much further than the web interface.
But I can't imagine it's very hard to find the cause of this by someone who is more 'involved'. Some input from a developer who actually makes this package would probably be helpful too.
If there is something I need to provide (logs or whatever) just tell me where and how to get them and I'll see if I can be of use.
-
The portal interface isn't a package, its a core function of pfSense.
I'm pretty sure a dev would drop in after the following:
State this:
What hardware are you sing ? Free disk size ? Mem size ? Interfaces ?
What is your pfSense setup - basic use ? load ?
Did it happen after a clean install (after 'format') ?
When did it happen ? How many users ?Start with:
(if doubts: in file /etc/rc.prunecaptiveportal copy line 50 to line 42 - and change the text to: "Portal minicron - running now"
it won't harm the activity of your pfSEnse setup - and show you when the minicron that logs of portal users, dies.
-
Alright, here you go:
What hardware are you sing ? Soekris 6501-70 - 1.6Ghz ARM, 2GB, Sata disk 250GB Version 2.1-RELEASE (i386) Platform pfSense CPU Type Genuine Intel(R) CPU @ 1.60GHz 2 CPUs: 1 package(s) x 1 core(s) x 2 HTT threads Free disk size ? At least 200GB Mem size ? 2GB (13% at time of writing) Interfaces ? 4x 1Gbit (2x wan, 2x lan diff subnets) What is your pfSense setup - basic use ? DHCP/DNS/FreeRadius (for CP)/CP (1 Zone)/NAT/Firewall/NTP load ? Load average 0.10, 0.03, 0.01 (At time of this writing, never seen it go notably high) Did it happen after a clean install (after 'format') ? This is a relative clean and basic setup (redid the whole thing for 2.1 because of a failed upgrade) When did it happen ? Since install How many users ? So far everyone who used CP
-
What hardware are you using ?
ESXI 5.1 vm
Dual-Core AMD Opteron Processor 8218
2 CPUs: 2 package(s) x 1 core(s)
Load average 0.07, 0.20, 0.31
Memory usage 45% of 3051 MB
Disk usage 50% of 8.7GVersion 2.1-RELEASE (i386)
Platform pfSense
CPU Type Genuine Intel(R) CPU @ 1.60GHz
2 CPUs: 1 package(s) x 1 core(s) x 2 HTT threadsInterfaces ? 3 in use, 8 vlans not in use now
What is your pfSense setup - basic use ? DHCP DNS Radius NAT Firewall NTP Snort Squid
Did it happen after a clean install (after 'format') ? Not a clean install, upgrade from 2.0.1
When did it happen ? Since upgradeThis morning i couldn't "restart" the CP, users remain active even after a "save" on the config page. Disable/enable the CP helped, and the portal minicron is back.
-
All minicrons are still up ?
-
Was away a few days, the cp minicrons are gone again :(