Bug 82146 - snmpwalk pins snmpd
snmpwalk pins snmpd
Product: Red Hat Linux
Classification: Retired
Component: net-snmp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
: 88677 101083 110060 (view as bug list)
Depends On:
Blocks: 79579 CambridgeTarget
  Show dependency treegraph
Reported: 2003-01-18 00:01 EST by Jon Willeke
Modified: 2015-03-04 20:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-03 09:54:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jon Willeke 2003-01-18 00:01:47 EST
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 mailing.unix.net-snmp-users 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 10:36:52 EST
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 10:52:37 EDT
*** Bug 88677 has been marked as a duplicate of this bug. ***
Comment 3 Phil Knirsch 2003-07-31 08:07:21 EDT
*** Bug 101083 has been marked as a duplicate of this bug. ***
Comment 4 Phil Knirsch 2003-11-14 11:52:54 EST
*** Bug 110060 has been marked as a duplicate of this bug. ***
Comment 5 Phil Knirsch 2004-02-03 09:54:34 EST
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.