From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823
Netscape/7.0

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 .1.3.6.1.2.1.1.6.0
  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:
Always

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.