You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(26) |
Nov
(262) |
Dec
(286) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(416) |
Feb
(420) |
Mar
(638) |
Apr
(722) |
May
(478) |
Jun
(697) |
Jul
(559) |
Aug
(502) |
Sep
(482) |
Oct
(992) |
Nov
(452) |
Dec
(415) |
2002 |
Jan
(465) |
Feb
(593) |
Mar
(472) |
Apr
(696) |
May
(715) |
Jun
(544) |
Jul
(428) |
Aug
(552) |
Sep
(418) |
Oct
(429) |
Nov
(327) |
Dec
(255) |
2003 |
Jan
(531) |
Feb
(380) |
Mar
(394) |
Apr
(408) |
May
(541) |
Jun
(483) |
Jul
(310) |
Aug
(329) |
Sep
(275) |
Oct
(360) |
Nov
(351) |
Dec
(300) |
2004 |
Jan
(334) |
Feb
(468) |
Mar
(433) |
Apr
(433) |
May
(448) |
Jun
(472) |
Jul
(456) |
Aug
(565) |
Sep
(536) |
Oct
(567) |
Nov
(451) |
Dec
(435) |
2005 |
Jan
(296) |
Feb
(373) |
Mar
(335) |
Apr
(663) |
May
(456) |
Jun
(537) |
Jul
(268) |
Aug
(364) |
Sep
(284) |
Oct
(395) |
Nov
(387) |
Dec
(391) |
2006 |
Jan
(464) |
Feb
(465) |
Mar
(556) |
Apr
(242) |
May
(202) |
Jun
(158) |
Jul
(314) |
Aug
(397) |
Sep
(379) |
Oct
(456) |
Nov
(381) |
Dec
(308) |
2007 |
Jan
(380) |
Feb
(438) |
Mar
(337) |
Apr
(344) |
May
(379) |
Jun
(316) |
Jul
(392) |
Aug
(287) |
Sep
(301) |
Oct
(413) |
Nov
(265) |
Dec
(325) |
2008 |
Jan
(468) |
Feb
(500) |
Mar
(367) |
Apr
(547) |
May
(316) |
Jun
(289) |
Jul
(383) |
Aug
(167) |
Sep
(190) |
Oct
(162) |
Nov
(152) |
Dec
(236) |
2009 |
Jan
(371) |
Feb
(384) |
Mar
(370) |
Apr
(368) |
May
(347) |
Jun
(319) |
Jul
(235) |
Aug
(354) |
Sep
(211) |
Oct
(155) |
Nov
(235) |
Dec
(227) |
2010 |
Jan
(326) |
Feb
(250) |
Mar
(336) |
Apr
(318) |
May
(269) |
Jun
(281) |
Jul
(324) |
Aug
(257) |
Sep
(299) |
Oct
(181) |
Nov
(182) |
Dec
(148) |
2011 |
Jan
(176) |
Feb
(240) |
Mar
(351) |
Apr
(177) |
May
(100) |
Jun
(131) |
Jul
(168) |
Aug
(228) |
Sep
(122) |
Oct
(115) |
Nov
(116) |
Dec
(88) |
2012 |
Jan
(127) |
Feb
(108) |
Mar
(117) |
Apr
(149) |
May
(166) |
Jun
(135) |
Jul
(205) |
Aug
(112) |
Sep
(63) |
Oct
(142) |
Nov
(67) |
Dec
(69) |
2013 |
Jan
(140) |
Feb
(62) |
Mar
(56) |
Apr
(38) |
May
(35) |
Jun
(30) |
Jul
(57) |
Aug
(35) |
Sep
(24) |
Oct
(32) |
Nov
(59) |
Dec
(41) |
2014 |
Jan
(47) |
Feb
(37) |
Mar
(46) |
Apr
(51) |
May
(36) |
Jun
(31) |
Jul
(49) |
Aug
(50) |
Sep
(38) |
Oct
(67) |
Nov
(47) |
Dec
(55) |
2015 |
Jan
(38) |
Feb
(47) |
Mar
(20) |
Apr
(30) |
May
(19) |
Jun
(27) |
Jul
(80) |
Aug
(48) |
Sep
(27) |
Oct
(23) |
Nov
(42) |
Dec
(32) |
2016 |
Jan
(34) |
Feb
(15) |
Mar
(46) |
Apr
(44) |
May
(49) |
Jun
(22) |
Jul
(36) |
Aug
(24) |
Sep
(6) |
Oct
(14) |
Nov
(13) |
Dec
(13) |
2017 |
Jan
(22) |
Feb
(19) |
Mar
(10) |
Apr
(9) |
May
(30) |
Jun
(48) |
Jul
(20) |
Aug
(21) |
Sep
(17) |
Oct
(11) |
Nov
(22) |
Dec
(16) |
2018 |
Jan
(25) |
Feb
(3) |
Mar
(19) |
Apr
(22) |
May
(20) |
Jun
(5) |
Jul
(17) |
Aug
(33) |
Sep
(9) |
Oct
(27) |
Nov
(9) |
Dec
(7) |
2019 |
Jan
(18) |
Feb
(23) |
Mar
(12) |
Apr
(22) |
May
(29) |
Jun
(23) |
Jul
(17) |
Aug
(15) |
Sep
(28) |
Oct
(12) |
Nov
(26) |
Dec
(22) |
2020 |
Jan
(7) |
Feb
(3) |
Mar
(12) |
Apr
(16) |
May
(24) |
Jun
(20) |
Jul
(43) |
Aug
(10) |
Sep
(5) |
Oct
(10) |
Nov
(6) |
Dec
(20) |
2021 |
Jan
(21) |
Feb
(10) |
Mar
(20) |
Apr
(17) |
May
(31) |
Jun
(16) |
Jul
(21) |
Aug
(5) |
Sep
(15) |
Oct
(13) |
Nov
(3) |
Dec
(10) |
2022 |
Jan
(10) |
Feb
(16) |
Mar
(14) |
Apr
(5) |
May
(8) |
Jun
(8) |
Jul
(12) |
Aug
(23) |
Sep
(4) |
Oct
(3) |
Nov
(5) |
Dec
|
2023 |
Jan
(3) |
Feb
(2) |
Mar
(1) |
Apr
(3) |
May
(3) |
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
(3) |
2024 |
Jan
(4) |
Feb
(3) |
Mar
(5) |
Apr
(4) |
May
(3) |
Jun
(4) |
Jul
(11) |
Aug
(5) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: John N. <jb...@ca...> - 2001-03-15 14:55:58
|
Dave> Remember that the agent will potentially be amending the table Dave> dynamically, and the various Notification Generator applications Dave> ought (ideally) to take account of these changes automatically. John> I'm confused by this. Why should two separate Notification John> Originator applications automatically share a set of notification John> targets? Dave> Errr... isn't that the point of the snmpNotifyTable et al? Dave> Given that typically, the main agent will be the only thing listening Dave> for SNMP requests, and hence the only thing that would be told about Dave> changes to notification receivers, then it would seem useful to allow Dave> other notification originator applications to find out about these Dave> changes in some way. Oh, I see what you mean. I was kind of taking the view that the agent (or its subagents) will typically be the principal notification originator. Or to look at it another way, if a notification originator is to have a remotely-configurable set of targets, then it should also be a command responder and implement TARGET-MIB and NOTIFY-MIB. Something like snmptrap doesn't really fit into this category, it's true. An snmptrap-like application that would send a notification to a set of targets as maintained by <something> would be a nice tool. Perhaps it could just parse (using a libnotify function maybe) the targetAddr etc. directives of an agent's .conf file? Then arrange that that gets re-written whenever it changes (which ought to be the case anyway really for true persistence, surely) and voila. Well, that would be one way to do it (beats shared memory, anyway: ugh). This is quite funny actually -- it's a good example of our differing biases; I would say that I tend to be quite agent-centric, whereas you are usually far more library-centric. John -- // Dr. John Naylon // Senior Software Engineer // Cambridge Broadband Ltd. // The future of broadband wireless access // www.cambridgebroadband.com |
From: Gavin W. <gp...@te...> - 2001-03-15 12:48:04
|
whoops, sorry - in the snmptrap command, 'hello world' won't work, but 'hello_world' will. -----Original Message----- From: Gavin White [SMTP:gp...@te...] Sent: 15 March 2001 12:26 To: 'gemma Ac'; SNMP Users Subject: RE: Begining help Hi, I was in this state a while ago, and I eventually did this: (NB. this is just what I did, it's quite fudged, it's not the best way to do it, and doesn't utilise a hundredth of the system's capabilities, but it's somewhere to start) 1. Get the latest release of ucd-net-snmp from http://sourceforge.net/project/showfiles.php?group_id=12694 2. Install according to your platform. eg. for most unices, get the ucd-snmp-x.x.tar.gz source file and do gunzip ucd-snmp-x.x.tar.gz; tar xvf ucd-snmp-x.x.tar; cd ucd-snmp-x.x ./configure '--with-mib-modules=host' make go superuser and do make install 3. start the snmpd demon /usr/local/sbin/snmpd (as root) 4. Query the snmpd demon snmpwalk <hostname> public 5. You can take lines from the output of snmpwalk and use them in snmpget, eg. snmpget <hostname> public sysUpTime.0 6. You can use shell scripts or the command line to send traps eg. snmptrap -v 1 <sender_hostname> public system <receiver_hostname> 6 0 '' system.sysContact s hello world - this will send a v1 trap saying 'hello world' (Fudge!) 7. To receive the trap as root, do /usr/local/sbin/snmptrapd -P Gavin -----Original Message----- From: gemma Ac [SMTP:ge...@ac...] Sent: 15 March 2001 10:26 To: SNMP Users Subject: Begining help Hello, I am starting off with snmp. I heard about this wonderful implementation and I began studing this tools. I have read many things from the web page but I am a little desperate because I want to work this net-snmp but I am very lost. Could somebody help me and say me: where can I find the programs to work with? what must I do with then to start working? what can I do with this tools? Please, help me. Somebody form Spain is listen to me? << File: ATT00005.htm >> _______________________________________________ Net-snmp-users mailing list Net...@li... http://lists.sourceforge.net/lists/listinfo/net-snmp-users |
From: Gavin W. <gp...@te...> - 2001-03-15 12:27:43
|
Hi, I was in this state a while ago, and I eventually did this: (NB. this is just what I did, it's quite fudged, it's not the best way to do it, and doesn't utilise a hundredth of the system's capabilities, but it's somewhere to start) 1. Get the latest release of ucd-net-snmp from http://sourceforge.net/project/showfiles.php?group_id=12694 2. Install according to your platform. eg. for most unices, get the ucd-snmp-x.x.tar.gz source file and do gunzip ucd-snmp-x.x.tar.gz; tar xvf ucd-snmp-x.x.tar; cd ucd-snmp-x.x ./configure '--with-mib-modules=host' make go superuser and do make install 3. start the snmpd demon /usr/local/sbin/snmpd (as root) 4. Query the snmpd demon snmpwalk <hostname> public 5. You can take lines from the output of snmpwalk and use them in snmpget, eg. snmpget <hostname> public sysUpTime.0 6. You can use shell scripts or the command line to send traps eg. snmptrap -v 1 <sender_hostname> public system <receiver_hostname> 6 0 '' system.sysContact s hello world - this will send a v1 trap saying 'hello world' (Fudge!) 7. To receive the trap as root, do /usr/local/sbin/snmptrapd -P Gavin -----Original Message----- From: gemma Ac [SMTP:ge...@ac...] Sent: 15 March 2001 10:26 To: SNMP Users Subject: Begining help Hello, I am starting off with snmp. I heard about this wonderful implementation and I began studing this tools. I have read many things from the web page but I am a little desperate because I want to work this net-snmp but I am very lost. Could somebody help me and say me: where can I find the programs to work with? what must I do with then to start working? what can I do with this tools? Please, help me. Somebody form Spain is listen to me? << File: ATT00005.htm >> |
From: Dave S. <D.T...@cs...> - 2001-03-15 12:00:55
|
Oops ... 's/Notification Generator/Notification Originator/' Dave> Remember that the agent will potentially be amending the table Dave> dynamically, and the various Notification Generator applications Dave> ought (ideally) to take account of these changes automatically. John> I'm confused by this. Why should two separate Notification Originator John> applications automatically share a set of notification targets? Errr... isn't that the point of the snmpNotifyTable et al? Given that typically, the main agent will be the only thing listening for SNMP requests, and hence the only thing that would be told about changes to notification receivers, then it would seem useful to allow other notification originator applications to find out about these changes in some way. > I can see > that you *might* want to do this for some reason, but equally I can see > cases where you would certainly want separate sets. Yes - that's a better way of phrasing it. I certainly wouldn't want to *force* this. (I've argued enough in the past about giving application writers the flexibility they need - so that applies equally well here). > And in the case where > you do want to share, I think it's up to the two applications to sort it out > amongst themselves. But I think we should try to enable them to share this information very simply. Ideally, this should be transparent (for those that wish to make use of this feature). Dave |
From: John N. <jb...@ca...> - 2001-03-15 11:17:27
|
Dave> Remember that the agent will potentially be amending the table Dave> dynamically, and the various Notification Generator applications Dave> ought (ideally) to take account of these changes automatically. I'm confused by this. Why should two separate Notification Originator applications automatically share a set of notification targets? I can see that you *might* want to do this for some reason, but equally I can see cases where you would certainly want separate sets. And in the case where you do want to share, I think it's up to the two applications to sort it out amongst themselves. John -- // Dr. John Naylon // Senior Software Engineer // Cambridge Broadband Ltd. // The future of broadband wireless access // www.cambridgebroadband.com |
From: Dave S. <D.T...@cs...> - 2001-03-15 10:25:37
|
> perl OURMIB.txt 1.3.6.1.3.8080 > Are the parameters and order of them, correct ? I don't think so. Set the name of the MIB file to load via the 'MIBFILES' env var (or the name of the MIB module via 'MIBS' - whichever you prefer), and give the *name* of a node to the mib2c command. Something like: MIBFILES=OURMIB.txt mib2c ourMibObject (where 'ourMibObject' is the object at the top level of the subtree you wish to implement). Dave P.S: *Please* reply to the list, not to me privately. |
From: gemma A. <ge...@ac...> - 2001-03-15 10:25:23
|
I'm sorry very much, my last mail was with format, I will never to it again. Excuse me. Hello, I am starting off with snmp. I heard about this wonderful implementation and I began studing this tools. I have read many things from the web page but I am a little desperate because I want to work this net-snmp but I am very lost. Could somebody help me and say me: where can I find the programs to work with? what must I do with then to start working? what can I do with this tools? Please, help me. Somebody form Spain is listen to me? |
From: gemma A. <ge...@ac...> - 2001-03-15 10:23:28
|
Hello, I am starting off with snmp. I heard about this wonderful = implementation and I began studing this tools. I have read many things = from the web page but I am a little desperate because I want to work = this net-snmp but I am very lost. Could somebody help me and say me: where can I find the programs to work with? what must I do with then to start working? what can I do with this tools? Please, help me. Somebody form Spain is listen to me? |
From: Dave S. <D.T...@cs...> - 2001-03-15 10:05:54
|
[on making snmpNotifyTable useable by external applications] Dave> Wes - it sounds as if this is likely to be worth following up, Dave> as part of the general re-design. Would you agree? Wes> Its a thought, and if we moved the data structures to libsnmp or Wes> actually just to the libagent library then it would be usable by Wes> external applications. I don't think it's quite as simple as that. Remember that the agent will potentially be amending the table dynamically, and the various Notification Generator applications ought (ideally) to take account of these changes automatically. And they won't necessarily be subagents, so won't be asking the agent to send traps on their behalf. Similarly, linking with the full 'libagent' library may not be appropriate. This is one area where I am tempted to split out a separate library 'libnotify' - to be used by all NG-apps. But the fundamental problem we need to address, is how to ensure that all NG applications use the same set of data. Not just the same library and data structure, but the same actual data. Shared memory? Regular synchronisation? Implicit subagents? ..... Dave |
From: Dave S. <D.T...@cs...> - 2001-03-15 09:57:15
|
> The enviroment variables we are setting is the following: > MIBDIR=d:\ucd\mibs; ^^^^^^ MIBDIRS - plural ^ Dave |
From: Wes H. <har...@us...> - 2001-03-14 18:34:59
|
>>>>> On Wed, 14 Mar 2001 10:37:28 +0000, Dave Shield <D.T...@cs...> said: Dave> Wes - it sounds as if this is likely to be worth following up, Dave> as part of the general re-design. Would you agree? Its a thought, and if we moved the data structures to libsnmp or actually just to the libagent library then it would be usable by external applications. -- Wes Hardaker NAI Labs Network Associates |
From: Mauro R. <res...@ce...> - 2001-03-14 16:38:15
|
Hi to all, we are are working on UCD-SNMP project in order to implement one of our MIB. At the moment we are trying to compile, with the MIB2C perl module, ourMIB.txt. When we try to compile the mib, it reply to us as follow: Note that we lunch the mib2c compiler from the follow directory: d:\ucd\local > perl OURMIB.txt 1.3.6.1.3.8080 > Cannot find module (IP-MIB): At line 1 in (none) > Cannot find module (IF-MIB): At line 1 in (none) > Cannot find module (TCP-MIB): At line 1 in (none) > Cannot find module (UDP-MIB): At line 1 in (none) > Cannot find module (SNMPv2-MIB): At line 1 in (none) > Cannot find module (SNMPv2-SMI): At line 1 in (none) > outputting to iso.c and iso.h ... > doing iso : .1 > depth: 0 > Number of Lines Created: > The name specified is not recognized as an > internal or external command, operable program or batch file. > Done. Note that we stored in d:\ucd\mibs all the mibs, with .txt extension .. Have we to modify snmp.pm or it should work as it is ? Are the parameters and order of them, correct ? The enviroment variables we are setting is the following: MIBDIR=d:\ucd\mibs; HOME=d:\ucd\win32\bin; and the visual studio enviroment. Note that we're using the WINNT 4. and perl snmp module 3.1.0. the installation of snmp perl module is ok but the test failed. I thank everyone who can solve our problem or can suggest us the way to solve it. Alessandro and Mauro. ___________________________ CEFRIEL/Politecnico di Milano Network System Area Via fucini,2 20133 Milano - Italy Tel. +39 02 23954248 Fax. +39 02 23954529 |
From: Dave S. <D.T...@cs...> - 2001-03-14 13:19:05
|
> I am setting the value of the env variable PREFIX to > .iso.org.dod.internet, so my agent starts searching for the objects from > this point onwards. I want to know where this value of prefix is stored( > i.e from where I can extract it) in the ucd-snmp code as I want to use it > elsewhere in my application. It's handled in 'snmplib/mib.c' - as the variable 'Prefix' and is used in both 'read_objid()' and '_sprint_objid()' (and hence anything that calls either of these) Note that this is a static variable, so is not directly accessible from routines outside this file. Dave |
From: Dave S. <D.T...@cs...> - 2001-03-14 13:09:29
|
> my oldest distribution is redhat6.2 and it has the same problem. > = > Have you tried it on a newer redhat or SuSE? <tap, tap, tap> Aha! I've now tried this on one of our other Linux systems (RH6.2), and both managed to reproduce the problem, and track down what was causing it. (I have no idea why it wasn't biting RH5.1!) The following patch appears to fix things. Thank you for your patience. Dave |
From: Jyothi V <jyo...@in...> - 2001-03-14 12:31:18
|
Hi, I am setting the value of the env variable PREFIX to .iso.org.dod.internet, so my agent starts searching for the objects from this point onwards. I want to know where this value of prefix is stored( i.e from where I can extract it) in the ucd-snmp code as I want to use it elsewhere in my application. Thanks in advance jyothi |
From: Dave S. <D.T...@cs...> - 2001-03-14 10:51:58
|
[ First - *please* don't mail me directly. 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. ] > I have removed the second line, but I still have the following error-me= ssages: > = > % snmpget localhost private UCD-SNMP-TUTORIAL-MIB::ustSSSimpleString.0= = > = > Error in packet > Reason: (noSuchName) There is no such variable name in this MIB. > Failed object: enterprises.ucdavis.ucdExperimental.ucdSnmpTutorialMIB.= ustMIBObjects.ustScalarSet.ustSSSimpleString.0 Silly question - are you sure that this module has been loaded by the age= nt? Can you see a reference to this area of the MIB tree if you walk the 'UCD-SNMP-MIB::mrTable' ? > % snmpset localhost private UCD-DLMOD-MIB::dlmodStatus.1 i create = > = > Timeout: No Response from localhost Similarly, are you sure that this module has been loaded by the agent? What does the access control table setting look like? (i.e. walking 'SNMP-VIEW-BASED-ACM-MIB::vacmAccessTable' and similar tables). That will show what the active access control settings are, as opposed to what they ought to be. Dave |
From: Dave S. <D.T...@cs...> - 2001-03-14 10:40:49
|
Please see the FAQ entry: I can see the system group, but nothing else. Why? Dave |
From: Dave S. <D.T...@cs...> - 2001-03-14 10:40:05
|
> Something more than *very* strange happened. I ran > snmpd -Dutil_funcs > but there's no debugging message returned, just the error when I start snmpd > without the flag. How are you invoking the agent? I typically use the '-f' and '-L' flags, to run it in the foreground, with logging to standard output. This saves having to search around in assorted log files for debug messages. (I usually run on a non-standard port as well, since this is typically investigating someone else's problem). My standard command line is therefore somthing like ./agent/snmpd -p 9999 -f -L -Dutil_funcs Of course, you'll only get these output messages when you actually run a query. Dave |
From: Dave S. <D.T...@cs...> - 2001-03-14 10:34:54
|
> Now suppose that I'm developing a regular management > tool (using libsnmp), external do the agent. Would it be my responsibility > to check the local MIBs for my trap sinks or does it work just like you > mentioned above, automagically sending traps to all configured receivers? Sorry - the snmpNotifyTable is *only* used by the agent, for notifications that the agent itself generates. Making this information available to external applications is an idea that we've floated briefly, but as yet nothing has been done about this. Wes - it sounds as if this is likely to be worth following up, as part of the general re-design. Would you agree? Dave |
From: <car...@mi...> - 2001-03-14 03:20:14
|
I'm a new net-snmp user. when I use snmpwalk or snmpget, it appears only system's variable and no other variables such as interfaces,at,ip and so on. My system is redhat linux 6.2. why? carl. 2001-03-14 |
From: Chen B. <cb...@is...> - 2001-03-14 01:18:30
|
Hi, Dave. Something more than *very* strange happened. I ran snmpd -Dutil_funcs but there's no debugging message returned, just the error when I start snmpd without the flag. Or, I should look the debug message up somewhere? Thanks! Ben :) -----Original Message----- From: Dave Shield <D.T...@cs...> To: Chen Bensong <cb...@is...> Cc: net...@li... <net...@li...> Date: Tuesday, March 13, 2001 10:30 PM Subject: Re: getnext? >> > Are you using the 'header_generic' call in your var_xxx routine? >> >> Yes -- It was generated by mib2c, so I let the >> if(header_generic(vp, ...) == MATCH_FAILED) >> return NULL; >> remain there intact. Shall I do something on it? > >No - that's right. > >Next thing - try running 'snmpd' with the flag '-Dutil_funcs' >to turn on the debugging messages from this header_generic function. >Then issue a single GET request on the offending object. > That should display the object being requested, and the result >of the OID comparison. For example, the expected output of requests >for 'sysUpTime', 'sysUpTime.0' and 'sysUpTime.1' is: > > util_funcs: header_generic: system.sysUpTime exact=1 > util_funcs: result: -1 > util_funcs: header_generic: system.sysUpTime.0 exact=1 > util_funcs: result: 0 > util_funcs: header_generic: system.sysUpTime.1 exact=1 > util_funcs: result: 1 > > >If you get something similar, then the problem is elsewhere in >your code. But if the request for .1.3.6.1.4.1.5733.1.2.0 >gives a non-zero result, then something *very* strange is >happening. > >Dave > > >_______________________________________________ >Net-snmp-users mailing list >Net...@li... >http://lists.sourceforge.net/lists/listinfo/net-snmp-users |
From: Luis F B. <ha...@ie...> - 2001-03-13 21:53:37
|
On 13 Mar 2001, Wes Hardaker wrote: WH>Yes, the agent makes use of these tables. If you use the functions WH>defined in agent_trap.h to send your traps, it'll send a trap to all WH>the appropriate receivers listed in that mib. Oh, that's great. Now suppose that I'm developing a regular management tool (using libsnmp), external do the agent. Would it be my responsibility to check the local MIBs for my trap sinks or does it work just like you mentioned above, automagically sending traps to all configured receivers? -- Luis F Balbinot <ha...@ie...> http://cscience.org/~hades |
From: Wes H. <har...@us...> - 2001-03-13 21:08:40
|
>>>>> On Tue, 13 Mar 2001 14:35:53 +0000, Dave Shield <D.T...@cs...> said: Dave> The advice given before has been to use 'ASN_OCTET_STR' instead, Dave> at least for generating the mib module template. It's the same Dave> underlying syntax type - just interpreted in a particular way. Dave> Wes - any more up to date advice? The following patch should provide support for it (more or less at least). -- Wes Hardaker NAI Labs Network Associates |
From: Wes H. <har...@us...> - 2001-03-13 21:02:45
|
>>>>> On Tue, 13 Mar 2001 10:53:13 -0500 (EST), harko <per...@wr...> said: perlldap> sorry, I guess that was a little vague. What i'm doing is perlldap> using the perl snmp module that comes with the net-snmp perlldap> package. I'm having it query a machine on a regular basis, perlldap> and process the data. I use a getnext call to read in all perlldap> the data. The problem starts when for some reason the perlldap> getnext fails, and kills the perl program. What I want to perlldap> do is trap the error, so the program will ignore the problem perlldap> and move on, rather than stop completely. It shouldn't ever kill the perl program, so that sounds like a bug. It should timeout instead and $SNMP::ErrorStr will get set to a message saying that its a timeout problem. -- Wes Hardaker NAI Labs Network Associates |
From: Wes H. <har...@us...> - 2001-03-13 20:59:50
|
>>>>> On Sat, 10 Mar 2001 13:57:27 -0300 (BRT), Luis F Balbinot <ha...@ie...> said: Luis> Hello, I didn't have time to check all source code, so I'll put Luis> my question on the list. How does NET-SNMP handles SNMP Luis> traps/informs in the presence of the SNMP-NOTIFICATION-MIB? Does Luis> it automatically checks this table (and SNMP-TARGET-MIB too) or Luis> do I have to manually check whether my trap is accepted by the Luis> registered filters? Luis> I took a quick look at the source code and I noticed that the Luis> agent does check these tables. Yes, the agent makes use of these tables. If you use the functions defined in agent_trap.h to send your traps, it'll send a trap to all the appropriate receivers listed in that mib. -- Wes Hardaker NAI Labs Network Associates |