Rebooting a router will obviously kill any state table within it.
Even if a future PF development hooked bytes-transferred into stateful tracking, rebooting starts from scratch. As it does today with all of the stateful tracking knobs.
When I had a cron job tracking bytes transferred, it was a simple perl script that used the output from sysutils/pftop.
The state table data from pftop are no longer accurate, as it has not caught up with all PF changes. This is why I recommended using pfctl instead -- it can be trusted to stay in sync with PF changes.
From memory, the script ran every 5 minutes, looked for inbound ftp control sessions (port 21) that had surpassed a total bytes transferred threshold (300KB). When found, the script would:
- add the offending IP address to a PF table of blocked addresses
- kill the state (dropping the session)
- append the IP address to the flat-file backup of the PF table (for restoring the table on reboot)
- add a record of the block to a DBMS table with timestamp, IP address, and reason
- send me an e-mail.