Description of Problem: If I do a "snmpwalk localhost public .1" on a sys w/ucd-snmp-4.2.3-5, It prints out all of the system tree untill: >system.sysORTable.sysOREntry.sysDRUptime.9 = (representation of timeticks go >here) >Timeout: No response from localhost After this any gets or walks will result in >Timeout: No response from localhost The daemon is still running. A look at the log indicates some sort of loop. I will send this info to the ucd-snmp lists. Version-Release number of selected component (if applicable): How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information:
Is this the default config? I've tried this on my box, and i don't get the system.sysORTable.sysOREntry.sysDRUptime at all. Otherwiese the snmpwalk runs through completely. Read ya, Phil
*** Bug 60160 has been marked as a duplicate of this bug. ***
----Feb, 25 2002----- This still happens on my box. It seems to fail when the snmpd.conf file has systemview to be enabled with read permissions. Any attempt to walk the "system" part of the tree will result in this strange behavior in the daemon. --Josh
#####Feb 26 2002########## There is talk about this on the snmp-lists @ sourceforge
This is patched in the 4.2.4 tree. Please update when possible.
It would be nice if the relevant patch could be extracted and applied to 4.2.3.
Looking into it today. Actually, where does ucd-snmp-4.2.3-5 come from? Just curious as the latest release i had was 4.2.3-4... Read ya, Phil
4.2.3-5 was the package that came with Hampton beta1.
4.2.3-5 was beta1, which is not moved back when we went beta1 to beta2. The current version in the tree contains the same fixes though... OK, this is from Wes, the maintainer of ucd-snmp (netsnmp :). According to that it seems as if there is no fix for the 4.2.x series yet. I've also looked at the differences between 4.2.3 and 4.2.4pre2 and couldn't locate and isolate the problem. Btw: A workaround always is to use .1 as systemview instead of .system only. Granted, this is not always possible or advisable, but for the time being it works that way. Question is wether we want to updated to 4.2.4 when it's released (hopefully sometime this week) or if we want to stick with 4.2.3... Pete> Yes I set this so that unprivileged users cant see the whole Pete> tree just the system tree. As this is a fairly common command Pete> (snmpwalk localhost public system) its quite worrying as any Pete> user can hang the snmpd with it. It does not seem to return to Pete> normal as I waited a few minutes and the daemon was using 80% Pete> CPU and not replying to requests so I eventually have to restart Pete> it. Yep, I hope to address it in the 5.0 release. It basically requires checking access control for GETNEXT's early on for an entire subtree of information. However, this may not even be trivial to do.
Looks like this behavior is not reproduceable on the latest and greatest version of ucd-snmp (4.2.3-1.7.2.3). This is the version thats on beta3 of Hampton.
This is still apparent in 4.2.3-1.7.2.3 and 4.2.4*-pre3.
Actually the daemon 'recovers' after approx. 1 minute (at least on my machine here). The problem is (as already described on the net-snmp mailing lists) related to 'invisible' subtrees and as i already pasted as well not likely to be fixed for the ucd-snmp-4.x release. So i am closing this bug again, as this bug has to be fixed upstream. Read ya, Phil PS: I've also provided a 'workaround' as well here in this bugreport which should be sufficent for now.
*** Bug 69918 has been marked as a duplicate of this bug. ***
*** Bug 72681 has been marked as a duplicate of this bug. ***