Re: Net-snmp-users Digest, Vol 44, Issue 4
astal vista <[email protected]>
| Newsgroups | gmane.network.net-snmp.user |
|---|---|
| Message-ID | <[email protected]> |
Hi all, I would like to know how to put a script in snmpd.conf file. i have seen the config file.it doesn't help me bcoz the scripts starts with #!/bin/bash. so when i try to use..., since there is # in the beginning it is taking as comment. how to solve the problem. one more thing. I want to monitor a service ...., along with the PID and how much memory it is occupying and all. i can do with the command *#ps -eo "%p %y %x %c %C"* now i want to use the same command in snmpd.conf file and some OID associated with it. and retrive the info with snmpwalk command. can any one help me. Thanks in advance. Antony On Tue, Jan 12, 2010 at 4:57 AM, < [email protected]> wrote: > Send Net-snmp-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/net-snmp-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Net-snmp-users digest..." > > > Today's Topics: > > 1. Re: [opennms-discuss] help finding a MIB file (Fulko Hew) > 2. IF-MIB requirement and modification (sanjaykumar) > 3. snmptrapd traphandle traptoemail not working (Dan Kingdon) > 4. RE: snmptrapd traphandle traptoemail not working (Seger, Mark) > 5. RE: snmptrapd traphandle traptoemail not working (Dan Kingdon) > 6. Re: help finding a MIB file (Fulko Hew) > 7. Re: help finding a MIB file (Brandon Wigfield) > 8. Embedding multiple Perl agents (Peter Luciak) > 9. Re: help finding a MIB file (Fulko Hew) > 10. RE: SNMP v3 (Mike Ayers) > 11. Changing the agent-address for SNMP v1 pdus ([email protected]) > 12. snmptrap (win32) tcp (C Wells) > 13. Changing the agent-address for SNMP v1 pdus (Nayman Felix-QA5535) > 14. InBuilt OIDs supported by snmpd (Peyush Kumar) > 15. Define Trap mib file and generate Trap codes problem > ( Alexander King ) > 16. Re: SNMPGET specifying the community name (Dave Shield) > 17. Re: InBuilt OIDs supported by snmpd (Dave Shield) > 18. Encryption support not enabled (??) > 19. Re:InBuilt OIDs supported by snmpd ( Alexander King ) > 20. Re: Define Trap mib file and generate Trap codes problem > (Dave Shield) > 21. Re: InBuilt OIDs supported by snmpd (Dave Shield) > 22. Re: Encryption support not enabled (Dave Shield) > 23. Re: Define Trap mib file and generate Trap codes problem > ( Alexander King ) > 24. Re: Define Trap mib file and generate Trap codes problem > (Dave Shield) > 25. val_len when returning oid (Kristoff Bonne) > 26. Re: val_len when returning oid (Dave Shield) > 27. snprint_objid in decimal format (Kristoff Bonne) > 28. Re: val_len when returning oid (Kristoff Bonne) > 29. Re: snprint_objid in decimal format (Dave Shield) > 30. snmpd seg faults on AIX (Fulko Hew) > 31. Re: snmpd seg faults on AIX (Dave Shield) > 32. Re: snmpd seg faults on AIX (Fulko Hew) > 33. Re: snmpd seg faults on AIX (Dave Shield) > 34. Re: snmpd seg faults on AIX (Fulko Hew) > 35. Re: snmpd seg faults on AIX (Fulko Hew) > 36. SNMP.pm / specifying MIB module as well as the leaf > identifier (Stuart Kendrick) > 37. Re: snmpd seg faults on AIX (Fulko Hew) > 38. Re: snmpd seg faults on AIX (Fulko Hew) > 39. Re: Changing the agent-address for SNMP v1 pdus > ([email protected]) > 40. Re: snmpd seg faults on AIX (Thomas Anders) > 41. Re: snmptrap (win32) tcp (Thomas Anders) > 42. munging Perl's stack (Stuart Kendrick) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 Jan 2010 08:30:48 -0500 > From: Fulko Hew <[email protected]> > Subject: Re: [opennms-discuss] help finding a MIB file > To: General OpenNMS Discussion <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > On Fri, Jan 8, 2010 at 6:46 AM, Andrew Hood <[email protected]> wrote: > > > Fulko Hew wrote: > > > > ... snip ... > > > > > I'm getting these OIDs out of an existing AIX box that I need to > convert > > > over to Net-SNMP, > > > and I thought I'd find out what their existing daemon is reporting > first. > > > > > > And as long as I'm on that topic... does anyone have experience in > > replacing > > > IBM's daemon with Net-SNMP (without breaking anything? > > > > The first part is actually getting it to compile and run. You'll > > probably find you have to statically link the crypto libs. > > > > I've got the compile, but your right, its probably not got crypto in it > right now. > > > > What in particular are you trying to achieve? AIX is a strange beast and > > using the supplied daemons is the most likely path to enlightenment. > > You could probably use AIX's snmpd's ability to talk to an external > > process to do anything snmpd won't do by itself. > > > > I need to add an already written extension (that uses AgentX), > but the AIX daemon only supports SMUX and DPI. > So I figured using Net-SNMP was the easiest way. > But since then I found I needed to compile in SMUX into Net-snmp (shoudln't > be a problem) > but then the AIX (important?) stuff can only get in via DPI (which Net-SNMP > doesn't support) > Heck, I didn't even know DPI existed till yesterday. :-( > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 2 > Date: Fri, 08 Jan 2010 19:41:58 +0530 > From: sanjaykumar <[email protected]> > Subject: IF-MIB requirement and modification > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi All, > I have a specific requirement regarding the IF-MIB. > As per code base Net-SNMP-5.4.2.1 I have come to know that IF mib > display all "interface" present on the Machine. > Like loopback [lo] as index ->1 > ethernet0 [eth0] as index ->2 > ethernet1 [eth1] as index ->3 > > As per my requirement I need to read only "ONE interface "eth0" as index > 1" and this change should reflect in IP MIB available with net-snmp-5.4.2.1 > > Does anyone could suggest what and where (if possible), Does I need to > change ? > Any suggestion would Great Help for Me. > > Rgds, > Sanjay > > > > ------------------------------ > > Message: 3 > Date: Fri, 8 Jan 2010 12:41:56 -0000 > From: "Dan Kingdon" <[email protected]> > Subject: snmptrapd traphandle traptoemail not working > To: <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Hi all, > > > > This is my first time dabbling with the snmptrapd program. I am using > Ubuntu on a fairly unmodified snmp setup. > > > > Just trying to set up a very basic email forwarder so that all snmp > traps are sent via email to the administrators address. > > > > The snmptrapd.conf I am using is > > > > " > > authCommunity log public > > traphandle default /usr/bin/perl /usr/bin/traptoemail -s localhost -f > <FROMADDRESS> <MYADDRESS> > > " > > > > I can see the traps being logged in the syslog when snmptrapd is > running, but I do not receive any emails. > > > > I have also tried the following test of the traptoemail script and > received the email fine. > > > > "(echo localhost; echo 127.0.0.1; echo snmpTrapOID oidValue ; echo > sysUpTime 1) | /usr/bin/traptoemail -f <FROMADDRESS> -s localhost > <MYADDRESS>" > > > > I am now completely stuck, I have tried every variation I can find for > the traphandle line and still nothing. > > > > Is there anyway I can debug what snmptrapd is doing other that the > default syslog output? > > > > Thanks in advance. > > > > Dan Kingdon > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 4 > Date: Fri, 8 Jan 2010 15:10:00 +0000 > From: "Seger, Mark" <[email protected]> > Subject: RE: snmptrapd traphandle traptoemail not working > To: Dan Kingdon <[email protected]>, > "[email protected]" > <[email protected]> > Message-ID: > < > 9FCE3A46FE7C8045A6207AE4B42E9F9A4A94D5EE6F@GVW1119EXC.americas.hpqcorp.net > > > > Content-Type: text/plain; charset="us-ascii" > > Wow, something even I can answer! ;-) > You need to include 'execute' with your authCommunity line like this: > > autoCommunity log,execute public > > then it will log AND execute your traphandle > > -mark > > From: Dan Kingdon [mailto:[email protected]] > Sent: Friday, January 08, 2010 7:42 AM > To: [email protected] > Subject: snmptrapd traphandle traptoemail not working > > Hi all, > > This is my first time dabbling with the snmptrapd program. I am using > Ubuntu on a fairly unmodified snmp setup. > > Just trying to set up a very basic email forwarder so that all snmp traps > are sent via email to the administrators address. > > The snmptrapd.conf I am using is > > " > authCommunity log public > traphandle default /usr/bin/perl /usr/bin/traptoemail -s localhost -f > <FROMADDRESS> <MYADDRESS> > " > > I can see the traps being logged in the syslog when snmptrapd is running, > but I do not receive any emails. > > I have also tried the following test of the traptoemail script and received > the email fine. > > "(echo localhost; echo 127.0.0.1; echo snmpTrapOID oidValue ; echo > sysUpTime 1) | /usr/bin/traptoemail -f <FROMADDRESS> -s localhost > <MYADDRESS>" > > I am now completely stuck, I have tried every variation I can find for the > traphandle line and still nothing. > > Is there anyway I can debug what snmptrapd is doing other that the default > syslog output? > > Thanks in advance. > > Dan Kingdon > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 5 > Date: Fri, 8 Jan 2010 15:16:22 -0000 > From: "Dan Kingdon" <[email protected]> > Subject: RE: snmptrapd traphandle traptoemail not working > To: "Seger, Mark" <[email protected]>, > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Thank you so much! > > > > I was just about ready to jump out a window. I was so focused on > getting the trap handle line correct that I didn't think to check the > authCommunity line. > > > > Thanks again. > > > > ________________________________ > > From: Seger, Mark [mailto:[email protected]] > Sent: 08 January 2010 15:10 > To: Dan Kingdon; [email protected] > Subject: RE: snmptrapd traphandle traptoemail not working > > > > Wow, something even I can answer! ;-) > > You need to include 'execute' with your authCommunity line like this: > > > > autoCommunity log,execute public > > > > then it will log AND execute your traphandle > > > > -mark > > > > From: Dan Kingdon [mailto:[email protected]] > Sent: Friday, January 08, 2010 7:42 AM > To: [email protected] > Subject: snmptrapd traphandle traptoemail not working > > > > Hi all, > > > > This is my first time dabbling with the snmptrapd program. I am using > Ubuntu on a fairly unmodified snmp setup. > > > > Just trying to set up a very basic email forwarder so that all snmp > traps are sent via email to the administrators address. > > > > The snmptrapd.conf I am using is > > > > " > > authCommunity log public > > traphandle default /usr/bin/perl /usr/bin/traptoemail -s localhost -f > <FROMADDRESS> <MYADDRESS> > > " > > > > I can see the traps being logged in the syslog when snmptrapd is > running, but I do not receive any emails. > > > > I have also tried the following test of the traptoemail script and > received the email fine. > > > > "(echo localhost; echo 127.0.0.1; echo snmpTrapOID oidValue ; echo > sysUpTime 1) | /usr/bin/traptoemail -f <FROMADDRESS> -s localhost > <MYADDRESS>" > > > > I am now completely stuck, I have tried every variation I can find for > the traphandle line and still nothing. > > > > Is there anyway I can debug what snmptrapd is doing other that the > default syslog output? > > > > Thanks in advance. > > > > Dan Kingdon > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 6 > Date: Fri, 8 Jan 2010 10:25:04 -0500 > From: Fulko Hew <[email protected]> > Subject: Re: help finding a MIB file > To: General OpenNMS Discussion > <[email protected]>, > [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > To summarize what I've found so far; 1.3.6.1.4.1.4 is either: > > APACHE-MIB > UNIX-MIB > OUTBACK-MIB > > Based on the numeric OIDs I've retrieved from the AIX box, the UNIX-MIB is > the most likely > candidate (it actually defines unix.5), but, for now... it doesn't compile. > > More detailed responses are below... > > > On Thu, Jan 7, 2010 at 4:18 PM, Ron Rader <[email protected] > >wrote: > > > > Fulko Hew [mailto:[email protected]] > > > > > Can anyone help me in locating a MIB file that contains: > > > > > 1.3.6.1.4.1.4.5... > > > > Closest references I found were here: > > > > http://www.snmplink.org/cgi-bin/nd/m/Ent/U/Unix/unix.mib > > > > Yup, I had found that too, but it doesn't compile (I haven't gotten around > to fixing it yet) > and its so old, that it may actually be what AIX is supporting. :-( > > and here: > > > > http://www.snmplink.org/cgi-bin/nd/m/Ent/S/Seneca%20Software%20&%20Solar > > ,%20Inc/PowerGuru/Outback%20Power%20Systems%20-%20inverters%20and%20char > > ge%20controllers/OUTBACK-MIB.txt< > http://www.snmplink.org/cgi-bin/nd/m/Ent/S/Seneca%20Software%20&%20Solar%0A,%20Inc/PowerGuru/Outback%20Power%20Systems%20-%20inverters%20and%20char%0Age%20controllers/OUTBACK-MIB.txt > > > > > > This is a bogus MIB. Some vendor of UPSs has stuck their tree where it > doesn't belong! > I pretty sure this isn't it. :-) > > > > Ron "Google is your friend" Rader > > > > I've been Googling all day. :-( > > On Fri, Jan 8, 2010 at 3:54 AM, Michael Seibold < > [email protected]> wrote: > Goolge... > > http://www.mibdepot.com/cgi-bin/xsearch_index3.cgi?id=95247 > > Thanks, but I had already looked there, and that comes up dry too. > > > On Fri, Jan 8, 2010 at 6:46 AM, Andrew Hood <[email protected]> wrote: > > > : snmptranslate -Td .1.3.6.1.4.1.4.5 > > SMUX-MIB::unix.5 > > unix OBJECT-TYPE > > -- FROM SMUX-MIB > > ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) unix(4) > 5 > } > > As you can see, this too is a dead end because the 5 isn't actually > decoded! > SMUX only defines unix.4, but it doesn't contain unix.5 > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 7 > Date: Fri, 8 Jan 2010 10:57:11 -0500 > From: Brandon Wigfield <[email protected]> > Subject: Re: help finding a MIB file > To: Fulko Hew <[email protected]> > Cc: General OpenNMS Discussion > <[email protected]>, > [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > I did some crawling of the net for MIBs a while back and then built a > database of oids for use in our in house NMS. > Since I have this in a DB I was able to run a query like: > > select n_oid, n_name, n_type, n_description, n_oid_string > from cco_mib_node > where n_oid like '1.3.6.1.4.1.4.5%' > order by n_oid > > > and get the following results: > > 1.3.6.1.4.1.4.5 netstat OBJECT IDENTIFIER > iso.org.dod.internet.private.enterprises.unix.netstat > > 1.3.6.1.4.1.4.5.1 unixNetstat INTEGER "Indicates whether the agent supports > a UNIX-like network MIB." > iso.org.dod.internet.private.enterprises.unix.netstat.unixNetstat > > 1.3.6.1.4.1.4.5.10 unixClnpRoutingTable SEQUENCE "The additional CLNP > routing table." > iso.org.dod.internet.private.enterprises.unix.netstat.unixClnpRoutingTable > > 1.3.6.1.4.1.4.5.10.1 unixClnpRouteEntry UnixClnpRouteEntry "An entry in the > additional CLNP routing table." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixClnpRoutingTable.unixClnpRouteEntry > > 1.3.6.1.4.1.4.5.10.1.1 unixClnpRouteFlags INTEGER "A value associated with > the CLNP routing entry. The value is a sum. This sum initial takes the > value zero. Then, for each flag, F, in the range 1 through N, that this > CLNP routing entry has TRUE, 2 raised to (F - 1) is added to the sum. > flag status ---- ------ 1 route useable 2 destination is a > gateway 3 host entry 4 re-instate route after timeout 5 > created dynamically (by redirect) Other values of flag are reserved for > future definition." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixClnpRoutingTable.unixClnpRouteEntry.unixClnpRouteFlags > > 1.3.6.1.4.1.4.5.10.1.2 unixClnpRouteRefCnt INTEGER "The number of sockets > using this IP routing entry." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixClnpRoutingTable.unixClnpRouteEntry.unixClnpRouteRefCnt > > 1.3.6.1.4.1.4.5.10.1.3 unixClnpRouteUses Counter "The number of times this > IP routing entry has been used." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixClnpRoutingTable.unixClnpRouteEntry.unixClnpRouteUses > > 1.3.6.1.4.1.4.5.2 unixTcpConnTable SEQUENCE "The TCP socket table." > iso.org.dod.internet.private.enterprises.unix.netstat.unixTcpConnTable > > 1.3.6.1.4.1.4.5.2.1 unixTcpConnEntry UnixTcpConnEntry "An entry in the TCP > socket table." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixTcpConnTable.unixTcpConnEntry > > 1.3.6.1.4.1.4.5.2.1.1 unixTcpConnSendQ INTEGER "The number of octets queued > for sending on this TCP socket." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixTcpConnTable.unixTcpConnEntry.unixTcpConnSendQ > > 1.3.6.1.4.1.4.5.2.1.2 unixTcpConnRecvQ INTEGER "The number of octets queued > for reading from this TCP socket." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixTcpConnTable.unixTcpConnEntry.unixTcpConnRecvQ > > 1.3.6.1.4.1.4.5.3 unixUdpTable SEQUENCE "The UDP socket table." > iso.org.dod.internet.private.enterprises.unix.netstat.unixUdpTable > > 1.3.6.1.4.1.4.5.3.1 unixUdpEntry UnixUdpEntry "An entry in the UDP socket > table." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixUdpTable.unixUdpEntry > > 1.3.6.1.4.1.4.5.3.1.1 unixUdpRemAddress IpAddress "The remote IP address > bound to this UDP socket. If no binding has occurred, the value 0.0.0.0 > is used." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixUdpTable.unixUdpEntry.unixUdpRemAddress > > 1.3.6.1.4.1.4.5.3.1.2 unixUdpRemPort INTEGER "The remote UDP port bound to > this UDP socket. If no binding has occurred, the value 0 is used." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixUdpTable.unixUdpEntry.unixUdpRemPort > > 1.3.6.1.4.1.4.5.3.1.3 unixUdpSendQ INTEGER "The number of octets queued for > writing to this UDP socket." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixUdpTable.unixUdpEntry.unixUdpSendQ > > 1.3.6.1.4.1.4.5.3.1.4 unixUdpRecvQ INTEGER "The number of octets queued for > reading from this UDP socket." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixUdpTable.unixUdpEntry.unixUdpRecvQ > > 1.3.6.1.4.1.4.5.4 unixIpRoutingTable SEQUENCE "The additional IP routing > table." > iso.org.dod.internet.private.enterprises.unix.netstat.unixIpRoutingTable > > 1.3.6.1.4.1.4.5.4.1 unixIpRouteEntry UnixIpRouteEntry "An entry in the > additional IP routing table." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixIpRoutingTable.unixIpRouteEntry > > 1.3.6.1.4.1.4.5.4.1.1 unixIpRouteFlags INTEGER "A value associated with the > IP routing entry. The value is a sum. This sum initial takes the value > zero. Then, for each flag, F, in the range 1 through N, that this IP > routing entry has TRUE, 2 raised to (F - 1) is added to the sum. > flag > status ---- ------ 1 route useable 2 destination is a gateway > 3 host entry 4 re-instate route after timeout 5 created > dynamically (by redirect) Other values of flag are reserved for future > definition." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixIpRoutingTable.unixIpRouteEntry.unixIpRouteFlags > > 1.3.6.1.4.1.4.5.4.1.2 unixIpRouteRefCnt INTEGER "The number of sockets > using > this IP routing entry." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixIpRoutingTable.unixIpRouteEntry.unixIpRouteRefCnt > > 1.3.6.1.4.1.4.5.4.1.3 unixIpRouteUses Counter "The number of times this IP > routing entry has been used." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixIpRoutingTable.unixIpRouteEntry.unixIpRouteUses > > 1.3.6.1.4.1.4.5.5 unixRouteBadRedirects Counter "The number of bogus > routing > redirects." > iso.org.dod.internet.private.enterprises.unix.netstat.unixRouteBadRedirects > > 1.3.6.1.4.1.4.5.6 unixRouteCreatedByRedirects Counter "The number of > routing > entries created by redirects." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixRouteCreatedByRedirects > > 1.3.6.1.4.1.4.5.7 unixRouteModifiedByRedirects Counter "The number of > routing entries modified by redirects." > > iso.org.dod.internet.private.enterprises.unix.netstat.unixRouteModifiedByRedirects > > 1.3.6.1.4.1.4.5.8 unixRouteLookupFails Counter "The number of times a > routing entry couldn't be found for a destination." > iso.org.dod.internet.private.enterprises.unix.netstat.unixRouteLookupFails > > 1.3.6.1.4.1.4.5.9 unixRouteWildcardUses Counter "The number of times the > `wildcard' routing entry was used." > iso.org.dod.internet.private.enterprises.unix.netstat.unixRouteWildcardUses > > > This information was on my system in a file called "snmp-rs6000" Using that > as a clue I found the MIB on MIB Depot at > > http://www.mibdepot.com/cgi-bin/getmib3.cgi?win=mib_a&r=ibm&f=snmp-rs6000&v=v1&t=txt > > > Hope that Helps, > > Brandon WIgfield > > > > > On Fri, Jan 8, 2010 at 10:25 AM, Fulko Hew <[email protected]> wrote: > > > To summarize what I've found so far; 1.3.6.1.4.1.4 is either: > > > > APACHE-MIB > > UNIX-MIB > > OUTBACK-MIB > > > > Based on the numeric OIDs I've retrieved from the AIX box, the UNIX-MIB > is > > the most likely > > candidate (it actually defines unix.5), but, for now... it doesn't > compile. > > > > More detailed responses are below... > > > > > > On Thu, Jan 7, 2010 at 4:18 PM, Ron Rader <[email protected] > >wrote: > > > >> > Fulko Hew [mailto:[email protected]] > >> > >> > Can anyone help me in locating a MIB file that contains: > >> > >> > 1.3.6.1.4.1.4.5... > >> > >> Closest references I found were here: > >> > >> http://www.snmplink.org/cgi-bin/nd/m/Ent/U/Unix/unix.mib > >> > > > > Yup, I had found that too, but it doesn't compile (I haven't gotten > around > > to fixing it yet) > > and its so old, that it may actually be what AIX is supporting. :-( > > > > and here: > >> > >> > http://www.snmplink.org/cgi-bin/nd/m/Ent/S/Seneca%20Software%20&%20Solar > >> ,%20Inc/PowerGuru/Outback%20Power%20Systems%20-%20inverters%20and%20char > >> ge%20controllers/OUTBACK-MIB.txt< > http://www.snmplink.org/cgi-bin/nd/m/Ent/S/Seneca%20Software%20&%20Solar%0A,%20Inc/PowerGuru/Outback%20Power%20Systems%20-%20inverters%20and%20char%0Age%20controllers/OUTBACK-MIB.txt > > > >> > > > > This is a bogus MIB. Some vendor of UPSs has stuck their tree where it > > doesn't belong! > > I pretty sure this isn't it. :-) > > > > > >> Ron "Google is your friend" Rader > >> > > > > I've been Googling all day. :-( > > > > On Fri, Jan 8, 2010 at 3:54 AM, Michael Seibold < > > [email protected]> wrote: > > Goolge... > > > > http://www.mibdepot.com/cgi-bin/xsearch_index3.cgi?id=95247 > > > > Thanks, but I had already looked there, and that comes up dry too. > > > > > > On Fri, Jan 8, 2010 at 6:46 AM, Andrew Hood <[email protected]> wrote: > > > > > : snmptranslate -Td .1.3.6.1.4.1.4.5 > > > SMUX-MIB::unix.5 > > > unix OBJECT-TYPE > > > -- FROM SMUX-MIB > > > ::= { iso(1) org(3) dod(6) internet(1) private(4) enterprises(1) > unix(4) > > 5 } > > > > As you can see, this too is a dead end because the 5 isn't actually > > decoded! > > SMUX only defines unix.4, but it doesn't contain unix.5 > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > This SF.Net email is sponsored by the Verizon Developer Community > > Take advantage of Verizon's best-in-class app development support > > A streamlined, 14 day to market process makes app distribution fast and > > easy > > Join now and get one step closer to millions of Verizon customers > > http://p.sf.net/sfu/verizon-dev2dev > > _______________________________________________ > > 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 > > > > > > > -- > Brandon Wigfield > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 8 > Date: Fri, 08 Jan 2010 17:33:43 +0100 > From: Peter Luciak <[email protected]> > Subject: Embedding multiple Perl agents > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > I've created two different Perl SNMP agents for 2 different OIDs, which > I've succesfully embedded into Net-SNMP using: > > perl do "/etc/snmp/snmpagent_1.pl" > > I'm able to successfully snmpwalk/snmpget the data from this agent. > > However, when I try to configure both of them at the same time, only one > of them works (the one which is first in the config file): > > perl do "/etc/snmp/snmpagent_1.pl" > perl do "/etc/snmp/snmpagent_2.pl" > > The 2 scripts are completely separate, different OIDs, handlers, etc. By > running "snmpd -f -d" and debugging lines in both scripts, I see that > both scripts were executed, but the only output I got from SNMPd is: > > get: /usr/share/snmp/snmp_perl.pl @ ibl > GET No value ... > > Any hints? > > Thanks, > Peter > -- > Peter LUCIAK ([email protected]) > IBL Software Engineering, http://www.iblsoft.com/ > Mierov? 103, 82105 Bratislava, Slovakia > Phone: +421-2-32662111, Fax: +421-2-32662110 > Direct: +421-2-32662175 > > > > ------------------------------ > > Message: 9 > Date: Fri, 8 Jan 2010 11:38:17 -0500 > From: Fulko Hew <[email protected]> > Subject: Re: help finding a MIB file > To: Brandon Wigfield <[email protected]> > Cc: General OpenNMS Discussion > <[email protected]>, > [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > On Fri, Jan 8, 2010 at 10:57 AM, Brandon Wigfield <[email protected] > >wrote: > > > I did some crawling of the net for MIBs a while back and then built a > > database of oids for use in our in house NMS. > > Since I have this in a DB I was able to run a query like: > > > > select n_oid, n_name, n_type, n_description, n_oid_string > > from cco_mib_node > > where n_oid like '1.3.6.1.4.1.4.5%' > > order by n_oid > > > > > > and get the following results: > > > > ... snip ... > > Thanks. > In the meantime, I pursued the 'unix.mib' idea, fix the unresolved bugs by > adding the missing includes, and that's solved my problem. > > > > This information was on my system in a file called "snmp-rs6000" Using > that > > as a clue I found the MIB on MIB Depot at > > > http://www.mibdepot.com/cgi-bin/getmib3.cgi?win=mib_a&r=ibm&f=snmp-rs6000&v=v1&t=txt > > > > The file this URL points at actually seems to consist of 3 things: > > 1/ The original unix.mib > 2/ A copy of rfc1213 (so that the unresolveds are now resolved (brute > force)) > 3/ Some IBM/RS6000 specific variables and traps. > > I don't know if I need 'part 3' since my box (wherever it came from and > contains) doesn't > seem to respond with those 'additional' variables, and I don't know about > the traps. > > Thanks for the pointer. > > At least now, this answer should be found in a search engine for the next > guy! > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 10 > Date: Fri, 8 Jan 2010 10:23:09 -0800 > From: "Mike Ayers" <[email protected]> > Subject: RE: SNMP v3 > To: "astal vista" <[email protected]>, > <[email protected]> > Message-ID: > < > 83E753BE7B6A324ABB336245BAF1DAAC0DBD1C17@mailserver.metatv-ds.metatv.com> > > Content-Type: text/plain; charset="UTF-8" > > > From: astal vista [mailto:[email protected]] > > Sent: Friday, January 08, 2010 12:00 AM > > > 1) to create 5 users and assign passwords for them. > > http://www.net-snmp.org/wiki/index.php/Vacm > > > 2)usage of snmpusm command. > > http://www.net-snmp.org/docs/man/snmpusm.html > > > 3) what is security passphrase > > Another way to say "password". Note that USM uses binary keys to > authenticate users. There is a convention for a 2-way key to password > conversion which permits one to think in terms of the more familiar > password, which is what you will usually see discussed here. > > > HTH, > > Mike > > > ------------------------------ > > Message: 11 > Date: Fri, 8 Jan 2010 12:22:33 -0800 (PST) > From: <[email protected]> > Subject: Changing the agent-address for SNMP v1 pdus > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > We are using Net-SNMP 5.3.0.1 and I have setup a "gateway" > to run snmptrapd and forward all traps it receives from internal > entities to an external managing entity. Everything is working fine > except that for SNMP Version 1 traps, the source/host address is > displaying as an internal address (it appears to be using the > agent-addr field from the SNMP v1 pdu) and not the external address of > the "gateway" that initiates the fowarding. For SNMP Version 2 > traps/informs, there is no agent-addr field since the pdu has been > modified and the traps are being displayed correctly using the external > address of the gateway presumably being retrieved from the source field > of the IP header. > > So I'm wondering how can I have snmptrapd modify the agent-addr field > for SNMP Version 1 traps before they get forwarded? I noticed that > snmptrapd supports the ability to execute a program when it receives a > trap using the traphandle directive. From the best I can gather, I > would have to capture all traps and reissue them with the correct agent > address for SNMP version 1 traps (I haven't tried this yet, but I'm > about to run some tests)? Is there a better way to accomplish the same > thing? Is there a way to just modify the agent-addr field for SNMP > version 1 traps? > > Thanks, > Felix > > > > > > > > ------------------------------ > > Message: 12 > Date: Fri, 08 Jan 2010 15:32:39 -0500 > From: C Wells <[email protected]> > Subject: snmptrap (win32) tcp > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I don't see a tcp option for snmptrap.exe so I assume it isn't there. > Does anyone know of a win32 snmptrap sending utility that can send using > TCP ? > Thanks > > > > > ------------------------------ > > Message: 13 > Date: Fri, 8 Jan 2010 12:37:15 -0500 > From: "Nayman Felix-QA5535" <[email protected]> > Subject: Changing the agent-address for SNMP v1 pdus > To: <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > We are using Net-SNMP 5.3.0.1 and I have setup a "gateway" to run > snmptrapd and forward all traps it receives from internal entities to an > external managing entity. Everything is working fine except that for > SNMP Version 1 traps, the source/host address is displaying as an > internal address (it appears to be using the agent-addr field from the > SNMP v1 pdu) and not the external address of the "gateway" that > initiates the fowarding. For SNMP Version 2 traps/informs, there is no > agent-addr field since the pdu has been modified and the traps are being > displayed correctly using the external address of the gateway presumably > being retrieved from the source field of the IP header. > > So I'm wondering how can I have snmptrapd modify the agent-addr field > for SNMP Version 1 traps before they get forwarded? I noticed that > snmptrapd supports the ability to execute a program when it receives a > trap using the traphandle directive. From the best I can gather, I would > have to capture all traps and reissue them with the correct agent > address for SNMP version 1 traps (I haven't tried this yet, but I'm > about to run some tests)? Is there a better way to accomplish the same > thing? Is there a way to just modify the agent-addr field for SNMP > version 1 traps? > > Thanks, > Felix > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 14 > Date: Mon, 11 Jan 2010 11:17:04 +0530 > From: Peyush Kumar <[email protected]> > Subject: InBuilt OIDs supported by snmpd > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I understand some inbuilt OIDs (can be queried using SNMP Get) > from snmpD > > >From where can I obtain this "complete" list > > Is it possible to supress the support of SNMP Get on these OIDs in a > particular deployment? > > TIA > Peyush. > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 15 > Date: Mon, 11 Jan 2010 13:53:14 +0800 > From: " Alexander King " <[email protected]> > Subject: Define Trap mib file and generate Trap codes problem > To: " net-snmp-users " <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Hi All: > > I define the trap entries in the same mib file like this: > > controllerInfo OBJECT IDENTIFIER ::= { systeminfoController 1 } > systemNumber OBJECT-TYPE > SYNTAX DisplayString( SIZE( 0..256 ) ) > ACCESS read-only > STATUS current > DESCRIPTION > "system Number." > ::= { controllerInfo 1 } > fcPort OBJECT-TYPE > SYNTAX DisplayString( SIZE( 0..256 ) ) > ACCESS read-only > STATUS current > DESCRIPTION > "fc Port." > ::= { hostInterfaceFCEntry 1 } > > and then: > > systemNumbertrap TRAP-TYPE > ENTERPRISE controllerInfo > VARIABLES { systemNumber } > DESCRIPTION "This is just a demo" > ::= 51898 > > fcPorttrap TRAP-TYPE > ENTERPRISE hostInterfaceFCEntry > VARIABLES { fcPort } > DESCRIPTION "Warning:fc port %d was failed!" > ::= 511 > > is it right? > > I used ' mib2c -c mib2c.notify.conf XXX ' generate the trap code,but I > just got send_controllerInfotrap_oid one trap send function,and do I should > be have two send_XXX_oid functions?such as:send_controllerInfotrap_oid and > send_hostInterfaceFCEntrytrap_oid > > /* > * Note: this file originally auto-generated by mib2c using > * : mib2c.notify.conf 10110 2004-04-15 12:29:19Z dts12 $ > */ > > #include <net-snmp/net-snmp-config.h> > #include <net-snmp/net-snmp-includes.h> > #include <net-snmp/agent/net-snmp-agent-includes.h> > #include "uit.h" > > static oid snmptrap_oid[] = {1, 3, 6, 1, 6, 3, 1, 1, 4, 1, 0}; > > int > send_controllerInfo#_trap( void ) > { > netsnmp_variable_list *var_list = NULL; > oid controllerInfo#_oid[] = { 1,3,6,1,4,1,30901,2090,7000,2,1,1,0 }; > > /* > * Set the snmpTrapOid.0 value > */ > snmp_varlist_add_variable(&var_list, > snmptrap_oid, OID_LENGTH(snmptrap_oid), > ASN_OBJECT_ID, > controllerInfo#_oid, sizeof(controllerInfo#_oid)); > > > /* > * Add any extra (optional) objects here > */ > > /* > * Send the trap to the list of configured destinations > * and clean up > */ > send_v2trap( var_list ); > snmp_free_varbind( var_list ); > > return SNMP_ERR_NOERROR; > } > > would you some warmhearted body mail me a trap prototype(mib and modified > .c files) or some hints and links? > > Do you have some constructive suggestions,Dave?Forgive me and my horrible > mails. :=) > > > > > Alex > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 16 > Date: Mon, 11 Jan 2010 08:22:00 +0000 > From: Dave Shield <[email protected]> > Subject: Re: SNMPGET specifying the community name > To: Irvs <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > [ First - *please* don't mail me privately, without copying > any responses to the mailing list. I don't have the time > or inclination to offer private, unpaid, SNMP consultancy. > Keep discussions to the list, where others can both learn > and offer advice. Thanks. ] > > 2010/1/11 Irvs <[email protected]>: > > I realized that its too risky to upgrade our system with a newer net-snmp > > version. > > Fair enough. > But be aware that by running with such an obsolete version > of the software, you are missing out on a *lot* of fixes > (including a number of security-related issues). > > You should think about planning an upgrade to something > a little newer when you have the time. > > > > > If it is not too much to ask, can you help me point out which file > > or which part of the code where I could possibly check the implementation > of > > commnunity name regarding its bug when it includes spaces? > > The most likely change would be SVN revision 10694 > (from July 2004). See > > http://net-snmp.svn.sourceforge.net/viewvc/net-snmp/trunk/net-snmp/agent/mibgroup/mibII/vacm_conf.c?r1=10540&r2=10694&view=patch > > Dave > > > > ------------------------------ > > Message: 17 > Date: Mon, 11 Jan 2010 08:24:20 +0000 > From: Dave Shield <[email protected]> > Subject: Re: InBuilt OIDs supported by snmpd > To: Peyush Kumar <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/1/8 Peyush Kumar <[email protected]>: > > I understand some inbuilt OIDs (can be queried using SNMP Get) > > from?snmpD > > > > From where can I obtain this "complete" > > See the file README.agent-mibs > > > > If I need to supress the support of SNMP Get on these OIDs in > > my deployment what can be done ? > > Compile the code using > configure --enable-mini-agent > > (plus any MIBs/functionality that you do wish to support). > That specifies the minimum modules for a working agent. > > Dave > > > > ------------------------------ > > Message: 18 > Date: Sun, 10 Jan 2010 23:53:39 +0800 > From: ?? <[email protected]> > Subject: Encryption support not enabled > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I have installed the binaries > net-snmp-5.4.1-1.win32 and want to send v3 authPriv getnext to my agent. > I am getting USM support not enabled error. > Is there a way to enable encryption in binary install, > > C:\Users\ebaozhu>snmpget -v3 -u leelin -n "" -A authpass -x DES -X privpass > -l a > uthPriv localhost sysDescr.0 > Encryption support not enabled. > snmpget: USM encryption error (Sub-id not found: (top) -> sysDescr) > > But if I do not use DES, that is OK. > > C:\Users\ebaozhu>snmpget -v3 -u leelin -n "" -l authNoPriv -A authpass -X > privpa > ss localhost sysDescr.0 > SNMPv2-MIB::sysDescr.0 = STRING: Windows EV001EEC72605A 6.0.6000 > Professional > x86 Family 6 Model 23 Stepping 6 > So why Encryption is not supported but authrization is supported? > > Many thanks. > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 19 > Date: Mon, 11 Jan 2010 13:54:56 +0800 > From: " Alexander King " <[email protected]> > Subject: Re:InBuilt OIDs supported by snmpd > To: " Peyush Kumar " <[email protected]> > Cc: net-snmp-users <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > try :snmpwalk in CLI > > I ususlly use 'snmpwalk -v2c -c public localhost' to get all the inbuilt > OID information. > > ------------------ Original ------------------ > From: "Peyush Kumar"<[email protected]>; > Date: Mon, Jan 11, 2010 02:17 PM > To: "net-snmp-users"<[email protected]>; > > Subject: InBuilt OIDs supported by snmpd > > > > Hi, > > I understand some inbuilt OIDs (can be queried using SNMP Get) > > from snmpD > > >From where can I obtain this "complete" list > > Is it possible tosupress the support of SNMP Get on these OIDs in a > particular deployment? > > TIA > > Peyush. > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 20 > Date: Mon, 11 Jan 2010 08:36:23 +0000 > From: Dave Shield <[email protected]> > Subject: Re: Define Trap mib file and generate Trap codes problem > To: Alexander King <[email protected]> > Cc: net-snmp-users <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/1/11 Alexander King <[email protected]>: > > I define the trap entries in the same mib file like this: > > > > controllerInfo ????OBJECT IDENTIFIER ::= { systeminfoController 1? } > > ??? systemNumber OBJECT-TYPE > > ??????? SYNTAX DisplayString( SIZE( 0..256 ) ) > > ??????? ACCESS read-only > .... > > > and then: > > > > ??? systemNumbertrap TRAP-TYPE > > > is it right? > > You seem to be using SMIv1 for your MIBs. > That has been obsolete for several years. > > Please use SMIv2 (MAX-ACCESS rather than ACCESS, > and NOTIFICATION-TYPE rather than TRAP-TYPE). > > And you wouldn't normally use the same OID as the > parent of a management information object, and a > notification. Traps are usually defined within a separate > subtree. > See (e.g.) the Net-SNMP MIBs for a typical arrangement. > > > > > I used ' mib2c -c mib2c.notify.conf XXX ' generate the trap code, > > What was 'XXX' ? > > > but I just got send_controllerInfotrap_oid one trap send function > > I'm guessing that's probably the only trap within the subtree you > specified. > But since you didn't tell us what XXX was, that's only a guess. > > > > > and do I should be have two send_XXX_oid functions? > > If your starting point contained two traps, then yes - you should > have two send_xxx_trap functions. > > > > would you some?warmhearted body?mail me a trap prototype(mib and?modified > .c > > files) or some hints and links? > > Define the MIB using SMIv2. > Keep all of the trap definitions in the same subtree. > > > Dave > > > > ------------------------------ > > Message: 21 > Date: Mon, 11 Jan 2010 08:38:01 +0000 > From: Dave Shield <[email protected]> > Subject: Re: InBuilt OIDs supported by snmpd > To: Alexander King <[email protected]> > Cc: net-snmp-users <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/1/11 Alexander King <[email protected]>: > > I ususlly use 'snmpwalk -v2c -c public localhost' to get all the > > inbuilt OID information. > > Except that this will only retrieve the *standard* MIB information. > It won't pick up any vendor-specific MIBs. > > Nor will it necessarily retrieve anything that needs particular > configuration on the agent side. > > Dave > > > > ------------------------------ > > Message: 22 > Date: Mon, 11 Jan 2010 08:40:40 +0000 > From: Dave Shield <[email protected]> > Subject: Re: Encryption support not enabled > To: ?? <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > 2010/1/10 ?? <[email protected]>: > > I have installed the binaries > > net-snmp-5.4.1-1.win32 and want to send v3 authPriv getnext to my agent. > > I am getting USM support not enabled error. > > Is there a way to enable encryption in binary install, > > Install the binary "net-snmp-{version}-ssl.win32" > rather than the non-SSL binary. > SSL is required for encryption support > > Dave > > > > ------------------------------ > > Message: 23 > Date: Mon, 11 Jan 2010 17:08:17 +0800 > From: " Alexander King " <[email protected]> > Subject: Re: Define Trap mib file and generate Trap codes problem > To: " net-snmp-users " <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > 2010/1/11 Alexander King <[email protected]>: > > I define the trap entries in the same mib file like this: > > > > controllerInfo OBJECT IDENTIFIER ::= { systeminfoController 1 } > > systemNumber OBJECT-TYPE > > SYNTAX DisplayString( SIZE( 0..256 ) ) > > ACCESS read-only > .... > > > and then: > > > > systemNumbertrap TRAP-TYPE > > > is it right? > > You seem to be using SMIv1 for your MIBs. > That has been obsolete for several years. > > Please use SMIv2 (MAX-ACCESS rather than ACCESS, > and NOTIFICATION-TYPE rather than TRAP-TYPE). > >>For use SMIv2 I just replace ACCESS for MAX-ACCESS,TRAP-TYPE for > NOTIFICATION-TYPE,is it right? > > And you wouldn't normally use the same OID as the > parent of a management information object, and a > notification. Traps are usually defined within a separate > subtree. > See (e.g.) the Net-SNMP MIBs for a typical arrangement. > > >>If I donot use the same parent OID,how do I distinguish the notification > entries belong to?I meaning I use the same OID as some notification entries > so we can easily known which alarm information they belong to.another way to > solve this?because I have a lot of this entries.I will go to see the mibs > arragment Howtos. > > > I used ' mib2c -c mib2c.notify.conf XXX ' generate the trap code, > > What was 'XXX' ? > > >>the XXX is my corporation name(you known it,:=)),I defined the > scalars,tables,and notification entries in one file,so I can run the mib2c > -c mib2c.scalar.conf XXX,mib2c -c mib2c.iterate.conf XXX, mib2c -c > mib2c.notify.conf XXX and integrated three code files into one,and compiling > it into my subagent.is it right? > > > but I just got send_controllerInfotrap_oid one trap send function > > I'm guessing that's probably the only trap within the subtree you > specified. > But since you didn't tell us what XXX was, that's only a guess. > > >> XXX is stand for uit,I had my mib file in the last mail, it ismaybe give > you some information. > > > and do I should be have two send_XXX_oid functions? > > If your starting point contained two traps, then yes - you should > have two send_xxx_trap functions. > > >>My start point have serval TRAP-TYPE,but they are belong to two > difference parent OIDs,I just got one trap function.I donot know why. > > > would you some warmhearted body mail me a trap prototype(mib and modified > .c > > files) or some hints and links? > > Define the MIB using SMIv2. > Keep all of the trap definitions in the same subtree. > > >>I will do this now.need learn how to arrangement the trap file structure. > > Thank you,Dave! > > Alex > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 24 > Date: Mon, 11 Jan 2010 11:20:17 +0000 > From: Dave Shield <[email protected]> > Subject: Re: Define Trap mib file and generate Trap codes problem > To: Alexander King <[email protected]> > Cc: net-snmp-users <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/1/11 Alexander King <[email protected]>: > >>>If I do not use the same parent OID,how do I distinguish the > >>> notification entries belong to? > > What do you mean by this? > > If there is management information associated with a notification, > this would typically be listed in the OBJECTS clause of the notification > definition. For example, see the linkUp/linkDown traps, in IF-MIB. > > This also means that you've got information about *which* interface > (or more generally, which row of the table) triggered the trap. > > > > >>>the XXX is my corporation name(you known it,:=)),I defined the > >>> scalars,tables,and notification entries in one file,so I can run the > mib2c > >>> -c mib2c.scalar.conf XXX,mib2c -c mib2c.iterate.conf XXX, mib2c -c > >>> mib2c.notify.conf XXX and integrated three code files into one,and > compiling > >>> it into my subagent.is it right? > > You don't have to combine all three files into one. > You could equally as well keep them as three separate files, > and compile all three into the subagent. > > > > >> but I just got send_controllerInfotrap_oid one trap send function > > The fcPorttrap seems to be associated with hostInterfaceFCEntry > Where is this defined? What is its OID? > > > > >>> XXX is stand for uit,I had my mib file in the last mail, it ismaybe > give > >>> you some information. > > You had a *fragment* of the MIB in your last mail. > But it gave no indication what the enterprise OIDs for the two > traps were, or how these relate to your starting point. > > There may be another message somewhere in the mailing list > archives that includes the full MIB, but I don't have the time to > search for it. > > If the OID hostInterfaceFCEntry lies within the subtree rooted at > 'uit', then mib2c should have generated a corresponding function > call. If it lies outside this subtree, then it wouldn't. > > > Dave > > > > ------------------------------ > > Message: 25 > Date: Mon, 11 Jan 2010 15:24:22 +0100 > From: Kristoff Bonne <[email protected]> > Subject: val_len when returning oid > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > > I have a small question concerning the value returned in "val_len" when > returning a variable of type "oid". > > > I have been writing a small program here in C using the net-snmp library > based on the examples on the net-snmp library. > > > It makes a snmp-query for a number of data-elements, one of them being > "SNMPv2-MIB::sysObjectID.0". > > This returns a value of the type "oid". > > However, I have noticed that size of the element (as found in > vars->val_len) is actually 4 times the number of elements in the oid. > > So, a query to a cisco returns "SNMPv2-SMI::enterprises.9.1.46" > (1.3.6.1.4.1.9.1.46), vars->val_len will be 36! > > I need the correct size as I want need to convert this to a string using > snprint_objid later. > > > Is this relation of "size = var_val_len / 4" something that is fixed and > the same on all platforms? > > Or is there some other trick I need do to find the correct lenght of the > oid returned? > > > > Cheerio! Kr. Bonne. > > > > > ------------------------------ > > Message: 26 > Date: Mon, 11 Jan 2010 14:47:28 +0000 > From: Dave Shield <[email protected]> > Subject: Re: val_len when returning oid > To: Kristoff Bonne <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/1/11 Kristoff Bonne <[email protected]>: > > I have a small question concerning the value returned in "val_len" when > > returning a variable of type "oid". > > "val_len" is always the size of the value being returned in "val". > Expressed in bytes. > > > > However, I have noticed that size of the element (as found in > > vars->val_len) is actually 4 times the number of elements in the oid. > > Correct. > Or more accurately, it's the number of subidentifiers, > multiplied by sizeof(oid). > > > > > > Is this relation of "size = var_val_len / 4" something that is fixed and > > the same on all platforms? > > size = var_val_len / sizeof(oid) > > would be safer. > > Dave > > > > ------------------------------ > > Message: 27 > Date: Mon, 11 Jan 2010 15:46:32 +0100 > From: Kristoff Bonne <[email protected]> > Subject: snprint_objid in decimal format > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > > > Using the C API from net-snmp, how can I print an object in its > "decimal" format? > > When I use snprint_objid, it returns something like > "SNMPv2-SMI::enterprises.9.1.46", I would to have it as > "1.3.6.1.4.1.9.1.46". > > > > Cheerio! Kr. Bonne. > > > > > ------------------------------ > > Message: 28 > Date: Mon, 11 Jan 2010 15:55:53 +0100 > From: Kristoff Bonne <[email protected]> > Subject: Re: val_len when returning oid > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Dave, > > > Dave Shield schreef: > >> I have a small question concerning the value returned in "val_len" when > >> returning a variable of type "oid". > > "val_len" is always the size of the value being returned in "val". > > Expressed in bytes. > (...) > > >> Is this relation of "size = var_val_len / 4" something that is fixed and > >> the same on all platforms? > > size = var_val_len / sizeof(oid) > > would be safer. > > Make sence once it gets explained. :-) > > > > Thanks! > > > > > > Dave > Cheerio! Kr. Bonne. > > > > > ------------------------------ > > Message: 29 > Date: Mon, 11 Jan 2010 15:05:28 +0000 > From: Dave Shield <[email protected]> > Subject: Re: snprint_objid in decimal format > To: Kristoff Bonne <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/1/11 Kristoff Bonne <[email protected]>: > > Using the C API from net-snmp, how can I print an object in its > > "decimal" format? > > > > When I use snprint_objid, it returns something like > > "SNMPv2-SMI::enterprises.9.1.46", I would to have it as > > "1.3.6.1.4.1.9.1.46". > > Call > netsnmp_ds_set_int(NETSNMP_DS_LIBRARY_ID, > NETSNMP_DS_LIB_OID_OUTPUT_FORMAT, > NETSNMP_OID_OUTPUT_NUMERIC); > > before printing the OID. > > Dave > > > > ------------------------------ > > Message: 30 > Date: Mon, 11 Jan 2010 10:33:32 -0500 > From: Fulko Hew <[email protected]> > Subject: snmpd seg faults on AIX > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > I've build net-snmp on this AIX (version 5.3.001) box I have, and when I > tried doing a walk at .iso > I get some answers back, but then it seg faults. > > After searching the web... I tried invoking it with debugging to see if I > can see more; > maybe determine why its segfaulting. I invoked it using: > > /net-snmp-5.5/agent/.libs/lt-snmpd -c/net-snmp-5.5/test.conf -DALL -f -Lo > -M > /net-snmp-5.5/mibs -mALL localhost:2000 > > and I'm browsing it using: > > # ./snmpwalk -cpublic -v1 -M /net-snm-5.5/mibs -mALL localhost:2000 .iso > > It doesn't get very far down the tree. > I see it trying to get ipFragsCreate, and then it faults. > With the debug turned on I see it passing emitting the following statement > 'a million times' > before it finally dies. > > ... > verbose:kernel:klookup: klookup(0, 2df24ac8, 24) succeededtrace: klookup(): > kernel.c, 196: > verbose:kernel:klookup: klookup(0, 2df24838, 24) succeededtrace: klookup(): > kernel.c, 196: > verbose:kernel:klookup: klookup(0, 2df245a8, 24) succeededtrace: klookup(): > kernel.c, 196: > Segmentation fault(coredump) > > > > Any clues as to what to try next? > > TIA > Fulko > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 31 > Date: Mon, 11 Jan 2010 15:40:41 +0000 > From: Dave Shield <[email protected]> > Subject: Re: snmpd seg faults on AIX > To: Fulko Hew <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/1/11 Fulko Hew <[email protected]>: > > and I'm browsing it using: > > > > # ./snmpwalk -cpublic -v1 -M /net-snm-5.5/mibs -mALL localhost:2000 .iso > > > > It doesn't get very far down the tree. > > I see it trying to get ipFragsCreate, and then it faults. > > > > Any clues as to what to try next? > > > Does it return ipFragsCreate.0 or not? > If not, what happens when you try a GET request on this object? > If it does, what happens when you try a GET request on the next object? > (ipAdEntAddr.127.0.0.1) > > What happens if you start walking shortly after this point? > Say ipRouteTable? or ipAdEntTable? > > Try to pinpoint exactly which object(s) are failing, > and what does work OK > > > Dave > > > > ------------------------------ > > Message: 32 > Date: Mon, 11 Jan 2010 11:19:34 -0500 > From: Fulko Hew <[email protected]> > Subject: Re: snmpd seg faults on AIX > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > On Mon, Jan 11, 2010 at 10:40 AM, Dave Shield <[email protected] > >wrote: > > > 2010/1/11 Fulko Hew <[email protected]>: > > > and I'm browsing it using: > > > > > > # ./snmpwalk -cpublic -v1 -M /net-snm-5.5/mibs -mALL localhost:2000 > .iso > > > > > > It doesn't get very far down the tree. > > > I see it trying to get ipFragsCreate, and then it faults. > > > > > > > Any clues as to what to try next? > > > > > > Does it return ipFragsCreate.0 or not? > > > > Yes it did, it fails on getNext(ipFragsCreate.0) > > If not, what happens when you try a GET request on this object? > > If it does, what happens when you try a GET request on the next object? > > (ipAdEntAddr.127.0.0.1) > > > > It returns 'noSuch' > > > > What happens if you start walking shortly after this point? > > Say ipRouteTable? or ipAdEntTable? > > > > It faults on getnext ipRouteTable > > I also tried querying the AIX supplied daemon for getnext(ipRouteTable) > to see what entry I should expect to see... > and it returned an entry, so I explictly queried netsnmp for _that_ > entry... > get(ipRouteDest.10.40.16.0) and it too segfaults with exactly the same > message. > > > > Try to pinpoint exactly which object(s) are failing, > > and what does work OK > > > > Moving forwards and backwards trying to isolate the bad spot, we see: > > snmpwalk ipFragCreates -> returns data > snmpwalk ipAddrTable) -> fails > snmpwalk ipRouteTable) -> fails > > snmpwalk ipNetToMediaTable -> doesn't segfault, the daemon returned a > packet, > but 'walk' didn't output anything (sorry, I > have > no sniffer available to examine the response > in > more detail.) > > snmpwalk ipforward) -> returns data > snmpwalk icmp -> returns data > > > FYI, when I invoke the daemon it complains about: > nlist err: neither proc nor _proc found. > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 33 > Date: Mon, 11 Jan 2010 16:30:32 +0000 > From: Dave Shield <[email protected]> > Subject: Re: snmpd seg faults on AIX > To: Fulko Hew <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > 2010/1/11 Fulko Hew <[email protected]>: > >> What happens if you start walking shortly after this point? > >> Say ipRouteTable? ?or ipAdEntTable? > > > > It faults on getnext ipRouteTable > > OK - It looks as if the problem lies within the ipRouteTable code. > Try using "-I-{token}" to disable this table, and check that > the agent runs successfully. > ("{token}" should match the name of the relevant "init_{token}" > routine - I'm not sure offhand which code you'll be using, and > hence which init routine you need to disable) > > > > snmpwalk?? ipNetToMediaTable -> doesn't segfault, the daemon returned > > a packet,? but 'walk' didn't output anything > > Try using "snmpgetnext" instead of "snmpwalk". > That will report the results returned, regardless of the OIDs involved. > > But it does sound as if you've managed to pinpoint the problem anyway. > > Dave > > > > ------------------------------ > > Message: 34 > Date: Mon, 11 Jan 2010 11:48:53 -0500 > From: Fulko Hew <[email protected]> > Subject: Re: snmpd seg faults on AIX > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > On Mon, Jan 11, 2010 at 11:30 AM, Dave Shield <[email protected] > >wrote: > > > 2010/1/11 Fulko Hew <[email protected]>: > > >> What happens if you start walking shortly after this point? > > >> Say ipRouteTable? or ipAdEntTable? > > > > > > It faults on getnext ipRouteTable > > > > OK - It looks as if the problem lies within the ipRouteTable code. > > Try using "-I-{token}" to disable this table, and check that > > the agent runs successfully. > > ("{token}" should match the name of the relevant "init_{token}" > > routine - I'm not sure offhand which code you'll be using, and > > hence which init routine you need to disable) > > > > Using the -Dmib_init option to find the token names, the only thing I could > disable > was the whole 'ip' table. Doing so allowed me to walk 'everything' else. > (But I guess I can't disable just the ipAddrTable or ipRouteTable.) > > > snmpwalk ipNetToMediaTable -> doesn't segfault, the daemon returned > > > a packet, but 'walk' didn't output anything > > > > Try using "snmpgetnext" instead of "snmpwalk". > > That will report the results returned, regardless of the OIDs involved. > > > > But it does sound as if you've managed to pinpoint the problem anyway. > > > > So the problem is in the handling of ipAddrTable and ipRouteTable... > now what? > > I'll look at that part of the code while I wait for feedback, > but I'm afraid I'm out of my expertise in Net-SNMP source code > and/or AIX kernel structures. :-( > > Fulko > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 35 > Date: Mon, 11 Jan 2010 13:37:05 -0500 > From: Fulko Hew <[email protected]> > Subject: Re: snmpd seg faults on AIX > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > On Mon, Jan 11, 2010 at 11:48 AM, Fulko Hew <[email protected]> wrote: > > > > > > > On Mon, Jan 11, 2010 at 11:30 AM, Dave Shield < > [email protected]>wrote: > > > >> 2010/1/11 Fulko Hew <[email protected]>: > >> > > > > > ... snip ... > > > > > > So the problem is in the handling of ipAddrTable and ipRouteTable... > > now what? > > > > > I'll look at that part of the code while I wait for feedback > > but I'm afraid I'm out of my expertise in Net-SNMP source code > > and/or AIX kernel structures. :-( > > > > For what its worth, here is the debug trace of what I think is the relevant > portion, > (when I did a getnext(ipAddrTable), but I don't know where to look next, or > go from here. > > > Fulko > > ... snip ... > > helper:cache_handler: Got request (161) for ip: > IP-MIB::iphelper:cache_handler: Got request (161) for ip: IP-MIB::ip > > trace: trace: netsnmp_call_handler(): agent_handler.c, 443: > netsnmp_call_handler(): agent_handler.c, 443: > handler:returned: handler:returned: handler cache_handler returned 0 > handler cache_handler returned 0 > trace: trace: netsnmp_call_handler(): agent_handler.c, 435: > netsnmp_call_handler(): agent_handler.c, 435: > handler:calling: handler:calling: calling handler bulk_to_next for mode > GETNEXT > calling handler bulk_to_next for mode GETNEXT > trace: trace: netsnmp_call_handler(): agent_handler.c, 443: > netsnmp_call_handler(): agent_handler.c, 443: > handler:returned: handler:returned: handler bulk_to_next returned 0 > handler bulk_to_next returned 0 > trace: trace: netsnmp_call_handler(): agent_handler.c, 435: > netsnmp_call_handler(): agent_handler.c, 435: > handler:calling: handler:calling: calling handler serialize for mode > GETNEXT > calling handler serialize for mode GETNEXT > trace: trace: netsnmp_serialize_helper_handler(): serialize.c, 50: > netsnmp_serialize_helper_handler(): serialize.c, 50: > helper:serialize: helper:serialize: Got request > Got request > trace: trace: netsnmp_call_handler(): agent_handler.c, 435: > netsnmp_call_handler(): agent_handler.c, 435: > handler:calling: handler:calling: calling handler scalar_group for mode > GETNEXT > calling handler scalar_group for mode GETNEXT > trace: trace: netsnmp_scalar_group_helper_handler(): scalar_group.c, 69: > netsnmp_scalar_group_helper_handler(): scalar_group.c, 69: > helper:scalar_group: helper:scalar_group: Got request: > Got request: > trace: trace: netsnmp_scalar_group_helper_handler(): scalar_group.c, 75: > netsnmp_scalar_group_helper_handler(): scalar_group.c, 75: > helper:scalar_group: cmp=0, oid:IP-MIB::ipAdEntAddrhelper:scalar_group: > cmp=0, oid:IP-MIB::ipAdEntAddr > > trace: trace: netsnmp_call_handler(): agent_handler.c, 435: > netsnmp_call_handler(): agent_handler.c, 435: > handler:calling: handler:calling: calling handler instance for mode GETNEXT > calling handler instance for mode GETNEXT > trace: trace: netsnmp_instance_helper_handler(): instance.c, 996: > netsnmp_instance_helper_handler(): instance.c, 996: > helper:instance: helper:instance: Got request: > Got request: > trace: trace: netsnmp_instance_helper_handler(): instance.c, 1001: > netsnmp_instance_helper_handler(): instance.c, 1001: > helper:instance: oid:IP-MIB::ipAdEntAddrhelper:instance: > oid:IP-MIB::ipAdEntAddr > > trace: trace: netsnmp_call_handler(): agent_handler.c, 435: > netsnmp_call_handler(): agent_handler.c, 435: > handler:calling: handler:calling: calling handler ip for mode GET > calling handler ip for mode GET > trace: trace: ip_load(): mibII/ip.c, 849: > ip_load(): mibII/ip.c, 849: > mibII/ip: mibII/ip: Loaded IP Group (AIX) > Loaded IP Group (AIX) > trace: trace: ip_handler(): mibII/ip.c, 290: > ip_handler(): mibII/ip.c, 290: > mibII/ip: mibII/ip: Handler - mode GET > Handler - mode GET > trace: trace: ip_handler(): mibII/ip.c, 296: > ip_handler(): mibII/ip.c, 296: > mibII/ip: oid: RFC1213-MIB::ipRouteTable.0mibII/ip: oid: > RFC1213-MIB::ipRouteTable.0 > > trace: trace: netsnmp_call_handler(): agent_handler.c, 443: > netsnmp_call_handler(): agent_handler.c, 443: > handler:returned: handler:returned: handler ip returned 0 > handler ip returned 0 > trace: trace: netsnmp_call_handler(): agent_handler.c, 443: > netsnmp_call_handler(): agent_handler.c, 443: > handler:returned: handler:returned: handler instance returned 0 > handler instance returned 0 > trace: trace: netsnmp_call_handler(): agent_handler.c, 443: > netsnmp_call_handler(): agent_handler.c, 443: > handler:returned: handler:returned: handler scalar_group returned 0 > handler scalar_group returned 0 > trace: trace: netsnmp_call_handler(): agent_handler.c, 443: > netsnmp_call_handler(): agent_handler.c, 443: > handler:returned: handler:returned: handler serialize returned 0 > handler serialize returned 0 > trace: trace: check_getnext_results(): snmp_agent.c, 2947: > check_getnext_results(): snmp_agent.c, 2947: > check_getnext_results: check_getnext_results: request response 1 out of > range > request response 1 out of range > trace: trace: handle_getnext_loop(): snmp_agent.c, 3041: > handle_getnext_loop(): snmp_agent.c, 3041: > results: results: getnext results, before next pass: > getnext results, before next pass: > trace: trace: handle_getnext_loop(): snmp_agent.c, 3044: > handle_getnext_loop(): snmp_agent.c, 3044: > results: trace: results: trace: sprint_realloc_by_type(): > mib.c, 1961: > sprint_realloc_by_type(): mib.c, 1961: > output: output: sprint_by_type, type 5 > sprint_by_type, type 5 > RFC1213-MIB::ipRouteDest = Wrong Type (should be IpAddress): > NULLRFC1213-MIB::ipRouteDest = Wrong Type (should be IpAddress): NULL > > trace: trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 1947: > netsnmp_add_varbind_to_cache(): snmp_agent.c, 1947: > snmp_agent: add_vb_to_cache(2012f808, 1, > RFC1213-MIB::ipRouteDestsnmp_agent: > add_vb_to_cache(2012f808, 1, RFC1213-MIB::ipRouteDest, 2001c0c8) > , 2001c0c8) > trace: trace: _callback_lock(): callback.c, 130: > _callback_lock(): callback.c, 130: > 9:callback:lock: 9:callback:lock: locked (APP,null) > locked (APP,null) > trace: trace: snmp_call_callbacks(): callback.c, 322: > snmp_call_callbacks(): callback.c, 322: > callback: callback: START calling callbacks for maj=1 min=12 > START calling callbacks for maj=1 min=12 > trace: trace: snmp_call_callbacks(): callback.c, 336: > snmp_call_callbacks(): callback.c, 336: > callback: callback: calling a callback for maj=1 min=12 > calling a callback for maj=1 min=12 > trace: trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1290: > vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1290: > mibII/vacm_vars: mibII/vacm_vars: vacm_in_view: ver=0, community=public > vacm_in_view: ver=0, community=public > trace: trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 1182: > netsnmp_udp_getSecName(): snmpUDPDomain.c, 1182: > netsnmp_udp_getSecName: netsnmp_udp_getSecName: opaque = 2012cbb8 (len = > 20), sizeof = 20, family = 2 (2) > opaque = 2012cbb8 (len = 20), sizeof = 20, family = 2 (2) > trace: trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 1199: > netsnmp_udp_getSecName(): snmpUDPDomain.c, 1199: > netsnmp_udp_getSecName: netsnmp_udp_getSecName: resolve <"public", > 0x7f000001> > resolve <"public", 0x7f000001> > trace: trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 1204: > netsnmp_udp_getSecName(): snmpUDPDomain.c, 1204: > netsnmp_udp_getSecName: compare <"public", > 0x00000000/0x00000000>netsnmp_udp_getSecName: compare <"public", > 0x00000000/0x00000000>... SUCCESS > ... SUCCESS > trace: trace: netsnmp_subtree_find_first(): agent_registry.c, 288: > netsnmp_subtree_find_first(): agent_registry.c, 288: > subtree: subtree: looking for subtree for context: "" > looking for subtree for context: "" > trace: trace: netsnmp_subtree_find_first(): agent_registry.c, 292: > netsnmp_subtree_find_first(): agent_registry.c, 292: > subtree: subtree: found one for: "" > found one for: "" > trace: trace: vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1418: > vacm_check_view_contents(): mibgroup/mibII/vacm_conf.c, 1418: > mibII/vacm_vars: vacm_in_view: sn=notConfigUser, gn=notConfigGroup, > vn=roviewmibII/vacm_vars: vacm_in_view: sn=notConfigUser, > gn=notConfigGroup, > vn=roview > > trace: trace: netsnmp_view_subtree_check(): vacm.c, 532: > netsnmp_view_subtree_check(): vacm.c, 532: > 9:vacm:checkSubtree: 9:vacm:checkSubtree: view roview > view roview > trace: trace: netsnmp_view_subtree_check(): vacm.c, 569: > netsnmp_view_subtree_check(): vacm.c, 569: > 9:vacm:checkSubtree: 9:vacm:checkSubtree: roview matched? > roview matched? > trace: trace: netsnmp_view_subtree_check(): vacm.c, 630: > netsnmp_view_subtree_check(): vacm.c, 630: > 9:vacm:checkSubtree: 9:vacm:checkSubtree: roview matched > roview matched > trace: trace: netsnmp_view_subtree_check(): vacm.c, 653: > netsnmp_view_subtree_check(): vacm.c, 653: > vacm:checkSubtree: vacm:checkSubtree: , included > , included > trace: trace: snmp_call_callbacks(): callback.c, 348: > snmp_call_callbacks(): callback.c, 348: > callback: callback: END calling callbacks for maj=1 min=12 (1 called) > END calling callbacks for maj=1 min=12 (1 called) > trace: trace: _callback_unlock(): callback.c, 164: > _callback_unlock(): callback.c, 164: > 9:callback:lock: 9:callback:lock: unlocked (APP,null) > unlocked (APP,null) > trace: trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 2018: > netsnmp_add_varbind_to_cache(): snmp_agent.c, 2018: > snmp_agent: tp->start RFC1213-MIB::ipRouteDest, tp->end > RFC1213-MIB::ipRouteIfIndexsnmp_agent: tp->start RFC1213-MIB::ipRouteDest, > tp->end RFC1213-MIB::ipRouteIfIndex, > , > trace: trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 2038: > netsnmp_add_varbind_to_cache(): snmp_agent.c, 2038: > verbose:asp: verbose:asp: asp 2012f808 reqinfo 2012d278 assigned to request > asp 2012f808 reqinfo 2012d278 assigned to request > trace: trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 2045: > netsnmp_add_varbind_to_cache(): snmp_agent.c, 2045: > verbose:asp: verbose:asp: asp 2012f808 reqinfo 2012d278 assigned to request > asp 2012f808 reqinfo 2012d278 assigned to request > trace: trace: netsnmp_call_handlers(): agent_handler.c, 515: > netsnmp_call_handlers(): agent_handler.c, 515: > handler:calling: handler:calling: main handler bulk_to_next > main handler bulk_to_next > trace: trace: netsnmp_call_handler(): agent_handler.c, 435: > netsnmp_call_handler(): agent_handler.c, 435: > handler:calling: handler:calling: calling handler bulk_to_next for mode > GETNEXT > calling handler bulk_to_next for mode GETNEXT > trace: trace: netsnmp_call_handler(): agent_handler.c, 443: > netsnmp_call_handler(): agent_handler.c, 443: > handler:returned: handler:returned: handler bulk_to_next returned 0 > handler bulk_to_next returned 0 > trace: trace: netsnmp_call_handler(): agent_handler.c, 435: > netsnmp_call_handler(): agent_handler.c, 435: > handler:calling: handler:calling: calling handler old_api for mode GETNEXT > calling handler old_api for mode GETNEXT > trace: trace: klookup(): kernel.c, 196: > klookup(): kernel.c, 196: > verbose:kernel:klookup: klookup(2fc3770, 2ff1bdf4, 124) > succeededklookup(f1000600, 2ff1bd80, 116): verbose:kernel:klookup: > klookup(2fc3770, 2ff1bdf4, 124) succeededklookup(f1000600, 2ff1bd80, 116): > klread: No such device or address > klread: No such device or address > trace: trace: klookup(): kernel.c, 196: > klookup(): kernel.c, 196: > verbose:kernel:klookup: klookup(cf5a00, 2ff1bd80, 116) succeededtrace: > verbose:kernel:klookup: klookup(cf5a00, 2ff1bd80, 116) succeededtrace: > klookup(): kernel.c, 196: > klookup(): kernel.c, 196: > verbose:kernel:klookup: klookup(0, 2ff1bb08, 24) succeededtrace: > verbose:kernel:klookup: klookup(0, 2ff1bb08, 24) succeededtrace: klookup(): > kernel.c, 196: > klookup(): kernel.c, 196: > verbose:kernel:klookup: klookup(0, 2ff1b878, 24) succeededtrace: > verbose:kernel:klookup: klookup(0, 2ff1b878, 24) succeededtrace: klookup(): > kernel.c, 196: > klookup(): kernel.c, 196: > > ... > > verbose:kernel:klookup: klookup(0, 2df24818, 24) succeededtrace: > verbose:kernel:klookup: klookup(0, 2df24818, 24) succeededtrace: klookup(): > kernel.c, 196: > klookup(): kernel.c, 196: > verbose:kernel:klookup: klookup(0, 2df24588, 24) succeededtrace: > verbose:kernel:klookup: klookup(0, 2df24588, 24) succeededtrace: klookup(): > kernel.c, 196: > klookup(): kernel.c, 196: > verbose:kernel:klookup: klookup(0, 2df242f8, 24) succeeded > > > ------- segfaults here ---------- > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 36 > Date: Mon, 11 Jan 2010 11:11:03 -0800 > From: Stuart Kendrick <[email protected]> > Subject: SNMP.pm / specifying MIB module as well as the leaf > identifier > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Is it possible to hand the MIB module plus the leaf identifier to the Perl > 'get' > method? > > > This works: > $oid = 'ifDescr'; > $val = $session->get($oid}; > > This does not: > $oid = 'IF-MIB::ifDescr'; > $val = $session->get($oid}; > > failing with the following error: > > error: get: unknown object ID (IF-MIB) at > /usr/local/lib/perl5/site_perl/5.10.1/ > x86_64-linux-thread-multi/SNMP.pm line 663. > > > I would like to do this because one of the enterprise MIB modules I load > (Broadcom) ... defines ifDescr (and ifName). > > I tried setting 'UseLongNames' to 1 ... didn't help ... I'm guessing that > this > affects output rather than input. > > net-snmp-5.5 > perl-5.10.1 > > --sk > > Stuart Kendrick > FHCRC > > Longer snippet of code below: > > > # Define SNMP session > $session = new SNMP::Session ( Community => $read, > DestHost => $host, > RemotePort => $port, > Retries => $retries, > UseSprintValue => $translate, > UseLongNames => $long_names, > Timeout => $timeout, > Version => $version > ); > unless (defined $session) { > print_it("Cannot build SNMP object for $host"); > return; > } > > # Perform the get > $val = $session->get($oid); > $error = $session->{ErrorStr}; > undef $error if $error eq $EMPTY_STR; > > > > ------------------------------ > > Message: 37 > Date: Mon, 11 Jan 2010 14:27:46 -0500 > From: Fulko Hew <[email protected]> > Subject: Re: snmpd seg faults on AIX > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="koi8-r" > > On Mon, Jan 11, 2010 at 1:37 PM, Fulko Hew <[email protected]> wrote: > > > On Mon, Jan 11, 2010 at 11:48 AM, Fulko Hew <[email protected]> wrote: > > > >> On Mon, Jan 11, 2010 at 11:30 AM, Dave Shield < > [email protected] > >> > wrote: > >> > >>> 2010/1/11 Fulko Hew <[email protected]>: > >>> > >> > > ... snip ... > > > > So the problem is in the handling of ipAddrTable and ipRouteTable... > > > > now what? > > > > > > > >> I'll look at that part of the code while I wait for feedback > > > > but I'm afraid I'm out of my expertise in Net-SNMP source code > >> and/or AIX kernel structures. :-( > >> > > > > For what its worth, here is the debug trace of what I think is the > relevant > > portion, > > (when I did a getnext(ipAddrTable), but I don't know where to look next, > or > > go from here. > > > > And here is a gdb backtrace (once I got gdb onto the system) to go along > with the previous dump. > > gdb) backtrace > #0 0xd0387af0 in write () from /usr/lib/libc.a(shr.o) > #1 0xd037eba8 in _xwrite () from /usr/lib/libc.a(shr.o) > #2 0xd037d82c in fwrite_unlocked () from /usr/lib/libc.a(shr.o) > #3 0xd037dab0 in fwrite_5_4 () from /usr/lib/libc.a(shr.o) > #4 0xd0377764 in _doprnt () from /usr/lib/libc.a(shr.o) > #5 0xd0375594 in fprintf () from /usr/lib/libc.a(shr.o) > #6 0xd0a7370c in log_handler_stdouterr (logh=0x20009948, pri=770849484, > str=0x2df23acc "trac\e: ") at snmp_logging.c:986 > #7 0xd0a73d10 in snmp_log_string (priority=7, str=0x2df23acc "trac\e: ") > at > snmp_logging.c:1171 > #8 0xd0a73e70 in snmp_vlog (priority=7, format=0xd0aed0cc "%s: ", > ap=0x2df23f80 "?<") at snmp_logging.c:1237 > #9 0xd0a71800 in debugmsg (token=0x2 "", format=0xd0aed0cc "%s: ") at > snmp_debug.c:257 > #10 0xd0a71864 in debugmsgtoken (token=0x2 "", format=0x2df23acc "trac\e: > ") > at snmp_debug.c:439 > #11 0xd0a54930 in klookup (off=3500555288, target=0x2df24068 "", siz=24) at > kernel.c:196 > #12 0xd09a9de8 in load_rtentries (pt=0x0) at mibII/var_route.c:885 > > ... lots of redundant duplicates omitted ... > > #51108 0xd09a9e08 in load_rtentries (pt=0x0) at mibII/var_route.c:890 > #51109 0xd09a9e08 in load_rtentries (pt=0x0) at mibII/var_route.c:890 > #51110 0xd09a9e08 in load_rtentries (pt=0x0) at mibII/var_route.c:890 > #51111 0xd09aa2f4 in Route_Scan_Reload () at mibII/var_route.c:1077 > #51112 0xd09aa454 in var_ipRouteEntry (vp=0x2ff1c4f4, name=0x2ff1c2f4, > length=0x2ff1c0f0, > exact=0, > var_len=0x2ff1c0ec, > write_method=0x653a2000) at mibII/var_route.c:498 > #51113 0xd0ca09dc in netsnmp_old_api_helper (handler=0x2, > reginfo=0x2001bfd8, > reqinfo=0x2012d278, requests=0x2012fa68) at old_api.c:291 > #51114 0xd0a32ec8 in netsnmp_call_handlers (reginfo=0x2001bfd8, > reqinfo=0x2012d278, requests=0x2012fa68) at agent_handler.c:440 > #51115 0xd0a38964 in handle_var_requests (asp=0x2012f808) at > snmp_agent.c:2611 > #51116 0xd0a39f74 in handle_getnext_loop (asp=0x2012f808) at > snmp_agent.c:3051 > #51117 0xd0a3d2ec in netsnmp_handle_request (asp=0x2012f808, status=0) at > snmp_agent.c:3203 > #51118 0xd0a3d7dc in handle_snmp_packet (op=2, session=0x2df23acc,reqid=7, > pdu=0x2012f808, magic=0x2) at snmp_agent.c:1929 > #51119 0xd0aaa340 in _sess_process_packet (sessp=0x2012c788, sp=0x201394c8, > isp=0x2012c958, transport=0xd0af30e0, opaque=0x1, > olength=538132936, > packetptr=0x20158fd8 "0(\002\001", length=42) at snmp_api.c:5604 > #51120 0xd0aab9a4 in _sess_read (sessp=0x2012c788, fdset=0x2ff1cb98) at > snmp_api.c:6043 > #51121 0xd0aac3cc in snmp_sess_read2 (sessp=0x2012c788, > fdset=0x2df23acc) at snmp_api.c:6075 > #51122 0xd0aac520 in snmp_read2 (fdset=0xd0a71800) at snmp_api.c:5667 > #51123 0x100023e4 in main (argc=-264803712, argv=0x20001b98) at > snmpd.c:1221 > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 38 > Date: Mon, 11 Jan 2010 16:37:53 -0500 > From: Fulko Hew <[email protected]> > Subject: Re: snmpd seg faults on AIX > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > 2010/1/11 Fulko Hew <[email protected]> > > > On Mon, Jan 11, 2010 at 1:37 PM, Fulko Hew <[email protected]> wrote: > > > >> On Mon, Jan 11, 2010 at 11:48 AM, Fulko Hew <[email protected]> > wrote: > >> > >>> On Mon, Jan 11, 2010 at 11:30 AM, Dave Shield < > >>> [email protected]> wrote: > >>> > >>>> 2010/1/11 Fulko Hew <[email protected]>: > >>>> > >>> > >> ... snip ... > >> > >> So the problem is in the handling of ipAddrTable and ipRouteTable... > >> > >> now what? > >> > >> > >> > >>> I'll look at that part of the code while I wait for feedback > >> > >> but I'm afraid I'm out of my expertise in Net-SNMP source code > >>> and/or AIX kernel structures. :-( > >>> > >> > >> For what its worth, here is the debug trace of what I think is the > >> relevant portion, > >> (when I did a getnext(ipAddrTable), but I don't know where to look next, > >> or go from here. > >> > > > > And here is a gdb backtrace (once I got gdb onto the system) to go along > > with the previous dump. > > > > Upon further searching the mailinst archives, I find that this is an old > (open) bug #1484814 > that fortunately has a workaround. (./configure --without-kmem-usage) > > That bug mentioned 'nlist', and I remembered seeing that warning message > when the > daemon powered up: > > "nlist err: neither proc nor _proc found." > > In the end... that bug entry should probably (at the very least) be closed > with with > the suggested workaround. > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 39 > Date: Mon, 11 Jan 2010 13:40:18 -0800 (PST) > From: <[email protected]> > Subject: Re: Changing the agent-address for SNMP v1 pdus > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > I've been looking into the idea of reissuing traps that are being received > by snmptrapd using snmptrap and I'm seeing a couple of issues: > > 1) the traphandle directive passes arguments as an (OID, value) pair but > snmptrap expects an (OID, type, value) triplet. If I want to reissue the > trap, how do I get the datatype to pas to snmptrap? > 2) Is there a way I can distinguish between version 1 and version 2 traps > through the arguments passed to the traphandle program? The manpage for > snmptrapd.conf seems to claim that for SNMPv1 traps, the final OID will be > SNMPv2-MIB::snmpTrapEnterprise.0. But from my limited testing so far > that's not what I'm seeing. I'm seeing the following as the final two OIDs > for SNMP v1 traps: SNMP-COMMUNITY-MIB::snmpTrapAddress.0 and > SNMP-COMMUNITY-MIB::snmpTrapCommunity.0. I'm not sure if I can rely on > those two always being the final OIDs for a version 1 trap though. > > Any other ideas on how I can accomplish reissuing of snmp traps with just > the agent-addr field changed for version 1 traps would be helpful. > > > Thanks, > Felix > > > ________________________________ > From: Nayman Felix-QA5535 <[email protected]> > To: [email protected] > Sent: Fri, January 8, 2010 11:37:15 AM > Subject: Changing the agent-address for SNMP v1 pdus > > > We are using Net-SNMP 5.3.0.1 and I have setup a "gateway" to run snmptrapd > and forward all traps it receives from internal entities to an external > managing > entity. Everything is working fine except that for SNMP Version 1 traps, > the > source/host address is displaying as an internal address (it appears to be > using > the agent-addr field from the SNMP v1 pdu) and not the external address of > the > "gateway" that initiates the fowarding. For SNMP Version 2 traps/informs, > there > is no agent-addr field since the pdu has been modified and the traps are > being > displayed correctly using the external address of the gateway presumably > being > retrieved from the source field of the IP header. > > So I'm wondering how > can I have snmptrapd modify the agent-addr field for SNMP Version 1 traps > before > they get forwarded? I noticed that snmptrapd supports the ability to > execute a > program when it receives a trap using the traphandle directive. From the > best I > can gather, I would have to capture all traps and reissue them with the > correct > agent address for SNMP version 1 traps (I haven't tried this yet, but I'm > about > to run some tests)? Is there a better way to accomplish the same thing? Is > there > a way to just modify the agent-addr field for SNMP version 1 > traps? > > Thanks, > Felix > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 40 > Date: Mon, 11 Jan 2010 22:54:35 +0100 > From: Thomas Anders <[email protected]> > Subject: Re: snmpd seg faults on AIX > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Fulko Hew wrote: > > Upon further searching the mailinst archives, I find that this is an old > > (open) bug #1484814 > > that fortunately has a workaround. (./configure --without-kmem-usage) > > [...] > > In the end... that bug entry should probably (at the very least) be > > closed with with the suggested workaround. > > FWIW, this problem is documented in README.aix shipping with the source. > > http://www.net-snmp.org/docs/README.aix.html > > > +Thomas > > > > ------------------------------ > > Message: 41 > Date: Mon, 11 Jan 2010 23:36:19 +0100 > From: Thomas Anders <[email protected]> > Subject: Re: snmptrap (win32) tcp > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > C Wells wrote: > > I don't see a tcp option for snmptrap.exe so I assume it isn't there. > > Does anyone know of a win32 snmptrap sending utility that can send using > > TCP ? > > Try: snmptrap.exe ... tcp:desthost:162 ... > > (with "desthost" being the trap destination host) > > In case it doesn't work: what exact version (and build options) or binary > package do you use? What error(s) do you get? > > > +Thomas > > > > ------------------------------ > > Message: 42 > Date: Mon, 11 Jan 2010 15:27:11 -0800 > From: Stuart Kendrick <[email protected]> > Subject: munging Perl's stack > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Wes, hi Tom, > > Any insights into this issue? > > > http://archives.devshed.com/forums/networking-100/munging-perl-s-stack-use-of-freed-vlaue-in-iteration-1378806.html > > I've replicated it under net-snmp-5.5 and perl-5.10.1, so I guess I can > predict > your answer "Ick, gross, run away". :) Or, less melodramatically, > "Unresolved". But I figured I'd ask! > > --sk > > > > ------------------------------ > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > > ------------------------------ > > _______________________________________________ > Net-snmp-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/net-snmp-users > > > End of Net-snmp-users Digest, Vol 44, Issue 4 > ********************************************* > ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ 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