https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293522
Bug ID: 293522
Summary: bsnmpd: does not create or update engine_file when
engine [ID] is auto-set (defaults)
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: [email protected]
Reporter: [email protected]
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
--
You are receiving this mail because:
You are the assignee for the bug.
