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.
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
*** Bug 88677 has been marked as a duplicate of this bug. ***
*** Bug 101083 has been marked as a duplicate of this bug. ***
*** Bug 110060 has been marked as a duplicate of this bug. ***
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. Thanks, Read ya, Phil