Date: Sun, 01 Mar 2026 10:06:53 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 293522] bsnmpd: does not create or update engine_file when engine [ID] is auto-set (defaults) Message-ID: <bug-293522-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
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: bugs@FreeBSD.org Reporter: bms@FreeBSD.org 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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-293522-227>