[Bug 282409] net-mgmt/net-snmp:
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 29 Oct 2024 19:07:17 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282409
Bug ID: 282409
Summary: net-mgmt/net-snmp:
Product: Ports & Packages
Version: Latest
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: Individual Port(s)
Assignee: zi@FreeBSD.org
Reporter: freebsd-bugzilla@umpquanet.com
Assignee: zi@FreeBSD.org
Flags: maintainer-feedback?(zi@FreeBSD.org)
Using the latest version of the net-snmp package, I am seeing an intermittent
problem that suggests the snmpd daemon has stopped listening on one or more
IPv4 sockets. The localhost socket continues to work, so snmpwalks from the
localhost succeed, but remote connections on UDP port 21 to an external are
ignored.
Fortunately this occurs fairly rarely, but not at any predictable interval.
Once the problem occurs, I haven't found any solution except to restart the
snmpd daemon.
Symptoms:
client # hostname
monitor.example.edu
client # host jimsdesk.example.edu
jimsdesk.example.edu has address 10.10.61.35
client # host mrtg.example.edu
mrtg.example.edu is an alias for monitor.example.edu.
monitor.example.edu has address 10.10.31.11
When the remote snmpwalk client executes:
client # snmpwalk -v 2c -c XXX jimsdesk.example.edu
Timeout: No Response from jimsdesk.example.edu
The local snmpd server observes:
server # sockstat -4 | grep snmpd
snmpd snmpd 2305 9 udp4 10.10.61.35:161 *:*
snmpd snmpd 2305 10 udp4 127.0.0.1:161 *:*
server # grep -i ^agentAddress ~snmpd/net-snmpd.conf
agentAddress udp:jimsdesk.example.edu
agentAddress udp:localhost
server # grep -i ^rocommunity ~snmpd/net-snmpd.conf
rocommunity XXX 127.0.0.1
rocommunity XXX jimsdesk.example.edu # jimsdesk
rocommunity XXX mrtg.example.edu # mrtg/monitor
Traffic definitely arrives at the server's public interface:
server # tcpdump -ni public udp and port 161
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on public, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:59:45.882875 IP 10.10.31.11.55829 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
10:59:46.887012 IP 10.10.31.11.55829 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
10:59:47.950106 IP 10.10.31.11.55829 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
10:59:48.954301 IP 10.10.31.11.55829 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
10:59:50.017772 IP 10.10.31.11.55829 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
10:59:51.081294 IP 10.10.31.11.55829 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
^C
6 packets captured
7215 packets received by filter
0 packets dropped by kernel
But during these episodic failures, the snmpd daemon does not respond.
server # tcpdump -ni public udp and port 161
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on public, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:23:38.450344 IP 10.10.31.11.53119 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
11:23:39.464183 IP 10.10.31.11.53119 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
11:23:40.470146 IP 10.10.31.11.53119 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
11:23:41.477932 IP 10.10.31.11.53119 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
11:23:42.483466 IP 10.10.31.11.53119 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
11:23:43.546906 IP 10.10.31.11.53119 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
^C
6 packets captured
11706 packets received by filter
0 packets dropped by kernel
It seems both necessary and sufficient to restart the daemon to restore
service:
server # service snmpd restart
Stopping snmpd.
Waiting for PIDS: 2305.
Starting snmpd.
client # snmpwalk -v 2c -c XXX jimsdesk.example.edu
SNMPv2-MIB::sysDescr.0 = STRING: FreeBSD jimsdesk.example.edu 14.2-PRERELEASE
FreeBSD 14.2-PRERELEASE #0 stable/14-n269296-5ae76ff5138e: Wed Oct 23 15:48:38
PDT 2024 root@build.example.edu:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.8
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (92659) 0:15:26.59
SNMPv2-MIB::sysContact.0 = STRING: bounce@example.edu
SNMPv2-MIB::sysName.0 = STRING: jimsdesk.example.edu
SNMPv2-MIB::sysLocation.0 = STRING: GQ Room 015
...etc...
server # tcpdump -ni public udp and port 161
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on public, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:24:15.761782 IP 10.10.31.11.55644 > 10.10.61.35.161: GetNextRequest(25)
.1.3.6.1.2.1
11:24:15.762314 IP 10.10.61.35.161 > 10.10.31.11.55644: GetResponse(248)
.1.3.6.1.2.1.1.1.0="FreeBSD jimsdesk.example.edu 14.2-PRERELEASE FreeBSD
14.2-PRERELEASE #0 stable/14-n269296-5ae76ff5138e: Wed Oct 23 15:48:38 PDT 2024
root@build.example.edu:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64"
11:24:15.762661 IP 10.10.31.11.55644 > 10.10.61.35.161: GetNextRequest(28)
.1.3.6.1.2.1.1.1.0
11:24:15.762757 IP 10.10.61.35.161 > 10.10.31.11.55644: GetResponse(38)
.1.3.6.1.2.1.1.2.0=.1.3.6.1.4.1.8072.3.2.8
11:24:15.763029 IP 10.10.31.11.55644 > 10.10.61.35.161: GetNextRequest(28)
.1.3.6.1.2.1.1.2.0
11:24:15.763096 IP 10.10.61.35.161 > 10.10.31.11.55644: GetResponse(30)
.1.3.6.1.2.1.1.3.0=919
11:24:15.763395 IP 10.10.31.11.55644 > 10.10.61.35.161: GetNextRequest(28)
.1.3.6.1.2.1.1.3.0
11:24:15.763447 IP 10.10.61.35.161 > 10.10.31.11.55644: GetResponse(43)
.1.3.6.1.2.1.1.4.0="bounce@example.edu"
11:24:15.763751 IP 10.10.31.11.55644 > 10.10.61.35.161: GetNextRequest(28)
.1.3.6.1.2.1.1.4.0
11:24:15.763804 IP 10.10.61.35.161 > 10.10.31.11.55644: GetResponse(49)
.1.3.6.1.2.1.1.5.0="jimsdesk.example.edu"
11:24:15.764104 IP 10.10.31.11.55644 > 10.10.61.35.161: GetNextRequest(28)
.1.3.6.1.2.1.1.5.0
11:24:15.764152 IP 10.10.61.35.161 > 10.10.31.11.55644: GetResponse(39)
.1.3.6.1.2.1.1.6.0="GQ Room 015"
11:24:15.764459 IP 10.10.31.11.55644 > 10.10.61.35.161: GetNextRequest(28)
.1.3.6.1.2.1.1.6.0
...etc...
--
You are receiving this mail because:
You are the assignee for the bug.