@wazim4u said in Captive Portal DB Issue (Active Users VS Active Vouchers ):
https://forum.netgate.com/post/1224016
That was the time that when ipfw, a firewall component of FreeBHSD, used for the captive portal as it supported and MAC addresses, was removed. The pf firewall was extended (Netgate added MAC related filtering to pf) and from then on only pf was used.
The portal 'glue' code - mostly /etc/inc/captiveportal.inc, PHP, was rewritten so it could dialog with the new pf.
Of course, things were not perfect right after this switch.
@wazim4u said in Captive Portal DB Issue (Active Users VS Active Vouchers ):
https://forum.netgate.com/post/1151842
That's maybe (?) more a resource issue.
Throws 10 of thousands of users on a "single web server" - even if it has multiple queues, multiple PHP-fpm instances.
And again, "ipfw was better" is mentioned here.
@wazim4u said in Captive Portal DB Issue (Active Users VS Active Vouchers ):
https://redmine.pfsense.org/issues/15262
Again, the switch from ipfw to pf is pointed.
Now some 'me' background info :
I don't use vouchers - and I don't have a '10k' portal network.
If I have 30 max portal connected users at any time, it's already a lot for me (don't laugh). It's impossible for me to test the portal under a xK user a load.
Worse : I don't think that any of the pfSense portal code developers have hand's on experience with sites where that number of users are connected.
What I think doesn't have much weight, but : "pf" by itself should be able to handle 10k users just fine. "xK portal users" is maybe a rare thing, a pfSense site with xK ordinary network users is way more common. pf is pretty core for FreeBSD, and, again, imho, can handle the load.
Constant insertion into the portal anchoer, or removal, might be something else ...
Also : just my point of view, you already know this :
pfSense isn't a router/firewall that creates the captive portal functionality.
It's the OS of the devices we use that create the portal's functionality.
The interface of pfSense the has the portal activate adds two rules :
A first rule, which is alias based, that passes all traffic, this rule will also use and apply the portal's GUI firewall rules.
A second rule ; "block all".
The portal user must be able to visit the portal's IP (using TCP a port like 8080) where it will fuind a web server that offers the user to "enter a voucher code". if this voucher code is valid (accepted), the IP and MAC of this uses is added to the first rule.
@wazim4u said in Captive Portal DB Issue (Active Users VS Active Vouchers ):
captiveportal_prune_old_automac()
Humm. Not sure. I would vote for the big one :
captiveportal_prune_old()
See this file :
/etc/rc.prunecaptiveportal
Take notice : this files starts with a
$rcprunelock = try_lock("rcprunecaptiveportal{$cpzone}", 3);
does it's work : calling : captiveportal_prune_old() in /etc/inc/captiveportal.inc
Then unlocks.
Suggestion :
/etc/inc/captiveportal.inc :
[image: 1763395473258-a72c759e-762d-4b85-a931-0b6398f91e03-image.png]
You see the variable "$croninterval" , It doesn't even exist in the pfSense config file.
It isn't surfaced in the GUI neither ...
What happens if you decide that pruning happens every ... 300 seconds instead of 60 seconds ?
Have a look at what captiveportal_prune_old() does.
It enumerates over all connected users. It uses a SQlight 'PHP' data base file, and collects a list with 'user to be removed', and at the end, removes them from the SQlight database file.
While doing so, if applicable, it also does an xml resync ...
Btw : it also calls captiveportal_prune_old_automac().
If this pruning process takes 'a lot of time' and at the same time other portal user are logging in ... what happens ?
To test for 'race conditions', I have to see them happening.
My issue with all this : it's all done using PHP .... that just perfect for a "couple of users".
xK users ? "PHP" isn't probably the best choice anymore.
My option of course.
Anyway, true, there is a list with "big portal users" that experience issues...
