net-snmp: do not override sysName with a static default

[micpf]

Problem

The default UCI config (net/net-snmp/files/snmpd.conf) ships:

config system
	option sysLocation	'office'
	option sysContact	'bofh@example.com'
	option sysName		'HeartOfGold'

net-snmp only falls back to the system hostname for SNMPv2-MIB::sysName.0 (1.3.6.1.2.1.1.5.0) when no sysName is configured. Because the packaged default hardcodes sysName 'HeartOfGold', the agent permanently reports HeartOfGold instead of the device's real hostname — for every SNMP version (v1/v2c/v3), since sysName lives in the agent's system group and is independent of the security model.

This makes the common "obtain the hostname via SNMP" use case fail out of the box, and diverges from net-snmp's own example config, which deliberately omits sysName so it auto-derives from the hostname.

Change

Comment out the sysName option so the agent reports the actual hostname by default. This matches the style of the already-commented optional sysServices/sysDescr/sysObjectID lines right below it. Users who want a static sysName can simply uncomment and edit it.

PKG_RELEASE is bumped (2 → 3) since the conffile content changed.

Testing

On a running device, removing the static sysName and restarting snmpd makes sysName.0 return the real hostname:

# before
SNMPv2-MIB::sysName.0 = STRING: HeartOfGold
# after (uci delete snmpd.@system[0].sysName; /etc/init.d/snmpd restart)
SNMPv2-MIB::sysName.0 = STRING: <actual-hostname>

Verified via SNMPv3 (authPriv) and SNMPv2c.

[openwrt-ai]

Reviewed 1 new commit. The change itself is small and the PKG_RELEASE bump (2 → 3) is correct for a conffile content change. One question inline about whether the fallback path really yields the hostname, given the empty sysName.0 shown in the PR body's own verification output. Nothing here looks merge-blocking to me — it is a maintainer call whether the init-script fallback needs the accompanying tweak.

---

Generated by Claude Code

[openwrt-ai]

Commenting the option out is the right shape of fix, but the stated mechanism doesn't match what OpenWrt actually does, and the verification output in the PR body suggests the resulting value may not be a hostname.

With sysName unset, net-snmp's own gethostname() fallback is not what runs. snmpd.init:33-35 synthesizes the line itself:

[ -z "$sysname" ] && hostname=$(uci_get system.@system[0].hostname) && echo "sysName $hostname" >> $CONFIGFILE

So the value comes from system.@system[0].hostname (set to OpenWrt by config_generate:316), not from the agent. The agent's own fallback is only reached if that uci_get fails.

That matters because the "after" result quoted in the PR body is SNMPv2-MIB::sysName.0 = STRING: — an empty string rather than a hostname. That is precisely what the branch above emits when uci_get succeeds but returns empty output: echo "sysName " writes a sysName directive with no value. Is the paste just truncated, or did sysName.0 really come back empty on the test device? If it really was empty, commenting the option out is not sufficient on its own — the [ -z "$sysname" ] branch would also need to omit the line when the hostname is empty, so the agent's built-in fallback takes over.

Either way, the commit message wording ("net-snmp only falls back to the system hostname ... when no sysName is configured") describes the agent, while on OpenWrt it is the init script that supplies the hostname; worth rewording so the reasoning matches the code.

---

Generated by Claude Code

[micpf]

Thanks, you're right on the mechanism and I've reworded the commit message and PR description accordingly.

To confirm the specifics:

• Mechanism: agreed — it's the init script (snmpd_system_add), not net-snmp's own gethostname(). When sysName is unset the [ -z "$sysname" ] branch supplies it from system.@system[0].hostname. The commit message now quotes that exact code and describes it correctly.
• The "empty string" in the old PR body: that was a rendering artifact, not a real result. I had used <actual-hostname> as a placeholder in the "after" line, which GitHub stripped as an unknown HTML tag, so it showed as STRING: . On the test device the real value came back (CYRTW-3010V0_DUT36), and the PR body now shows a concrete hostname instead of an angle-bracket placeholder.
• Stock OpenWrt behavior: system.@system[0].hostname defaults to OpenWrt via config_generate, so sysName.0 reports OpenWrt there — a meaningful, operator-editable value that tracks hostname changes, rather than the fixed HeartOfGold. So the empty-hostname edge case (echo "sysName ") isn't hit in normal operation, and I've left the init script untouched to keep this change minimal. Happy to add an init-script guard ([ -n "$hostname" ] before emitting the line) as a follow-up if you'd prefer belt-and-suspenders.

[openwrt-ai]

Reviewed 1 new commit; no new issues found.

The tree is unchanged since f2525ba — the update is a commit-message rewording, and it now describes the mechanism correctly (init script snmpd_system_add, not net-snmp's own gethostname()).

I checked the remaining edge case from my earlier comment and it does not apply: uci_get in uci.sh:100-111 propagates uci -q get's exit status, so when system.@system[0].hostname is unset the && echo "sysName $hostname" in snmpd.init:35 never runs — no empty sysName directive is emitted and the agent's built-in fallback takes over. The init-script guard is not needed; leaving it untouched is the right call for this change.

uci_get is in scope in the init script (functions.sh:546 sources /lib/config/uci.sh, and rc.common sources functions.sh), so the newly-default [ -z "$sysname" ] path works as described. PKG_RELEASE 2 → 3 is correct for a conffile content change. All CI checks are green.

---

Generated by Claude Code