- don't poll periodically, find the next timeout
- use the socket also for commands? Or separate socket?
- add functionality to the control program. Should it change the database
directly, or talk to the daemon to have it do it?
- perhaps handle interfaces too instead of addresses for dynamic ip?
<bge0/4>? What to do with multiple addresses?
- perhaps rate limit against DoS
- perhaps instead of scanning the list have a sparse map by port?
- do we want to use libnpf directly for efficiency?
- add more daemons ftpd?
- do we care about the db state becoming too large?
- instead of a yes = bump one, no = return to 0 interface, do we want
to have something more flexible like?
+n
-n
block
unblock
- do we need an api in blocklistctl to perform maintenance
- fix the blocklistctl output to be more user friendly
- figure out some way to do distributed operation securely (perhaps with
a helper daemon that authenticates local sockets and then communicates
local DB changes to the central server over a secure channel --
perhaps blocklistd-helper can have a back-end that can send updates to
a central server)
- add "blocklistd -l" to enable filter logging on all rules by default
- add some new options in the config file
"/all" - block both TCP and UDP (on the proto field?)
"/log" - enable filter logging (if not the default) (on the name field?)
"/nolog"- disable filter logging (if not the default) (on the name field?)
The latter two probably require a new parameter for blocklistd-helper.
- "blocklistd -f" should (also?) be a blocklistctl function!?!?!
- if blocklistd was started with '-r' then a SIGHUP should also do a
"control flush $rulename" and then re-add all the filter rules?
- should/could /etc/rc.conf.d/ipfilter be created with the following?
