[ previous ] [ next ] [ threads ]
 
 From:  YvesDM <ydmlog at gmail dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] problem with captiveportal (locking problem?) - sessions gone missing
 Date:  Wed, 12 Dec 2007 07:42:18 +0100
jan dash ake dot ronnblom at skeria dot skelleftea dot se> wrote:

> Hi!
>
> Im having problem with monowall 1.231 and the captiveportal. Sometimes
> when a
> user should be logged off and the firewall rule removed the user is sort
> of
> "removed" BUT the firewall rule is still there. I think this might be due
> to a
> problem with either in php or somewhere in the captiveportal source.
>
> Or perhaps I cant read the source correct :=)
>
> I have done some testing with a machine with 240 virtual interfaces and
> using
> wget I logged in 240 users. I didn't send any trafic so the firewall rule
> timestamp that is used in the timeout code never triggerd. I fixed this by
> adding the line:
>
>            $lastact = $lastact ? $lastact : 1;
>
> in the captiveportal.inc in the captiveportal_prune_old() function as:
>
>        /* if an idle timeout is specified, get last activity timestamp
> from
> ipfw */
>        if (!$timedout && $idletimeout) {
>            $lastact = captiveportal_get_last_activity($cpdb[$i][1]);
>            captiveportal_logportalauth($lastact, $idletimeout, time(),
> "DEBUG:
> idletimeout1");
>            /* DEBUG: idletimeout1: 0, 900, 1197390106 */
>            $lastact = $lastact ? $lastact : 1;
>            if ($lastact && ((time() - $lastact) >= $idletimeout)) {
>                captiveportal_logportalauth("jardebug", "jardebug",
> "jardebug",
> "DEBUG: idletimeout-SHOULD_LOGOUT");
>                $timedout = true;
>                $term_cause = 4; // Idle-Timeout
>                $stop_time = $lastact; // Entry added to comply with WISPr
>            }
>            captiveportal_logportalauth("jardebug", "jardebug", "jardebug",
> "DEBUG: idletimeout-DONE");
>
>        }
>
> This allows captiveportal for logging out users that haven't sent any
> trafic
> yet!
>
> I have added som shitty debugging code in the captiveportal_lock()
> function and
> also in the rc.captiveportal start script and in the algoritm above. I did
> miss
> to rename it from captiveportal_lock() in the rc.captiveportal script so
> the
> below logs are messy. Sorry :(
>
> However the next time the captiveportal_prune_old() is called it doesn't
> logoff
> all users but only a subset of the users and it also only runs for 14
> seconds
> where it before ran for 51 seconds when it was checking all users. I cant
> understand why not all users are logged off at the same time.
>
> Here is an example. At 17:30:09 (aprox) the function is triggered (proc id
> 10977) and runs for 7 seconds until 17:30:15. You can se that the user
> janron
> has a 0 (actually 1) trafic count and according to the algoritm above he
> should
> be logged off and he is. Then the script terminates se the line
> "captiveportal_lock():7"
>
> Then at 17:30:50 an unknown script runs.
>
> At 17:31:15 the ?_prune_old() is run again until 17:31:19 (total of 3
> seconds)
> and now it continues to loggoff all my "janron" users. But notice since
> none of
> the janron users have sent any data the should all be logged out at the
> first
> runtime.
>
> Dec 11 17:30:15 wifirouter-test logportalauth[10977]: DEBUG: idletimeout1:
> 0,
> 900, 1197390615
> Dec 11 17:30:15 wifirouter-test logportalauth[10977]: DEBUG:
> idletimeout-SHOULD_LOGOUT: jardebug, jardebug, jardebug
> Dec 11 17:30:15 wifirouter-test logportalauth[10977]: DEBUG:
> idletimeout-DONE:
> jardebug, jardebug, jardebug
> Dec 11 17:30:15 wifirouter-test logportalauth[10977]: TIMEOUT: janron,
> 00:ff:7a:c8:1a:58, 192.168.1.183
> Dec 11 17:30:15 wifirouter-test logportalauth[10977]: DEBUG:
> captiveportal_lock(): 7, jardebug, jardebug
> Dec 11 17:30:15 wifirouter-test logportalauth[11261]: DEBUG:
> captiveportal_lock(): jardebug, jardebug, jardebug
> Dec 11 17:30:50 wifirouter-test logportalauth[11795]: DEBUG:
> captiveportal_lock(): jardebug, jardebug, jardebug
> Dec 11 17:31:15 wifirouter-test logportalauth[12034]: DEBUG:
> captiveportal_lock(): jardebug, jardebug, jardebug
> Dec 11 17:31:15 wifirouter-test logportalauth[12034]: DEBUG: idletimeout1:
> 0,
> 900, 1197390675
> Dec 11 17:31:15 wifirouter-test logportalauth[12034]: DEBUG:
> idletimeout-SHOULD_LOGOUT: jardebug, jardebug, jardebug
> Dec 11 17:31:15 wifirouter-test logportalauth[12034]: DEBUG:
> idletimeout-DONE:
> jardebug, jardebug, jardebug
> Dec 11 17:31:15 wifirouter-test logportalauth[12034]: TIMEOUT: janron,
> 00:ff:7a:c8:1a:58, 192.168.1.184
> ...
> Dec 11 17:31:18 wifirouter-test logportalauth[12034]: DEBUG: idletimeout1:
> 0,
> 900, 1197390678
> Dec 11 17:31:18 wifirouter-test logportalauth[12034]: DEBUG:
> idletimeout-SHOULD_LOGOUT: jardebug, jardebug, jardebug
> Dec 11 17:31:18 wifirouter-test logportalauth[12034]: DEBUG:
> idletimeout-DONE:
> jardebug, jardebug, jardebug
> Dec 11 17:31:19 wifirouter-test logportalauth[12034]: TIMEOUT: janron,
> 00:ff:f4:b4:59:db, 192.168.1.212
> Dec 11 17:31:19 wifirouter-test logportalauth[12034]: DEBUG:
> captiveportal_lock(): 3, jardebug, jardebug
>
> When it reaches 192.168.1.240 no more users are logged out so the rest up
> to
> .250 should still be logged on and visible in the captive portal
> webgui. However they are missing but the firewall rules are still there!
>
> Is there anybody who can give me an clue where to look? And how to solve
> this
> problem?
>
> Tomorrow Im going to clean up the debug logs and add more debug messages
> to try
> to see where it goes wrong.
>
> =====================================================


> Assistentgatan 23
> 931 77 Skelleftea (Sweden)
> -----------------------------------------------------
> Phone  : +46-910-58 54 24
> Mobile : 070-397 07 43
> Fax    : +46-910-58 54 99
> URL    : http://skeria.skelleftea.se
> -----------------------------------------------------
> "Those who do not understand Unix are condemned to reinvent it, poorly."
> --
> Henry Spencer
>
>
>

Interesting,

I got a look-a-like issue too from time to time.
Users are shown logged in on the CP status page with 0 bytes up/down.
These sessions can reside for days, untill I clean them manually from
m0n0wall webif.
When it happens, that particular user is unable to login untill the session
is manually cleaned.
I 'll build a custom image with your patch and see what it brings me, tnx
;-)

Kind regards,
Y.