System reached maximum login capacity
-
-rw-r–r-- 1 root wheel 805060 Jun 17 11:29 captiveportaldn.rules
-rw-r--r-- 1 root wheel 1262900 May 21 17:29 captiveportaldn.rules.1030521
-rw-r--r-- 1 root wheel 1262900 Jun 16 09:26 captiveportaldn.rules.1030616my solution:When the file size grows to 1262900 ,Users can not log in CP.So I will move the file.
Current users no more than 2000+
about ideal: instead of running this minicron every 60 secondes, would it help if they start every 300 seconds ?
how to modify 60 > 300?
in CLI enter command:/usr/local/bin/minicron 300 /var/run/cp_prunedb_ZZZ.pid /etc/rc.prunecaptiveportal ZZZ
or
edit :vi captiveportal.inc
$croninterval = $cpcfg['croninterval'] ? $cpcfg['croninterval'] : 60;to
$croninterval = $cpcfg['croninterval'] ? $cpcfg['croninterval'] : 300;================================================
what kind of approach is right?
-
-rw-r–r-- 1 root wheel 805060 Jun 17 11:29 captiveportaldn.rules
-rw-r--r-- 1 root wheel 1262900 May 21 17:29 captiveportaldn.rules.1030521
-rw-r--r-- 1 root wheel 1262900 Jun 16 09:26 captiveportaldn.rules.1030616my solution:When the file size grows to 1262900 ,Users can not log in CP.So I will move the file.
Current users no more than 2000+1.3 Mega … :o
Btw: it means the file "captiveportaldn.rules" is also growing.how to modify 60 > 300?
edit :vi captiveportal.inc
$croninterval = $cpcfg['croninterval'] ? $cpcfg['croninterval'] : 60;to
$croninterval = $cpcfg['croninterval'] ? $cpcfg['croninterval'] : 300;================================================
what kind of approach is right?That the one to go !
Normally, <croninterval>isn't defind in the config.xml, so, yes, just change 60 to 300 on that spot should do the job.</croninterval> -
If i use the crontab timed rm captiveportaldn.rules
Whether it will cause other problems?because restart captive portal, all online client must re-authentication,users complain :'(
-
If i use the crontab timed rm captiveportaldn.rules
Whether it will cause other problems?because restart captive portal, all online client must re-authentication,users complain :'(
Don't do that !
If this was file was notusefull at that point, why pfSense generates it in the first place ?
It contains the relationship between all logged in users and the their related pipes.
Removing it and the pipes will not be removed anymore when a user logs out.The number of pipes in the system will continue to grow ….. and pfSense with it.
The file captiveportaldn.rules can be "cleaned", its done when you stop (a zone in) the portal interface.
-
Guys, I have a hard version
2.1.4-RELEASE (i386)
built on Fri Jun 20 12:59:29 EDT 2014
FreeBSD 8.3-RELEASE-p16And I have a similar problem. Users becomes 1500, and Capt portal authentication can not do.
Has anyone found a normal solution?
-
Up to now I still experiencing this problem since 2.1
logportalauth[98669]: ERROR: , , , System reached maximum login capacity2.1.5-RELEASE (amd64)
built on Mon Aug 25 07:44:45 EDT 2014
FreeBSD 8.3-RELEASE-p16 -
How do you solve the problem?
You often overload the server?every day to clean the file?
/var/db/captiveportaldn.rules -
Well….
As usual:
What kind of hardware are you guys using ?
Radius, or not ?
Client get disconnected ?
Tried putting in a hard time out ?
Soft time out - hard time out - DHCP lease time is what ?
This phrase "Skipping CP prunning process because previous/another instance is already running" is present in the captive portal log ? -
1. Dell PowerEdge 2970, 3Gb RAM, 2 CPU
2. Radius
3. Clients can not authorization
4. hard time out is present
5. IDLE timeout 10080 min; Hard timeout 40320 min; DHCP lease time 604870 sek
6.
Sep 19 16:17:34 logportalauth[64207]: ERROR: T**, f0:db:f8:33:fb:6f, 172.16.11.119, System reached maximum login capacity
Sep 19 16:14:19 logportalauth[91861]: ERROR: K*******_d, f0:db:f8:33:fb:6f, 172.16.11.119, System reached maximum login capacity
Sep 19 16:11:54 logportalauth[64207]: ERROR: Gg, f0:db:f8:33:fb:6f, 172.16.11.119, System reached maximum login capacity
Sep 19 16:09:18 logportalauth[95112]: ERROR: K*_d, f0:db:f8:33:fb:6f, 172.16.11.119, System reached maximum login capacity
Sep 19 16:08:03 logportalauth[95112]: ERROR: K*******_d, f0:db:f8:33:fb:6f, 172.16.11.119, System reached maximum login capacity
Sep 19 16:06:30 logportalauth[80230]: ERROR: y*****_a, f0:db:f8:33:fb:6f, 172.16.11.119, System reached maximum login capacity
Sep 19 16:04:54 logportalauth[95112]: ERROR: M****_i, 04:0c:ce:90:d7:bb, 172.16.12.178, System reached maximum login capacity
Sep 19 16:04:46 logportalauth[80230]: ERROR: y*****_a, f0:db:f8:33:fb:6f, 172.16.11.119, System reached maximum login capacity
Sep 19 16:04:44 logportalauth[80230]: ERROR: a*******_ky, 20:d6:07:76:d2:62, 172.16.17.19, System reached maximum login capacity
Sep 19 15:59:31 logportalauth[80230]: ERROR: A***_g, 40:30:04:e5:77:7e, 172.16.18.155, System reached maximum login capacity -
2. Radius
Miss-communication with a Radius server returns a message:
"System reached maximum login capacity"Btw:
Client get disconnected ?
Means: look at your portal log
Are clients disconnected ?
Because, if they don't the all goes well: the system will blow up (== "System reached maximum login capacity" because clients connect - and have to disconnect (are disconnected) to make pleace for new connections)4. hard time out is present
5. IDLE timeout 10080 min; Hard timeout 40320 min; DHCP lease time 604870 sekHummm.
This DHCP time-out is fine for a wired LAN setup using fixed clients.Portal software runs fine with:
Idle time out : 3 -6 hours max
Hardware time out + xx %
DHCP time out hard time out + xx %Wifi clients, per definition, are network-guest-users.
If your clients are semi residential, (staying there for days or weeks) or if they need a connection that is active for hundreds of hours, you should use something different as what pfSense offers.Btw: the program logic can handle the clients, although I really would like to see what happens when the portal software keeps hitting hard this one:
/etc/inc/captiveportal.inc : line 1366 + 1377 (and 1389 + 1409).
