Project

General

Profile

Actions

Bug #1298

closed

Captive portal Idle timeout and Hard timeout not working

Added by Tyler Antonio over 14 years ago. Updated over 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
-
Start date:
02/21/2011
Due date:
% Done:

0%

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

Description

Clients stay logged in even after being inactive for longer than the idle timeout and and aren't disconnected after the hard timeout setting.

I have my idle timeout set to 10 minutes and hard time out set to 24 hours. I've had my laptop idle for 4 hours and it's been authenticated for 2 days.

Actions #1

Updated by Chris Buechler over 14 years ago

  • Status changed from New to Feedback

works for me. first a 5 minute hard timeout, second a 2 minute inactivity timeout. note you pretty much have to unplug a system from the network for it to be inactive, too many background things generate network traffic, that doesn't impact the hard timeout though.

Feb 21 15:17:48    logportalauth[55599]: ACCEPT: unauthenticated, 00:0d:93:74:68:d6, 192.168.1.250
Feb 21 15:23:50    logportalauth[35967]: TIMEOUT: unauthenticated, 00:0d:93:74:68:d6, 192.168.1.250
Feb 21 15:32:25    logportalauth[55599]: ACCEPT: unauthenticated, 00:0d:93:74:68:d6, 192.168.1.250
Feb 21 15:35:04    logportalauth[14114]: TIMEOUT: unauthenticated, 00:0d:93:74:68:d6, 192.168.1.250

what are the exact settings you're using? all of <captiveportal> to </captiveportal> in the config.

Actions #2

Updated by Tyler Antonio over 14 years ago

My laptop was turned off for 4 hours. Still didn't timeout.

Here is the output from the config file. I removed the <element></element> section (As it was a huge pile of characters), and the RADIUS key.

<captiveportal>
                <page>
                        <htmltext>{REMOVED}</htmltext>
                        <errtext>{REMOVED}</errtext>
                </page>
                <timeout>2440</timeout>
                <interface>lan</interface>
                <maxproc/>
                <idletimeout>10</idletimeout>
                <freelogins_count/>
                <freelogins_resettimeout/>
                <enable/>
                <auth_method>radius</auth_method>
                <reauthenticateacct/>
                <httpsname/>
                <bwdefaultdn/>
                <bwdefaultup/>
                <certificate/>
                <cacertificate/>
                <private-key/>
                <logoutwin_enable/>
                <redirurl/>
                <radiusip>10.0.1.3</radiusip>
                <radiusip2/>
                <radiusport/>
                <radiusport2/>
                <radiusacctport/>
                <radiuskey>{KEYREMOVED}</radiuskey>
                <radiuskey2/>
                <radiusvendor>default</radiusvendor>
                <radiussrcip_attribute>opt1</radiussrcip_attribute>
                <radmac_format>default</radmac_format>
                <allowedip>
                        <ip>10.255.56.2</ip>
                        <sn>32</sn>
                        <dir>to</dir>
                        <descr><![CDATA[MAINGATE]]></descr>
                </allowedip>
                <preauthurl/>
                <reauthenticate/>
                <allowedhostname>
                        <hostname>www.tdm-net.com</hostname>
                        <sn/>
                        <dir>to</dir>
                        <descr/>
                </allowedhostname>
        </captiveportal>
Actions #3

Updated by Chris Buechler over 14 years ago

  • Status changed from Feedback to Closed

works fine with your exact config too, diff RADIUS server and using the default portal pages, but those doesn't impact anything related.

Feb 21 20:00:36    logportalauth[57413]: USER LOGIN: cmb, 00:0d:93:74:68:d6, 192.168.1.250
Feb 21 20:10:44    logportalauth[56936]: TIMEOUT: cmb, 00:0d:93:74:68:d6, 192.168.1.250

I'm not going to wait 40.6 hours for your hard timeout but lower timeouts work fine and I know higher ones are working on other installs in production.

not sure what you have going on there but the timeouts definitely work.

Actions

Also available in: Atom PDF