Project

General

Profile

Actions

Bug #1653

closed

CP timeout bug: get_last_activity

Added by Josh Stompro over 13 years ago. Updated over 13 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
-
Start date:
07/06/2011
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:
i386

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

Actions #1

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

Actions #2

Updated by Ermal Luçi over 13 years ago

  • Status changed from New to Feedback

Fixed on next snapshots thanks for reporting.

Actions #3

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.

Actions #4

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

Actions #5

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

Actions #6

Updated by Ermal Luçi over 13 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF