System reached maximum login capacity

uaxero

thanks ar4uall for you reply.

I was able to fix the problem deleting the captiveportaldn.rules in /var/db

thanks

aneip

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.

jimp

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.

lifeform08

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.

lifeform08

Does anyone know how to fixed this?

logportalauth[86566]: ERROR: System reached maximum login capacity

jimp

@lifeform08:

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.

lifeform08

Thank you
Done. Installed 2.1.1 prerelease
Under Observation

magura

2.1.1-RELEASE (amd64)
built on Tue Apr 1 15:22:32 EDT 2014
FreeBSD 8.3-RELEASE-p14

online 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.

jivanmp

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

magura

Beside deleting it, there is anyway to solute this bug?
Pfense will fix this problem ?

Gertjan

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

magura

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?

eri--

Can you upgrade to 2.1.2 and verify that this is not happening anymore?

Also some system specification is welcome here.

tpramos

I Have one 2.1.2 with the same problem.

codywood

I also just hit this issue on 2.1.2.

deltix

Is this valid fix for this issue or this fixes something else?

https://github.com/pfsense/pfsense/pull/1070

Gertjan

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".

deltix

This patch is not in 2.1.3 and it should be.

Can somebody reopen this bug?

doktornotor

https://redmine.pfsense.org/projects/pfsense/repository/revisions/4ec6b54d189dbd84265cf1f7dc18050ae941df7c

uaxero

hi my last update 2.1.3

the problem didn´t return to happen

thanks