Problem with index variable

2004-06-28 Thread Karthikeyan N
Hi, I am facing a problem in one of our mib implementation during run-time. I have a table having two different indexes such as one string ( mac address index) and another simple integer index. If I generate the code with ucd-snmp style and implemented my data, the agent is always returning

Re: hrStorageIndex values changed from 5.0.9 to 5.1.1

2004-06-28 Thread Dave Shield
5.1.1 hrStorageEntry.hrStorageDescr.2 = STRING: Real Memory hrStorageEntry.hrStorageDescr.3 = STRING: Swap Space 5.0.9 hrStorageEntry.hrStorageDescr.101 = STRING: Real Memory hrStorageEntry.hrStorageDescr.102 = STRING: Swap Space Yes - that's correct. The old arrangement put an

Re: no snmpd binary

2004-06-28 Thread Dave Shield
Iam using ucd-snmp-4.2.6 . When I do a 'make' in the agent directory I get the following error message - /usr/bin/ld: cannot find -lelf Yes - recent versions of RedHat don't seem to include the version-independent softlink for libelf.so (or at least, only in a relatively obscure

Re: problems with snmptrapd

2004-06-28 Thread Dave Shield
I encountered the broken pipe error during my tests. the snmptrapd.conf file only contains the line traphandle default /bin/pwd A couple of quick tests seem to indicate that this error is being generated because /bin/pwd doesn't actually read from standard input (and may well close it

Re: sef fault registering

2004-06-28 Thread Users
On Sun, 27 Jun 2004 10:42:25 -0600 Carlos wrote: CC CC Program received signal SIGSEGV, Segmentation fault. CC CC [Switching to Thread 1024 (LWP 13779)] CC CC __pthread_mutex_lock (mutex=0x410) at mutex.c:99 CC CC 99 mutex.c: No such file or directory. CC CC in mutex.c CC CC

Re: sef fault registering

2004-06-28 Thread Carlos Cantu
I don't think so. Are you saying that an unmodified net-snmp snmpd has this problem? What PowerPC platform are you on? Which OS? True, net-snmp is unmodified. Both on Intel and on the IBM pSeries 630 running SuSE Linux with 2.4.19 kernel. Don't ask, you'll get the same answer as to why we're