TL;DR In bsnmpd, snmpEngineID is normally set from kern.hostid, but if allowed to do so, it appears both the snmpEngineBoots counter and the snmpEngineID OID will NOT be persisted to disk, as they should be. This is effectively how a "boot counter" is presented as a management object, and follows on from GSoC work to be proposed. SNMP v3 USM, i.e. RFC 3414, defines OID 1.3.6.1.6.3.10.2.1.2, aka snmpEngineBoots: https://datatracker.ietf.org/doc/html/rfc3414#section-2.2 Net-SNMP implements this by writing to $SNMP_PERSISTENT_FILE which normally points to /var/net-snmp/snmpd.conf as an integer value to the configuration variable "engineBoots". bsnmpd allegedly does the same thing, in contrib/bsnmp/snmpd/action.c, where snmpd_engine.engine_boots is also persisted to a disk file, in this case, named by engine_file defined in contrib/bsnmp/snmpd/main.c, which defaults to PATH_ENGINE: "/var/snmpd.engine". However, I could not get this to function on a first run. In /etc/rc.conf, bnmpd_flags had to be set to a non-default value: "-e /var/snmpd.engine". Moreover, two lines had to be uncommented in /etc/snmpd.config; the default engine file location also had to be "touched". The snmpEngineBoots counter is however being exposed via SNMP and this can be verified from outside the bsnmpd process, however, not on an unqualified snmpwalk: snmpget -v2c -c public localhost .iso.org.dod.internet.snmpV2.snmpModules.snmpFrameworkMIB.snmpFrameworkMIBObjects.snmpEngine.snmpEngineBoots.0 For some obscure reason, you have to specify an OID subtree to snmpwalk, or it doesn't see it. A search on Bugzilla for bsnmpd issues shows many historical closed bug reports, and few open ones (I opened one for the lack of AgentX support). However, this isn't one of them, unless you count: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174974 And the relevant change seems to be commit-id 3b49535 in git, for contrib/bsnmp/lib/snmpagent.c, originally from SVN: https://svnweb.freebsd.org/base?view=revision&revision=308490 Whilst this may explain why snmpEngineBoots wasn't readily visible on an unqualified snmpwalk, it does not explain why bsnmpd has problems persisting its setting when its engine ID is not set statically in config. There are surely other issues lurking deeper in bsnmpd. OT: glebius@ seems to have been historically critical of (the lack of) bsnmpd maintenance: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=93758#c2
bsnmpd is the user base's primary means of obtaining pf(4) packet level statistics, assuming they are not scraping pfctl(8) by scripted means. So, the fact I have not heard of these issues being reported by major stakeholders (e.g. OPNsense, pfSense) is a concern.
What concerns maintenance: Actually I have rewritten large parts of the bsnmp server code. SNMPv3 is working now (there are even tests for this). I lack time to integrate this into FreeBSD. A problem is also that I changed to module interface somewhat so modules need also to be fixed.
(In reply to hartmut.brandt from comment #2) Harti, It is good to hear from you. I was sorry to learn you had been having health problems. I myself also was absent from FreeBSD for 7+ years due to health problems and more than one bereavement, including my mother, and only just rejoined last month. For the moment, these features are a "nice to have" for me (AgentX support included) but OPNsense (Deciso BV) et al may have a compelling commercial need for them; I may do so in the future, but for now, the ball is in their court, as the saying goes. I am happy to contribute cycles towards testing/git-wrangling/review. Please see my other ticket for proposal to take AgentX server-side support from OpenBSD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293417