Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 82146 - snmpwalk pins snmpd
Summary: snmpwalk pins snmpd
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: net-snmp
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
: 88677 101083 110060 (view as bug list)
Depends On:
Blocks: 79579 CambridgeTarget
TreeView+ depends on / blocked
Reported: 2003-01-18 05:01 UTC by Jon Willeke
Modified: 2015-03-05 01:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-02-03 14:54:34 UTC

Attachments (Terms of Use)

Description Jon Willeke 2003-01-18 05:01:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823

Description of problem:
I started the snmpd and snmptrapd services, so I could try a simple example from
_Essential SNMP_ (O'Reilly):

  $ snmpget -v 1 localhost -c public .
  SNMPv2-MIB::sysLocation.0 = STRING: Unknown (edit /etc/snmp/snmpd.conf)

I then tried the next example:

  $ snmpwalk -v 1 localhost -c public system
  Timeout: No Response from localhost

If start the top program, I see that snmpd is taking 90% or more of the CPU. 
Subsequently repeating the trivial snmpget command times out, as well.

I found a similar problem report in at Google
Groups.  Wes Hardaker replied: "It's a known optimization problem with
restrictive VACM settings.  This is actually fixed in the current CVS tree and
due to be released in 5.0.7."

I installed 5.0.7 and found that, while it still ultimately times out, it
behaves a little better:

  $ snmpwalk -v 1 localhost -c public system
  SNMPv2-MIB::sysORUpTime.8 = Timeticks: (3) 0:00:00.03
  SNMPv2-MIB::sysORUpTime.9 = Timeticks: (3) 0:00:00.03
  Timeout: No Response from localhost

I recommend that you upgrade net-snmp to 5.0.7.

Version-Release number of selected component (if applicable): 5.0.6-9

How reproducible:

Steps to Reproduce:
1. Ensure that net-snmp and net-snmp-utils are installed.
2. Start the snmpd service (and possibly snmptrapd).
3. Issue an snmpwalk on "system" in the public community; e.g.:
   snmpwalk -v 1 localhost -c public system

Actual Results:  You'll likely get a time out immediately.  If you have a fast
system or a non-default snmpd.conf, you may see a few entries.

Expected Results:  I guess snmpwalk should display all the items.

Additional info:

snmpwalk times out immediately on the following systems:

  * RH 6.2 on a Celeron 600
  * RH 8.0 on a K6-3+ 450
  * RH 8.0.92 on a Pentium Pro 200

I managed to get some output on these systems:

  * RH 7.3 on a Pentium II 400
  * RH 8.0 on a quad Pentium III Xeon 450

Upgrading to 5.0.7 improved the situation with 8.0.92 on the Pentium Pro and 8.0
on the K6-3+.  Still, this package is, effectively, vulnerable to a
denial-of-service attack.

You'll need to update the nodb patch that's in 5.0.6-11 (the current rawhide
package).  Also, the syslog patch no longer appears to be necessary.

By the way, I could not build this package without libelf-devel, a dependency
that is not caught by RPM or configure.

Comment 1 Phil Knirsch 2003-01-23 15:36:52 UTC
Verified, this is again the problem with the read-only public view being system
instead if .1

I have considered changing this in the snmpd.conf file we deliver, but i am very
reluctant about it as it will offer much more information about a machine
running snmpd by default than before.

As there are multiple bugs open with that problem i tend to make this change
despite the security concerns i have (after all, we're 'only' talking about
read-only stuff.).

Read ya, Phil

Comment 2 Phil Knirsch 2003-05-14 14:52:37 UTC
*** Bug 88677 has been marked as a duplicate of this bug. ***

Comment 3 Phil Knirsch 2003-07-31 12:07:21 UTC
*** Bug 101083 has been marked as a duplicate of this bug. ***

Comment 4 Phil Knirsch 2003-11-14 16:52:54 UTC
*** Bug 110060 has been marked as a duplicate of this bug. ***

Comment 5 Phil Knirsch 2004-02-03 14:54:34 UTC
I'll close this bug now as after long consideration i will leave the
config file in the secure but DoS-able state.

The implications of opening up a default configuration so that all
available information about a system can be gathered from any host is
just too much of a security risk.

If anyone wants or needs a responsive snmpd he can make the necessary
and in this bugzilla descibed changes to the snmpd.conf file.


Read ya, Phil

Note You need to log in before you can comment on or make changes to this bug.