Shouldn't expired sessions be removed?

adegans

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!

Mathiew

Same problem, hard timeout doesn't seem to do his job for me.

adegans

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 :(

adegans

The idle and hard timeout don't seem to work at all.

Nachtfalke

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.

adegans

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)

mikenl

@adegans:

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

Gertjan

Hi there …

Just a wild shot: goto Diagnostics: Execute command and execute this command:
ps ax | grep minicron

The 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 running

You 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.

adegans

I've since disabled the proxy server and timeouts seem to work more often now… Perhaps a relation? Incompatibility?

mikenl

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 cpzone

This morning i did ps ax | grep minicron and the cron command is gone ??????

@Gertjan:

Hi there …

Just a wild shot: goto Diagnostics: Execute command and execute this command:
ps ax | grep minicron

The 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 running
You 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.

adegans

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

Gertjan

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.

adegans

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.

Gertjan

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).

adegans

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.

Gertjan

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.

adegans

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

mikenl

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.7G

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

Interfaces ? 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 upgrade

This 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.

Gertjan

All minicrons are still up ?

mikenl

Was away a few days, the cp minicrons are gone again :(