Hide Forgot
Problem Description: The net-snmp daemon dies as soon as an snmpwalk is done on the Compaq mib items. The crash is either in cmaX (wrong arguments passed into callback) or in a system call pertaining to memory. The hpasm/hprsm agents do keep on running, though. System Configuration: System : ML 350 Operating System: Redhat 8.1 RC 3 Management Agents: 6.20 Pass 10 hpasm & hprsm NOTES: the hpasm and hprsm are the Health and Management agents from HP. ---------- Action by: Bryan.Leopard Issue Registered
Issue Tracker 13584
I need more information to be able to at least try to reproduce this problem. Please add a description on how to set up a machine to reproduce this problem. Also, what version of net-snmp was used? Thanks, Read ya, Phil
Created attachment 89790 [details] threadtst.c Sample program to reproduce error (from HP)
HP entered this problem in Issue Tracker (13584) as a severity 1.
FROM ISSUE TRACKER 14159 WHICH MAY BE A DUP OF IT 13584.... ------------ The NetSNMP has been getting more and more unstable with each new release. This version is no longer suitable for production. We found that if you restrict the permissions in NetSNMP and try to walk the MIB from a machine that should not have permission to do so, the snmpd daemon consumes near full CPU utilization for like 20 to 30 seconds. Since our agents register some 1400 MIB variables into snmpd, we found (through experimentation) that the stack appears to wind through all these registrations at every request that fails the security pass. This causes snmpd to use 100% CPU for 20 to 30 seconds until it recovers. This would make it very easy for someone to cause a denial of service on a server by simply attempting to walk its mib from an unauthorized workstation. This is also evident on 8.1. HP would like to propose that red hat use the UCD SNMP instead of the net-snmp for all of it's products.
This is not an option. ucd-snmp is not being actively developed anymore and the switch to net-snmp has already been done. ucd-snmp is going to die sooner or later completely, so we would be betting on a nearly dead horse. Additionally, most of the upstream bug fixes are done to net-snmp first, too. Now, the test program is nice, but could you please specify how to compile and use it, too? I have no clue whatsoever how the HP health monitor and management stuff works, where to get it etc. And without that i can't reproduce the bug and without being able to reproduce the bug i can't even start to think about fixing it. Read ya, Phil
FROM BRYAN LEOPARD VIA ISSUE TRACKER.... We understand that ucd-snmp is "legacy software". That was the whole point of filing this issue, as it happens on *net-snmp*. Upstream bug fixes are nice if no new bugs are introduced. This does not seem to be the case right now for net-snmp (things break that used to work). The test program has no dependencies on HP management stuff. If just uses signals and setjmp/longjmp. It runs completely standalone as a programming exercise, as it were. It will run well on RH 8.0, but fails on RH 9. We suspect a glibc problem. It can be argued that this technique of setjmp/longjmp and signals is somewhat archaic, but you can find it in textbooks, so... Compile with gcc -o test threadtst.c -l pthread ./test Status set to: Waiting on Tech
Erh, i am confused now. Was this bug about a problem in net-snmp or a thread problem in glibc? If the later, then the bug should be assigned to glibc instead of net-snmp. If the former, then i can assure you that i've been experiencing the same DoS problem for restricted trees in ucd-snmp as well as in net-snmp. This has been a long standing problem in both and net-snmp-5.0.7 (which won't make it into the next release but will be included in the one afterwards) fixes some of the performance problems. Read ya, Phil
Please try with current rawhide packages.
No more response, closing bug as worksforme. Read ya, Phil