Problem with index variable
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 the last row in the table. Here the problem in more detail manner : I have used a structure which contain the table data and passing that structure into the method header_complex_add_data() method. This method will store the data in a linked list, i believe. After that I am calling the method header_complex() from my var_XXXTable() method ( which is generated one) and retrieving the table structure information. Here after retrieving the info and print the same, I am getting the table elements of the last row. I mean if 3 rows are there and tryign to print all the 3 rwos from this place, it is returning only the last row. From the code walk which I have done in the header_complex.c file , I understood that there might be some problem in that or the way I am doing is wrong. For your info, I have taken the example mteTriggerTable.c file implementation from agent/mibgroup/disman directory( which also contains two index as like my case) and implemented it. I copied the parse_XXX() and the mteXXX_add() method for my case and modified accordingly my table. there is no other extra modification done except the variable name modifications. Please clarify on this issue? expecting ur early response. Thanks Regards, Karthik -- __ IndiaInfo Mail - the free e-mail service with a difference! www.indiainfo.com Check out our value-added Premium features, such as an extra 20MB for mail storage, POP3, e-mail forwarding, and ads-free mailboxes! Powered by Outblaze --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: hrStorageIndex values changed from 5.0.9 to 5.1.1
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 artificial limit on the number of mounted filesystems that could be reported before running into these oddity entries. By putting them at the start instead, it's made it possible to handle significantly larger numbers of mounted filesystems. Doesn't seem like a good idea to have ifindex values change between versions, but if their is a good reason than it must be done. Please note that in general, MIB index values are not guaranteed to remain constant when an agent re-starts. It is quite common for the same information to be provided in a different order, and monitoring tools really need to be able to cope with this. I'm a little surprised that Cricket didn't spot the change and adjust automatically. Dave --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: no snmpd binary
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 development RPM) Try the following: ls -l /usr/lib/libelf* This should list one library and (probably) one or more symbolic links. Ignore the links, and make a note of the name of the real file. It should be something like libelf-0.76.so Then do ln -s libelf-0.76.so /usr/lib/libelf.so ldconfig (but using the correct version-name for your system). That should allow things to compile properly. Dave --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: problems with snmptrapd
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 completely). Try testing with a command that *does* read in the trap details (even if it doesn't do anything with them) Dave --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: sef fault registering
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 Current language: auto; currently c CC CC (gdb) where CC CC #0 __pthread_mutex_lock (mutex=0x410) at mutex.c:99 CC CC Using threads in the agent is unsupported. CC CC This code is working on Intel platforms. This error is on CC PowerPC architecture. Architecture shouldn't make a difference in the net-snmp code. My development machine is Yellowdog Linux, running on a PPC G4 laptop. CC But it's the same underlying code so CC I guess I don't understand how we're dying all of a sudden. CC Unless PowerPC is inherently thread-based and the identical CC system call to start snmpd is kicked-off as a thread, where CC on Intel it's a process. 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? -- Robert Story; NET-SNMP Junkie http://www.net-snmp.org/ irc://irc.freenode.net/#net-snmp Archive: http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-users You are lost in a twisty maze of little standards, all different. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
Re: sef fault registering
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 still running on 5.0.8 net-snmp. Only we've never gotten things to run on the PPC platform due to seemingly config- type problems like the one where it couldn't find the libnetsnmpagent.so. I think I needed to set a path in my LD_LIBRARY_PATH environment variable. But that probably has more to do with our build scripts rather than net- snmp itself. I could be wrong -- I'm no makefile guru. I do know that we're trying to connect with the daemon as follows. /usr/loca/sbin/snmpd -V -Dagentx I'm not sure if I should add like a -L or something to try to get more detailed error printfs when trying to make the connection. Realistically, the seg fault could be coming from any component in the system, and snmpd is not coming up as a result of us crashing before we've finished the connection. But right now all the call-stacks I've seen when we crash have net-snmp functions, so I'm trying to net-snmp debug a bit further. Any ideas, tips or tricks, would be greatly appreciated. I tried to be consistent when running configure, but could there be any conf-type stuff that would cause irregular behaviour? Thanks, Carlos --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Net-snmp-users mailing list [EMAIL PROTECTED] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
