Captiveportal db not updating?
-
I've modified the captiveportal.inc file fixing up the code like I suggested, and implemented a sort of optimization to avoid multiple dictionary lookups for each reference to the current row.
Since the forum doesn't allow .inc uploads I've renamed it to .txt
I've put it on our server and it now seems to prune automatically again without problems.
-
It should not do that so please check again.
I put this fix in for the referenced entries https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/3e5c0ab797c65ac4833dfb75049a3e5dd396db74 -
Will try the updated snapshot this afternoon then.
My temporary implemented fix as was attached did get reauthentication running again, but I'm seeing entries in the firewall which aren't in the .db file again. Will report back after testing if the new snapshot fixes the problem. -
Right, tried to do an update with the autoupdater, which seemed to go well, except the captiveportal.inc file is now back to before that last edit again (e.g. using ints for trying to access the data).
I guess I'm a bit stupid, but haven't been able to find a download link for that version of the captiveportal.inc file, so I quickly mirrored my kludge back together.
Also with a bit of a lookover I think I might've found why we're still experiencing users getting dropped out of the database.
It seems captiveportal_write_db only re-reads the .db file (and thus any changes other processes might've done) if unsetindexes isn't an empty array. If the pruning function doesn't remove anyone (which is kinda likely considering it passes once every minute) it seems to behave the same way as before with overwriting any changes made with the memory cached version.
To combat this I've made a small change to the prune function on our server again to do thus:
if (!empty($cpdb)) { captiveportal_write_db($cpdb, false, $unsetindexes); }Still not entirely sure nothing is altered during the prune function other than removing, but the way write_db works seems to discard any changes if there's any deleted indexes, so skipping the write entirely if there's no deleted rows shouldn't prove that much more of a problem.
I'll report back how things go with this approach.
Any pointers on how to retrieve the captiveportal.inc file with your changes would be nice to have too, since any small hacks I make in an attempt to narrow down the root of the problem get overwritten when autoupdate is invoked.
-
From console you can use pfSense shell or just go to rcs.pfsense.org and browse the repo.
-
The if condition I mentioned, wrapped around the captiveportal_write_db call seems to work. Halfway through a normal day we've got 1402 users online without anyone having dropped out of the database. Good difference from yesterday with 1200 users online and 130 missing from the database file.
The edit was done on the same captiveportal.inc file I uploaded before, as I get an error message when trying to download captiveportal.inc from the tree.
-
Well it is now on latest snapshots so you can upgrade or just download an update file.
Extract it and go get the file uploaded manually to pfSense install.Good to hear it works as it should now.
-
Updated to the snapshot last night and reauthentication seems to be running again with the snapshot code.
Unfortunately it's also started dropping logins out of the database again.
Can I once again suggest you alter captiveportal_prune_old() from ending with
captiveportal_write_db($cpdb, false, $unsetindexes);to ending with
//Write database again if we have deleted anything, as an empty $unsetindexes will cause the database to rollback to when this function was called if(!empty($unsetindexes)) { captiveportal_write_db($cpdb, false, $unsetindexes); } -
I actually put another solution in.
Please test that. -
I shall update monday and report how it works out. Thank you very much.
-
yup, that definately seems to have fixed it. No more spilling out of the database.
Thank you very much for all your help :-)