I am migrating a working net-snmpd setup from FreeBSD 8.4 to FreeBSD
9.3. The net-snmp versions involved are 5.7.1_7 and 5.7.3_7,
respectively. By "working," I mean that I can successfully snmpwalk
the old snmp server.
On the new server, I have installed net-snmp from ports, and copied
/usr/local/etc/snmp/snmpd.conf from the old system to the new.
On the old system, 10.162.202.121, snmpwalk works when targeting
itself, and I can run it multiple times with no problem:
# time snmpwalk -v1 -c foObAR1 10.162.202.121 | wc -l
2452
real 0m2.830s
user 0m0.643s
sys 0m0.389s
# time snmpwalk -v1 -c foObAR1 10.162.202.121 | wc -l
2452
real 0m3.394s
user 0m0.603s
sys 0m0.366s
# time snmpwalk -v1 -c foObAR1 10.162.202.121 | wc -l
2461
real 0m2.803s
user 0m0.544s
sys 0m0.317s
On the new system, 10.158.10.10, snmpwalk fails, and snmpd terminates
shortly after receiving the UDP packet.
First, I start the snmpd agent manually, then as quickly as possible
(about half a second later), I start the snmpwalk process from a host
on an adjacent IP number. FWIW, I get the same symptoms if I run snmpwalk
from the same host that is running snmpd.
Agent:
# time /usr/local/sbin/snmpd -c /usr/local/etc/snmp/snmpd.conf -Lo -df &
[1] 17067
# NET-SNMP version 5.7.3
Received 41 byte packet from UDP: [10.158.10.9]:33811->[10.158.10.10]:161
0000: 30 27 02 01 00 04 07 73 41 57 6E 33 74 31 A1 19 0'.....foObAR1..
0016: 02 04 60 B5 05 1F 02 01 00 02 01 00 30 0B 30 09 ..`.........0.0.
0032: 06 05 2B 06 01 02 01 05 00 ..+......
real 0m5.959s
user 0m0.038s
sys 0m0.047s
Notice that snmpd has terminated, and time reports the elapsed run
time. /usr/local/etc/snmp/snmpd.conf should be a default config
location, but I am specifying it explicitly to be certain. No
other snmp*.conf files exist on the new server:
# find / -name 'snmp*.conf'
/usr/local/etc/snmp/snmpd.conf
/var/net-snmp/snmpd.conf
#
On the client side, 10.158.10.9:
# time snmpwalk -v1 -c foObAR1 10.158.10.10 | wc -l
Timeout: No Response from 10.158.10.10
0
real 0m6.086s
user 0m0.043s
sys 0m0.043s
http://www.net-snmp.org/docs/FAQ.html says:
If the agent displays a dump of the incoming request, but nothing going
out, then the most likely cause is access control settings. See the
relevant entries in the AGENT section for details. Note that if the agent
receives an SNMPv1 or SNMPv2c request with a unknown community string,
then it will not return an error response - the request is simply discarded.
I am ruling out this possibility because on 10.158.10.10, I can grep
/usr/local/etc/snmp/snmpd.conf and obtain a match on the community
string seen in the hex dump of the incoming request:
# grep -w 'foObAR1$' /usr/local/etc/snmp/snmpd.conf
rocommunity foObAR1
#
The FAQ continues:
Another possibility is that the request may be rejected by settings in
/etc/hosts.{allow,deny}. Again, '-d' will display an incoming packet
dump but no corresponding outgoing response. However in this situation,
the agent should also log a message that the request is being refused.
With the logging set to stdout above, no message is logged about any refused
requests. However, there is a syslog entry which arises from /etc/hosts.allow:
Jun 22 21:23:56 hostname snmpd: warning: /etc/hosts.allow, line 139:
twist_option: dup: Bad file descriptor
The old (8.4) and new (9.3) hosts have identical hosts.allow files:
# md5 /etc/hosts.allow; ssh oldhost md5 /etc/hosts.allow
MD5 (/etc/hosts.allow) = 7cb32c11209ab63aed7ba28024649fc7
MD5 (/etc/hosts.allow) = 7cb32c11209ab63aed7ba28024649fc7
#
The old server also logs hosts.allow twist warnings, but they don't
prevent snmpd from responding successfully to the snmpwalk request.
Jun 22 20:37:02 oldhost snmpd: error: /etc/hosts.allow, line 139: twist option
in resident process
Still, I would gladly receive guidance on how to get rid of this warning
message, just on general principles.
But what I'm really stumped by is what I'm missing that is
preventing the new snmpd host from responding to snmpwalk requests.
Here is my snmpd.conf:
# grep '^[^#]' /usr/local/etc/snmp/snmpd.conf
syslocation "Somewhere, Earth"
syscontact [email protected]
rocommunity foObAR1
rwcommunity foObAR2
load 8 7 6
#
All suggestions are welcome, as are specific requests for additional
information related to this problem.
Thank you!
Jim
------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users