Captive Portal

Currently running v1.33 'generic PC' on a VMWare platform. The captive portal services over 100 users daily.

We have the idle timeout set to  480 minutes. Thus, should a user of the captive portal remain inactive for 480 minutes, he/she is disconnected, and must re-authenticate via portal page to continue use.

However, since the beginning of 2012, the idle timeout has been inoperative. I've verified this through the 'captive portal > status' page and found many users' 'last activity' exceeds several weeks prior, yet they remain connected.

Has anyone else experienced this issue?

Thanks,

Dan

Sounds like the "minicron" scheduler that triggers periodic session maintenance has died. What is the output of "ps xauww" (entered on /exec.php)? When was the last time this box was rebooted?

[root 47068 0.0 0.1 1268 748 ?? INs 3Jan12 0:06.20 /usr/local/bin/minicron 60 /var/run/minicron.pid /etc/rc.prunecaptiveportal]

Output of "ps xauww":

$ ps xauww
USER     PID %CPU %MEM   VSZ   RSS  TT  STAT STARTED      TIME COMMAND
root      10 92.6  0.0     0     8  ??  RL   27Jul11 278903:46.69 [idle]
root       0  0.0  0.0     0     0  ??  WLs  27Jul11   0:00.00 [swapper]
root       1  0.0  0.2  1452   896  ??  SLs  27Jul11   5:29.33 /sbin/init --
root       2  0.0  0.0     0     8  ??  DL   27Jul11   7:04.13 [g_event]
root       3  0.0  0.0     0     8  ??  DL   27Jul11   9:25.83 [g_up]
root       4  0.0  0.0     0     8  ??  DL   27Jul11   8:44.07 [g_down]
root       5  0.0  0.0     0     8  ??  DL   27Jul11   0:00.00 [crypto]
root       6  0.0  0.0     0     8  ??  DL   27Jul11   0:00.00 [crypto returns]
root       7  0.0  0.0     0     8  ??  DL   27Jul11   0:00.00 [thread taskq]
root       8  0.0  0.0     0     8  ??  DL   27Jul11   0:00.00 [acpi_task_0]
root       9  0.0  0.0     0     8  ??  DL   27Jul11   0:00.00 [acpi_task_1]
root      11  0.0  0.0     0     8  ??  WL   27Jul11 490:31.96 [swi1: net]
root      12  0.0  0.0     0     8  ??  WL   27Jul11 358:25.72 [swi4: clock sio]
root      13  0.0  0.0     0     8  ??  WL   27Jul11   0:00.00 [swi3: vm]
root      14  0.0  0.0     0     8  ??  DL   27Jul11  24:52.06 [yarrow]
root      15  0.0  0.0     0     8  ??  WL   27Jul11   0:00.00 [swi5: +]
root      16  0.0  0.0     0     8  ??  WL   27Jul11   0:00.00 [swi6: Giant taskq]
root      17  0.0  0.0     0     8  ??  WL   27Jul11   0:00.00 [swi6: task queue]
root      18  0.0  0.0     0     8  ??  DL   27Jul11   0:00.00 [acpi_task_2]
root      19  0.0  0.0     0     8  ??  DL   27Jul11   0:00.00 [xpt_thrd]
root      20  0.0  0.0     0     8  ??  WL   27Jul11   0:00.00 [swi2: cambio]
root      21  0.0  0.0     0     8  ??  DL   27Jul11   0:00.00 [kqueue taskq]
root      22  0.0  0.0     0     8  ??  WL   27Jul11   0:00.00 [irq9: acpi0]
root      23  0.0  0.0     0     8  ??  WL   27Jul11   0:03.15 [irq14: ata0]
root      24  0.0  0.0     0     8  ??  WL   27Jul11   0:00.00 [irq15: ata1]
root      25  0.0  0.0     0     8  ??  WL   27Jul11  82:18.42 [irq18: em0]
root      26  0.0  0.0     0     8  ??  WL   27Jul11 122:21.79 [irq19: em1]
root      27  0.0  0.0     0     8  ??  WL   27Jul11   0:54.45 [irq16: em2]
root      28  0.0  0.0     0     8  ??  WL   27Jul11   0:00.00 [irq1: atkbd0]
root      29  0.0  0.0     0     8  ??  WL   27Jul11   0:00.00 [swi0: sio]
root      30  0.0  0.0     0     8  ??  DL   27Jul11   0:42.34 [fdc0]
root      31  0.0  0.0     0     8  ??  DL   27Jul11  10:59.52 [md0]
root      32  0.0  0.0     0     8  ??  DL   27Jul11   0:08.56 [pagedaemon]
root      33  0.0  0.0     0     8  ??  DL   27Jul11 963:30.82 [pagezero]
root      34  0.0  0.0     0     8  ??  DL   27Jul11   0:13.75 [idlepoll]
root      35  0.0  0.0     0     8  ??  DL   27Jul11   0:41.17 [bufdaemon]
root      36  0.0  0.0     0     8  ??  DL   27Jul11   0:44.16 [vnlru]
root      37  0.0  0.0     0     8  ??  DL   27Jul11   5:59.81 [syncer]
root      38  0.0  0.0     0     8  ??  DL   27Jul11   0:41.47 [softdepflush]
root      39  0.0  0.0     0     8  ??  DL   27Jul11  14:49.41 [schedcpu]
root     119  0.0  0.3  1968  1528  ??  Ss   27Jul11  33:08.30 /sbin/ipmon -sD
root     135  0.0  0.4  2648  2068  ??  Ss   27Jul11   0:20.35 /usr/local/sbin/mini_httpd -S -E /var/etc/cert.pem -c **.php|**.cgi -u root -maxproc 16 -i /var/run/mini_httpd.pid
root     258  0.0  0.2  1712  1188  ??  I    27Jul11   0:00.01 /bin/sh /etc/rc.initial console
root   16489  0.0  0.4  2620  1768  ??  IN    8:24AM   0:00.00 /usr/local/sbin/mini_httpd -a -M 0 -u root -maxproc 16 -maxperip 4 -p 8000 -i /var/run/mini_httpd.cp.pid -cpelement /var/db/cpelements <<LAN IP Address>>:8000
root   16944  0.0  0.4  2620  1768  ??  IN    8:25AM   0:00.00 /usr/local/sbin/mini_httpd -a -M 0 -u root -maxproc 16 -maxperip 4 -p 8000 -i /var/run/mini_httpd.cp.pid -cpelement /var/db/cpelements <<LAN IP Address>>:8000
root   17096  0.0  0.4  2620  1768  ??  IN    8:25AM   0:00.00 /usr/local/sbin/mini_httpd -a -M 0 -u root -maxproc 16 -maxperip 4 -p 8000 -i /var/run/mini_httpd.cp.pid -cpelement /var/db/cpelements <<LAN IP Address>>:8000
root   17103  0.0  0.4  2620  1768  ??  IN    8:25AM   0:00.00 /usr/local/sbin/mini_httpd -a -M 0 -u root -maxproc 16 -maxperip 4 -p 8000 -i /var/run/mini_httpd.cp.pid -cpelement /var/db/cpelements <<LAN IP Address>>:8000
root   17337  0.0  1.7  8896  8388  ??  SN    8:26AM   0:00.03 /usr/local/bin/php exec.php
root   17338  0.0  0.0     0     0  ??  Z     8:26AM   0:00.00 <defunct>
root   17339  0.0  0.5  2732  2264  ??  S     8:26AM   0:00.00 /usr/local/sbin/mini_httpd -S -E /var/etc/cert.pem -c **.php|**.cgi -u root -maxproc 16 -i /var/run/mini_httpd.pid
root   17340  0.0  0.2  1708  1124  ??  SN    8:26AM   0:00.00 sh -c ps xauww
root   17341  0.0  0.2  1476   976  ??  RN    8:26AM   0:00.00 ps xauww
root   47065  0.0  0.3  2620  1716  ??  SNs   3Jan12  11:38.63 /usr/local/sbin/mini_httpd -a -M 0 -u root -maxproc 16 -maxperip 4 -p 8000 -i /var/run/mini_httpd.cp.pid -cpelement /var/db/cpelements <<LAN IP Address>>:8000
root   47068  0.0  0.1  1268   748  ??  INs   3Jan12   0:06.20 /usr/local/bin/minicron 60 /var/run/minicron.pid /etc/rc.prunecaptiveportal
nobody 65148  0.0  0.2  1468  1168  ??  SN   10:03AM   0:04.67 /usr/local/sbin/dnsmasq --edns-packet-max=4096 --all-servers
root   65156  0.0  0.5  2644  2292  ??  SNs  10:03AM   0:02.79 /usr/local/sbin/dhcpd -cf /var/etc/dhcpd.conf em1
root   65186  0.0  0.2  1708  1156  ??  IN   10:03AM   0:00.00 /bin/sh /usr/local/bin/runsntp.sh /var/run/runsntp.pid /var/run/sntp.pid 300  <<WAN Default Gateway>>
root   65187  0.0  0.2  1420  1072  ??  IN   10:03AM   0:00.00 /usr/sbin/sntp -r -P no -l /var/run/sntp.pid -x 300 <<WAN Default Gateway>>
root   98195  0.0  0.2  1436  1096  ??  SNs  10Aug11  46:31.92 /usr/sbin/syslogd -s -f /var/etc/syslog.conf


Current uptime / Time since last reboot:

204 days, 19:58

Thanks for the response Manuel!!

Since we're an enterprise environment we have to document all issues, thus I'm hoping maybe we can find a root cause instead of doing a reboot. Prior to this M0n0wall implementation we used Cisco BBSM for guest access (which just like anything Cisco comes at a price!) but I have to admit, m0n0wall has proved more stable and less problematic than the BBSM used to be, despite this minor issue. You have a great product.

Anyway, does this output tell you if the "minicron" is the issue?

Thanks - apparently minicron is still running, so that is not the problem. The output of http://m0n0wall/status.php, as well as the output from "cat /var/db/captiveportal.db" (executed via exec.php) could help narrow down this issue. You can send it to me via e-mail (mk@neon1.net) if you prefer.

Attached is the status.php output.
 

Here is the output of "cat /var/db/captiveportal.db" in exec:

$ cat /var/db/captiveportal.db
1325598763,10027,<<LAN Net>>29,,<<user>>ker,<<Hash>>963,,,,
1325604686,10046,<<LAN Net>>7,,<<user>>und,<<Hash>>4e7,,,,
1325609190,10054,<<LAN Net>>00,,<<user>>ms2,<<Hash>>905,,,,
1325622938,10056,<<LAN Net>>31,,<<user>>ldo,<<Hash>>fe6,,,,
1325684594,10035,<<LAN Net>>5,,<<user>>rns,<<Hash>>8ed,,,,
1325684813,10036,<<LAN Net>>6,,<<user>>ace,<<Hash>>d24,,,,
1325684950,10039,<<LAN Net>>7,,<<user>>ste,<<Hash>>293,,,,
1325709681,10075,<<LAN Net>>2,,<<user>>uch,<<Hash>>24e,,,,
1325779082,10073,<<LAN Net>>7,,<<user>>ord,<<Hash>>02b,,,,
1325780013,10074,<<LAN Net>>36,,<<user>>ing,<<Hash>>4e7,,,,
1325780587,10077,<<LAN Net>>45,,<<user>>ert,<<Hash>>d37,,,,
1325780703,10078,<<LAN Net>>46,,<<user>>erd,<<Hash>>b7f,,,,
1325791164,10086,<<LAN Net>>11,,<<user>>fon,<<Hash>>6c4,,,,
1326120672,10064,<<LAN Net>>9,,<<user>>cox,<<Hash>>daf,,,,
1326129136,10092,<<LAN Net>>66,,<<user>>ard,<<Hash>>92d,,,,
1326228167,10053,<<LAN Net>>04,,<<user>>zen,<<Hash>>055,,,,
1326289336,10041,<<LAN Net>>3,,<<user>>afe,<<Hash>>eab,,,,
1326722015,10049,<<LAN Net>>10,,<<user>>uer,<<Hash>>65f,,,,
1326729513,10093,<<LAN Net>>19,,<<user>>ink,<<Hash>>a0d,,,,
1326810200,10060,<<LAN Net>>69,,<<user>>ove,<<Hash>>f2a,,,,
1326816045,10108,<<LAN Net>>71,,<<user>>yer,<<Hash>>4e3,,,,
1326819090,10111,<<LAN Net>>,,<<user>>mes,<<Hash>>1f6,,,,
1326819262,10112,<<LAN Net>>,,<<user>>eak,<<Hash>>c1e,,,,
1326900825,10107,<<LAN Net>>62,,<<user>>iff,<<Hash>>3a8,,,,
1326903493,10114,<<LAN Net>>9,,<<user>>var,<<Hash>>935,,,,
1326917297,10115,<<LAN Net>>29,,<<user>>est,<<Hash>>89a,,,,
1326983156,10096,<<LAN Net>>90,,<<user>>del,<<Hash>>872,,,,
1326983337,10067,<<LAN Net>>91,,<<user>>ger,<<Hash>>11d,,,,
1326986531,10120,<<LAN Net>>95,,<<user>>ney,<<Hash>>544,,,,
1326990082,10122,<<LAN Net>>99,,<<user>>p24,<<Hash>>396,,,,
1326990108,10123,<<LAN Net>>,,<<user>>p23,<<Hash>>e02,,,,
1326990154,10124,<<LAN Net>>,,<<user>>mp1,<<Hash>>258,,,,
1326990401,10125,<<LAN Net>>,<<user>>mp2,<<Hash>>55d,,,,
1326990493,10126,<<LAN Net>>,,<<user>>p25,<<Hash>>656,,,,
1327068245,10050,<<LAN Net>>65,,<<user>>ser,<<Hash>>b86,,,,
1327075384,10109,<<LAN Net>>89,,<<user>>pre,<<Hash>>7c4,,,,
1327324611,10042,<<LAN Net>>59,,<<user>>sch,<<Hash>>983,,,,
1327328335,10090,<<LAN Net>>70,,<<user>>ley,<<Hash>>abf,,,,
1327349565,10137,<<LAN Net>>6,,<<user>>yes,<<Hash>>70d,,,,
1327414060,10106,<<LAN Net>>78,,<<user>>nks,<<Hash>>f31,,,,
1327415690,10132,<<LAN Net>>6,,<<user>>zak,<<Hash>>d10,,,,
1327416420,10141,<<LAN Net>>17,,<<user>>ull,<<Hash>>b99,,,,
1327425962,10051,<<LAN Net>>51,,<<user>>aya,<<Hash>>af5,,,,
1327441770,10113,<<LAN Net>>7,,<<user>>don,<<Hash>>dc0,,,,
1327451157,10101,<<LAN Net>>00,,<<user>>ill,<<Hash>>548,,,,
1327503633,10131,<<LAN Net>>18,,<<user>>ntz,<<Hash>>3fe,,,,
1327511389,10088,<<LAN Net>>30,,<<user>>on3,<<Hash>>401,,,,
1327511890,10144,<<LAN Net>>31,,<<user>>on2,<<Hash>>4d6,,,,
1327512001,10145,<<LAN Net>>32,,<<user>>on1,<<Hash>>fb2,,,,
1327522254,10147,<<LAN Net>>72,,<<user>>t-1,<<Hash>>531,,,,
1327587930,10085,<<LAN Net>>03,,<<user>>thy,<<Hash>>ca1,,,,
1327588777,10105,<<LAN Net>>4,,<<user>>erg,<<Hash>>bfb,,,,
1327672484,10061,<<LAN Net>>1,,<<user>>aar,<<Hash>>24a,,,,
1327948018,10136,<<LAN Net>>0,,<<user>>azo,<<Hash>>ba6,,,,
1327950350,10089,<<LAN Net>>94,,<<user>>uff,<<Hash>>85d,,,,
1327952491,10095,<<LAN Net>>98,,<<user>>den,<<Hash>>cd0,,,,
1328017010,10045,<<LAN Net>>1,,<<user>>yes,<<Hash>>181,,,,
1328017048,10048,<<LAN Net>>9,,<<user>>eil,<<Hash>>5c3,,,,
1328024387,10119,<<LAN Net>>10,,<<user>>ith,<<Hash>>c1e,,,,
1328034728,10110,<<LAN Net>>4,,<<user>>les,<<Hash>>1c7,,,,
1328041425,10149,<<LAN Net>>01,,<<user>>ll1,<<Hash>>76b,,,,
1328116700,10157,<<LAN Net>>9,,<<user>>ing,<<Hash>>211,,,,
1328137343,10055,<<LAN Net>>9,,<<user>>ius,<<Hash>>c35,,,,
1328202311,10139,<<LAN Net>>8,,<<user>>ick,<<Hash>>1c5,,,,
1328287185,10117,<<LAN Net>>,,<<user>>ach,<<Hash>>753,,,,
1328290323,10032,<<LAN Net>>0,,<<user>>olm,<<Hash>>375,,,,
1328546521,10152,<<LAN Net>>1,<<MAC Addr>>b:e9,<<user>>kau,<<Hash>>776,,,,
1328557931,10164,<<LAN Net>>7,,<<user>>rdy,<<Hash>>fd7,,,,
1328558505,10165,<<LAN Net>>,,<<user>>ton,<<Hash>>4c7,,,,
1328634082,10154,<<LAN Net>>51,,<<user>>ins,<<Hash>>c07,,,,
1328635405,10104,<<LAN Net>>,,<<user>>-ng,<<Hash>>57b,,,,
1328638610,10161,<<LAN Net>>,,<<user>>lor,<<Hash>>149,,,,
1328646600,10169,<<LAN Net>>47,,<<user>>ine,<<Hash>>eba,,,,
1328651393,10079,<<LAN Net>>78,,<<user>>cio,<<Hash>>af6,,,,
1328704192,10031,<<LAN Net>>09,,<<user>>ris,<<Hash>>8a2,,,,
1328705911,10037,<<LAN Net>>1,,<<user>>reC,<<Hash>>10a,,,,
1328712233,10128,<<LAN Net>>3,,<<user>>ott,<<Hash>>012,,,,
1328726155,10153,<<LAN Net>>6,,<<user>>eve,<<Hash>>cb6,,,,
1328737450,10072,<<LAN Net>>2,,<<user>>ann,<<Hash>>8f4,,,,
1328737547,10171,<<LAN Net>>3,,<<user>>uch,<<Hash>>925,,,,
1328738052,10172,<<LAN Net>>62,,<<user>>ert,<<Hash>>0cd,,,,
1328739438,10173,<<LAN Net>>8,,<<user>>ley,<<Hash>>cf4,,,,
1328801164,10151,<<LAN Net>>71,,<<user>>onA,<<Hash>>0f5,,,,
1328809780,10176,<<LAN Net>>6,,<<user>>ler,<<Hash>>82a,,,,
1328814653,10143,<<LAN Net>>2,,<<user>>mer,<<Hash>>6f1,,,,
1328839005,10026,<<LAN Net>>02,,<<user>>sma,<<Hash>>59a,,,,
1328883561,10127,<<LAN Net>>69,,<<user>>rob,<<Hash>>fa9,,,,
1328898291,10142,<<LAN Net>>16,,<<user>>mer,<<Hash>>e9b,,,,
1328898760,10181,<<LAN Net>>62,,<<user>>sch,<<Hash>>325,,,,
1328899703,10150,<<LAN Net>>09,,<<user>>rce,<<Hash>>29f,,,,
1328914584,10116,<<LAN Net>>66,,<<user>>lph,<<Hash>>3dc,,,,
1328970671,10023,<<LAN Net>>0,,<<user>>yDS,<<Hash>>09e,,,,
1329136644,10038,<<LAN Net>>01,,<<user>>egg,<<Hash>>299,,,,
1329141068,10070,<<LAN Net>>74,,<<user>>des,<<Hash>>285,,,,
1329141527,10071,<<LAN Net>>19,,<<user>>ms1,<<Hash>>d36,,,,
1329154539,10103,<<LAN Net>>76,,<<user>>ard,<<Hash>>acf,,,,
1329155614,10129,<<LAN Net>>37,,<<user>>ms4,<<Hash>>ca1,,,,
1329162223,10170,<<LAN Net>>3,,<<user>>ett,<<Hash>>c93,,,,
1329162423,10156,<<LAN Net>>46,,<<user>>ms3,<<Hash>>a43,,,,
1329166438,10182,<<LAN Net>>5,,<<user>>let,<<Hash>>01f,,,,
1329170407,10134,<<LAN Net>>45,,<<user>>ell,<<Hash>>fba,,,,
1329230230,10025,<<LAN Net>>24,,<<user>>ker,<<Hash>>1a3,,,,
1329231920,10159,<<LAN Net>>3,,<<user>>ter,<<Hash>>e75,,,,
1329237813,10186,<<LAN Net>>8,,<<user>>een,<<Hash>>14e,,,,
1329242450,10183,<<LAN Net>>4,,<<user>>don,<<Hash>>5ce,,,,
1329244226,10162,<<LAN Net>>10,,<<user>>ien,<<Hash>>0c8,,,,
1329244818,10189,<<LAN Net>>39,,<<user>>hur,<<Hash>>272,,,,
1329245996,10190,<<LAN Net>>87,,<<user>>utt,<<Hash>>5b5,,,,
1329246323,10191,<<LAN Net>>88,,<<user>>eau,<<Hash>>c53,,,,
1329247084,10192,<<LAN Net>>7,,<<user>>gue,<<Hash>>ba0,,,,
1329261956,10168,<<LAN Net>>70,,<<user>>dez,<<Hash>>ae7,,,,
1329313326,10058,<<LAN Net>>6,,<<user>>ard,<<Hash>>352,,,,
1329319966,10166,<<LAN Net>>19,,<<user>>ung,<<Hash>>39b,,,,
1329323066,10179,<<LAN Net>>14,,<<user>>pel,<<Hash>>08a,,,,
1329329444,10177,<<LAN Net>>27,,<<user>>ing,<<Hash>>c5f,,,,
1329404276,10148,<<LAN Net>>,,<<user>>ger,<<Hash>>f40,,,,
1329408228,10187,<<LAN Net>>32,,<<user>>rin,<<Hash>>aab,,,,
1329409071,10185,<<LAN Net>>60,,<<user>>Day,<<Hash>>da8,,,,
1329411317,10199,<<LAN Net>>02,,<<user>>nds,<<Hash>>a12,,,,
1329417131,10135,<<LAN Net>>5,,<<user>>esb,<<Hash>>e7b,,,,
1329424424,10201,<<LAN Net>>6,,<<user>>may,<<Hash>>9d7,,,,
1329427731,10155,<<LAN Net>>2,,<<user>>ry,<<Hash>>63e,,,,
1329428148,10204,<<LAN Net>>0,<<MAC Addr>>2:ce,<<user>>der,<<Hash>>1db,,,,
1329432803,10033,<<LAN Net>>0,,<<user>>ick,<<Hash>>93b,,,,
1329436243,10052,<<LAN Net>>91,,<<user>>ung,<<Hash>>a7b,,,,
1329486829,10069,<<LAN Net>>35,,<<user>>dzi,<<Hash>>0a0,,,,
1329487528,10087,<<LAN Net>>33,,<<user>>ier,<<Hash>>8b9,,,,
1329487540,10091,<<LAN Net>>32,,<<user>>igt,<<Hash>>f7,,,,
1329493254,10146,<<LAN Net>>15,<<MAC Addr>>9:ce,<<user>>son,<<Hash>>c91,,,,
1329494023,10057,<<LAN Net>>59,,<<user>>lth,<<Hash>>e87,,,,
1329494189,10178,<<LAN Net>>3,,<<user>>lis,<<Hash>>e82,,,,
1329496170,10174,<<LAN Net>>92,,<<user>>ier,<<Hash>>bee,,,,
1329506559,10193,<<LAN Net>>26,,<<user>>RC2,<<Hash>>7a9,,,,
1329507648,10194,<<LAN Net>>71,,<<user>>ung,<<Hash>>764,,,,
1329513566,10188,<<LAN Net>>7,,<<user>>lan,<<Hash>>86a,,,,
1329516696,10043,<<LAN Net>>7,,<<user>>ila,<<Hash>>942,,,,
1329523515,10081,<<LAN Net>>9,,<<user>>lly,<<Hash>>f84,,,,
1329740123,10022,<<LAN Net>>,,<<user>>ard,<<Hash>>d0b,,,,
1329740196,10024,<<LAN Net>>40,,<<user>>tta,<<Hash>>35b,,,,
1329740278,10029,<<LAN Net>>69,<<MAC Addr>>0:aa,<<user>>eke,<<Hash>>498,,,,
1329742208,10040,<<LAN Net>>73,,<<user>>rtz,<<Hash>>189,,,,
1329742432,10044,<<LAN Net>>,,<<user>>son,<<Hash>>2a6,,,,
1329742791,10034,<<LAN Net>>41,<<MAC Addr>>a:08,<<user>>nes,<<Hash>>652,,,,
1329744247,10062,<<LAN Net>>4,<<MAC Addr>>1:c3,<<user>>rym,<<Hash>>f5d,,,,
1329744317,10063,<<LAN Net>>18,<<MAC Addr>>b:64,<<user>>dke,<<Hash>>205,,,,
1329744801,10068,<<LAN Net>>28,<<MAC Addr>>5:fb,<<user>>len,<<Hash>>dd4,,,,
1329745446,10076,<<LAN Net>>36,<<MAC Addr>>9:32,<<user>>lls,<<Hash>>750,,,,
1329745675,10080,<<LAN Net>>51,<<MAC Addr>>7:30,<<user>>ske,<<Hash>>eed,,,,
1329745768,10083,<<LAN Net>>0,<<MAC Addr>>e:60,<<user>>yan,<<Hash>>d36,,,,
1329745905,10084,<<LAN Net>>77,,<<user>>ton,<<Hash>>db5,,,,
1329746301,10066,<<LAN Net>>38,<<MAC Addr>>4:f1,<<user>>ron,<<Hash>>f66,,,,
1329746998,10097,<<LAN Net>>09,,<<user>>ead,<<Hash>>ee5,,,,
1329747033,10098,<<LAN Net>>,<<MAC Addr>>3:10,<<user>>nje,<<Hash>>0fa,,,,
1329747060,10099,<<LAN Net>>27,<<MAC Addr>>5:aa,<<user>>ott,<<Hash>>180,,,,
1329747132,10100,<<LAN Net>>8,,<<user>>ook,<<Hash>>c69,,,,
1329747421,10030,<<LAN Net>>30,<<MAC Addr>>5:dc,<<user>>ars,<<Hash>>e0f,,,,
1329748550,10102,<<LAN Net>>9,<<MAC Addr>>f:6c,<<user>>obs,<<Hash>>f81,,,,
1329748603,10118,<<LAN Net>>8,<<MAC Addr>>c:a3,<<user>>g-2,<<Hash>>642,,,,
1329748939,10121,<<LAN Net>>51,<<MAC Addr>>b:97,<<user>>onB,<<Hash>>337,,,,
1329749285,10130,<<LAN Net>>86,<<MAC Addr>>d:2e,<<user>>ffs,<<Hash>>9d6,,,,
1329749546,10138,<<LAN Net>>9,,<<user>>eel,<<Hash>>54d,,,,
1329750137,10047,<<LAN Net>>0,,<<user>>ird,<<Hash>>4f5,,,,
1329750292,10133,<<LAN Net>>5,,<<user>>gel,<<Hash>>f43,,,,
1329750808,10082,<<LAN Net>>9,<<MAC Addr>>c:8b,<<user>>son,<<Hash>>114,,,,
1329751592,10140,<<LAN Net>>39,<<MAC Addr>>3:26,<<user>>hak,<<Hash>>e84,,,,
1329752861,10158,<<LAN Net>>05,<<MAC Addr>>d:d8<<user>>elf,<<Hash>>6e1,,,,
1329752931,10160,<<LAN Net>>0,<<MAC Addr>>5:ad,<<user>>ell,<<Hash>>3c8,,,,
1329753257,10065,<<LAN Net>>2,,<<user>>ear,<<Hash>>a4d,,,,
1329753789,10094,<<LAN Net>>3,,<<user>>ine,<<Hash>>520,,,,
1329755200,10059,<<LAN Net>>3,,<<user>>imo,<<Hash>>9ce,,,,

Manuel, thanks again for your assistance with diagnosing thus far!
Here is an update on symptoms:

Some users' "Last activity" in the status_captiveportal.php page far exceeds the allocated 480 minutes. For example, users "ace" and "ste":
<<LAN Net>>6       01/04/2012 07:46:53   7.64 MB   1.45 MB   01/05/2012 16:42:31   <<User>>ace    
<<LAN Net>>7       01/04/2012 07:49:10   16.49 MB   2.30 MB   01/29/2012 00:08:15   <<User>>ste



However, Some users appear to be 'disconnected' correctly, and are not listed in the status_captiveportal.php page as expected. The diag_logs_portal.php page reflects this. For example, user "own":
Feb 18 02:28:43   TIMEOUT: <<User>>own, <<MAC Addr>>2:c0, <<LAN Net>>9
Feb 17 08:19:53   LOGIN: <<User>>own, <<MAC Addr>>2:c0, <<LAN Net>>9

Thus, the scope of the issue is either: Some users are still displayed on the status_captiveportal.php page after disconnection occurs, OR Some users are failing to be disconnected per inactivity timeout setting.

Attached is the text contents of the status_captiveportal.php and diag_logs_portal.php pages.

*Edited for 'verbage'

Thanks for the detailed logs. At first I thought there were multiple sessions for the same client IP addresses, but I suppose that's only a side effect of redacting the subnet part (since LAN uses a /22 mask).

It's quite a strange phenomenon, and looking at the code that cleans up the old sessions once a minute, I can't see much that could go wrong. The timestamp of the last packet received from the client is apparently determined correctly (the same method is used on the captive portal status page).

Could you also run "cat /var/db/captiveportal_mac.db" please? There shouldn't be any entries since you're apparently not using the pass-thru MAC feature, but just to be sure there aren't any remnants of an earlier configuration or something.

One thing that has caught my eye is that your idle timeout is much larger than your DHCP lease time. While not the problem in this case (the sessions have clearly exceeded their idle time and should be disconnected by the portal), you might run into the situation that a client's DHCP lease expires before their idle timeout elapses. If another client gets the same IP address (possible when pool usage is high), that client might be able to continue the original user's session (DHCP leases and captive portal sessions are not directly coupled in m0n0wall). I suggest setting idle timeout and DHCP lease time such that the idle timeout is less than half of the DHCP lease time (m0n0wall default lease time is two hours).

Also, MAC filtering is disabled on the captive portal (why was this necessary? captive portal clients behind router?), and most of the sessions don't have a MAC address associated. Since there are also many "arplookup failed" messages in the log, I'm wondering if there's confusion about the subnet size, or overlapping subnets...

You asked a few questions regarding the DHCP lease time and disabling of MAC address filtering. The m0n0wall services many locations, each on different subnets (layer 3 boundaries). At the primary location (where m0n0wall resides) clients are on the same subnet as the server. Thus, the server can determine the MAC address of some clients, but not all.

The server provides DHCP for clients at the primary location. Since we do not use proxy / 'ip helper' DHCP, each remote location has it's own DHCP service.

I'm fairly confident we are clear of overlaping subnet or ip conflicts, as our IP schema in this VRF has been in place for years and is actively policed by an IPAM appliance.

When I executed cat /var/db/captiveportal_mac.db" I received:

$ cat /var/db/captiveportal_mac.db


To summerize..

We have MAC filtering disabled due to the layer 3 boundaries between the server and most locations.

Each remote location has its own DHCP service. The lease-time on the remote DHCP servers is 24 hours. Per your suggestion I'll seek approval to amend the lease times to 4 hours (half of the idle timeout).


I'm going to setup a few test PCs with portal logins and and attempt to recreate the issue. I'll let you know what I find...

EDIT: You mentioned I should ensure the ..."idle timeout is less than half of the DHCP lease time." I incorrectly reversed these in my previous paragraphs.

[It appears the issue is only occurring with users connecting from remote sites, as only those sessions with no MAC address entries on status_captiveportal.php page exhibit the issue.]

One more thought for the day....

It appears the issue is only occurring with users connecting from remote sites, as only those sessions with no MAC address entries on status_captiveportal.php page exhibit the issue. Conversely, all sessions with MAC address entries have a "Last activity" within 480 minutes.

As you probably know, due to the nature of broadcast domains every packet from a remote subnet will have the same source MAC address upon ingress at the M0n0wall server.

Does the "inactivity timeout" function track by MAC address or IP Address?

[It appears the issue is only occurring with users connecting from remote sites, as only those sessions with no MAC address entries on status_captiveportal.php page exhibit the issue.]

You asked a few questions regarding the DHCP lease time and disabling of MAC address filtering. The m0n0wall services many locations, each on different subnets (layer 3 boundaries). At the primary location (where m0n0wall resides) clients are on the same subnet as the server. Thus, the server can determine the MAC address of some clients, but not all.

Ah OK, that's fine then. I'm still wondering where the arplookup errors came from though...

$ cat /var/db/captiveportal_mac.db

Now that's interesting - the file shouldn't exist at all (i.e. it should have given you a "No such file or directory" error) since there are no passthru MAC entries. But after some digging in the code and trying to reproduce this, I think I know how this happened: apparently some pass-thru MAC entries have been added in the past, then all of them have been removed, but the captive portal (or the whole firewall) has not been restarted since (only pass-thru MAC changes applied). Since there's a bug in the code, this means that this empty file was left behind and has then confused the code that deals with cleaning up old sessions, but only if their MAC address was not known.

If you simply remove the file (rm /var/db/captiveportal_mac.db), the old entries will probably be expired within a minute, and it will keep working properly (until you add/remove pass-thru MAC entries again).

Each remote location has its own DHCP service. The lease-time on the remote DHCP servers is 24 hours. Per your suggestion I'll seek approval to amend the lease times to 4 hours (half of the idle timeout).

I assume that was the un-edited version, but just to be sure: the idle timeout should be less than the DHCP lease time, not the other way round. So if your remote locations have a lease time of 24 hours, then that's fine and you'll only need to change the lease time on the local (m0n0wall) DHCP server.

It appears the issue is only occurring with users connecting from remote sites, as only those sessions with no MAC address entries on status_captiveportal.php page exhibit the issue. Conversely, all sessions with MAC address entries have a "Last activity" within 480 minutes.

Well, that was the important piece of information that made me look in the right place. Good catch, thanks! I'll commit a fix for this to the repository tomorrow; not sure when the next release in the 1.3x branch will be, but at least it will be ready (and will of course be in 1.8 beta immediately). But as long as you don't add any pass-thru MAC entries anymore, it shouldn't happen again (they're less than ideal anyway since they require a HTTP request from the client in order to trigger, so it's better to use DHCP reservation + allowed IP address feature instead).

Does the "inactivity timeout" function track by MAC address or IP Address?

Always by IP address.

Thanks Manuel, the "rm /var/db/captiveportal_mac.db" worked perfectly. Inactive sessions beyond the 480 minutes were disconnected almost immediately with no disruption to others' service.

Hello
I just want let you know that we exeprience exactly the same problem. But we are using Pass-Through MAC and vouchers. The problem is with the client that have pass-through MAC. I have set hardtimeout to 240 min and dhcp lease to 250 min but the client still reamins logged in. The last activity column shows time way beyond the hardtimeout limit. It doesnt help to clear the arp table or firewall states.

We have mono 1.33 runnning on vmware and with 8 D-link AP connected to captive portal interface. About 50 users at the same time.

I have checked with exec.php and the cron job is running. Any suggestions ?

Keep up the good work with Monowall. I have been using it for many years but this is my first post on your board.

Best regards

Christer