This is an interesting problem and one I've chatted with philip@ about
	in the past on IRC.  Basically, bsnmpd(1), when requested for some OIDs
	"in bulk", will return cached data -- meaning, what the OIDs return
	doesn't match what "pfctl -s info" shows.

	If a manual SNMP GET (ex. snmpget) is executed for a single OID that
	would get handled by snmp_pf.ko, the counters/stats for all OIDs within
	that module (snmp_pf.so) are updated and returned.  But all subsequent
	"bulk" requests continue to return the data that the last GET showed.

	I do have tcpdumps available that confirm this problem, and can also
	provide user-level access to production machines if a developer wants
	to do some analysis.  I can provide SNMP community names and so on
	privately.  I've only tested/confirmed this using SNMP protocol 2c due
	to the need for 64-bit counters; I cannot test version 1.

	Because of the nature of this problem, I've marked it serious/medium
	given how important SNMP monitoring is on production *IX machines.

Fix: 

None known.
How-To-Repeat: 	1. Run bsnmpd(1), making sure that pf is in use, and snmp_pf.so is
	loaded as defined by snmpd.config.

	2. Install something like net-mgmt/rrdbot and set up SNMP monitoring
	of OIDs such as the following, polled at a 30 second intervals:

pfCounterMatch                = begemot.200.1.2.1.0
pfCounterBadOffset            = begemot.200.1.2.2.0
pfCounterFragment             = begemot.200.1.2.3.0
pfCounterShort                = begemot.200.1.2.4.0
pfCounterNormalize            = begemot.200.1.2.5.0
pfCounterMemDrop              = begemot.200.1.2.6.0
pfStateTableCount             = begemot.200.1.3.1.0
pfStateTableSearches          = begemot.200.1.3.2.0
pfStateTableInserts           = begemot.200.1.3.3.0
pfStateTableRemovals          = begemot.200.1.3.4.0

	Note: "begemot" OID name/label expands to 1.3.6.1.4.1.12325.1

	3. Launch a tcpdump that will capture the SNMP data between the
	machine running bsnmpd and the machine running rrdbotd.  They
	can be the same host (in which case, packet capture from lo0).

	4. Run rrdbotd and watch the SNMP results which are returned.
	They'll repetitively be the same value.

	5. Execute rrdbot-get against one of the above OIDs.

	6. Watch for the next SNMP query/response in tcpdump; you'll
	see that the values returned are all up-to-date.

	7. Watch for the next SNMP query/response; you'll see that the
	values returned continue to be those from step #6.