System reached maximum login capacity
-
hi.
i have this messages in pfsense 2.1 captive portal
System reached maximum login capacity.
users can´t logging in captive portal.
somebody know what is the problem?
thanks.
-
What do you have the Maximum concurrent connections set for ?
what kind of hardware? -
thanks ar4uall for you reply.
I was able to fix the problem deleting the captiveportaldn.rules in /var/db
thanks
-
I also got this problem..
It's seems the ruleno saved in captiveportaldn.rules is leaking. While our user count hovering around 1500 user, after 6 hour the max ruleno/captiveportaldn already 8000+.. I will monitor this but our first run last 3 days.. after that all ruleno have been used. This produce error message "System reached maximum login capacity".
Anyone can suggest how do I restart captive portal using cron nightly? Because I believe deleting captiveportaldn without clearing all ipfw pipe/table will have some side effect.
-
If you grab the latest captiveportal.inc from RELENG_2_1 on github and replace yours in /etc/inc/, then it should be OK. It's a bug we have fixed after 2.1-RELEASE.
-
I replace captiveportal.inc from https://github.com/pfsense/pfsense/blob/RELENG_2_1/etc/inc/captiveportal.inc
but the result still the same. System reached maximum login capacity. -
Does anyone know how to fixed this?
logportalauth[86566]: ERROR: System reached maximum login capacity
-
Does anyone know how to fixed this?
logportalauth[86566]: ERROR: System reached maximum login capacity
Install 2.1.1, either a snapshot now, or when it's released.
-
Thank you
Done. Installed 2.1.1 prerelease
Under Observation -
2.1.1-RELEASE (amd64)
built on Tue Apr 1 15:22:32 EDT 2014
FreeBSD 8.3-RELEASE-p14online users:2067
then users also can´t logging in captive portal.
system logs: logportalauth[87673]:ERROR:XXXXX,11:11:11:11:11:11,172.17.8.39,System reached maximum login capacity. -
Good
My gave me the same problem and in the end the only solution I've got is to empty the contents of the file uaxero mentioned in a post above.
I leave the path: /var/db/captiveportaldn.rules
My version is 2.1.1 RELEASE
Sorry for my English
-
Beside deleting it, there is anyway to solute this bug?
Pfense will fix this problem ? -
hello.
What you should check is : are users getting disconnected by the portal interface.
If not, then things will go wrong.Some ideas about how to test if the disconnecting is working, see here https://forum.pfsense.org/index.php?topic=67739.0
-
At that time,The disconnected Does not seem normal!But the future users may 2000+,Has the maximum number of bug, will go wrong!
About disconnected,There are command can be executed to restart the disconnect procedure?in CLI or UI?
-
Can you upgrade to 2.1.2 and verify that this is not happening anymore?
Also some system specification is welcome here.
-
I Have one 2.1.2 with the same problem.
-
I also just hit this issue on 2.1.2.
-
Is this valid fix for this issue or this fixes something else?
https://github.com/pfsense/pfsense/pull/1070
-
This patch looks simple ;)
What about checking if the patch is been used?
Instead of applying the patch:
/* Release unused pipe number */ captiveportal_free_dn_ruleno($pipeno);
use this:
if ($pipeno) { captiveportal_logportalauth($cpentry[4],$cpentry[3],$cpentry[2],"CONCURRENT LOGIN - REUSING IP {$cpentry[2]} - removing pipe number {$pipeno}"); captiveportal_free_dn_ruleno($pipeno); }
It seems (to me) more logic to test the value of $pipeno (should be non-zero) before using it **
And, of course, make a log so you can see that the patch was executed (and actually freeing up a pipe rule).
Remember: no more free pipes rules provokes the message "System reached maximum login capacity". -
This patch is not in 2.1.3 and it should be.
Can somebody reopen this bug?