I tested this :
replace :
if (platform_booting()) {
echo "Starting captive portal({$cpcfg['zone']})... ";
/* remove old information */
unlink_if_exists("{$g['vardb_path']}/captiveportal{$cpzone}.db");
} else {
captiveportal_syslog("Reconfiguring captive portal({$cpcfg['zone']}).");
}
/* init ipfw rules */
for this :```
if (platform_booting()) {
echo "Starting captive portal({$cpcfg['zone']})... ";
/* remove old information */
unlink_if_exists("{$g['vardb_path']}/captiveportal{$cpzone}.db");
} else {
captiveportal_syslog("Reconfiguring captive portal({$cpcfg['zone']}).");
/* remove users from the database */
$unsetindexes = array();
$cpdb = captiveportal_read_db();
$unsetindexes = array_column($cpdb,5);
if (!empty($unsetindexes)) {
captiveportal_remove_entries($unsetindexes);
}
captiveportal_syslog("Reconfiguring : database emptied ({$cpcfg['zone']}).");
}
/* init ipfw rules */
What happens is that when **booting**, de database file is just deleted - that's ok, the system is booting, so no ipfw rules, neither logged in user are present anyway.
If not, when enabling or reconfiguring, the database file is emptied.
True, a simple
unlink_if_exists("{$g['vardb_path']}/captiveportal{$cpzone}.db");
does the job also.
All this :
if (platform_booting()) {
echo "Starting captive portal({$cpcfg['zone']})... ";
/* remove old information */
unlink_if_exists("{$g['vardb_path']}/captiveportal{$cpzone}.db");
} else {
captiveportal_syslog("Reconfiguring captive portal({$cpcfg['zone']}).");
}
/* init ipfw rules */
......
could be replace by a mere (no more if statement) :
echo "Starting captive portal({$cpcfg['zone']})... ";
/* remove old information */
unlink_if_exists("{$g['vardb_path']}/captiveportal{$cpzone}.db");
/* init ipfw rules */
.....
captiveportal_init_rules(true);
that follows just after these lines finishes the job.
Remember : every time you (re) configure the Captive Portal instance, all user on that instance** get thrown out.
This is definitely not a good thing when you are running a very busy captive portal.
** Looking through the code, only the reconfigured instance is concerned.
Other instances are not touched, I have tested this with a second captive portal instance.
