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  h...@example.com
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
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to