Bug #1653
closedCP timeout bug: get_last_activity
0%
Description
Running 2.0-RC3 Jul 4 17:29 Nanobsd.
Captive portal is expiring entries every cycle (60 seconds by default). So I get the login page, I click continue, which creates the captiveportal.db entry, and then I can make connections until the next time the database is pruned.
I have the timeouts set to 30 minute soft(idletimeout) and 120 minute hard(timeout).
One thing that I have noticed is that the command to find out the last activity (captiveportal_get_last_activity in captiveportal.inc) "/sbin/ipfw table 1 entrystats {$ip} 2>/dev/null" is not returning a timestamp as the last entry anymore.
When I run it on an older snapshot I get something like:
192.168.1.164/32 20014 5071 658430 1309977260
When I run it on the newest version, I get: (no timestamp)
192.168.1.130/32 0 893 0 119298
I haven't been able to find documentation on what entrystats is supposed to be returning, but field 4 looks like it should be a timestamp.
I also noticed a comment typo on line 803 of captiveportal.inc.
/* Delete client's ip entry from tables 3 and 4. */
mwexec("/sbin/ipfw table 1 delete {$dbent2}");
mwexec("/sbin/ipfw table 2 delete {$dbent2}");
Thanks
Josh
Updated by Josh Stompro over 13 years ago
When I set idletimeout to blank the problem goes away.
When I set timeout to blank and idletimeout to 30, the problem comes back.
When I set both timeout and idletimeout to blank, the problem goes away.
Josh
Updated by Ermal Luçi over 13 years ago
- Status changed from New to Feedback
Fixed on next snapshots thanks for reporting.
Updated by Lo Zio over 13 years ago
I confirm this is the behaviour of my previus bug report (1647).
As per previous request, here is the log:
Jul 6 13:47:41 logportalauth11549: TIMEOUT: XXXUSERNAME, 00:13:77:e0:29:6e, 10.210.1.100
Jul 6 13:46:57 logportalauth26473: USER LOGIN: XXXUSERNAME, 00:13:77:e0:29:6e, 10.210.1.100
After a minute the timeout was triggered.
Updated by Lo Zio over 13 years ago
Also "Last activity" info from Captive portal status (/status_captiveportal.php?order=&showact=1) is wrong.
It shows 01/01/1970 19:14:11, but it cannot be, I set a timeout :):):)
Updated by Josh Stompro over 13 years ago
I can confirm that this is fixed with the Jul 7 01:04:41 snapshot.
"ipfw table 1 entrystats 192.168.1.130" Now returns the expected timestamp.
192.168.1.130/32 20002 116 23345 1310045780
The auto updater change threw me off for a little bit, thanks for posting that notice this morning.
http://forum.pfsense.org/index.php?topic=38689.new#new
CP entries no longer time out every time the prunedb runs.
Josh
Updated by Ermal Luçi over 13 years ago
- Status changed from Feedback to Resolved