💡 there it is
so as I expected that reboot is causing these 'Unknown' records to be added to the ip_cache database.
When the system is starting up
the filter starts blocking (as it should)..
but the "lists" that pfB would be using are not available (I think this is primarily where tmpfs is memory based - I need to test this on a virtual using disk not ram disk someday - lol)
so when the process goes to look it up of course they are Unknown.
The problem is the "Unknown" entries are being written to the cache and then
subsequent hits from the same IP lookup it up in the cache and find unknown.
even if the underlying list might now be available, it will read the "unknown" from cache and use that. - That's the problem
There is a better way, pondering, but for now the simple solution is don't cache "unknown"
$stmt->execute();
becomes this
if ($pfb_query[0] != 'Unknown') {
$stmt->execute();
}
Now the records won't be cached (still blocked and reported that way during the startup process) but as soon as the underlying data is correct the records start caching with IP address again. - Confirmed by doing...
I'm ok with a couple of hundred block records saying unknown during the boot process, but then using the cached "unknown".. not so good.
Now it occurs to me as well, that the ip_cache appears to only get flushed on a reboot, but the underlying lists used by pfBlocker could change. An IP that was listed and therefore blocked yesterday, may have been removed from a list and therefore should not be cached against the previous list. ie a) it is not on a list anymore (not blocked) and/or b) it is on a different list and should not be listed against the old one (or both)
I'm thinking that when you see this
408 addresses added.337 addresses deleted.
you don't need to worry about the "added" ones - they will cache if/when used.
but the deleted ones (337 in this case) should be removed from the cache if they are there..
The quick solution here might be simply flush the entire cache and just let it start over, like on a reboot. I'm not seeing that it currently does either.(a seek and delete or a flush)
If you reboot often the cache is flushed every time you do, but if you typically run for weeks (like here) the cache will become bloated with IPs that may or may not be what they currently are.
The mechanism to remove stale ones and "update" existing one with fresher info doesn't seem to be there/work IMHO
Pondering continues.. Still need to look at the reports but I don't believe they use the cache and likely shouldn't, you want to report on what happened at that time (from the record) not what happened from a stale or incorrect cache. etc etc
Cheers
